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

GPUStack
0 阅读9分钟

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 HBM3
  • Qwen3.5-35B-A3B on NVIDIA H200

Performance-mode 到底是什么

截至 2026 年 3 月 30 日，performance-mode 来自 vLLM PR github.com/vllm-projec… ，并已于 2026 年 2 月 26 日合并进主分支，该功能从 v0.17.0 开始提供。

当前 vLLM 文档中，这个参数提供三个选项：

  • balanced
  • interactivity
  • throughput

官方文档对它的说明比较明确：

  • interactivity 偏向小 batch 下更低的端到端请求延迟
  • throughput 偏向高并发下更高的 aggregate tokens/sec
  • balanced 保持默认行为

从 PR 描述来看，这一版实现主要体现为：

  • interactivity 使用更细粒度的 CUDA graph 捕获，偏向低延迟场景
  • throughput 使用更激进的 batch 上限，偏向高吞吐场景

因此，当前更适合把它看成一个：

“性能目标入口”，而不是一个独立完成优化的参数。

这轮实验想回答什么

如果只问一句“performance-mode 有没有用”，结论很容易过于简单。 更实际的问题是：

  • 单独启用某个 mode 时，效果如何
  • 它和 backend、量化、prefix cache、speculative decoding 相比，优先级在哪里
  • 它带来的主要变化，是不是更多体现在“缩小调优范围”，而不是直接决定最终性能

本文主要基于以下实验文档整理：

给当前 performance-mode 一个更准确的定位

如果要给当前的 performance-mode 一个比较准确的定位，可以概括为一句话：

它不是替代实验的性能开关，而是一个把调优从“猜参数”推进到“按目标调优”的入口。

这背后主要是三点：

  1. 它能提供一个更合理的起点 偏交互场景，可以先从 interactivity 开始；偏吞吐场景，可以先从 throughput 开始。

  2. 它不能替代完整实验 单开某个 mode 不一定直接带来收益，很多情况下仍然要结合 engine、量化、cache 和 speculative decoding 一起看。

  3. 它缩短的是调优空间 以前往往需要先从很多底层参数里反复试；现在至少可以先把问题收敛成一句话： 当前是在优化交互，还是在优化吞吐。

Throughput：throughput 模式更像组合优化的一部分

Qwen3.5-9B / H100

backend 基线

Profile: ShareGPT

BackendTotal TPSMean LatencyMean TTFTMean TPOT
vLLM11527.1424.11s1604.23ms15.12ms
SGLang6499.4139.08s26217.15ms138.86ms

这组结果说明，在这套实验里，后续的 performance-mode 调优是建立在“先选定 vLLM 作为更优 backend”的基础上的。

调优过程

调优步骤配置特征Total TPS相对基线
基线vLLM 默认配置11527.141.00x
Prefix Cache--enable-prefix-caching11224.700.97x
Speculative Decodingspeculative decoding15059.89成功率 51.5%，未纳入最终方案
只开 throughput--performance-mode=throughput11496.390.997x
调 max-num-seqs更高并发窗口11532.641.0005x
throughput + batched tokens更大 batch token11672.721.013x
throughput + max-num-seqs=512最终推荐配置11768.221.021x

这组结果比较清楚地说明：

  • 单独启用 throughput，并没有直接带来收益
  • 收益主要出现在它和 max-num-seqs、max-batched-tokens 等参数联动之后

最终结果

推荐配置：

vllm serve Qwen/Qwen3.5-9B \
  --reasoning-parser=qwen3 \
  --performance-mode=throughput \
  --max-model-len=32768 \
  --max-num-seqs=512

不同 profile 下的结果如下：

Profile基线优化后变化
ShareGPT ProfileTotal TPS: 11527.14 / Mean TPOT: 15.12msTotal TPS: 11768.22 / Mean TPOT: 15.85ms+2.09%
Throughput ProfileTotal TPS: 29822.16 / Mean TPOT: 34.63msTotal TPS: 34470.14 / Mean TPOT: 36.97ms+15.59%
Long Context ProfileTotal TPS: 32416.84 / Mean TPOT: 10.21msTotal TPS: 32658.73 / Mean TPOT: 9.97ms+0.75%
Generation Heavy ProfileTotal TPS: 2973.42 / Mean TPOT: 0.33msTotal TPS: 3025.11 / Mean TPOT: 0.12ms+1.74%

Qwen3.5-35B-A3B / H200

backend 基线

Profile: ShareGPT

BackendTotal TPSMean LatencyMean TTFTMean TPOT
vLLM9632.0130.19s4072.64ms25.89ms
SGLang4995.6650.86s34359.37ms180.73ms

调优过程

调优步骤配置特征Total TPS相对基线
基线vLLM 默认配置9632.011.00x
QuantizationFP89942.931.032x
Prefix Cache + Quantizationprefix cache + FP810338.961.073x
throughput + Prefix Cache + Quantization最终主路径10570.881.097x
KV Cache Dtype + 上述组合更复杂组合10363.771.076x
Speculative Decoding + Quantizationspeculative decoding + FP815514.15成功率 51.6%，未纳入最终方案

这一组更适合用来说明 throughput 的真实位置：

  • 第一层收益来自量化
  • 第二层收益来自 prefix cache
  • 第三层才是 throughput

也就是说，它的作用更接近“在合理配置基础上继续往吞吐方向收敛”。

最终结果

推荐配置：

vllm serve Qwen/Qwen3.5-35B-A3B-FP8 \
  --reasoning-parser=qwen3 \
  --performance-mode=throughput \
  --max-model-len=32768 \
  --enable-prefix-caching

不同 profile 下的结果如下：

Profile基线优化后变化
ShareGPT ProfileTotal TPS: 9632.01 / Mean TPOT: 25.89msTotal TPS: 10570.88 / Mean TPOT: 24.71ms+9.75%
Throughput ProfileTotal TPS: 37934.72 / Mean TPOT: 45.39msTotal TPS: 50464.84 / Mean TPOT: 41.12ms+33.03%
Long Context ProfileTotal TPS: 44993.20 / Mean TPOT: 319.79msTotal TPS: 56424.42 / Mean TPOT: 227.43ms+25.41%
Generation Heavy ProfileTotal TPS: 10455.38 / Mean TPOT: 2.48msTotal TPS: 12258.79 / Mean TPOT: 2.92ms+17.25%

Latency：interactivity 有帮助，但通常不是最先起效的变量

Qwen3.5-9B / H100

backend 基线

Profile: ShareGPT 8RPS

BackendMean LatencyMean TTFTMean TPOTTotal TPS
vLLM2.62s41.12ms1.34ms4867.84
SGLang8.13s98.72ms28.88ms4754.13

调优过程

调优步骤配置特征Mean Latency相对基线
基线vLLM 默认配置2.62s1.00x
Prefix Cache--enable-prefix-caching2.69s0.97x
Max Batch Token调 batch token2.64s0.99x
Max Num Seqs调 seqs2.64s0.99x
Speculative Decodingspeculative decoding2.39s1.09x
Speculative + interactivity加 --performance-mode=interactivity2.38s1.10x
Speculative + interactivity + --language-model-only最终推荐配置2.32s1.13x

这组数据说明，interactivity 的作用更多是进一步细调，而不是单独决定低延迟结果。

最终结果

vllm serve Qwen/Qwen3.5-9B \
  --reasoning-parser=qwen3 \
  --max-model-len=32768 \
  --speculative-config={"method":"mtp","num_speculative_tokens":1} \
  --language-model-only \
  --performance-mode=interactivity
Profile基线优化后变化
Rate 1Mean latency: 2.09sMean latency: 1.65s1.26x faster
Rate 4Mean latency: 2.33sMean latency: 1.90s1.23x faster
Rate 8Mean latency: 2.62sMean latency: 2.32s1.13x faster
Rate 16Mean latency: 4.37sMean latency: 3.72s1.17x faster

Qwen3.5-35B-A3B / H200

backend 基线

Profile: ShareGPT 8RPS

BackendMean LatencyMean TTFTMean TPOTTotal TPS
vLLM5.32s68.48ms2.35ms4734.87
SGLang25.15s6456.42ms89.37ms4201.01

调优过程

调优步骤配置特征Mean Latency相对基线
基线vLLM 默认配置5.32s1.00x
QuantizationFP83.53s1.51x
CUDA Graph + Quantization调 graph capture + FP83.54s1.50x
Max Batch Token + Quantizationbatch token + FP83.82s1.39x
interactivity + Quantizationperformance-mode=interactivity + FP83.67s1.45x
Prefix Cache + Quantizationprefix cache + FP83.70s1.44x
Speculative Decoding + Quantizationspeculative decoding + FP83.28s1.63x

这组数据更适合说明另一点：在大模型低延迟场景里，更先起效的往往是量化和 speculative decoding，而不是 interactivity 本身。

最终结果

vllm serve Qwen/Qwen3.5-35B-A3B-FP8 \
  --reasoning-parser=qwen3 \
  --speculative-config={"method":"mtp","num_speculative_tokens":1} \
  --max-model-len=32768
Profile基线优化后变化
Rate 1Mean latency: 1.85sMean latency: 1.50s1.23x faster
Rate 4Mean latency: 3.30sMean latency: 2.52s1.31x faster
Rate 8Mean latency: 5.32sMean latency: 3.28s1.63x faster
Rate 16Mean latency: 18.59sMean latency: 6.79s2.74x faster

benchmark 真正解决的，是结果能不能回到上下文里看

推理优化里，真正消耗时间的通常不是想到一个优化点，而是把它稳定地跑完、比完，再确认结论是否只在某个 profile 下成立。

一个完整 benchmark 过程通常需要反复处理这些事情：

  • 部署不同 backend
  • 切换不同模型配置
  • 提交不同 benchmark profile
  • 收集结果
  • 回看详细指标
  • 对照模型配置和运行环境确认结果边界

所以 benchmark 工具的重要性，更多在于两点：

1. 快速横向比较不同实验

不同 profile、不同 backend、不同配置之间的快速比较。

2. 完整保留实验细节

这些信息是否完整，直接决定后面的性能结论能不能复盘。

为什么实验方法比单次结果更重要

这次把整套实验串起来之后，一个比较直观的感受是：真正麻烦的不是“有没有优化点”，而是“实验过程能不能组织清楚”。

尤其是在同时比较这些维度的时候：

  • 不同 backend
  • 不同量化方式
  • 不同 speculative decoding 配置
  • 不同 benchmark profile
  • 不同运行环境

如果这些信息是分散的，最后很容易只留下一个模糊印象，比如“某个参数好像有效”，但不容易回到具体实验上下文里确认它到底在什么条件下有效。

从这个角度看，GPUStack 更像是把部署、benchmark、结果查看和配置记录放在了一条链路里。这样做的意义，不是替实验下结论，而是让结论更容易回到原始实验里核对。

对这类性能调优工作来说，这一点往往比单次结果更重要。

结论

这轮实验看下来，performance-mode 的位置已经比较清楚：

它不是一个单独决定性能结果的参数，但它确实提供了一个更明确的调优起点。对于交互和吞吐这两类目标，这种“先按目标收敛方向，再进入具体实验”的方式，比直接从一堆底层参数开始尝试要更有效率。

把前面的实验步骤串起来看，GPUStack 承接的其实不是某一个单独参数，而是一整条从模型部署、模型调优到结果回顾的流程。

  1. 模型部署 先把模型以可测试、可切换的方式部署起来，为后续 backend 对比和 benchmark 实验建立统一起点。

  2. 模型调优 在同一套 benchmark 流程里比较 backend、量化、缓存策略、投机解码和 performance-mode 等不同优化手段，判断哪种组合在当前模型与负载下更有效。

  3. 结果回顾 不只是看一次跑分结果，还可以结合成功率、稳定性、配置和运行环境，把实验结果放回上下文里复盘，确认哪些结论值得保留。

  4. 快速 benchmark 把原本漫长、零散、手工化的试错流程，尽量收敛成一个可重复、可比较、可回看的实验过程。

参考资料

加入 GPUStack 社区

GPUStack 社区聚焦 AI 基础设施与大模型实践。

社区中持续分享真实环境下的部署经验、问题排查案例，以及推理引擎、算力管理和系统架构相关讨论。

欢迎扫码加入 GPUStack 社区，与更多关注 AI Infra 与大模型推理实践的伙伴一起交流、学习与分享。

社区群二维码

若群聊已满或二维码失效，请访问以下页面查看最新群二维码： github.com/gpustack/gp…

avatar
文章
阅读
粉丝