MTP 基准测试结果：生成任务的性质决定了你是会受益于推测性推理（如编程）还是导致推理变慢（如创意写作）。没有其他因素接近其影响力。

我最近发布了 [Qwen 3.6 27B 的 MTP 量化版本](https://www.reddit.com/r/LocalLLaMA/comments/1t57xuu/25x_faster_inference_with_qwen_36_27b_using_mtp/)，对 Reddit 和 Hugging Face 上用户报告的推测性推理速度反而变慢的情况感到惊讶。这与我观察到的结果不符，但当我尝试复现他们的确切使用场景时，证实了他们的体验。我尝试分析这一问题，提出了一些后来被证明是错误的假设，并开展了一次全面的系统性分析，运行了 300 多项测试和基准，收集并比较了更改各种参数后的结果。以下是我的发现： > F16 + MTP 使编程任务速度**几乎翻三倍**。Q4_K_M + MTP **减慢了创意写作速度**。同样的特性、同样的模型、同样的设置，结果却截然相反。我并未测试所有量化级别（否则我还得在这里待上好几天），而是仅局限于 5 个主要的量化级别。我变化的其他参数包括任务类型（4 种）、温度（0.0、0.3、0.7）以及 MTP 层的量化（q8 和匹配模型量化）。温度和 MTP 量化对结果的影响微乎其微。 与无 MTP 基线相比，随着模型量化和任务类型变化，MTP 的累积平均解码速度： |量化|基础 tok/s|代码|事实|分析|创意| |:-|:-|:-|:-|:-|:-| |Q4_K_M|15.1|19.7|17.5|14.9|13.7| |Q5_K_M|13.1|19.2|16.5|14.7|12.6| |Q6_K|13.4|20.1|17.6|15.2|13.4| |Q8_0|11.4|25.4|21.7|18.6|16.9| |F16|6.6|17.9|14.9|12.6|11.0| **内存带宽决定了模型能从推测性解码中获益多少。** F16 在 51GB 显存下以 6.6 tok/s 的速度缓慢运行，因为每个 token 都需要将整个模型载入内存。被接受的 MTP 草稿可以跳过这一过程。Q4_K_M 在 16GB 显存下已经足够快，以至于对于任何比代码可预测性更低的任务来说，草稿开销几乎不值一提。 控制草稿 token 接受率的因素： |任务|接受率|示例| |:-|:-|:-| |代码|79-89%|编写函数、调试、重构| |事实|62-70%|定义、翻译、数学证明| |分析|48-56%|利弊分析、技术对比| |创意|39-48%|故事、诗歌、头脑风暴、角色扮演| 从代码到创意，差距高达 40 个百分点。我尝试了三种温度和五种量化级别，数字几乎未变。编程任务中 4/5 的草稿 token 是正确的；而在创意任务中，甚至不到 1/2。**没有任何其他因素比***你生成的是什么***更为重要。** 我还测试了上述所有场景下该模型的最优草稿 token 数量。**3 是草稿 token 数的最佳点。** 设置更高会导致接受率下降的速度快于额外草稿带来的补偿。**F16 是个例外：N=4 优于 N=3**（17.9 vs 16.2），因为在 6.6 tok/s 的速度下，每一个幸存的草稿 token 都值得承受较低的命中率。 |用例|Q4_K_M|Q5_K_M|Q6_K|Q8_0|F16| |:-|:-|:-|:-|:-|:-| |编程|🟢 +31%|🟢 +47%|🟢 +50%|🟢 +123%|🟢 +171%| |事实问答|🟡 +16%|🟢 +26%|🟢 +31%|🟢 +90%|🟢 +125%| |分析|🔴 -1%|🟡 +12%|🟡 +13%|🟢 +64%|🟢 +91%| |创意|🔴 -9%|🔴 -4%|🔴 -1%|🟢 +48%|🟢 +67%| 🟢 加速，🟡 收益微乎其微，🔴 减速。 * Q8_0 和 F16：始终使用带有 MTP 层的推测性解码。 * 任何量化级别的编程任务：保持开启。 * Q4_K_M（及以下）创意任务：保持关闭。 最后一个观察：在编程任务中开启“思考模式”时：Q8_0 的草稿 token 接受率从 87% 降至 73%。仍然有 +94% 的速度提升，只是没有达到完全的 +123%。 测试环境：Apple Silicon M2 Max 96GB，带有 MTP PR 的 llama.cpp 手动编译版，保留 MTP 层的 Qwen3.6-27B。