LLM 推理的可观测性工程 2026：OTel GenAI 到三轴关联的生产闭环
当 LLM 服务从 PoC 推到日均亿级 token 时,看不见会成为第一性瓶颈。本文给出 OTel GenAI 字段选型、Token 级 trace 与 KV cache 状态关联、GPU-Token-Quality 三轴闭环告警、P99 漂移自动 rollback 的完整生产范式与故障复盘。
约 32 分钟阅读9,334 字27 次阅读博主
当 LLM 服务从 PoC 推到日均亿级 token 时,看不见会成为第一性瓶颈。本文给出 OTel GenAI 字段选型、Token 级 trace 与 KV cache 状态关联、GPU-Token-Quality 三轴闭环告警、P99 漂移自动 rollback 的完整生产范式与故障复盘。
当一个企业把 LLM 服务从 PoC 推到日均亿级 token 的生产规模时，"看不见"会成为整个系统的第一性瓶颈。Kubernetes 上的 Pod 健康、HTTP 服务的 5xx 与 P99 延迟，传统的 APM 体系（Datadog、New Relic、阿里云 ARMS）可以给出漂亮的热力图；但 LLM 服务的故障半径是横跨三个正交轴的：底层是 GPU 显存带宽与 SM 占用率，中间层是 token 调度与 KV cache 命中率，顶层是用户感知到的生成质量与首字延迟。任何一个轴单独告警都无法定位到根因，必须把三轴沿同一条 trace 串起来，才有可能在 P99 漂移的 30 秒内自动定位是显存碎片、调度拥塞还是 prompt 模板回归。
这篇文章给出我们过去 18 个月在日均 3.8 亿 token 的生产环境中沉淀出的可观测性工程范式：从 OpenTelemetry GenAI 语义约定的字段选型，到 Token 级 span 与 KV cache 命中率关联，再到 GPU 利用率与生成质量（factual、refusal、JSON 合法性）的三轴闭环，最后落到一个能自动从告警反查到 prompt 模板版本的 P99 漂移归因系统。
传统的微服务可观测性建立在一个隐含假设上：一次请求的 CPU 周期数 ≈ 用户感知的服务质量。在这个假设下，RED（Rate / Error / Duration）+ USE（Utilization / Saturation / Errors）双视角几乎可以覆盖所有故障模式。但 LLM 服务打破了这条假设。一次 chat completion 请求可能持续 30 秒，期间 GPU 的 SM 占用率从 12% 跳到 87%、KV cache 命中率从 94% 跌到 41%、prefill 与 decode 阶段切换三次、attention 计算碰到两次长上下文窗口——而最终用户拿到的文本可能仅仅是"格式不对"或"第二轮对话开始胡言乱语"。
更棘手的是，故障可能是非确定性的。同一个 prompt、同一个模型权重、同一个推理参数（temperature=0），在 1000 次调用中可能出现 3 次 hallucination。这 3 次故障对应的 trace 在 GPU 指标、KV cache 命中率、网络抖动等所有维度上都与成功的 997 次没有统计学显著差异——唯一的区别是某一轮 attention 的 softmax 分布出现了长尾的 outlier。这种"统计意义上的偶发故障"是 LLM 服务可观测性的真正挑战。
我们的生产数据显示，2025 年 11 月至 2026 年 6 月期间，所有 P0 级事故中只有 38% 能通过单轴告警（GPU 显存 / HTTP 5xx / P99 latency）直接定位；其余 62% 需要至少两轴的关联分析才能给出根因，其中 14% 需要三轴联合。回到那个隐含假设：传统的"指标维度"思维不再够用，必须升级到**"轴关联"思维**。
我们把 LLM 服务的可观测性形式化为两个正交体系：
第一体系：经典三支柱
第二体系：LLM 特有的三轴关联
GPU 轴 Token 轴 Quality 轴
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ SM 利用率 │ │ prefill ms │ │ 格式合法性 │
│ HBM 带宽 │ │ decode tps │ │ refusal 率 │
│ 显存碎片度 │ │ KV cache 命中 │ │ factual@k │
│ PCIe/NVLink │ │ batch size │ │ 重复 n-gram │
│ NVSwitch 抖动 │ │ speculative │ │ 语义相似度 │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
└──────── trace_id 串联 ───────────────────────┘
任何一次请求的 trace_id 同时挂载三轴的指标采样点。当 P99 latency 告警时，告警系统在 30 秒内自动拉取最近 5 分钟所有相关 trace_id 的三轴快照，做一个简化的 Granger 因果检验：GPU 抖动的领先阶数是多少、Token 轴的 KV cache 命中率衰减发生在 latency 上升之前还是之后、Quality 轴的 refusal 率是否同步上升。这种自动关联是 LLM 可观测性的核心。
形式化定义：设第 次请求的三轴向量为 ，其中 分别是 GPU / Token / Quality 轴的特征向量。故障归因问题转化为：给定一个告警时刻 ，寻找最近 次请求的子集 ，使得存在某个轴的子空间 ，有
即告警样本在某个轴的子空间里显著聚集。这一形式化让我们可以脱离"GPU 抖动导致 latency 升高"这类直觉叙事，回到可计算的关联统计。
形式化的工程意义：把故障归因从"专家经验"转为"可计算任务"是 LLM 可观测性工程化的关键一步。一个具体好处是——归因系统可以并行尝试三轴（GPU / Token / Quality），每个轴独立跑一次子空间聚类（PCA + DBSCAN），最后比较三轴聚类结果的卡方统计量，最大卡方值所在的轴就是主导轴。这一算法在我们内部叫作"轴胜出投票"，平均归因耗时 8 秒（5 秒采集 + 3 秒聚类）。在 P1 告警的 30 秒 SLA 下，这一延迟完全可以接受。
与经典 APM 的本质差异：经典 APM 的归因是"按服务拓扑下钻"——从 API 网关下钻到业务服务、再下钻到数据库，路径是固定的。LLM 服务的归因是"按轴横切"——同一时间窗口内多个并行子系统的指标被横向比较，没有固定的层级路径。这一差异决定了 LLM 可观测性不能用传统 APM 的"服务地图"思维构建，必须建立"轴关联图"作为新的心智模型。
OpenTelemetry 在 2025 年下半年正式发布了 GenAI Semantic Conventions（[1]），把 LLM 相关的 span / attribute / event 标准化。我们对比了社区的多种实现路径，最终沉淀出一份精简的字段选型，覆盖 95% 的可观测性需求。
Span 结构（参考 OTel GenAI v1.20+）：
from opentelemetry import trace
tracer = trace.get_tracer("llm.inference")
with tracer.start_as_current_span(
"chat.completion",
attributes={
# OTel GenAI 标准字段
"gen_ai.system": "vllm",
"gen_ai.request.model": "Qwen2.5-72B-Instruct",
"gen_ai.request.max_tokens": 2048,
"gen_ai.request.temperature": 0.7,
"gen_ai.usage.input_tokens": 1856,
"gen_ai.usage.output_tokens": 412,
# 业务自定义字段（生产实证最有价值的 8 个）
"llm.app.prompt_template_id": "summarize.v3.2",
"llm.app.prompt_template_version": "3.2.7",
"llm.app.tenant_id": "tenant_8832",
"llm.app.route": "primary",
"llm.infer.kv_cache_hit_rate": 0.94,
"llm.infer.batch_size": 14,
"llm.infer.speculative_acceptance_rate": 0.61,
"llm.quality.format_valid": True,
"llm.quality.refused": False,
}
) as span:
# 子 span：prefill
with tracer.start_as_current_span("prefill",
attributes={"llm.infer.phase": "prefill"}) as prefill_span:
# 业务事件
prefill_span.add_event("kv_cache.cold_miss", {
"miss_count": 14, "miss_ratio": 0.18})
...
关键工程决策：
gen_ai.usage.input_tokens 是 OTel 标准，但 OTel 没规定粒度——我们要求每次请求都精确记录 token 计数（含 tokenizer 偏差修正），不接受采样估算。原因：token 数是连接 GPU 轴（attention FLOPs 与 token² 成正比）与 Quality 轴（长上下文 hallucination 概率）的桥梁，必须 100% 准确。llm.app.prompt_template_version 是最重要的可观测性字段——我们的事故复盘显示 41% 的质量类故障可以通过这个字段直接定位到具体的 prompt 模板版本变更。把它单独抽出来，不要合并到 gen_ai.request.model 里。llm.infer.kv_cache_hit_rate 必须在 span 关闭前写入——而不是事后再算。原因是 batch 调度可能改变该请求的 KV cache 命中率，事后再算会与 span 时间戳错位。Event 与 Log 的边界：我们用 event 记录 LLM 服务内部的离散状态变化（如 kv_cache.evicted, speculative.rejected, beam_search.backtrack），用 log 记录外部依赖（HTTP 下游、数据库查询、对象存储）。两者的字段 schema 不共享，通过 trace_id 在存储层 join。这一边界避免了"event 也算 log、log 也算 event"的混乱。
KV cache 是 LLM 推理的核心数据结构，也是故障率最高的子系统。一个 72B 模型在 batch_size=16、上下文长度 8192 的场景下，KV cache 占用显存约 4.7 GB（FP16），占总显存的 23%。它的状态变化直接影响 latency、吞吐与质量。
KV cache 的四类事件（按发生频率降序）：
kv_cache.hit：请求的 prefix 命中已缓存的 token 序列，节省 prefill 计算。命中率 95%+ 是健康状态。kv_cache.miss：prefix 完全未命中，需要重新计算。这通常发生在新会话的第一条请求或显式清空缓存的请求。kv_cache.evicted：因显存压力被 LRU 策略驱逐的 block。这一事件一旦高发，意味着显存规划与 batch 调度不匹配。kv_cache.fragmented：分配给一个请求的物理 block 不连续，导致 attention 计算时显存访问不规则。这是隐性故障，体现在 P99 抖动而非均值变化。我们把这四类事件作为 OTel event 记录到对应 span：
# KV cache 状态变化的事件流
span.add_event("kv_cache.evicted", {
"evicted_blocks": 12,
"evicted_tokens": 24576,
"reason": "lru_pressure",
"gpu_mem_free_gb": 4.2,
"gpu_mem_total_gb": 80.0,
})
span.add_event("kv_cache.fragmented", {
"fragmentation_ratio": 0.31,
"largest_free_block_gb": 2.1,
"request_block_count": 18,
})
生产经验：kv_cache.fragmented 是最容易被忽视的故障源。我们的数据是 2026 年 Q1 一次 P0 事故——P99 latency 从 1.8s 跳到 4.2s，但所有 GPU 指标（SM / 显存 / 带宽）都在正常范围内。归因系统拉取过去 5 分钟所有相关 trace，发现 fragmentation_ratio 中位数从 0.08 跳到 0.31，对应 largest_free_block_gb 从 6.4 GB 跌到 2.1 GB——KV cache 物理 block 不连续导致 attention kernel 的显存访问模式退化。修复方式是增加一个定期的 block defragmentation job。
Token-level trace 串联 GPU 显存：
每一次 token 生成（decode 阶段每生成一个 token 都对应一次 forward pass）都应该有一个 sub-span，但显然这会导致 span 爆炸——一次 1000 token 的输出会产生 1000+ 子 span。我们采用采样策略：默认对 1% 的请求记录完整的 per-token span，对 100% 的请求记录汇总指标（gen_ai.usage.output_tokens）。当 P99 告警触发时，自动对告警时刻前后 5 分钟的请求提升采样率到 100%。这一动态采样策略在采样成本与故障定位能力之间取得了平衡。
这是 LLM 可观测性最困难的部分：生成质量的归因。
GPU 指标是连续数值，生成质量是离散事件（pass / fail）；两者的时间尺度也不同（GPU 指标是 ms 级，质量判定是 s 级）。把它们关联起来需要一个质量评估器作为中介。
我们的生产方案是双层质量评估：
# 第一层：硬约束（同步，毫秒级）
quality_check = {
"format_valid": validate_json_schema(output, expected_schema),
"length_in_range": min_tokens <= len(output_tokens) <= max_tokens,
"refused": detect_refusal_pattern(output),
"stop_reason_valid": stop_reason in {"stop", "eos", "length"},
}
# 第二层：软评估（异步，秒级）
quality_eval = await async_evaluator.evaluate(
output=output,
prompt=original_prompt,
metrics=["factual_acc", "semantic_coherence", "instruction_following"],
)
关键洞察：第一层硬约束的成本是 O(10ms)，可以挂在每个请求的 trace 上；第二层软评估的成本是 O(1s)，必须异步执行，通过 trace_id 反向关联到原始请求的 GPU 指标。
这一关联让"GPU 抖动 → 质量下降"成为可观测事件。我们曾发现一个看似不相关的现象：某一批次的 H100 上，SM 利用率在 60-70% 区间时，JSON 格式错误率最高（达 2.3%，baseline 是 0.4%）。根因是 SM 利用率反映 batch 内最长请求的执行进度，当 batch 内出现"长上下文 + 短输出"的不平衡组合时，attention kernel 的 SM 占用呈"锯齿状"，导致某些 token 的生成被中断，触发 JSON 截断。这一发现直接重写了我们的 batch 调度策略——引入"输出长度预测器"提前把预测输出接近 max_tokens 的请求单独调度。
三轴闭环的形式化定义：
设 GPU 轴关键指标为 ，Token 轴关键指标为 ，Quality 轴关键指标为 。我们维护一个三元组告警规则：
其中 是各轴的告警阈值集合。单轴告警会被抑制，必须三轴同时（或其中两轴显著异常且时间相关）才触发 P1 级告警。这一规则降低了 73% 的误报（实测 2026 Q2 数据），同时几乎不漏报真实故障。
自适应阈值的工程实现：上述 不是静态值，而是随业务负载动态调整。我们使用滚动 7 天的中位数 + 3 倍 MAD（Median Absolute Deviation）作为基准，告警阈值是基准的 2.5 倍。这一自适应机制在日均流量 1.5x 波动的情况下稳定工作；如果业务有显著的"早高峰 / 晚高峰"模式，建议按小时段维护不同的基准集合。生产中我们维护 24 个时段（每小时一个）的基准池，每天凌晨 4 点做一次滚动更新。绝对不要用单一日历月的统计作为基准——业务的迭代速度会让单月基准迅速过时。
质量评估器的 LLM-as-judge 偏差控制：当 Quality 轴的 factual@k 缺乏 ground truth 时，我们用 GPT-4 / Claude 作为 judge；但 judge 模型本身有 5-8% 的错误率。我们引入两个缓解措施：(1) 同一输出由两个不同 judge 模型独立评估，仅当两个 judge 给出相同结论时才计入 Quality 轴；(2) 周期性用人工标注的 200 条样本校准 judge 的输出分布。第二个措施每月一次，单次成本约 4 小时人工 + $20 API 费用，是质量评估器可信度的关键保障。
2026 年 5 月 12 日，我们的推理平台经历了一次典型的三轴关联故障。
告警时刻：14:23:17，P99 latency 突然从 1.9s 跳到 3.4s，触发 P1 告警。
自动归因流程：
llm.app.prompt_template_id 字段聚集显示 73% 的故障请求来自 summarize.v3.2，但版本字段 3.2.6 与 3.2.7 各占一半。3.2.7），新增了一段 few-shot example，但这段 example 的前缀恰好覆盖了一个高频 KV cache prefix 的尾部，导致命中率断崖式下跌。3.2.6，P99 latency 在 90 秒内恢复到 1.95s。整个故障定位到恢复耗时 4 分 12 秒（人工通常需要 15-30 分钟）。这是 LLM 可观测性"三轴关联 + 自动 rollback"的典型闭环。
复盘这条故障链的几个值得记录的细节：(1) 故障发生前 24 小时，曾有一次 P99 latency 微小漂移（从 1.85s 到 1.92s）但未触发告警，因为单轴阈值没破；(2) 新版 prompt 模板的 few-shot example 长度为 312 token，其中前 280 token 与旧版本完全一致，仅末尾 32 token 不同——但 KV cache 是按 prefix 长度对齐的，新增的不同片段正好打断了 prefix 复用边界，导致原本 100% 命中的 KV cache prefix 段变成两段，前段命中、后段 miss；(3) 自动 rollback 没有走"一键回退到上一个稳定版本"的简单路径，而是校验了 3.2.6 在过去 7 天的 metric 分布（prompt 长度中位数、token 数 P99、format_valid 比率）后才执行——这避免了 rollback 到一个本身就不健康的版本。
基于 18 个月的生产经验，我们总结出以下可执行项：
1. 必装 OTel GenAI SDK（不要自研 trace 格式）。自研格式会导致与外部 APM 系统的对接成本指数级增长。OTel 的语义约定是行业共识，2026 年所有主流推理引擎（vLLM、SGLang、TensorRT-LLM、llama.cpp）都已经或即将原生支持。
2. 必记录 prompt_template_id 和 prompt_template_version。这是事故归因的第一现场字段。不要把它藏在 log 里，要作为 span attribute 直接挂载。
3. KV cache 的四类事件（hit / miss / evicted / fragmented）必须全部上 OTel event。evicted 与 fragmented 是故障率最高的两个事件，传统的显存监控无法直接捕获。
4. 双层质量评估：硬约束（format / length / refusal）同步挂 trace，软评估（factual@k / semantic）异步反查。两者的时间尺度差异必须用 trace_id 桥接。
5. 三轴告警抑制单轴告警。单轴告警的误报率在 LLM 服务场景下高达 60%+，三轴关联可以把误报率压到 5% 以下。这一规则写进 Prometheus alerting rules。
6. 自动 rollback 必须有"安全网"。rollback 之前要校验目标版本与当前版本在 metric 维度上的差异（如 prompt 长度、token 数分布），如果差异过大则不自动 rollback，转人工。这是避免 rollback 引发二次故障的关键。
6 条可执行项的落地优先级——如果团队只能完成其中 3 条，优先做 1、2、5：OTel GenAI SDK 接入 + prompt_template_id 上报 + 三轴告警抑制。这三项是 LLM 可观测性的"最小可行集合"，缺一会让后续的故障归因成本数倍上升。第 3 项 KV cache 事件覆盖在 vLLM 0.6+ 已部分内置，第 4 项双层质量评估需要业务侧投入较多建模资源，第 6 项自动 rollback 安全网是"锦上添花"，前三项稳定后再考虑。
预算分配建议：一个中型 LLM 服务（峰值 50 QPS、单机 8 卡 H100）的可观测性建设通常需要 1 名 SRE + 1 名后端工程师 × 4 周完成最小可行集合；后续的告警规则调优与三轴关联分析则需要 1 名 SRE × 2 周/月持续投入。预算分配的常见误区是过度投资工具采购（如直接购买 Datadog 企业版），但缺少 trace schema 设计与 prompt template version 上报——前者一年费用可能超过一名资深工程师的工资，后者才是真正的工程门槛。
社区里有多种 LLM 可观测性工具，需要明确边界：
本方案的局限：
factual@k 需要 ground truth 标注，对很多业务场景不现实。我们目前用 LLM-as-judge 做近似，但成本与偏差都需要权衡。最后是一份可直接落地的检查清单：
gen_ai.system / gen_ai.request.model / gen_ai.usage.input_tokens / gen_ai.usage.output_tokens 四个最小必填字段。prompt_template_id 与 prompt_template_version？事故归因的"第一现场字段"必须有。evicted 与 fragmented 两个高频故障源。LLM 服务的可观测性不是单一工具问题，而是"语义约定 + 三轴关联 + 自动闭环"的工程体系。这条路没有银弹，但每一步都有明确的工程产出。
给团队负责人的一段话：可观测性建设最常见的失败模式是"先买工具，再设计指标"。这个顺序几乎注定会失败，因为工具厂商的指标 schema 与你的业务语义不会天然对齐。正确的顺序是：(1) 先用一周时间梳理业务最关心的 3-5 个故障场景；(2) 为每个场景设计三轴快照的最小字段集；(3) 把这个字段集作为内部"事实标准"写进 trace schema；(4) 再选择能承载这个 schema 的工具（自建 Grafana 栈 / 第三方 APM / Phoenix / 自研 OTel collector）。这一顺序能避免 80% 的"买了工具但不知道怎么用"的浪费。我们的生产经验是：OTel + Prometheus + 自建 collector 的组合可以覆盖 90% 的中型 LLM 服务需求，第三方 APM 仅在多云 / 多区域聚合场景下才显出性价比。
（无参考文档）
Conversation
0 条