我在本地单节点双卡服务器上做了一次vLLM 部署测试：哪些参数真的有用？

最近我在本地一台单节点双卡服务器上做了一轮 vLLM
部署测试。目的并不是跑一个“最好看”的
benchmark，而是想回答一个更实际的问题：

在自己的服务器上部署大模型时，vLLM
的不同参数配置，到底会对真实推理性能带来多大影响？

这类问题我之前其实一直是“知道有这些参数”，但并没有真正系统地测过。比如：optimization_level
要开到几级？performance_mode 选 throughput 还是
interactivity？YaRN、MTP、expert parallel
这些开关到底值不值得动？

所以这次我干脆把它们拆开做了一轮测试，整理成这篇实验记录。整篇文章更偏向个人实践总结，适合和我一样想在本地服务器上体验
vLLM 部署、调参和性能分析的人参考。

---

一、测试背景

这次测试的场景非常明确：

• 部署方式：本地单节点双卡服务器
• 推理框架：vLLM
• 测试目标：比较不同部署参数组合对吞吐、首 token
  延迟、单 token 生成时间和端到端时延的影响
• 关注重点：
  • 低并发场景下，怎样的配置更适合“交互式使用”
  • 高并发场景下，怎样的配置更适合“压榨吞吐”

换句话说，这次测试不是想证明某个参数“理论上先进”，而是想回答一个工程问题：

如果我手里只有一台本地双卡机器，想把 vLLM
部署得更实用，我应该优先关注哪些参数？

---

二、测试环境与方法

1. 测试环境

从实验记录来看，本次测试使用的是一套固定的部署环境：

• 单节点双卡
• tensor_parallel_size = 2
• max_model_len = 81920
• 输入长度：512
• 输出长度：256
• 温度：0
• 每组测试请求数：100

测试中使用了两类并发场景：

• 低并发：max_concurrency = 2
• 高并发：max_concurrency = 100

我把它们理解成两种典型使用方式：

• 低并发更像本地交互、少量用户或自己调试时的场景。
• 高并发更像压测、批量请求或者多人共用服务时的场景。

2. 对比的配置项

这次一共测试了 10 组配置，每组在低并发 /
高并发两个场景下各跑 2 次重复实验，总共
40 条结果。

主要对比的变量包括：

• optimization_level = 0 / 1 / 2 / 3
• performance_mode = throughput / balanced / interactivity
• 是否开启 expert parallel
• 是否开启 YaRN
• 是否开启 MTP
• 是否设置 cp_kv_cache_interleave_size = 16

3. 关注的指标

本次主要看以下几个指标：

• request throughput：请求吞吐
• output throughput：输出 token 吞吐
• TTFT（Time To First Token）：首 token 延迟
• TPOT（Time Per Output Token）：平均单 token
  生成耗时
• E2EL（End-to-End Latency）：端到端时延

这些指标组合在一起，基本能反映一套推理配置到底是偏“交互体验”还是偏“吞吐效率”。

---

三、整体结论先说

如果只让我先说结论，我会总结成下面几句话：

1. optimization_level 从 0 升到
   2/3，性能提升非常明显，Opt0 基本不建议使用。
2. 低并发场景下，保留 MTP 更好；关闭 MTP
   会明显拉低吞吐并拉长端到端时延。
3. 高并发场景下，关闭 MTP
   反而是这批测试里表现最好的配置。
4. YaRN、performance_mode、expert parallel
   的影响都存在，但远小于 optimization_level 和
   MTP 开关。
5. Opt2 和 Opt3
   已经很接近，很多情况下真正决定结果的不是“再微调一点
   mode”，而是有没有踩到关键参数。

也就是说，这次实验最有价值的地方并不是发现了某个“神奇参数”，而是让我更清楚地看到：

在 vLLM
本地部署里，真正一锤定音的配置项其实没有那么多，最关键的就那几个。

---

四、低并发场景：更像真实交互使用

先看低并发，也就是 max_concurrency = 2 的情况。

在这个场景里，Opt3 是一个很强的基准配置：

• 请求吞吐：1.035 req/s
• 输出吞吐：264.879 tok/s
• 平均 TTFT：169.859 ms
• 平均 E2EL：1930.785 ms

1. Opt0 和 Opt1 的差距非常明显

最差的配置是 Opt0：

• 请求吞吐只有 0.169 req/s
• 输出吞吐只有 43.373 tok/s
• 平均 E2EL 高达 11796.860 ms

和 Opt3 相比，Opt0：

• 请求吞吐下降约 83.7%
• 输出吞吐下降约 83.6%
• 端到端时延增加约 511%

这个结果其实很直观：optimization_level
不开起来，很多优化根本没吃到，最终会让整套服务从“可用”变成“非常笨重”。

Opt1 虽然比 Opt0 好很多，但和 Opt3 仍然有明显差距：

• 请求吞吐 0.733 req/s
• 平均 E2EL 2724.515 ms

相比 Opt3，吞吐仍低约 29%，端到端时延高约
41%。所以如果机器和模型允许，Opt1
也不算一个理想选择。

2. Opt2 和 Opt3 已经非常接近

Opt2 的结果是：

• 请求吞吐 1.026 req/s
• 输出吞吐 262.748 tok/s
• 平均 E2EL 1945.348 ms

和 Opt3 相比，差距都在 1%
左右。这说明在低并发场景下，Opt2
基本已经吃到了大部分性能收益，Opt3
更多是进一步打磨，而不是本质性跃升。

3. 关闭 MTP 会明显变差

低并发下，我最关注的一个现象是：关闭 MTP
会明显伤害性能。

关闭 MTP 后：

• 请求吞吐：0.798 req/s
• 输出吞吐：204.313 tok/s
• 平均 E2EL：2505.243 ms

相对 Opt3：

• 请求吞吐下降约 22.9%
• 输出吞吐下降约 22.9%
• 平均 E2EL 增加约 29.8%

也就是说，在低并发交互场景里，MTP
是有明显正收益的。如果你的主要使用方式是自己在本地交互、少量用户调用，或者更重视响应体验，那么我会倾向于保留
MTP。

4. 其他参数影响相对有限

剩下几个变量——YaRN、Balanced 模式、Interactivity 模式、关闭
expert parallel——在低并发里变化都不大。

例如：

• 关闭 YaRN：几乎和 Opt3 持平
• Balanced 模式：和 Opt3 基本同级
• Interactivity 模式：没有出现特别突出的优势
• 关闭 EP：甚至略好一点，但幅度很小

这说明在低并发场景下，真正影响体验的不是这些“细分 mode”，而是：

1. 你的优化等级是不是太低；
2. 你有没有把 MTP 关掉。

---

五、高并发场景：更接近压测与共享服务

再看高并发，也就是 max_concurrency = 100 的情况。

Opt3 在高并发下的基准结果是：

• 请求吞吐：6.497 req/s
• 输出吞吐：1663.330 tok/s
• 平均 TTFT：4670.809 ms
• 平均 E2EL：14881.842 ms

这个场景下，最有意思的地方来了。

1. 关闭 MTP 反而成了最优配置

在高并发测试里，关闭 MTP 的结果最好：

• 请求吞吐：6.974 req/s
• 输出吞吐：1785.471 tok/s
• 平均 TTFT：4078.795 ms
• 平均 E2EL：14302.512 ms

相对 Opt3：

• 请求吞吐提升约 7.3%
• 输出吞吐提升约 7.3%
• 平均 TTFT 降低约 12.7%
• 平均 E2EL 降低约 3.9%

这个结论和低并发正好相反。

我的理解是：在高并发压力下，系统已经不再是“单个请求是否更快”这么简单，而是要考虑整体调度、资源竞争和吞吐效率。在这种情况下，MTP
带来的额外机制未必总是净收益，甚至可能拖累整体并发效率。

所以如果你的使用目标更接近：

• 多请求批量跑
• 多人共享推理服务
• 想尽可能榨出吞吐

那么这组数据给出的建议很明确：可以认真考虑关闭 MTP
测一轮。

2. Opt0 依然明显落后

高并发下 Opt0 也还是最差的一档：

• 请求吞吐：5.379 req/s
• 输出吞吐：1377.060 tok/s
• 平均 E2EL：17076.570 ms

虽然高并发下它没有像低并发那样“崩得特别夸张”，但相对 Opt3 依旧：

• 吞吐下降约 17.2%
• 端到端时延增加约 14.7%

所以我的结论还是一样：Opt0 不推荐。

3. Opt1 / Opt2 / Opt3 差距并不大

高并发下，Opt1、Opt2、Opt3 三者非常接近：

• Opt1：6.523 req/s
• Opt2：6.581 req/s
• Opt3：6.497 req/s

Opt2 相比 Opt3 只高了约 1.3%，而 Opt1 也只高了约
0.4%。这说明在高并发场景里，optimization_level
从 1 到 3 的收益已经没有从 0 到 1
那么夸张，系统更像是在一个高位平台上微调。

4.
YaRN、performance_mode、EP 的影响依然较小

高并发下：

• 关闭 YaRN：比 Opt3 略好一点
• Balanced / Interactivity 模式：都比 Opt3
  小幅改善
• 关闭 EP：略差一点

这些变化整体都在小范围内波动。相比之下，关闭 MTP
带来的差异最清晰，也最有工程意义。

---

六、这次测试让我真正记住的几点

做完这轮实验以后，我觉得自己对 vLLM
的理解比之前清晰很多，尤其是下面几点。

1. 不是所有参数都值得同等关注

在没有系统测试之前，很容易对一堆参数都有“是不是该调一下”的冲动。但这轮结果告诉我：

• 真正关键的，优先看
  optimization_level
• 其次要重点关注 MTP
• performance_mode、YaRN、expert parallel
  更适合在前两者稳定后做细调

也就是说，调参不是“把所有开关都试一遍”，而是应该先找出真正高影响的变量。

2.
同一个参数，在不同负载下可能结论相反

MTP 是这次最典型的例子：

• 低并发下，开着更好
• 高并发下，关掉更好

这件事很重要，因为它提醒我：

推理部署里的“最优配置”不是绝对的，而是和你的使用场景绑定的。

如果不区分场景，只看单一 benchmark，很容易得出错误结论。

3.
本地部署学习的价值，不只是跑起来

我这次做这轮测试，最大的收获其实不是“知道哪个配置最快”，而是更具体地感受到：

• 部署参数会怎样影响服务行为
• 吞吐和时延之间怎么权衡
• 不同负载模式下，系统瓶颈会怎么变化

这比单纯把模型启动成功更有价值。因为真正做工程时，最后拼的往往不是“能不能跑”，而是“能不能解释为什么这样配”。

---

附：本次实验中我最关心的几个结论（简版）

• Opt0 不推荐，低并发和高并发都明显落后。
• Opt2 / Opt3
  已经很接近，不是所有场景都需要执着于拉满。
• 低并发保留 MTP 更好。
• 高并发关闭 MTP 更好。
• YaRN、Balanced / Interactivity mode、expert parallel
  有影响，但不是第一优先级。

如果你也在做类似的本地 vLLM
部署测试，希望这篇记录能给你一点参考。