吞吐量关键指标：吞吐量、延迟、首Token延迟、TTFT、TPOT等
在优化大模型推理服务时，我们首先需要建立一套统一的“度量语言”。如果团队对“快”和“好”的定义不一致，任何性能优化都无从谈起。本节将聚焦于吞吐量场景下最核心的六个指标：吞吐量（Throughput）、延迟（Latency）、首Token延迟（TTFT）、单Token生成时间（TPOT），以及由它们推导出的端到端延迟与每秒请求数（QPS）。理解这些指标的定义、测量方式与相互制约关系，是后续所有调优策略（如Continuous Batching、PagedAttention）的前提。
核心原理：为什么单一指标会误导优化？
大模型推理服务是一个典型的多阶段流水线：请求先经过预填充（Prefill）阶段处理输入Token，再进入解码（Decode）阶段逐Token生成输出。这两个阶段的计算特征截然不同——预填充是计算密集型的矩阵乘法，解码则是访存密集型的自回归生成。因此，任何单一指标都无法完整反映服务质量。
吞吐量与延迟之间存在经典的倒挂关系：当系统同时处理更多请求（提高吞吐）时，单个请求在队列中等待的时间变长，延迟随之上升。反之，若追求极低延迟（如串行处理每个请求），GPU算力将被大量闲置，吞吐量急剧下降。优化的本质是在资源利用率与用户体验之间寻找平衡点。
指标定义与测量方法
下表汇总了各核心指标的定义、单位与测量要点，是后续分析的基础工具。
| 指标 | 定义 | 单位 | 测量要点 |
|---|---|---|---|
| 吞吐量 | 系统单位时间内生成的Token总数 | Tokens/s | 需在稳定并发下持续测量，避免冷启动影响 |
| QPS | 每秒完成的请求数量 | req/s | 与输出长度强相关，需注明平均输出Token数 |
| TTFT | 从请求发出到收到第一个Token的时间 | ms | 包含网络、排队、预填充时间；对交互式应用至关重要 |
| TPOT | 解码阶段生成单个Token的平均耗时 | ms/Token | 通常取稳定解码阶段的平均值，排除首Token |
| 端到端延迟 | 从请求发出到完整响应返回的总时间 | ms | ≈ TTFT + TPOT × (输出Token数 - 1) |
方法流程：如何正确测量与解读指标
在实际压测中，建议按照以下流程获取可靠指标：
- 确定负载模型：明确并发数、请求到达分布（固定速率或泊松分布）、输入Token长度与输出Token长度的比例。不同负载模型下，指标表现差异巨大。
- 预热系统：先发送少量请求触发CUDA Kernel加载、显存分配等初始化操作，等待GPU利用率稳定后再开始正式测量。
- 分位点统计：不要只关注平均值，应同时记录P50、P95、P99分位值。P99 TTFT能反映长尾延迟，对用户体验影响更大。
- 区分阶段测量：在服务端日志中分别记录排队时间、预填充耗时、每步解码耗时，便于定位瓶颈。
# 压测工具输出示例（vLLM benchmark_serving）
# 并发数=16，输入长度=512，输出长度=256
Throughput: 2,847 tokens/s
Total time: 45.2s
Requests: 128
Successful requests: 128
TTFT (ms):
P50 = 385.2 | P95 = 612.8 | P99 = 890.3
TPOT (ms):
P50 = 42.1 | P95 = 58.7 | P99 = 76.4
End-to-end latency (ms):
P50 = 11,204 | P95 = 15,876 | P99 = 19,432案例场景：聊天机器人的指标权衡
假设我们部署一个面向终端用户的聊天机器人，平均输入200 Token，输出300 Token。通过压测得到两组配置数据：
- 配置A（低并发）：并发数=4，吞吐量=850 Tokens/s，P50 TTFT=180ms，P50 TPOT=35ms
- 配置B（高并发）：并发数=32，吞吐量=2,400 Tokens/s，P50 TTFT=650ms，P50 TPOT=55ms
配置B的吞吐量是A的2.8倍，但TTFT增加了3.6倍，TPOT也恶化了57%。对于聊天场景，用户能容忍约1秒的初始等待，但若每个Token间隔超过80ms，打字机效果就会变得断断续续。因此，配置B虽然吞吐更高，但已接近体验红线。此时应通过动态批处理或抢占调度策略，在保持高吞吐的同时将TPOT压回50ms以内。