4、推理性能指标：延迟、吞吐量、首延迟、生成速率、TTFT与TPOT的定义与测量方法
在GPU大模型推理的工程实践中，性能指标是衡量系统能力、定位瓶颈、制定优化策略的基石。如果指标定义不清晰或测量方法不统一，团队之间的讨论就会陷入“鸡同鸭讲”的困境。本章将系统梳理大模型推理中最核心的六个性能指标：延迟（Latency）、吞吐量（Throughput）、首延迟（TTFT）、生成速率（TPOT）以及由它们派生出的端到端延迟与每秒请求数（QPS）。我们将从定义、测量方法、相互关系到实战案例进行完整拆解，帮助你在性能调优时建立统一的量化坐标系。
上图展示了一次完整的大模型推理请求的生命周期。从客户端发送Prompt开始，GPU首先执行Prefill（预填充）阶段，对输入的所有进行并行计算，生成Key-Value Cache（KV Cache）。这一阶段不产生任何输出，其耗时直接决定了TTFT。随后进入Decode（解码）阶段，模型逐自回归生成回答，每一步都依赖前一步的输出和KV Cache，该阶段的单步耗时决定了TPOT。理解这两个阶段的本质差异——Prefill是计算密集型（Compute-Bound），Decode是内存带宽密集型（Memory-Bound）——是解读所有性能指标的前提。
4.1 核心指标精确定义
在工程实践中，我们通常使用以下六个指标来全面刻画推理系统的性能。它们并非孤立存在，而是相互关联、此消彼长的关系。
| 指标名称 | 缩写 | 定义 | 单位 | 测量工具/方法 |
|---|---|---|---|---|
| 首延迟 | TTFT | 从发送请求到接收到第一个输出的时间间隔 | 毫秒 (ms) | 客户端打点，记录请求发出时间与首个数据包到达时间 |
| 每输出时间 | TPOT | Decode阶段生成单个所需的平均时间 | 毫秒/ (ms/tok) | (总延迟 - TTFT) / (输出数 - 1) |
| 生成速率 | - | 每秒生成的数量，即 1000 / TPOT | Tokens/s | 由TPOT换算，或通过日志统计 |
| 端到端延迟 | Latency | 从发送请求到接收完整响应的总耗时 | 秒 (s) | 客户端整体计时 |
| 吞吐量 | Throughput | 系统在单位时间内处理的请求数或生成的总数 | req/s 或 tok/s | 压测工具（如wrk、ghz、Locust）统计 |
| 每秒请求数 | QPS | 压测时施加的请求速率，用于测试系统在不同负载下的表现 | queries/s | 压测工具配置参数 |
4.2 测量方法与操作流程
测量这些指标并非简单地“掐秒表”。由于GPU推理涉及排队、批处理（Batching）、显存交换等复杂机制，测量方法必须严谨，否则数据将失去参考价值。以下是标准化的测量流程：
- 环境隔离： 确保测试环境与生产环境隔离，避免其他任务干扰GPU计算。记录GPU型号、驱动版本、CUDA版本、推理引擎（如TensorRT-LLM、vLLM）版本。
- 固定输入： 准备标准化的Prompt数据集，固定输入长度（如512 tokens）和输出长度（如128 tokens）。可使用固定种子（Seed）保证生成内容一致。
- 预热（Warm-up）： 正式测量前，先发送10-20个请求，让GPU达到稳定工作温度，并确保CUDA上下文、KV Cache池已初始化。
- 单请求测量： 使用客户端脚本记录每个请求的TTFT和总延迟。发送至少100个请求，取P50（中位数）、P95、P99分位值，而非平均值。平均值容易掩盖长尾延迟问题。
- 并发压测： 使用压测工具以固定QPS（如1、4、8、16、32）发送请求，持续运行5-10分钟，记录系统吞吐量、GPU利用率、显存占用。
- 数据记录： 同时采集GPU利用率（nvidia-smi dmon）、显存使用量、KV Cache命中率等硬件指标，用于关联分析。
4.3 实战案例：某智能客服系统的性能基准测试
我们以某金融科技公司部署的智能客服大模型为例，完整演示指标测量与解读过程。该系统基于单张NVIDIA A100 80GB GPU，使用vLLM作为推理引擎，模型为7B参数的对话模型。
初始目标： 支撑200路并发客服会话，要求端到端延迟不超过3秒，生成速率不低于30 tokens/s。
测量过程：
- 固定输入Prompt为“用户咨询信用卡账单问题”的模板，长度约200 tokens；设置最大输出长度为256 tokens。
- 预热20个请求后，先进行单请求测试，发送50个请求，记录数据：TTFT P50 = 180ms，P95 = 220ms；TPOT P50 = 45ms（约22 tokens/s）。
- 发现生成速率未达标（22 < 30），端到端延迟 P95 = 180ms + 45ms × 255 ≈ 11.6秒，远超3秒目标。
- 使用并发压测，以QPS=10发送请求，系统吞吐量达到8.5 req/s，GPU利用率仅45%，显存占用32GB。此时TTFT P95飙升至1.2秒，TPOT P95升至80ms。
分析判断： 单请求TPOT为45ms，说明Decode阶段性能不足。GPU利用率仅45%表明计算资源未充分利用，但显存占用32GB说明KV Cache已占用大量空间。结合vLLM的Continuous Batching机制，推测瓶颈在于KV Cache的显存管理导致批处理规模受限，无法通过增大Batch Size来提升吞吐。
优化操作：
- 将vLLM的
--max-num-seqs从默认的256提升至512，允许更多请求同时参与Decode。 - 启用
--enable-prefix-caching，对常见客服问题前缀进行缓存，减少Prefill计算量。 - 调整
--gpu-memory-utilization至0.92，为KV Cache预留更多显存。
结果对比： 优化后，单请求TPOT降至38ms（约26 tokens/s），仍略低于目标。进一步使用FP8量化（A100支持）后，TPOT降至32ms（约31 tokens/s），达标。并发压测下，QPS=10时TTFT P95降至600ms，端到端延迟P95降至2.8秒，吞吐量提升至9.2 req/s。
风险与代价： FP8量化引入了约0.5%的精度损失，在金融场景中需通过人工审核兜底。增大Batch Size导致单请求的TTFT略有上升（从180ms升至200ms），但换来了整体吞吐的提升。复盘经验：性能优化是系统工程，必须结合指标数据定位瓶颈，而非盲目调参。TTFT与TPOT的权衡、吞吐与延迟的跷跷板效应，在本案例中体现得淋漓尽致。
4.4 常见误区与总结复盘
在指导多个团队进行性能调优后，我们总结了以下高频误区，这些错误会导致测量数据失真或优化方向偏离：
- 混淆TTFT与总延迟： 有些团队将“首延迟”误认为是“响应延迟”，导致对Prefill阶段性能的误判。TTFT只反映模型“看到”Prompt并开始输出的速度，不包含生成完整回答的时间。
- 忽略批处理效应： 在并发场景下，单个请求的TPOT会因其他请求的加入而变慢（共享GPU资源）。测量时必须区分“单流延迟”和“并发延迟”。单流TPOT为30ms，不代表并发32路时仍能保持30ms。
- 使用平均值而非分位数： 平均值无法反映尾部延迟。在金融、医疗等对实时性要求高的场景，必须关注P99甚至P999。
- 不记录硬件指标： 只记录延迟和吞吐，不记录GPU利用率、显存带宽、SM占用率，导致无法定位瓶颈是计算、显存还是通信。
- 忽略输入/输出长度的影响： 输入长度直接影响Prefill计算量，输出长度直接影响Decode步数。对比不同系统的性能时，必须固定输入输出长度，否则数据不可比。