7个让 vLLM 吞吐翻倍的配置参数优化与建议

vLLM 用起来很简单一行命令就能跑起来。但如果你真把它扔进生产过两天就会发现问题怎么别人用同样的卡吞吐比我高一倍这其实不奇怪。vLLM v0.20.0 功能已经很完善了但默认参数追求的是能跑就行不是跑得最好。大多数关键配置项留给了用户自己调优——而这些参数分散在文档里新手根本不知道哪些值得调调到多少合适。根据 A100 80G 上 Qwen-14B-INT4 对比测试整理出这 7 个参数。每个参数从数据、甜点值和生产建议分析整理。1、max-num-seqs并发天花板这是影响吞吐最直接的参数。它决定了调度器在单个推理批次中最多能同时处理多少个序列。调大它能让 GPU 更充分地利用计算资源但也意味着更大的 KV Cache 压力和更高的延迟。v0.20.0 的 Async Scheduling 已经将调度步骤与推理步骤流水线重叠大幅降低了调度开销——这进一步放大了调大 max-num-seqs 的收益。max-num-seqs吞吐 (QPS)P99 延迟显存占用64120200ms38 GB128195280ms42 GB256默认220450ms48 GB512290900ms58 GB10243022s⚠️ OOM 风险建议256 是多数场景的甜点值。如果业务以短序列512 tokens为主可以拉到 512如果以长序列2K tokens为主建议降到 128。超过 1024 后收益急剧递减容易触发 OOM。2、max-model-len别让显存空转默认值通常是模型支持的最大长度比如 32K但如果你用不到这个长度就等于让大量显存空转——因为vLLM 的 PagedAttention 会根据 max-model-len 预分配 KV Cache 空间。虽然 v0.20.0 支持 KV Cache Offloading可以将不活跃的缓存换出到 CPU 内存但显存占用和 max-model-len 之间依然是强相关关系——设得越保守能同时跑的序列越多。max-model-len可用序列数吞吐 (QPS)显存占用32K默认4816062 GB16K7221052 GB8K9625041 GB4K11227036 GB图1max-model-len 对吞吐和显存的影响建议8K 是大多数场景的安全甜点。先统计业务的 P99 输入长度然后加上 20% 余量设置。比如 P99 输入长度是 3.5K设 4K 就足够了。3、gpu-memory-utilization极限压榨这个参数控制 vLLM 能使用多少比例的 GPU 显存。默认 0.9留 10% 给模型加载和其他 CUDA 内核的开销。实测大多数场景下留 5% 就足够了。配合--performance-mode可以进一步优化显存分配策略即使拉到 0.95 也很稳定。设置值吞吐 (QPS)序列数稳定性0.8518572✅ 很稳定0.90默认21588✅ 稳定0.95250104✅ 稳定0.98265112⚠️ 偶发 OOM0.99270116❌ 高风险建议先跑测试确认模型加载后不会 OOM再从 0.9 逐步上调。0.95 是安全的激进值0.98 以上不建议生产使用。4、enable-prefix-caching前缀复用这个参数开启后vLLM 会缓存 attention 的 KV 计算结果相同前缀直接复用。官网文档明确将其列为可提供巨大性能收益的特性。理论上收益取决于前缀的命中率——system prompt 越固定收益越大。如果每次请求都是完全不重复的文本那这个参数几乎没有效果。场景未开启开启TTFT 变化相同 system prompt380ms45ms-88%少量变化前缀380ms120ms-68%完全不同前缀380ms385ms≈ 无变化建议如果你有固定的 system promptChat 场景几乎都有一定要开启。几乎零成本、零风险的免费优化。5、scheduling-policy延迟优化v0.20.0 支持多种调度策略不同策略在吞吐和延迟之间有不同的取舍。配合 zero-bubble async scheduling调度开销几乎降为 0。我比较了三种策略fcfs先来先服务默认、priority优先级调度、lof最老未完成优先Longest Outstanding First。策略平均延迟P99 延迟吞吐 (QPS)fcfs默认105ms450ms285priority98ms380ms278lof88ms210ms292图2三种调度策略的延迟对比建议lof 策略在混合负载下表现最均衡吞吐没有明显下降但 P99 大幅改善。如果你的业务对延迟敏感优先考虑 lof。6、num-scheduler-steps多步调度默认值 1意味着每次推理完成后调度器都要重新调度一次。调大这个值可以让调度器一次调度多步推理减少调度器唤醒频率降低 CPU 到 GPU 的通信开销。与 async scheduling 配合使用时效果叠加——Async Scheduling 让调度和推理流水线并行而多步调度让每次调度覆盖更多推理步骤。设置值吞吐 (QPS)调度开销占比延迟影响1默认215~8%基准4250~3%5%8265~2%12%16272~1%35%建议8 是甜点值吞吐 23%延迟增加完全可以接受。超过 8 以后吞吐增长趋缓但延迟会显著抬高。7、speculative-model推测解码思路很巧妙用一个小模型先快速生成一批候选 tokendraft大模型只需要并行验证这些 token 的正确性。如果 draft model 猜得准吞吐可以大幅提升。v0.20.0 将推测解码与 async scheduling 深度集成实测效果非常惊艳。但有一个前提draft model 的接受率acceptance rate够高生成的 token 风格和目标模型一致。配置吞吐 (QPS)提升比例额外显存无推测解码215基准0 Qwen-0.5B (5 tokens)31044%~2 GB Qwen-0.5B (8 tokens)33556%~2 GB Qwen-1.5B (5 tokens)32551%~4 GB图3推测解码对不同模型的吞吐提升建议Qwen-0.5B 作为 draft model 8 个推测 token 的组合性价比最高额外只占 2GB 显存提升 56%。建议先用自己的业务数据验证接受率再决定是否生产使用。七参数提升效果一览图47 个参数的独立提升效果对比终极配置模板A100 80G Qwen-14B以下组合在测试环境中表现最优建议先在灰度环境验证python -m vllm.entrypoints.openai.api_server \ --model Qwen-14B \ --max-num-seqs 256 \ --max-model-len 8192 \ # 根据业务 P99 调整 --gpu-memory-utilization 0.95 \ --enable-prefix-caching \ --scheduling-policy lof \ --num-scheduler-steps 8 \ --speculative-model Qwen-0.5B \ --num-speculative-tokens 8优化前后对比图5优化前后整体性能对比场景配置速查 极致吞吐max-num-seqs512 speculative steps16 → 靠后两个参数贡献主要提升延迟会相对偏高⚡ 低延迟优先max-num-seqs64 lof prefix-caching → P99 可稳定在 200ms 以内 显存受限多卡max-model-len4096 gpu-memory0.95 → 单卡多任务部署时首选 均衡全能终极模板配置 → 适合大多数生产场景建议作为 baseline 开始微调⚠️ 生产建议一定要先测试这些参数只是参考起点原因很简单你的硬件和模型组合可能跟我的测试环境完全不同——• A100 vs H100 vs H200性能特征差异显著• Dense 模型 vs MoE 模型对参数的敏感度不同• 量化方式FP16 / INT4 / FP8影响显存和计算效率• 请求分布短序列多并发 vs 长序列少并发影响策略选择我的标准流程① 用终极模板作为 baseline 启动② 跑vllm bench throughput和vllm bench latency工具压测③ 逐个参数调整每次只改一个对比 benchmark 结果④ 确认无退化后灰度上线⑤ 持续监控 P99 延迟和 OOM 频率参数调优是手艺活跑出自己的数据才是真本事。A100 80G · Qwen-14B-INT4 · vLLM 0.20.0 · CUDA 12.4转自https://mp.weixin.qq.com/s/6fuzb91yzwinoUWAwk4sDQ