LLM 延迟与吞吐指标

摘要：LLM 是流式生成的自回归服务，传统"请求响应延迟"一个指标远远不够。本文讲清三个核心延迟指标（TTFT / TPOT / 端到端）、流式场景的分位数治理、吞吐（tokens/s、并发、goodput）的口径，以及延迟-吞吐-成本的三角权衡如何指导容量评估。适用栈：vLLM / SGLang / TGI 自托管推理，或通过网关调用商业 API。前置阅读：LLMOps 可观测性总览。

三个延迟指标

指标	定义	用户感知	主要影响因素
TTFT（Time To First Token）	请求发出到首个 token 返回	"点了没反应"	prefill 长度、排队、KV cache 命中
TPOT（Time Per Output Token）	输出阶段每 token 平均间隔	"打字机卡不卡"	decode 批大小、显存带宽
端到端延迟	完整响应耗时	整体快慢	输出 token 数 × TPOT + TTFT

三者要分开统计：RAG 应用输入长（TTFT 高但可接受）、长文生成（TPOT 主导体验）、客服问答（TTFT 决定用户是否流失）——同一服务在不同场景下需要保住的指标完全不同。

vLLM 直接暴露的指标

自托管 vLLM 的 /metrics 已内置 vllm:time_to_first_token_seconds、vllm:time_per_output_token_seconds、vllm:e2e_request_latency_seconds、vllm:num_requests_running/waiting 等指标，先 scrape 再谈自建。

流式场景的分位数治理

流式输出下"平均值"毫无意义，用户体验由尾部决定。建议对 TTFT 与 TPOT 分别监控 P50 / P95 / P99：

promql

# TTFT P99（vLLM）
histogram_quantile(0.99,
  sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le, model_name))

# 排队深度：排队占比升高通常先于 TTFT 恶化
sum(rate(vllm:num_requests_waiting[5m]))
/
(sum(rate(vllm:num_requests_running[5m])) + sum(rate(vllm:num_requests_waiting[5m])))

先看排队再看推理：TTFT P99 恶化时，第一排查项是 num_requests_waiting——排队是 prefill 阶段的滞留，往往意味着并发配额、max_num_seqs 或上游限流问题，而不是 GPU 算力不足。

吞吐与 goodput

总吞吐：output_tokens_per_second（全实例求和），反映硬件效率；
单请求吞吐：输出 token 数 / 端到端耗时，用户感知的"打字速度"；
goodput（有效吞吐）：满足 SLO（如 TTFT < 2s 且 TPOT < 100ms）的请求吞吐。并发提升后总吞吐可能上升而 goodput 下降——容量评估必须以 goodput 为准。

promql

# 输出吞吐（按模型）
sum(rate(vllm:generation_tokens_total[5m])) by (model_name)

商业 API 的延迟监控

调用 OpenAI / Anthropic API 时，指标从 SDK 埋点产生：记录 TTFT（流式首 chunk 时间）、token 数、finish_reason。注意两点：

流式与非流式的延迟分布完全不同，分开关看；
厂商侧故障常表现为 TTFT P99 抖动而非错误率上升，延迟异常告警往往比错误率告警更早发现厂商事故。

容量评估：延迟-吞吐-成本三角

调大并发（max_num_seqs、batch）→ 总吞吐上升、单请求 TPOT 变慢。落地节奏建议：

压测得到该模型在目标硬件上的 goodput-并发曲线（vLLM 官方 benchmark 脚本可复用）；
选定 SLO 约束下的最大 goodput 点作为容量基准；
按峰均比预留实例数，num_requests_waiting 持续 > 0 即触发扩容评估。

性能调优手段本身见推理性能调优与 KV Cache 与显存优化；本文关注的是把这些指标变成可持续监控的信号。

LLM 延迟与吞吐指标 ​

三个延迟指标 ​

流式场景的分位数治理 ​

吞吐与 goodput ​

商业 API 的延迟监控 ​

容量评估：延迟-吞吐-成本三角 ​