监控与可观测性

LLM 服务监控分三层: ① 系统级指标——延迟(P50/P95/P99)、吞吐(QPS、tokens/sec)、错误率(4xx/5xx 与超时)、GPU 利用率、KV cache 命中率与排队长度;② Token 级指标——TTFT(Time To First Token,请求发出到首个 token 返回的时间)与 TPOT(Time Per Output Token,单个 token 的生成耗时),总延迟 $T = TTFT + TPOT \times (N-1)$,其中 $TPOT = \frac{T_{\text{decode}}}{N-1}$(解码总耗时除以生成的 token 数);③ 日志与 trace——记录请求/响应、参数、工具调用链路的分布式追踪,把一次多跳对话串成一条完整 trace,支撑按请求维度定位;④ 告警与根因分析——围绕 SLO 预算设置分级告警,异常时沿 trace 区分输入侧(超长 prompt)、服务侧(排队、显存 OOM、pod 扩容)还是模型侧(输出退化)。

线上推理服务的日常稳定性保障与故障排查;面试常问 TTFT/TPOT 如何测量与优化、为什么看 P99 而不是平均延迟、QPS 突增时如何定位瓶颈。

黑盒只能告诉你“变慢了”,可观测性告诉你“慢在哪一段”——TTFT 高指向 prefill 或排队,TPOT 高指向 decode 的带宽/算力瓶颈;平均延迟会被长尾请求稀释,P99 才能暴露超长 prompt 或批次不均造成的体验问题;trace 把多副本、多服务、多次工具调用的调用链串起来,根因定位从小时级缩短到分钟级,为限流、扩容、SLO 赔付提供数据支撑。

TTFT 和 TPOT 各衡量什么、互相怎么影响?总延迟公式 $T = TTFT + TPOT \times (N-1)$ 如何使用?

为什么监控延迟要看 P99 而不是平均值?LLM 服务的长尾请求来自哪里?

QPS 突增时,如何用 trace 区分输入侧/服务侧/模型侧瓶颈?

SLO 与告警怎么设?错误率、延迟告警的阈值与分级如何设计?

KV cache 命中率、GPU 利用率、排队长度这些服务侧指标如何指导扩缩容?