LLM 推理性能基准方法：吞吐、TTFT 与成本实测
实验目标
推理引擎（vLLM/TensorRT-LLM 等，见 12 章各篇）装好上线前，"感觉挺快"不够——生产决策需要一套统一、可复现、可对比的推理基准：
- 不同引擎/量化/并发参数，怎么在同口径下比较？
- "吞吐高"和"首字快"能不能兼得？指标之间什么关系？
- 一个请求"到底多快"，怎么从引擎自带工具与外部压测两个层面测？
本篇以 vLLM 自带基准工具为主线，逐段拆解推理性能基准方法：指标语义、工具参数、并发建模与成本口径。命令为真实可复现操作；具体数字随模型/硬件而异，方法描述不编造基准。
第一段：先统一指标语言——五个数字
| 指标 | 含义 | 谁关心 |
|---|---|---|
| Throughput（吞吐） | 每秒输出 token 数（tokens/s），或请求数/秒 | 容量规划 |
| TTFT（Time To First Token） | 首个输出 token 的时延 | 交互体验（聊天/流式） |
| TPOT（Time Per Output Token） | 每个输出 token 的间隔 | 流式体验（打字感） |
| ITL（Inter-Token Latency） | TPOT 的实测观测口径 | 流式体验验证 |
| E2E Latency | 完整请求从发起到结束 | 单请求体验/超时设计 |
关键关系：并发升高 → 吞吐先升后降（拐点即容量上限），同时 TTFT/TPOT 恶化——"高吞吐"与"快响应"是同一资源下的权衡，基准必须同时报告两者，只报一个等于作弊。
第二段：vLLM 自带基准——命令与参数拆解
vLLM 提供两个工具：benchmark_throughput.py（离线，只管吞吐）与 benchmark_serving.py（在线，带时延与并发建模）。
bash
# 离线吞吐：固定输入/输出长度，纯算引擎上限
python3 benchmark_throughput.py \
--model /models/Qwen2.5-72B-Instruct \
--backend vllm --num-prompts 2000 \
--input-len 512 --output-len 256 \
--max-num-seqs 128
# 在线服务基准：模拟真实并发请求流
python3 benchmark_serving.py \
--model /models/Qwen2.5-72B-Instruct \
--backend vllm --endpoint /v1/completions \
--num-prompts 500 \
--request-rate 20 \ # 每秒新请求数（泊松到达）
--input-len 512 --output-len 256 \
--percentile-metrics "ttft,tpot,itl,e2e_latency"参数语义：
| 参数 | 含义 | 调整要点 |
|---|---|---|
--input-len/--output-len | 请求输入/输出 token 长度 | 对齐真实负载分布；输出长=压力在 decode |
--request-rate | 每秒到达请求数（0=全并发压测） | 模拟真实到达；调大观察吞吐拐点与时延恶化 |
--num-prompts | 总请求数 | 覆盖到稳定态（前几十个请求预热/排队不算数） |
--percentile-metrics | 输出指定指标的分位 | 看 P50/P95/P99，不看均值（长尾决定体验） |
工程观察：基准要回答的问题是"我的真实负载在哪一档"——请求长度分布、到达速率、并发峰谷决定参数。拿默认参数测出的数字无法指导容量规划。
第三段：外部压测——引擎自带工具的补充
引擎自带工具测的是"引擎视角"，生产环境还需要"客户端视角"（网络、网关、批处理队列都算进去）：
bash
# 用通用压测工具（如 locust/wrk/自定义脚本）打真实 API
# 关键：客户端记录 TTFT/TPOT/E2E，而不是只看引擎日志外部压测补三类盲区：
- 网络与网关开销：TTFT 里包含的网络往返、网关排队，引擎日志看不到；
- 真实到达模式：突发（burst）与平稳的区别——用泊松/尖峰到达建模而不是匀速；
- 端到端超时设计：客户端超时、重试策略对"用户感知时延"的影响。
第四段：成本口径——把性能变成钱
性能指标最终要落到成本决策：
成本口径（每百万 token 输出）≈ 服务成本（GPU 摊销 + 能耗 + 运维） / 吞吐 × 时间- GPU 摊销：按服务独占 GPU 数与单价折算（容量规划的直接输入）；
- 吞吐 vs 成本的拐点：并发超过拐点后吞吐不涨时延涨，继续加并发等于烧钱换坏体验——基准找到拐点，容量定在拐点前；
- 量化/引擎对比：同口径（同模型同硬件）下对比 FP8 量化、不同引擎的吞吐-时延曲线与成本，才能回答"换引擎值不值"。
推理基准检查清单
- [ ] 指标同时报告吞吐 + TTFT/TPOT 分位（P50/P95/P99），不单报吞吐
- [ ] 请求长度/到达速率对齐真实负载分布，而非默认参数
- [ ] 覆盖并发拐点（逐步调高 request-rate 观察吞吐与时延）
- [ ] 外部压测补充网络/网关/超时视角
- [ ] 成本口径统一（GPU 摊销 + 吞吐拐点），跨引擎/量化对比同口径
- [ ] 基准命令与结果存档，扩容/换参后复跑对比
工程启示
- 指标成对才有意义：吞吐与时延是同一枚硬币的两面，只报一个等于作弊；
- 负载建模决定决策价值：拿真实分布（长度、到达、并发）建模，基准结果才能指导容量与成本；
- 基准是可回归的标尺：每次换引擎、换量化、扩 GPU，用同一命令复跑，决策才有依据。
下一篇预告：推理测量就绪后，回到 AI×Science 主战场——下一篇《气象科学大模型落地：从论文架构到业务化预报服务》拆解 AI4S 代表性领域的落地路径。