本文是《大模型推理系统揭秘：从 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 指标总览        四个维度下各指标的定义、反映的问题与使用注意
第三章  指标常见误区与优化方向      六个常见误区、指标与优化方向的对应表、分析顺序
第四章  在 vLLM 里怎么测            `vllm bench` 的四个子命令与五条口径细节
第五章  本文小结

二、LLM Serving 指标总览

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

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

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 达标率

指标说明

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

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. 使用原则

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

先确认指标口径
    ↓
区分 Prefill、Decode、排队和网络因素
    ↓
观察平均值与 P95/P99 的差异
    ↓
结合 GPU、显存、带宽和通信指标定位瓶颈
    ↓
选择与指标对应的优化方向
    ↓
用 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) / 时长，包含输入。

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

五、本文小结

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

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

其中最重要的区别是：

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

下一篇

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

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