文章

推理性能基准测试与调优

#llm#inference#benchmark#performance#tuning

推理性能基准测试与调优

“快不快”不能拍脑袋。本文讲清怎么测（指标与方法）、怎么定位瓶颈（算力 vs 带宽）、以及 vLLM 常见调优参数。这是把前面所有优化落到”可量化收益”的闭环。

一、四大核心指标

指标含义受什么影响
TTFT (Time To First Token)发请求→首 tokenprefill 长度、算力、队列等待
TPOT (Time Per Output Token)相邻输出 token 间隔HBM 带宽、batch 大小、KV 量化
Throughput (token/s)系统总产出并发数、调度效率、batch
tokens/watt能效架构、量化、利用率
用户体验 ≈ TTFT（别让人等） + TPOT（生成是否流畅，>100ms 明显卡顿）
成本效率 ≈ Throughput / GPU 数（越高单 token 越便宜）

二、瓶颈定位：算力密集 vs 访存密集

这是调优的第一性原理（与 高并发调度与吞吐优化 的 prefill/decode 分离呼应）：

Prefill 阶段：大矩阵乘 → 受 FLOPS 限制（算力密集）
  → 瓶颈信号：GPU 利用率高、但 HBM 带宽未满
  → 优化：更大的 batch、更长 prompt 摊薄、chunked prefill

Decode 阶段：每步只算 1 token，反复读全部 KV → 受 HBM 带宽限制（访存密集）
  → 瓶颈信号：HBM 带宽打满(DCGM_DRAM_ACTIVE 高)、GPU 算力空转
  → 优化：KV 量化、减少 KV 体积(GQA)、投机解码、提升 batch 摊薄读开销

经验判断

  • TPOT 高 + 单请求也慢 → 带宽瓶颈（decode 本质），看 KV/量化
  • TTFT 高 + 短 prompt 也慢 → 队列/调度问题，看并发与 batch
  • 整体吞吐低 + GPU 利用率低 → 调度没填满，看 Continuous Batching 配置

三、压测方法

3.1 vLLM 自带 benchmark

# 固定请求数、并发、输入输出长度
python benchmarks/benchmark_serving.py \
  --model Qwen/Qwen2.5-7B-Instruct \
  --backend vllm \
  --request-rate 10 \        # 每秒发 10 个请求（inf 表示打满）
  --num-prompts 1000 \
  --dataset-name random \
  --random-input-len 1024 \
  --random-output-len 256
# 输出：TTFT p50/p99、TPOT、throughput、队列时间

3.2 真实流量回放

  • 用生产日志的 (prompt_len, output_len) 分布构造数据集，比 random 更准
  • 工具：Genai-Perf（NVIDIA）、LLMPerf

3.3 关键压测变量

固定：模型、硬件
变化：request-rate(并发)、input_len、output_len、--max-num-seqs
观察：TTFT/TPOT p99 何时劣化 → 找到容量拐点

四、vLLM 调优参数清单

参数作用调优方向
--gpu-memory-utilizationKV Cache 可用显存比例0.90→0.95 撑更高并发（留余量防 OOM）
--max-num-seqs最大并发请求数受 KV 容量限制，逐步调大找拐点
--max-model-len最大上下文调小→省 KV 预留，但限制长上下文
--enable-prefix-caching前缀 KV 复用多轮/Agent 必开
--enable-chunked-prefill长 prompt 不卡 decode延迟敏感必开
--kv-cache-dtype fp8KV 量化长上下文/高并发必开
--quantization awq权重量化显存不够时降档
--tensor-parallel-size多卡切分单请求延迟敏感时加大
--swap-spaceKV 换出到 CPU防 OOM 但慢，应急用
CUDA Graph固化 kernel默认开，降 launch 开销

五、调优实战流程

1. 基线测量
   跑 benchmark，记录 TTFT/TPOT/吞吐 基线

2. 定位瓶颈
   GPU util 高+DRAM 满 → decode 带宽瓶颈
   GPU util 低+队列长 → 调度/并发不足

3. 针对性调优
   带宽瓶颈 → 开 KV 量化、降 --max-model-len、GQA 架构
   并发不足 → 提 --max-num-seqs、--gpu-memory-utilization、开 prefix cache
   延迟高   → TP 多卡、chunked prefill、投机解码

4. 回归验证
   同一 benchmark 复测，确认指标改善且无 OOM/质量下降

5. 容量规划
   找到 p99 达标时的最大 request-rate → 定副本数/卡数

六、量化收益对照（典型值）

配置显存相对吞吐备注
FP16, 无 KV 量化140GB1.0×基线(70B 需多卡)
INT8 权重70GB~1.0×显存减半，速度接近
INT4(AWQ)35GB~0.9-1.0×单卡可跑，质量略降
INT4 + KV FP835GB~1.1-1.3×显存省 + 带宽降 → 吞吐反升
FP8 全量(Hopper)70GB~1.3-1.5×硬件原生，最佳

量化不总是降速：KV 量化降了 decode 的带宽压力，反而能提吞吐（见 KV Cache 原理与 PagedAttention）。

七、常见误区

误区真相
”加卡一定更快”单请求延迟看 TP 互联；盲目 PP 跨节点反而更慢
”batch 越大越好”过大→TTFT 劣化、KV 爆；有甜点区间
”量化一定降速”KV 量化常提速（带宽释放）
“只看吞吐”用户体验看 TTFT/TPOT p99，不是均值
”压测用 random 就行”真实长度分布差异大，容量拐点会偏

关联知识

参考资源

学习时间

阶段时间备注
内容创建2026-07-20四大指标、算力vs带宽瓶颈、压测方法、调优参数、实战流程

状态标记

📖 已掌握 — 指标定义、瓶颈定位、调优参数、实战流程 📓 待实践 — 真实模型压测数字回填、不同引擎同硬件对比