本文是《大模型推理系统揭秘：从 vLLM 看 LLM Serving Infra 核心技术》系列的第 2 篇（共十五篇）。上一篇：为什么 LLM Serving 比传统 DL 推理难？；下一篇：鸟瞰 vLLM：一个请求如何穿过整个推理系统？。

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码剖析。文中文件路径、类名和函数名均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。

上一篇说明了 LLM Serving 为什么难：服务对象变成了持续生成过程，Prefill 与 Decode 是两种不同的 Workload，吞吐与时延无法同时最优。在动手优化之前，还需要先回答一个更基本的问题——系统到底好不好、问题出在哪一段。

LLM Serving 的性能不能只看单一指标：延迟、吞吐、效率与服务质量四个维度各自暴露不同阶段、不同资源的瓶颈。本篇的核心问题是：

应该用哪些指标衡量一个 LLM Serving 系统？¹ 指标异常时，如何判断问题出在排队、Prefill、Decode 还是资源，并选择对应的优化方向？²

一、总览：先定义指标，再对应瓶颈

1. 四个维度与一条使用原则

本篇先给出完整的指标体系——延迟（TTFT、TPOT、ITL、E2E、Queueing Time）、吞吐（Tokens/s、Requests/s、Goodput）、资源效率（MFU、GPU 利用率、显存利用率、Cost per Token）和服务质量（P50/P95/P99、SLO 达标率）——并逐一说明定义、反映的问题和使用注意；然后讨论常见的解读误区，把“指标异常”映射到“重点优化方向”；最后读一遍 vLLM 自带的 vllm bench 实现，用源码口径消除定义上的歧义。

贯穿全篇的原则是：不同指标对应不同瓶颈，不同瓶颈对应不同优化手段。

2. 本文的章节安排

二、LLM Serving 指标总览

LLM Serving 的性能不能只看单一指标，而应同时关注四个维度：

• 延迟：用户需要等待多久？
• 吞吐：系统单位时间处理多少请求和 Token？
• 效率：GPU、显存和资金利用得好不好？
• 服务质量：有多少请求满足 SLO？

%% 图：LLM Serving 指标体系：延迟、吞吐、资源效率、服务质量四组
mindmap
  root((LLM Serving 指标体系))
    延迟指标
      TTFT
      TPOT
      ITL
      E2E Latency
      Queueing Time
    吞吐指标
      Output Tokens/s
      Total Tokens/s
      Requests/s
      Goodput
    资源效率
      MFU
      GPU 利用率
      显存利用率
      Cost per Token
    服务质量
      P50
      P95
      P99
      SLO 达标率

延迟维度的五个指标其实是同一条请求时间线上的不同区间，先把它们放到一张图里，后面的定义就不容易混（t0 客户端发出请求，t1 服务端开始执行，t2 首 token 到达客户端，t3..tN 后续每个输出 token 到达客户端，共 N 个输出 token）：

时间 ────────────────────────────────────────────────────────────────▶
   t0            t1            t2      t3      t4      t5   ...     tN
   │             │             │       │       │       │            │
   ├── Queueing ─┼── Prefill ──┤       │       │       │            │
   ├─────────── TTFT ──────────┤       │       │       │            │
   │                           ├─ITL1──┼─ITL2──┼─ITL3──┼─── ... ────┤
   │                           ├─── TPOT = (E2E - TTFT)/(N - 1) ────┤
   ├───────────────────────── E2E Latency ──────────────────────────┤

几个容易看错的地方：TTFT 从 t0 而不是 t1 起算，所以它包含排队、首 token 采样和网络传输，不等于 Prefill；ITL 是 t2 之后每一段间隔各自的值，有 N−1 个样本，所以能算分位数；TPOT 是这 N−1 段的平均值，一个请求只有一个数，它和 ITL 的均值相等，但抹掉了抖动；E2E 覆盖整条线。

指标说明

三、指标常见误区与优化方向

LLM Serving 的各项指标并非相互独立。不同指标暴露的是不同阶段或不同资源的瓶颈，因此应根据指标异常选择优化方向，而不是笼统地追求 GPU 利用率或总吞吐。

1. 常见误区

误区一：只看平均延迟

平均值可能掩盖严重的尾延迟问题。在线服务通常应同时报告：

平均值 + P50 + P95 + P99 + SLO 达标率

尤其是在动态批处理和多租户环境中，少量长请求可能显著拖高 P99。

误区二：将 TTFT 等同于 Prefill 时间

TTFT 通常还包括：

排队时间 + 调度等待 + Prefill + 首 Token 生成 + 网络传输

因此 TTFT 过高不一定意味着 Prefill Kernel 低效，也可能是请求在队列中等待过久。

误区三：只用 TPOT 衡量流式体验

TPOT 是平均值，而用户实际感受到的是每个 Token 的到达间隔。调度抖动、Batch 动态变化和通信阻塞可能导致平均 TPOT 正常，但 ITL 的 P95/P99 很差。

误区四：用 GPU 利用率判断系统是否高效

GPU 利用率较高，可能只是 GPU 在等待显存访问或通信；GPU 利用率较低，也可能是系统受限于显存带宽、请求不足或模型并行通信。因此需要结合以下指标共同判断：

• HBM 带宽利用率；
• Kernel 执行时间；
• MFU；
• Decode TPOT；
• GPU 间通信时间；
• 有效 Tokens/s。

误区五：只比较 Requests/s

不同测试的 Prompt 长度、Output 长度和请求分布不同，Requests/s 很难直接比较。更合理的报告方式是同时给出：

• 并发数、输入 Token 数、输出 Token 数、Output Tokens/s、
• Total Tokens/s、TTFT、TPOT/ITL 和 P99

误区六：显存占用越高越好

提高 KV Cache 使用率有助于增加并发，但过度填充显存可能造成：

• 新请求无法接入；
• 长请求触发抢占；
• KV Cache 频繁换入换出；
• P99 延迟显著升高；
• 系统出现 OOM 风险。

因此，显存利用率应与并发度、KV Cache 命中率、抢占率和尾延迟联合分析。

2. 指标与优化方向的对应关系

3. 使用原则

指标分析应遵循以下顺序：

1. 先确认指标口径
2. 区分 Prefill、Decode、排队和网络因素
3. 观察平均值与 P95/P99 的差异
4. 结合 GPU、显存、带宽和通信指标定位瓶颈
5. 选择与指标对应的优化方向
6. 用 Goodput 和 SLO 达标率验证优化是否有效

核心原则是：

不同指标对应不同瓶颈，不同瓶颈对应不同优化手段。
不能用提高吞吐的方法解决 TTFT，也不能用单纯增加 GPU 利用率的方法解决 P99 或 KV Cache 容量问题。

四、在 vLLM 里怎么测：vllm bench

上面的指标不是纸面定义，vLLM 自带的压测工具就是按这些口径实现的，读一遍源码可以消除大部分口径歧义。入口是 vllm bench <子命令>（vllm/entrypoints/cli/benchmark/），子命令分别对应 vllm/benchmarks/ 下的同名模块：

一次典型的在线压测：

vllm bench serve --model <MODEL> --dataset-name sharegpt --dataset-path ShareGPT.json \
  --request-rate 8 --num-prompts 500 \
  --percentile-metrics ttft,tpot,itl,e2el --metric-percentiles 50,95,99 \
  --goodput ttft:300 tpot:60

几个与口径直接相关的实现细节（vllm/benchmarks/lib/endpoint_request_func.py 与 serve.py 的 calculate_metrics）：

• TTFT 在客户端收到第一个 SSE chunk 时打点，所以包含了网络与 HTTP 解析开销，不是服务端的 Prefill 时间；
• ITL 是相邻 chunk 到达时刻的差，逐个记录后再算分位数；
• TPOT = (latency − ttft) / (output_len − 1)，不含首 Token；
• Goodput 按请求计数，一个请求只有 ttft、tpot、e2el 三项全部达标才算有效；
• Total Token throughput = (总输入 Token + 总输出 Token) / 时长，包含输入。

用上面命令里的 --goodput ttft:300 tpot:60 举一个 6 个请求、跑了 10 s 的例子，看 Goodput 是怎么从 Requests/s 里“扣”出来的（没有给 e2el 阈值，所以不检查）：

R3 和 R4 各只违反一项，但一样不计入——Goodput 是按请求做“与”判断，不是按指标各算达标率。这也解释了第三章“吞吐高但 Goodput 低”那一行：加大 Batch 让 6 个请求都完成了（Requests/s 不变甚至更高），却把一半请求推过了阈值。

对比不同引擎的 benchmark 数字时，先确认对方工具的这五条口径是否一致，否则数字没有可比性。

五、本文小结

LLM Serving 的指标体系可以归纳为：

• 延迟：TTFT、TPOT、ITL、E2E
• 吞吐：Tokens/s、Requests/s、Goodput
• 效率：MFU、GPU 利用率、显存利用率、Cost per Token
• 质量：P50、P95、P99、SLO 达标率

其中最重要的区别是：

吞吐衡量系统处理了多少工作；
延迟衡量用户等待了多久；
Goodput 衡量系统在满足 SLO 的前提下完成了多少有效工作。

六、自测

1. TTFT、TPOT、ITL、E2E 各量什么？一个 2000 token prompt、300 token 输出、TTFT 0.3 s、TPOT 30 ms 的请求 E2E 是多少？

   答案

   TTFT 首 token 延迟（含排队 + prefill）；TPOT 每输出 token 的平均间隔；ITL 逐 token 的间隔分布；E2E 端到端。E2E ≈ 0.3 + 299 × 0.03 ≈ 9.3 s——decode 占 97%。

2. 吞吐 5000 tokens/s 但 P99 TTFT 8 s，这个系统好不好？该看什么指标？

   答案

   不一定好——吞吐高可能是因为 batch 很大、请求排队很久；看 Goodput：SLO（比如 TTFT < 1 s、TPOT < 50 ms）下完成的 tokens/s，超过 SLO 的部分不算。

3. TTFT 突然升高、TPOT 不变，最可能在哪一段？先看什么？

   答案

   排队或 Prefill：看 waiting 队列长度、running 数是否达到上限（max_num_seqs）、KV 是否满（抢占次数）、有没有超长 prompt 占满 token budget。TPOT 不变说明 decode 本身没受影响。

4. GPU 利用率 95% 但 MFU 只有 5%，矛盾吗？说明什么？

   答案

   不矛盾：利用率只说 SM 上有 kernel 在跑，不说算力用了多少；decode 是 memory-bound，SM 大部分时间在等 HBM，MFU 天然只有几个百分点。看 decode 该看带宽利用率与每步时间对下界的比值。

5. 压测一个 serving 系统时为什么要固定输入输出长度分布、控制到达率、区分冷热 prefix cache？

   答案

   三者任一变化都会让结果不可比：长 prompt 抬 TTFT、长输出抬 KV 占用，到达率决定排队，prefix cache 命中让 prefill 几乎免费；报告要带上这三个条件，且报分位数不报均值。

下一篇

鸟瞰 vLLM：一个请求如何穿过整个推理系统？

• 上一篇
  大模型推理系统揭秘（01）：为什么 LLM Serving 比传统 DL 推理难？
• 下一篇
  大模型推理系统揭秘（03）：鸟瞰 vLLM：一个请求如何穿过整个推理系统？