vLLM 新参数 performance-mode 能带来多大提升？Qwen3.5 实测告诉你答案

vLLM 最近新增了--performance-mode {balanced, interactivity, throughput}。从命名上看这像是一个直接面向用户的性能选项交互优先、吞吐优先或者保持平衡。这类参数很容易让人产生一种直觉既然已经明确区分了交互和吞吐那实际部署时是不是只要选对 mode性能就会自然往正确方向走。但真正把实验跑完之后会发现问题没有这么简单。有些场景下单独打开performance-mode并没有直接带来收益有些场景下它要和量化、prefix cache、speculative decoding 叠在一起看才能看出价值。真正值得关注的可能不是“它能不能单独提速”而是 vLLM 正在把推理调优从“逐个猜参数”往“先按目标收敛方向”推进。这篇文章主要回答三个问题performance-mode当前到底解决了什么问题在真实 workload 下它单独使用时效果如何它和 backend、量化、prefix cache、speculative decoding 这些常见优化手段相比应该放在什么位置看实验数据来自两组测试Qwen3.5-9B on NVIDIA H100 80GB HBM3Qwen3.5-35B-A3B on NVIDIA H200Performance-mode 到底是什么截至 2026 年 3 月 30 日performance-mode 来自 vLLM PRhttps://github.com/vllm-project/vllm/pull/34936 并已于 2026 年 2 月 26 日合并进主分支该功能从 v0.17.0 开始提供。当前 vLLM 文档中这个参数提供三个选项balancedinteractivitythroughput官方文档对它的说明比较明确interactivity偏向小 batch 下更低的端到端请求延迟throughput偏向高并发下更高的 aggregate tokens/secbalanced保持默认行为从 PR 描述来看这一版实现主要体现为interactivity使用更细粒度的 CUDA graph 捕获偏向低延迟场景throughput使用更激进的 batch 上限偏向高吞吐场景因此当前更适合把它看成一个“性能目标入口”而不是一个独立完成优化的参数。这轮实验想回答什么如果只问一句“performance-mode有没有用”结论很容易过于简单。更实际的问题是单独启用某个 mode 时效果如何它和 backend、量化、prefix cache、speculative decoding 相比优先级在哪里它带来的主要变化是不是更多体现在“缩小调优范围”而不是直接决定最终性能本文主要基于以下实验文档整理Qwen3.5-9B on H100 吞吐优化实验https://docs.gpustack.ai/latest/performance-lab/qwen3.5-9b/h100/Qwen3.5-9B on H100 时延优化实验https://docs.gpustack.ai/latest/performance-lab/qwen3.5-9b/h100-latency/Qwen3.5-35B-A3B on H200 吞吐优化实验https://docs.gpustack.ai/latest/performance-lab/qwen3.5-35b-a3b/h200/Qwen3.5-35B-A3B on H200 时延优化实验https://docs.gpustack.ai/latest/performance-lab/qwen3.5-35b-a3b/h200-latency/给当前 performance-mode 一个更准确的定位如果要给当前的performance-mode一个比较准确的定位可以概括为一句话它不是替代实验的性能开关而是一个把调优从“猜参数”推进到“按目标调优”的入口。这背后主要是三点它能提供一个更合理的起点偏交互场景可以先从interactivity开始偏吞吐场景可以先从throughput开始。它不能替代完整实验单开某个 mode 不一定直接带来收益很多情况下仍然要结合 engine、量化、cache 和 speculative decoding 一起看。它缩短的是调优空间以前往往需要先从很多底层参数里反复试现在至少可以先把问题收敛成一句话当前是在优化交互还是在优化吞吐。Throughputthroughput 模式更像组合优化的一部分Qwen3.5-9B / H100backend 基线Profile:ShareGPTBackendTotal TPSMean LatencyMean TTFTMean TPOTvLLM11527.1424.11s1604.23ms15.12msSGLang6499.4139.08s26217.15ms138.86ms这组结果说明在这套实验里后续的performance-mode调优是建立在“先选定 vLLM 作为更优 backend”的基础上的。调优过程调优步骤配置特征Total TPS相对基线基线vLLM 默认配置11527.141.00xPrefix Cache--enable-prefix-caching11224.700.97xSpeculative Decodingspeculative decoding15059.89成功率 51.5%未纳入最终方案只开throughput--performance-modethroughput11496.390.997x调max-num-seqs更高并发窗口11532.641.0005xthroughput batched tokens更大 batch token11672.721.013xthroughputmax-num-seqs512最终推荐配置11768.221.021x这组结果比较清楚地说明单独启用throughput并没有直接带来收益收益主要出现在它和max-num-seqs、max-batched-tokens等参数联动之后最终结果推荐配置vllm serve Qwen/Qwen3.5-9B\--reasoning-parserqwen3\--performance-modethroughput\--max-model-len32768\--max-num-seqs512不同 profile 下的结果如下Profile基线优化后变化ShareGPT ProfileTotal TPS: 11527.14 / Mean TPOT: 15.12msTotal TPS: 11768.22 / Mean TPOT: 15.85ms2.09%Throughput ProfileTotal TPS: 29822.16 / Mean TPOT: 34.63msTotal TPS: 34470.14 / Mean TPOT: 36.97ms15.59%Long Context ProfileTotal TPS: 32416.84 / Mean TPOT: 10.21msTotal TPS: 32658.73 / Mean TPOT: 9.97ms0.75%Generation Heavy ProfileTotal TPS: 2973.42 / Mean TPOT: 0.33msTotal TPS: 3025.11 / Mean TPOT: 0.12ms1.74%Qwen3.5-35B-A3B / H200backend 基线Profile:ShareGPTBackendTotal TPSMean LatencyMean TTFTMean TPOTvLLM9632.0130.19s4072.64ms25.89msSGLang4995.6650.86s34359.37ms180.73ms调优过程调优步骤配置特征Total TPS相对基线基线vLLM 默认配置9632.011.00xQuantizationFP89942.931.032xPrefix Cache Quantizationprefix cache FP810338.961.073xthroughput Prefix Cache Quantization最终主路径10570.881.097xKV Cache Dtype 上述组合更复杂组合10363.771.076xSpeculative Decoding Quantizationspeculative decoding FP815514.15成功率 51.6%未纳入最终方案这一组更适合用来说明 throughput 的真实位置第一层收益来自量化第二层收益来自 prefix cache第三层才是 throughput也就是说它的作用更接近“在合理配置基础上继续往吞吐方向收敛”。最终结果推荐配置vllm serve Qwen/Qwen3.5-35B-A3B-FP8\--reasoning-parserqwen3\--performance-modethroughput\--max-model-len32768\--enable-prefix-caching不同 profile 下的结果如下Profile基线优化后变化ShareGPT ProfileTotal TPS: 9632.01 / Mean TPOT: 25.89msTotal TPS: 10570.88 / Mean TPOT: 24.71ms9.75%Throughput ProfileTotal TPS: 37934.72 / Mean TPOT: 45.39msTotal TPS: 50464.84 / Mean TPOT: 41.12ms33.03%Long Context ProfileTotal TPS: 44993.20 / Mean TPOT: 319.79msTotal TPS: 56424.42 / Mean TPOT: 227.43ms25.41%Generation Heavy ProfileTotal TPS: 10455.38 / Mean TPOT: 2.48msTotal TPS: 12258.79 / Mean TPOT: 2.92ms17.25%Latencyinteractivity 有帮助但通常不是最先起效的变量Qwen3.5-9B / H100backend 基线Profile:ShareGPT 8RPSBackendMean LatencyMean TTFTMean TPOTTotal TPSvLLM2.62s41.12ms1.34ms4867.84SGLang8.13s98.72ms28.88ms4754.13调优过程调优步骤配置特征Mean Latency相对基线基线vLLM 默认配置2.62s1.00xPrefix Cache--enable-prefix-caching2.69s0.97xMax Batch Token调 batch token2.64s0.99xMax Num Seqs调 seqs2.64s0.99xSpeculative Decodingspeculative decoding2.39s1.09xSpeculative interactivity加--performance-modeinteractivity2.38s1.10xSpeculative interactivity--language-model-only最终推荐配置2.32s1.13x这组数据说明interactivity的作用更多是进一步细调而不是单独决定低延迟结果。最终结果vllm serve Qwen/Qwen3.5-9B\--reasoning-parserqwen3\--max-model-len32768\--speculative-config{method:mtp,num_speculative_tokens:1}\--language-model-only\--performance-modeinteractivityProfile基线优化后变化Rate 1Mean latency: 2.09sMean latency: 1.65s1.26x fasterRate 4Mean latency: 2.33sMean latency: 1.90s1.23x fasterRate 8Mean latency: 2.62sMean latency: 2.32s1.13x fasterRate 16Mean latency: 4.37sMean latency: 3.72s1.17x fasterQwen3.5-35B-A3B / H200backend 基线Profile:ShareGPT 8RPSBackendMean LatencyMean TTFTMean TPOTTotal TPSvLLM5.32s68.48ms2.35ms4734.87SGLang25.15s6456.42ms89.37ms4201.01调优过程调优步骤配置特征Mean Latency相对基线基线vLLM 默认配置5.32s1.00xQuantizationFP83.53s1.51xCUDA Graph Quantization调 graph capture FP83.54s1.50xMax Batch Token Quantizationbatch token FP83.82s1.39xinteractivity Quantizationperformance-modeinteractivity FP83.67s1.45xPrefix Cache Quantizationprefix cache FP83.70s1.44xSpeculative Decoding Quantizationspeculative decoding FP83.28s1.63x这组数据更适合说明另一点在大模型低延迟场景里更先起效的往往是量化和 speculative decoding而不是 interactivity 本身。最终结果vllm serve Qwen/Qwen3.5-35B-A3B-FP8\--reasoning-parserqwen3\--speculative-config{method:mtp,num_speculative_tokens:1}\--max-model-len32768Profile基线优化后变化Rate 1Mean latency: 1.85sMean latency: 1.50s1.23x fasterRate 4Mean latency: 3.30sMean latency: 2.52s1.31x fasterRate 8Mean latency: 5.32sMean latency: 3.28s1.63x fasterRate 16Mean latency: 18.59sMean latency: 6.79s2.74x fasterbenchmark 真正解决的是结果能不能回到上下文里看推理优化里真正消耗时间的通常不是想到一个优化点而是把它稳定地跑完、比完再确认结论是否只在某个 profile 下成立。一个完整 benchmark 过程通常需要反复处理这些事情部署不同 backend切换不同模型配置提交不同 benchmark profile收集结果回看详细指标对照模型配置和运行环境确认结果边界所以 benchmark 工具的重要性更多在于两点1. 快速横向比较不同实验不同 profile、不同 backend、不同配置之间的快速比较。2. 完整保留实验细节这些信息是否完整直接决定后面的性能结论能不能复盘。为什么实验方法比单次结果更重要这次把整套实验串起来之后一个比较直观的感受是真正麻烦的不是“有没有优化点”而是“实验过程能不能组织清楚”。尤其是在同时比较这些维度的时候不同 backend不同量化方式不同 speculative decoding 配置不同 benchmark profile不同运行环境如果这些信息是分散的最后很容易只留下一个模糊印象比如“某个参数好像有效”但不容易回到具体实验上下文里确认它到底在什么条件下有效。从这个角度看GPUStack 更像是把部署、benchmark、结果查看和配置记录放在了一条链路里。这样做的意义不是替实验下结论而是让结论更容易回到原始实验里核对。对这类性能调优工作来说这一点往往比单次结果更重要。结论这轮实验看下来performance-mode的位置已经比较清楚它不是一个单独决定性能结果的参数但它确实提供了一个更明确的调优起点。对于交互和吞吐这两类目标这种“先按目标收敛方向再进入具体实验”的方式比直接从一堆底层参数开始尝试要更有效率。把前面的实验步骤串起来看GPUStack 承接的其实不是某一个单独参数而是一整条从模型部署、模型调优到结果回顾的流程。模型部署先把模型以可测试、可切换的方式部署起来为后续 backend 对比和 benchmark 实验建立统一起点。模型调优在同一套 benchmark 流程里比较 backend、量化、缓存策略、投机解码和performance-mode等不同优化手段判断哪种组合在当前模型与负载下更有效。结果回顾不只是看一次跑分结果还可以结合成功率、稳定性、配置和运行环境把实验结果放回上下文里复盘确认哪些结论值得保留。快速 benchmark把原本漫长、零散、手工化的试错流程尽量收敛成一个可重复、可比较、可回看的实验过程。参考资料vLLM PR: https://github.com/vllm-project/vllm/pull/34936vLLM 文档: Engine Argumentshttps://docs.vllm.ai/en/latest/configuration/engine_args/实验数据: Qwen3.5-9B on H100 吞吐优化实验https://docs.gpustack.ai/latest/performance-lab/qwen3.5-9b/h100/实验数据: Qwen3.5-9B on H100 时延优化实验https://docs.gpustack.ai/latest/performance-lab/qwen3.5-9b/h100-latency/实验数据: Qwen3.5-35B-A3B on H200 吞吐优化实验https://docs.gpustack.ai/latest/performance-lab/qwen3.5-35b-a3b/h200/实验数据: Qwen3.5-35B-A3B on H200 时延优化实验https://docs.gpustack.ai/latest/performance-lab/qwen3.5-35b-a3b/h200-latency/加入 GPUStack 社区GPUStack 社区聚焦AI 基础设施与大模型实践。社区中持续分享真实环境下的部署经验、问题排查案例以及推理引擎、算力管理和系统架构相关讨论。欢迎扫码加入 GPUStack 社区与更多关注 AI Infra 与大模型推理实践的伙伴一起交流、学习与分享。若群聊已满或二维码失效请访问以下页面查看最新群二维码https://github.com/gpustack/gpustack/blob/main/docs/assets/wechat-group-qrcode.jpg