我在 vLLM 和 llama.cpp 上对 Gemma 4 和 Qwen 3.6 测试了 MTP —— 推理速度提升 3.34 倍，这是我的发现（RTX 6000 PRO）。

大家好，过去几周我一直在本地使用 **vLLM** 和 **llama.cpp** 对 **Gemma 4 31B** 和 **Qwen 3.6 27B**（**GGUF, FP8** 格式）进行多令牌预测（MTP）基准测试。MTP 是目前各大实验室悄悄加入其技术栈的推理技巧，结果着实让我惊讶。\n\n**基准测试配置：** \- 每轮 10 次运行 \- 每次运行 1500 个令牌 \- vLLM 上使用顺序模式，因为我无法完全加载两个模型 \- 所有运行使用相同提示 \- 前缀缓存关闭 **使用的模型：** \- unsloth/Qwen3.6-27B-MTP-GGUF (Q8\_0) 通过 llama.cpp \- RedHatAI/gemma-4-31B-it-FP8-block 通过 vLLM \- Qwen/Qwen3.6-27B-FP8 通过 vLLM **硬件：** AMD Ryzen 9 9950X | NVIDIA RTX PRO 6000 Blackwell | 96GB VRAM | 92GB RAM | CUDA 13.1 | Ubuntu 24.04\n\n**以下是我运行结果的完整排行榜：** https://preview.redd.it/3seyqbmi754h1.png?width=1440&format=png&auto=webp&s=23aaf1bc4cd190d4f49a06f03b62018bb90dbdc0\n\n最佳结果：132.52 vs 39.69 tok/s，速度提升 3.34 倍。\n\n关于质量下降——由于时间限制，我没有进行深入评估。但根据对架构的研究，其设计很难降低质量：目标模型在接收每个令牌前仍会进行验证，因此输出路径与标准解码相同。\n\n关于 VRAM 差异——我尝试捕捉但没时间进行准确测量。从快速抽查来看，差异似乎可以忽略不计，这也与架构一致，因为草案模型很小（Gemma 4 上为 76M 参数）。但我不声称这些是确定的——请将其视为方向性观察，而非基准事实。\n\n以下是我的五大发现：\n\n**1. 在 Gemma 4 上，vLLM 的 MTP 优于 llama.cpp——但 llama.cpp 在 Qwen 上表现稳定** vLLM 在 Gemma 4 上达到 **132.52 tok/s**（n=5）。llama.cpp 在 Qwen 3.6 Q8 上最高为 **117.70 tok/s**（n_max=3）。重要提示：llama.cpp 尚不支持 Gemma 4 的 MTP，因此这不是引擎之间的直接对比。目前 vLLM 的实现也更加成熟，因为 llama.cpp 较晚才加入 MTP 支持。\n\n**2. 最优推测令牌数量并非总是越大越好** 对于 vLLM + Gemma 4：n=5 最佳（132.52 tok/s） 对于 llama.cpp + Qwen 3.6：n=3 是最佳点（117.70 tok/s），n=4 和 n=5 时性能波动。更多推测令牌不等于更快速度。每个模型和引擎组合都有一个最佳点，因此需要自行基准测试。此外，结果可能因提示而异，因此测试几个提示并取平均值等。\n\n**3. 密集模型是 MTP 收益最大的地方** 我在 Gemma 4 31B 和 Qwen 3.6 27B 上测试了 MTP，因为密集模型通常是衡量推测解码收益最干净的地方。在我的测试中，Gemma 4 实现了 **3.34 倍加速**，而 vLLM 上的 Qwen 3.6 实现了 **2.59 倍加速**。我不将其视为普遍规则，但我选择在密集模型上运行测试，因为它应该能带来最清晰的收益。原因在于架构：密集模型具有更统一的前向传递，这可以使草案验证路径更容易优化和更可预测，但始终取决于整体模型架构。\n\n**4. 解码阶段受内存带宽限制，而非计算限制** 这是 MTP 效果如此好的原因之一。在自回归解码过程中，模型通常一次生成一个令牌。每生成一个新令牌，运行时都必须再执行一次目标模型步骤，并通过 GPU 内存移动大量数据。在许多低批量推理工作负载中，瓶颈并非 GPU 缺乏原始计算能力，而是系统在每个解码步骤中花费大量时间将模型权重和 KV 缓存数据在内存中移动。MTP 通过草拟几个可能的后续令牌，并让目标模型一起验证它们来提供帮助。当草拟令牌被接受时，系统可以通过一次验证过程推进多个令牌。换句话说，MTP 并未消除内存带宽成本，但可以将该成本分摊到多个被接受的令牌上。这就是加速高度依赖接受率的原因。如果草拟路径预测良好，目标模型可以在每次传递中接受更多令牌，解码速度就会更快。如果草拟路径预测不佳，则接受的令牌较少，加速效果也会变小。\n\n**5. 推理速度 = 金钱，而不仅仅是用户体验** 如果你在生产环境中提供 LLM 服务，3 倍更快的推理意味着在相同硬件上支持 3 倍的用户，或是相同负载下计算成本降低 3 倍。训练烧钱，推理则印钱——不优化就会流血。这就是 vLLM 和 llama.cpp 都急于加入 MTP 支持的原因。\n\n[其中一个测试。](https://preview.redd.it/fbm158cl054h1.png?width=1927&format=png&auto=webp&s=a4a34c8b9ce64dbdbbf3ed4050162cb97817dad6)\n\n📦 资源：GitHub —— 包含 Docker 配置、基准测试脚本和 CSV 结果的完整设置，还有我解释架构和思路的视频 [https://github.com/lukaLLM/llamacpp-vllm-mtp-setup-and-speed-benchmark-qwen3.6-gemma4](https://github.com/lukaLLM/llamacpp-vllm-mtp-setup-and-speed-benchmark-qwen3.6-gemma4)\n\n告诉我你在什么硬件上运行 MTP 或其他你发现有用的推理加速方法，或者你的发现是什么！AI 被滥用于编辑和表格 xd 干杯