1. 为什么传统 APM 看不透 LLM 推理延迟从请求级到 Token 级的监控盲区大模型推理的延迟结构和普通 HTTP 接口完全不是一回事。一个 Chat Completion 请求从发出到结束中间至少经历四个阶段请求排队、Prompt 编码Prefill、Token 逐个生成Decode、网络回传。其中 Decode 阶段的耗时和输出 Token 数几乎成正比在长文本生成场景里能占到总延迟的 80% 以上。传统 APM 只记录一个请求总耗时你看到 P99 从 2 秒涨到 8 秒但根本分不清是排队变长了、Prefill 卡住了还是 Decode 每步都慢了。流式响应SSE把这个盲区放得更大。用户感知的延迟其实是两个指标首 Token 延迟TTFTTime To First Token决定他等多久看到第一个字Token 间延迟ITLInter-Token Latency决定后面“打字”顺不顺。传统 APM 的请求级指标压根捕获不到这些 Token 级别的特征因为请求还没结束指标就没法落库。我试过在一个日调用量几十万的推理服务上只挂通用 APM结果一次 GPU 显存打满导致的 ITL 抖动整整两天没人发现——因为端到端延迟被大量短请求稀释了均值看着正常但尾部用户体验已经崩了。这就是为什么 LLM 推理延迟监控必须从 Token 级指标起步再串联网关、模型服务和调用端做成全链路可观测性。这篇面向的是正在把大模型接进生产环境的后端或平台工程师尤其是用统一 Key 通道比如 TaoToken管理多模型调用的团队。下面会给出可复制的指标采集配置、统一 Key 接入示例以及延迟异常时的验证动作帮你把 TTFT 和吞吐瓶颈定位到具体环节。2. TaoToken 统一 Key 接入为全链路可观测性铺好数据通道做全链路可观测性第一步不是上 Prometheus而是让所有模型调用走同一条可观测的通道。如果团队里每个人各自申请 Key、各自直连不同厂商延迟数据就散落在十几个地方根本没法做统一归因。TaoToken 在这里的角色是统一 Key 和 API 通道你用一个 Key 调用多个模型所有请求都经过同一个入口指标采集点自然就统一了。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 。注意 API 地址不带 UTM 参数配置时别把推广参数拼进去否则部分 SDK 会把它当成路径的一部分导致 404。统一 Key 对监控的价值体现在三个层面。第一调用端只需要维护一套鉴权和重试逻辑埋点代码写一次就能覆盖所有模型。第二网关层可以统一记录请求级指标端到端延迟、成功率、并发数不用在每个厂商 SDK 里各写一遍。第三模型切换时监控口径不变你可以直接对比 GPT 系列和 Claude 系列在同一个业务场景下的 TTFT 分布而不是被不同的采集方式干扰。接入前你需要准备三样东西一个 TaoToken API Key、确认要调用的模型 ID、以及调用端的 Base URL 配置。Key 在控制台的 API Keys 页面生成模型 ID 在模型对话页面能看到当前可用的列表。如果你用的是 Claude Code 这类编码工具还需要额外配置 Anthropic 兼容的 Base URL这个在接入文档里有说明。这里要提醒一个常见误区统一 Key 不是让你把所有请求都塞到一个模型上。它的意义是统一入口和统一观测模型选择仍然按业务来。监控系统里应该按 model 这个 label 做分组这样你既能看整体健康度也能下钻到单个模型的延迟特征。3. 可复制配置Token 级指标采集与统一 Key 接入片段这一节给出可以直接抄的配置。先解决接入再解决采集。3.1 统一 Key 的客户端配置JSON / TOML / settings如果你用 OpenAI 兼容的 SDK配置长这样。把这段存成llm_client_config.json调用端读取即可{ base_url: https://taotoken.net/api, api_key: sk-你的TaoTokenKey, default_model: claude-sonnet-4-20250514, timeout_seconds: 120, max_retries: 2, stream: true }如果你用 Claude Code 或类似的 Anthropic 协议工具配置走settings.json关键是 Base URL 要指向 Anthropic 兼容端点Key 和 Model ID 三件套缺一不可{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoTokenKey, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }用 Codex 的话认证信息写在auth.json里Base URL 同样指向统一入口{ base_url: https://taotoken.net/api, api_key: sk-你的TaoTokenKey, model: gpt-4o }三件套记牢Base URL 用https://taotoken.net/apiKey 用控制台生成的Model ID 用模型对话页面确认过的。任何一处写错后面指标全是 401监控也就无从谈起。3.2 Token 级指标采集Python 版可直接跑下面这段用 Python 实现流式响应的 TTFT 和 ITL 采集指标通过 Prometheus client 暴露。为什么用 Python 而不是 Java大多数做 LLM 接入的团队调用端是 Python采集逻辑贴近调用端能减少一次跨进程传递。import time from prometheus_client import Histogram, Counter, start_http_server from openai import OpenAI TTFT Histogram( llm_ttft_seconds, 首 Token 延迟, [model], buckets[0.1, 0.3, 0.5, 1, 2, 5, 10, 30] ) ITL Histogram( llm_itl_seconds, Token 间延迟, [model], buckets[0.005, 0.01, 0.02, 0.05, 0.1, 0.5] ) TOKENS Counter(llm_tokens_total, Token 总消耗, [model, direction]) client OpenAI( base_urlhttps://taotoken.net/api, api_keysk-你的TaoTokenKey ) def stream_with_metrics(prompt: str, model: str): start time.perf_counter() first_token_at None last_token_at None stream client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], streamTrue ) for chunk in stream: now time.perf_counter() delta chunk.choices[0].delta.content if chunk.choices else None if delta: if first_token_at is None: first_token_at now TTFT.labels(modelmodel).observe(now - start) else: ITL.labels(modelmodel).observe(now - last_token_at) last_token_at now TOKENS.labels(modelmodel, directionoutput).inc() return first_token_at - start if first_token_at else None if __name__ __main__: start_http_server(8000) stream_with_metrics(用一句话解释什么是 KV Cache, claude-sonnet-4-20250514)这段代码的关键点TTFT 只在第一个有内容的 chunk 到达时记录一次ITL 记录相邻两个内容 chunk 的间隔。注意要过滤掉delta.content为空的 chunk因为有些实现会先推一个 role 声明那不是真正的首 Token。3.3 网关层请求级指标Nginx / OpenResty 片段调用端采集 Token 级指标网关层采集请求级指标两边通过 trace_id 关联。下面是一段 OpenResty 配置记录端到端延迟和状态码log_by_lua_block { local latency tonumber(ngx.var.request_time) * 1000 local model ngx.var.arg_model or unknown local status ngx.var.status local trace_id ngx.var.http_x_trace_id or ngx.var.request_id local prometheus require(prometheus).init(llm_gateway_metrics) local request_latency prometheus:histogram( llm_gateway_request_latency_ms, 网关请求延迟, {model, status}, {0.1, 0.5, 1, 2, 5, 10, 30, 60} ) request_latency:observe(latency, {model, status}) ngx.log(ngx.INFO, trace_id, trace_id, model, model, latency_ms, latency, status, status) }网关层不需要知道 Token 细节它只负责把请求级延迟和 trace_id 打出来。Token 级指标由调用端上报两边用 trace_id 在日志系统里对齐就能还原一个请求从进网关到最后一个 Token 的完整时间线。4. 验证请求与成功结果确认指标真的在动配置写完不验证等于没配。这一节给出具体的验证动作和预期结果。4.1 先验证统一 Key 通道能通用 curl 打一个最小请求确认 Base URL 和 Key 没问题curl -s -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoTokenKey \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 回复 OK 两个字母}], stream: false }预期返回里能看到choices[0].message.content包含内容usage字段有 prompt_tokens 和 completion_tokens。如果返回 401说明 Key 或 Base URL 有问题如果返回 404检查是不是把 UTM 参数拼进了 API 路径。4.2 再验证 Token 级指标在动跑 3.2 的 Python 脚本然后另开一个终端查指标curl -s http://localhost:8000/metrics | grep llm_预期能看到类似输出llm_ttft_seconds_bucket{modelclaude-sonnet-4-20250514,le0.5} 1.0 llm_ttft_seconds_bucket{modelclaude-sonnet-4-20250514,le1.0} 1.0 llm_ttft_seconds_count{modelclaude-sonnet-4-20250514} 1.0 llm_itl_seconds_count{modelclaude-sonnet-4-20250514} 23.0 llm_tokens_total{modelclaude-sonnet-4-20250514,directionoutput} 24.0llm_ttft_seconds_count是 1说明首 Token 延迟记录了一次llm_itl_seconds_count是 23说明后面 23 个 Token 间隔都记上了llm_tokens_total是 24和 ITL 次数加一吻合。三个数字对得上采集逻辑就是对的。4.3 最后验证延迟异常能被捕捉人为制造一次长 Prompt观察 TTFT 是否明显升高long_prompt 请逐字解释以下概念 KV Cache * 2000 stream_with_metrics(long_prompt, claude-sonnet-4-20250514)再查指标llm_ttft_seconds_bucket在 2 秒以上的桶应该开始有计数。如果 TTFT 没变化说明你的采集点可能记在了错误的位置比如把第一个空 chunk 当成了首 Token。成功的结果是TTFT 随 Prompt 长度上升ITL 保持相对稳定Token 总数和输出长度一致。这三条同时成立你的 Token 级监控就算立住了。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth接入和采集过程中最容易撞的几类报错这里逐个对照。401 Unauthorized。最常见的原因是 Key 写错或 Base URL 不对。检查三件套Base URL 必须是https://taotoken.net/apiKey 必须是控制台生成的完整字符串Model ID 必须是模型对话页面确认过的。如果 Key 里带了空格或换行也会 401。还有一种情况是环境变量没生效比如ANTHROPIC_API_KEY设了但进程没读到用echo $ANTHROPIC_API_KEY确认一下。local proxy failed。这个报错通常出现在调用端配置了本地代理但代理没起来或者代理地址写成了127.0.0.1:7890但端口不对。排查顺序先确认调用端有没有设置HTTP_PROXY/HTTPS_PROXY环境变量如果有但代理服务没运行直接 unset 掉再试。如果确实需要走代理确认代理进程在监听对应端口。注意不要在生产环境依赖不稳定的本地代理统一 Key 通道本身就是为了减少这类中间环节。reading choices 相关报错。典型信息是KeyError: choices或list index out of range。这通常发生在流式响应里某个 chunk 的choices是空数组。原因可能是模型返回了 usage 统计块或者触发了内容过滤。修复方式是在解析前加判断if not chunk.choices: continue delta chunk.choices[0].delta.content另外如果用的是非流式请求但代码按流式解析也会报这个错。确认streamTrue和解析逻辑匹配。OAuth 相关报错。如果你用 Claude Code 或 Codex 这类工具它们可能默认走 OAuth 登录流程。当你切换到统一 Key 接入时需要把认证方式从 OAuth 改成 API Key。Claude Code 里检查settings.json的env段是否设置了ANTHROPIC_API_KEYCodex 里检查auth.json的api_key字段。如果两个都配了工具可能优先走 OAuth导致 Key 不生效。清掉 OAuth 缓存或显式指定用 Key 认证。指标采集相关的坑。TTFT 记成了 0通常是因为把请求发出时间当成了开始时间但实际应该从收到第一个内容 chunk 算起。ITL 出现负值说明时间戳用了不同时钟源统一用time.perf_counter()。指标基数爆炸是因为给 ITL 加了太多 label建议只按 model 分组详细维度走 trace。排查时记住一个原则先确认请求能通curl 验证再确认指标在动查 /metrics最后确认异常能捕捉长 Prompt 测试。三步都过监控链路就是完整的。6. 把监控接进日常从指标到告警的落地建议指标采集起来只是第一步真正有用的是让它进入日常告警和排障流程。这里给几条实操建议。TTFT 和 ITL 的告警阈值不要拍脑袋定。先跑一周基线看 P50 和 P99 的实际分布再把告警线设在 P99 的 1.5 倍左右。比如基线 TTFT P99 是 2 秒告警线设 3 秒持续 3 分钟触发。这样既不会误报也能在用户体验明显劣化前发现。告警要带上下文。光说“TTFT P99 超过 3 秒”没用要带上 model、当前并发数、最近的 Prompt 长度分布。这些信息在排障时能直接指向根因如果并发数高且 Prompt 长大概率是 Prefill 资源竞争如果并发不高但 ITL 也涨了可能是 Decode 阶段的 batch 配置有问题。Trace 采样要分层。正常请求只记摘要TTFT、ITL 均值、Token 数异常请求记全量每个 Token 的时间戳。这样存储成本可控排障时又有足够细节。判断异常的标准就是告警阈值超过阈值的请求自动打上详细 trace 标记。最后把监控指标和业务指标对齐。TTFT 影响的是用户首次看到内容的时间ITL 影响的是阅读流畅度这两个指标应该和你的业务转化率、用户停留时长放在同一个看板上。技术指标只有和业务结果挂钩才能推动团队真正去优化它。如果你还没开始接入建议先从统一 Key 通道走起把调用入口收敛到一个地方再逐步补上 Token 级采集和告警。接入文档和 API Keys 在控制台都能找到模型对话页面可以快速验证通道是否正常。长期做编码和 Agent 场景的话Coding Plan 能帮你把多模型的调用配额和监控统一管理起来。