Qwen3.6 27B 与 MTP 在单张 RTX 3090 上的对比测试

我在 llama.cpp 中测试了“常规“的 Qwen3.6 27B GGUF 与 @UnslothAI 发布的新 MTP GGUF 变体，使用一张 24GB 显存的 RTX 3090。

目标很简单：看看 MTP 在本地消费级硬件上是否真的有帮助，尤其是在长上下文场景下。

测试配置：

• GPU：单张 RTX 3090
• 运行时：llama.cpp
• 量化：Q4_K_S GGUF
• KV 缓存：K 和 V 均为 q8_0
• GPU 功耗限制：250W
• 测试的提示长度：4k、16k、32k、64k

简短总结

MTP 速度很快，但并非所有场景都适用。

在 4k 上下文下，常规基线更快。但随着上下文长度增加，MTP 速度也大幅提升。

生成速度：

MTP 在短提示场景下并不占优，但在长上下文生成中变得非常有用。

在 32k 时，生成速度提升超过 2 倍。在 64k 时，相比基线甚至更快。

这看起来好得让人难以置信，肯定有某种权衡。没错，确实存在一个小权衡。

权衡：预填充变慢

根据我的测试，缺点在于提示处理（prefill/prompt processing）环节。

在所有测试的上下文长度下，MTP 的预填充/提示处理速度都更慢。本次测试中，MTP 的提示处理速度约为基线速度的 69%–86%，即最多慢 31%，最少慢 14%。

这可能是一个重要的注意事项。

如果你的工作负载主要是短提示、短回复、或者大量新请求（预填充占主导），那么 MTP 可能不会感觉更快。在 4k 上下文下，它甚至整体生成速度也更慢。

但如果你主要处理长上下文生成——在加载完大型提示后，解码速度更为重要——那么 MTP 的表现就好得多。

长上下文下的表现

在 32k 和 64k 下，MTP 的优势非常明显。

32k：

• 基线：27.15 tok/s
• MTP：57.29 tok/s
• 加速比：2.11 倍

64k：

• 基线：21.88 tok/s
• MTP：51.89 tok/s
• 加速比：2.37 倍

这是在单张 3090 上，而非高显存工作站显卡。

测试使用了 q8_0 KV 缓存，这有助于让长上下文在 24GB 显存中运行。

并发测试结果

由于 llama.cpp 的 MTP 目前不支持 -np > 1（据 Unsloth 模型卡说明），因此无法测试高于 p1 的并发 MTP。所以这里公平的 MTP 比较仅限于 p1 模式。

即便如此，我还是记录了基线 Qwen3.6 27B 在 32k 下的结果：

p8 失败并不意外。8 个 32k 插槽会带来巨大的 KV 缓存内存需求，3090 在尝试再分配 1197 MiB 时显存耗尽。

我的结论

对于本地 llama.cpp 用户来说，MTP 很有前景，但取决于使用场景。

• 短提示场景：基线可能仍然更好。
• 长上下文生成：MTP 可以快得多。
• 预填充速度在 MTP 下更慢。
• 当前 llama.cpp 对 MTP 的支持仅限于 p1，因此尚不支持并发。
• 在 24GB 显存下，使用 q8_0 KV 缓存时，基线可以运行 32k p4，但 32k p8 无法容纳。

MTP 似乎非常适合 Hermes Agent 和 @openclaw 以及智能体编码这类场景——在这些场景中，你更关心生成速度而非提示处理速度。