跳到主要内容
推理优化

9.2 压测工具：vllm bench、GenAI-Perf 与可复现配置

vllm bench serve/latency/throughput 用法与输出解读、GenAI-Perf 一站式 LLM 指标、Triton Perf Analyzer、可复现的 Benchmark 配置管理

vllm benchGenAI-Perf压测BenchmarkPoisson可复现

指标定义好了（9.1），9.2 上手压测。工具选型：vLLM 自带 vllm bench 三件套（serve/latency/throughput）为主，NVIDIA GenAI-Perf 作为一站式补充。更重要的是方法论：负载怎么构造、结果怎么存、怎么保证两次压测可比——可复现性比工具本身更值钱。

📑 目录

1. 工具矩阵：选哪个

工具场景特点
vllm bench serve在线服务压测（推荐首选）打真实 HTTP API，输出 TTFT/TPOT/ITL 全套指标 + goodput
vllm bench latency单批固定长度延迟离线引擎内测，纯净的模型级延迟（无网络/调度噪声）
vllm bench throughput离线吞吐直接驱动引擎，测峰值 token 吞吐
vllm bench sweep serve参数扫描一次跑多个配置（并发/批大小/量化）画 Pareto 图
GenAI-Perf（NVIDIA）生产服务通用压测支持 vLLM/TensorRT-LLM/Triton 等，指标一站式
Triton Perf AnalyzerTriton 后端压测NVIDIA Triton 生态专用

📌 关键点：serve 与 latency/throughput 测的不是同一层——serve 测”服务端到端”（含网络、调度、批处理），latency/throughput 测”引擎”（无网络）。排障时两者对照用：serve 慢但 latency 快 → 问题在网络/调度层；都慢 → 引擎/模型层问题。

2. vllm bench serve：在线压测

2.1 基本用法

# 先启动服务
vllm serve NousResearch/Hermes-3-Llama-3.1-8B

# 另开终端压测
vllm bench serve \
  --backend vllm \
  --model NousResearch/Hermes-3-Llama-3.1-8B \
  --endpoint /v1/completions \
  --dataset-name sharegpt \
  --dataset-path <你的数据路径>/ShareGPT_V3_unfiltered_cleaned_split.json \
  --num-prompts 10

2.2 输出解读（Serving Benchmark Result）

============ Serving Benchmark Result ============
Successful requests:                     10          ← 成功率（先看这个）
Benchmark duration (s):                  5.78
Total input tokens:                      1369
Total generated tokens:                  2212
Request throughput (req/s):              1.73       ← QPS
Output token throughput (tok/s):         382.89     ← 输出 tok/s（9.1 的算力效率）
Total token throughput (tok/s):          619.85     ← 输入+输出
---------------Time to First Token----------------
Mean TTFT (ms):                          71.54
Median TTFT (ms):                        73.88
P99 TTFT (ms):                           79.49      ← 体验 SLO 挂载点
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          7.91
Median TPOT (ms):                        7.96
P99 TPOT (ms):                           8.03
---------------Inter-token Latency----------------
Mean ITL (ms):                           7.74
Median ITL (ms):                         7.70
P99 ITL (ms):                            8.39
==================================================

📌 关键点：读报告的顺序：成功率 → 吞吐 → TTFT P99 → TPOT P99。任何指标异常前先确认”请求都成功了吗”——压测中失败的请求不计入延迟统计，会系统性低估 P99（慢请求都失败掉了，剩下的自然快）。

2.3 关键参数

参数作用
--num-prompts请求数（越大越稳，建议 ≥ 500）
--request-rate到达速率（默认 Poisson 过程）；inf = 尽最快发（测上限）
--max-concurrency并发上限（模拟网关限流场景）
--burstiness到达分布：1 = Poisson；<1 更突发（gamma 分布）
--num-warmups预热请求数（避免冷启动污染）
--save-result / --save-detailed保存结果 JSON（含每请求明细）
--goodput "ttft:500 tpot:40"直接输出 Goodput（按 SLO 计达标吞吐）
--metric-percentiles 99,95,50自定义百分位
--metadata key=value记录环境信息（模型/TP/GPU/版本）
--profile配合服务端 --profiler-config 做链路 profile
--plot-timeline生成请求完成时间线（HTML，调优排障利器）

2.4 Goodput 实战

vllm bench serve \
  --model <model> --dataset-name sharegpt \
  --dataset-path <path> --num-prompts 1000 \
  --request-rate inf \
  --goodput "ttft:500 tpot:40"

输出会额外给出满足 TTFT≤500ms 且 TPOT≤40ms 的请求占比与 Goodput 值——这就是 9.1 第 7 节的 SLO 视角落地。

3. vllm bench latency：单批延迟

测引擎的纯净延迟（默认关闭 prefix caching，避免缓存命中虚高）：

vllm bench latency \
  --model <model> \
  --input-len 32 --output-len 128 \
  --batch-size 8 \
  --num-iters 30 --num-iters-warmup 10 \
  --output-json latency.json
  • --input-len / --output-len：固定长度（32/128 默认）
  • --batch-size：单批请求数（批大小对 TPOT 影响最大——加大 batch 测出 TPOT 随批的曲线）
  • --num-iters：迭代次数（统计稳定需要 ≥ 30）
  • --n：每 prompt 生成几条（等价 8.5 的并行采样）
  • --profile：单批生成过程 profile（配合 9.3 分析）
  • 输出 JSON：avg_latency、percentiles、每次迭代的延迟明细

💡 提示：latency bench 的经典用法是扫 batch-size 曲线：--batch-size 1,8,32,64,128 各跑一遍，画出”TPOT vs batch”曲线——这是判断”当前负载下 TPOT 余量”的最直接数据（配合 6.3 的黄金组合思维）。

4. vllm bench throughput：离线吞吐

vllm bench throughput \
  --model <model> \
  --dataset-name sonnet \
  --dataset-path vllm/benchmarks/sonnet.txt \
  --num-prompts 10

输出：

Throughput: 7.15 requests/s, 4656.00 total tokens/s, 1072.15 output tokens/s
Total num prompt tokens:  5014
Total num output tokens:  1500
  • 直接驱动引擎（无需起 HTTP 服务），测算力上限
  • 与 serve 的区别：没有网络/API 层，也没有到达过程——所有请求立刻进引擎
  • 适合：模型/量化/并行配置的横向对比（6.2 的 TP 对比、4.x 的量化对比）

📌 关键点：throughput 的结果是乐观上界（无网络、无排队），serve 的结果是现实值。两者之比 ≈ 服务层的开销占比——如果差距 > 30%，先查调度与网络层。

5. 负载构造：数据集与到达模式

5.1 内置数据集（v0.26）

数据集特点适用
sharegpt真实对话长短混合默认首选（通用聊天）
sonnet固定长度（输入 550 / 输出 150）稳定对比
random合成随机长度无数据时的基线
prefix_repetition高频前缀复用测 APC（第 2 章）收益
spec_bench推理模型长短混合测投机解码（第 5 章）
hf任意 HF 数据集业务真实数据
custom / custom_image本地 jsonl内部数据（{"prompt": ...}）

5.2 到达模式：Poisson 与突发

  • --request-rate <r>：按 Poisson 过程到达（间隔服从指数分布）——最接近真实用户行为
  • --request-rate inf：尽快发——测系统上限（饱和点）
  • --burstiness <1：gamma 分布，制造突发流量——压 P99 的最狠手段（9.1 的”突发 → P99 涨”）

💡 提示：先跑 inf 找饱和点，再在饱和点的 50%-80% 速率上测 P99——这是”容量规划”的标准两步法：饱和点告诉你上限，亚饱和区间的 P99 告诉你”日常能承诺什么”。

5.3 数据准备三原则

  1. 真实：用业务数据（hf/custom），不要只用 sonnet 固定长度
  2. 冻结：数据集版本固定（存到仓库或对象存储，不许流式更新）
  3. 多样：至少覆盖 短-中-长 prompt × 短-中-长输出 的组合（9.1 的负载形状干扰）

6. GenAI-Perf 与 Triton Perf Analyzer

6.1 GenAI-Perf（NVIDIA，推荐用于生产服务验收）

genai-perf profile \
  -m <model> \
  --endpoint-type chat \
  --endpoint v1/chat/completions \
  --service-kind openai \
  --concurrency 32 \
  --sla TTFT:0.5 TPOT:0.04 \
  --artifact-dir ./perf-artifacts
  • 一站式输出：TTFT/TPOT/ITL 分布、吞吐、显存、Power（GPU 功耗）
  • --sla 直接给 Goodput；--concurrency 扫并发 → 出并发-延迟-吞吐曲线
  • 支持 vLLM/TensorRT-LLM/Triton 等任意 OpenAI 兼容服务——跨引擎对比的唯一公平工具
  • 输出可生成报告（markdown/html/PDF），方便归档

6.2 Triton Perf Analyzer

Triton 生态的压测工具（perf_analyzer）：测 Triton Inference Server 后端的延迟/吞吐，支持模型集成（ensemble）与动态批。只在 Triton 部署栈内使用，配合 GenAI-Perf 做端到端。

📌 关键点：工具选型的铁律——验收服务用 GenAI-Perf（外部视角），调优引擎用 vllm bench（内部视角）。两者互补：前者管”承诺能不能兑现”，后者管”瓶颈在哪一层”。

7. 可复现的 Benchmark 配置管理

7.1 一次压测的完整元信息（必须记录）

模型：meta-llama/Llama-3.1-8B-Instruct（含 revision/hash）
框架：vLLM v0.26.0（含 commit）
硬件：8× H100 80G，NVLink 全互联
并行：TP=8，无 PP
量化：FP8（W8A8）
引擎参数：max-num-seqs=512, gpu-memory-utilization=0.9
负载：ShareGPT v3，1000 prompts，request-rate=10（Poisson）
采样：temperature=0.8, top_p=0.95, max_tokens=512
结果文件：label-10qps-model-20260807-103000.json

7.2 落盘与命名（vllm bench 原生支持）

vllm bench serve \
  ... \
  --save-result --save-detailed \
  --result-dir ./results/ \
  --metadata model=llama-3.1-8b \
  --metadata tp=8 quant=fp8 \
  --metadata vllm=v0.26.0
  • 自动命名：{label}-{request_rate}qps-{model}-{timestamp}.json
  • --metadata 把环境信息写进结果文件（比记在 README 里可靠）
  • --save-detailed 存每请求明细（TTFT/TPOT/错误），供事后深挖

7.3 可比性铁律

  1. 同一负载文件（数据版本冻结）
  2. 同一引擎版本（升级前后对比要记录两个版本）
  3. 同一并发/到达配置（或至少记录）
  4. 同样的预热（--num-warmups ≥ 20，等 GPU 利用率稳定再计时）
  5. 多次取稳（至少 3 次，看方差；波动 > 5% 先查环境）

💡 提示：把压测命令做成脚本 + 参数文件（而不是口头传命令），脚本入库、结果归档、对比自动化——这就是 9.5 性能回归门禁的前置条件。没有可复现的压测，就没有性能回归检测。

📝 总结

  • 工具矩阵：serve（在线端到端）/ latency（引擎纯净延迟）/ throughput（离线算力上限）/ sweep（参数扫描）/ GenAI-Perf（生产验收）
  • serve 输出解读顺序：成功率 → 吞吐 → TTFT P99 → TPOT P99（失败请求会低估 P99）
  • 负载构造：真实数据 + Poisson 到达 + 固定版本；inf 找饱和点，50-80% 饱和率测 P99
  • GenAI-Perf：跨引擎公平对比、--sla 直接出 Goodput、并发扫描曲线
  • 可复现六要素：模型+框架版本+硬件+并行配置+负载+采样参数全记录
  • 铁律：同一负载、同一版本、同一并发、预热充分、多次取稳

🎯 自我检验清单

  • serve / latency / throughput 分别测哪一层？排障时怎么对照？
  • Serving Benchmark Result 的正确解读顺序？为什么失败请求会低估 P99？
  • --request-rate inf 和有限速率分别回答什么问题？
  • Poisson 与 burst 到达模式分别模拟什么场景？
  • GenAI-Perf 和 vllm bench 的分工？
  • 写出你上次压测的完整元信息清单，缺了什么？
  • 可复现压测的五条铁律是哪些？

📚 参考资料