推理服务的可观测性：从用户体验、流式交付到 GPU 证据的完整排障闭环

推理服务的可观测性：从用户体验、流式交付到 GPU 证据的完整排障闭环

用户说“回答很慢”，工程师需要回答四个问题：慢在哪里，影响谁，有什么证据，怎么验证修复。

本文以 Kubernetes 上的流式 LLM 推理服务为主线，结合框架指标、OpenTelemetry、自定义阶段埋点、DCGM 和 eBPF，建立从用户体验到 GPU 执行的关联分析方法。适用于 vLLM 等推理框架；具体指标与参数必须以部署版本为准。文中的阈值、案例数字和容量配置均为教学示例，不代表实测结果或通用性能承诺。

这张图只展示在线请求的主路径；实际关联必须同时维护两条辅助路径：

请求路径：客户端 → Ingress/网关 → 业务/RAG → 推理引擎 → GPU/rank Metrics： 各层低基数指标 ─────────────────────────→ Prometheus/Grafana/SLO Trace： trace_id/request_id ─────────────────────→ OTel Collector/Trace Store 映射： model → Pod UID → node/worker → GPU UUID/rank → batch_id（采样追踪） 下钻： 体验告警 → model/pod 看板 → 慢请求 Trace → 短窗口 eBPF/Nsight

Prometheus 只保存有限枚举标签；request_id、trace_id、batch_id只放日志/追踪。图或映射中任何一环不存在时，禁止把节点全部 GPU 活动强行归属给单个请求。

术语与数据契约（先读本节）

若只有代理/客户端视角，面板必须叫chunk_gap，而不是 ITL。输入 token 吞吐是输入工作负载代理，前缀缓存、KV 重用和分块 Prefill 存在时不等于实际 Prefill 计算量。

一、用户的一句“慢”，可能是四类不同的问题

上线了流式推理接口，GPU 利用率在 90% 左右，输出吞吐也很高，但用户仍在投诉。原因可能完全不同：

• 请求发出后几秒没有内容：首个有效输出晚，优先检查网关、业务前置处理、排队和 Prefill。
• 很快开始回答，但持续生成很慢：检查 Decode 调度、活跃序列、KV Cache、计算、访存和通信。
• 回答一阵后突然停顿，再一次性出现大量文字：检查流式缓冲、客户端读取、批量输出、调度中断和抢占。
• 每个 token 都正常，但整段回答耗时很长：可能只是输出长度变大，不能直接认定模型变慢。

因此，第一步不是加卡，而是把“慢”转化为明确的测量口径。可观测性建设的顺序也应如此：先量化体验，再拆解阶段，最后用硬件证据解释原因。

二、先统一指标口径：TTFT、TPOT、ITL 不是同一件事

2.1 为每个测量位置定义时间点

在客户端或网关的一次请求观测中，定义：

“有效输出”要写入接口契约：角色信息、SSE 心跳、空 delta 不计入；如果产品隐藏思考内容，需要同时记录“首个模型输出”和“首个用户可见内容”。只有后者直接解释用户为什么迟迟看不到回答。

同一个指标必须带测量位置：客户端 TTFT、网关 TTFT、引擎 TTFT 的起止点不同，数值不能直接比较。非流式接口收到完整响应前通常看不到首个 token，不能拿首字节时间冒充流式 TTFT。

2.2 指标定义与使用场景

对同一测量位置、同一输出 token 口径：

tN − t0 = TTFT + TPOT × (N − 1)

若 E2E 定义到完成标记，还应加上tend − tN。N 为 0 或 1 时，TPOT 不定义，不能填 0 混入延迟直方图。失败、取消和没有输出的请求单独统计结果与耗时，避免只看成功样本。

例如：首个输出等待 0.8 秒，200 个输出 token 的平均 TPOT 为 0.04 秒，则生成跨度为0.8 + 199 × 0.04 = 8.76 秒。其中约 25 token/s 是这条请求的速度，不能用集群的 5,000 token/s 来替代。

2.3 chunk 不是 token，TPOT 分位数也不是 ITL 分位数

SSE 的一个内容事件可以包含多个 token。一次网络读取还可能包含多个 SSE 事件；token 的文本片段也不能通过“字符数”准确反推 token 数。推测解码、输出合并与代理缓冲都可能进一步改变到达形态。

因此建议保留两套统计：

1. 请求级平均 TPOT：每个完成请求产生一个样本，适合比较请求体验。
2. 输出事件间隔：每个间隔产生一个样本，适合发现停顿；面板必须标清 token gap 还是 chunk gap。

长请求贡献更多间隔样本。ITL P99 与请求 TPOT P99 权重不同，不能互换。vLLM 当前文档也区分了输出事件间隔与请求级 TPOT，旧版指标名和语义可能不同。[1][2]

2.4 分位数之前，先控制工作负载差异

至少按模型版本、输入长度档、输出长度档、业务优先级和副本查看分布。常见误判是：模型没有退化，只是输入从短问答变成了长上下文 RAG。

长度档使用有限枚举，例如0–1k / 1k–4k / 4k–16k / >16k；档位应与业务匹配。不要把精确 token 长度、用户 ID 或 request_id 放到 Prometheus 标签中。

还要记住三条统计边界：

• 不能平均多个副本的 P99；应合并相同桶边界的 Histogram，再计算分位数。
• P99(TTFT) − P99(queue)不是 Prefill P99。
• P99(TTFT) + P99(decode)不是 E2E P99。分位数对应的可能是不同请求。

三、把请求拆开：找到首字之前和生成之中的等待

3.1 建立阶段契约，而不是画一张含糊的耗时图

对单个请求，建议记录以下阶段。名字可以自定义，起止事件必须固定。

连续批处理、分块 Prefill、Prefill/Decode 分离和抢占会让阶段反复发生。此时记录事件与区间：入队、调度、暂停、恢复、首次输出、最后输出，而不是假定每个请求只有一次完整 Prefill 和一次连续 Decode。

请求生命周期时长也不等于该请求独占的 GPU 时间。多条请求共用一个 batch，一次 GPU 执行可能同时推进多个请求。若需要归因，可在采样追踪中记录 batch_id、调度步与参与请求，使用 span link 或事件关联；不要把整个 batch 的 GPU 时长重复相加后当成集群总耗时。

3.2 如何解释客户端与服务端的差值

同一请求的客户端 TTFT 明显高于服务端 TTFT，说明额外耗时存在于引擎测量范围之外，可能包含连接建立、网关、业务前置、转发缓冲、网络和客户端调度。

这个差值是缩小范围的线索，不能直接命名为“网络延迟”。下一步对比网关收到后端首内容、网关写出首内容、客户端读取首内容的事件，再检查连接与缓冲。

用单调时钟测本进程耗时，用同步后的墙钟关联不同主机的时间线。不要直接拿不同机器的单调时间戳相减；时钟偏差也会影响跨主机事件排序。

四、分层采集：每种工具负责一种证据