Qwen3.6 MTP GGUF 发布：本地推理 1.4-2.2 倍加速，精度无损

Unsloth 团队为 Qwen3.6 发布了 MTP（Multi Token Prediction）GGUF 量化版本，据 Unsloth 官方文档，这一发布让 Qwen3.6 的本地推理速度提升 1.4-2.2 倍，精度无任何损失。

在 RTX 6000 上的官方测试中，Qwen3.6 27B MTP 达到 160 tokens/s，35B-A3B MTP 达到 240 tokens/s；硬件门槛维持在消费级——27B 起步 18GB 内存，35B-A3B 起步 22GB。MTP GGUFs 已在 llama.cpp 主线中合入支持，也可直接在 Unsloth Studio 中跑。

MTP 是什么：投机解码的工程化实现

MTP 的全称是 Multi Token Prediction，技术上属于投机解码（speculative decoding）的一种实现。传统大模型生成是纯自回归过程——算出一个 token，再把它喂回去算下一个 token，每生成一个 token 都要走完一次完整的网络前向传播。这个串行结构是本地推理速度的主要瓶颈。

投机解码改变这件事的逻辑——先预测出未来几个 token，再让主模型并行验证这些候选。如果验证通过，几个 token 一次性产出；如果验证失败，回退到分叉点重新算。本质上是用一次主模型的前向传播来确认多个 token 的合法性，减少前向次数。Unsloth 文档原文的描述是”MTP predicts several future tokens, then the main model verifies those tokens in parallel”。

Qwen3.6 MTP 的工程意义在于把这一能力直接绑进 GGUF——配合最近合入 MTP 支持的 llama.cpp 即可开启。

精度无损是 MTP 与”量化压缩换速度”方案的关键区别——量化（如 Q4_K_M）会牺牲一定的输出质量来换取更小的模型体积与更快的推理；MTP 不动模型权重本身，只改生成路径，据 Unsloth 官方说明保持精度无损。

实测数据与配置要点

Unsloth 在文档中给出的测试结果按模型类型分了两档：

• 稠密模型加速比约 1.4×
• MoE 模型加速比约 1.15-1.2×（如 Qwen3.6 35B-A3B）

原文档未对加速比差异给出技术归因，但从两档数字可以看到——MTP 的提升空间在稠密模型上更明显。

启用 MTP 的关键参数是 --spec-draft-n-max，决定一次预测多少个 draft token。Unsloth 在自家环境测得 6 是最优值，但项目方明确说明该值依赖硬件，建议从 1 到 6 全部跑一遍取最快的。

还有一个反直觉的细节——draft tokens 不是越多越好。Unsloth 测试发现，从 2 个 draft tokens 增加到 4 个时，接受率从 83% 急剧下降到约 50%。Unsloth 据此不推荐在 27B/35B-A3B 上使用大于 2 的 draft tokens 配置。

MTP GGUF 比标准 GGUF 多占约 1 GB 内存/显存——这是预测器本身的开销。其他硬件要求和标准量化版本基本一致：27B 4-bit 19 GB、35B-A3B 4-bit 24 GB、BF16 全精度分别 56 GB 与 71 GB。

怎么开启 MTP

Unsloth Studio 路径（最低门槛）——一行命令装好后启动，搜索 Qwen3.6 MTP 下载即用，参数会自动配好：

curl -fsSL https://unsloth.ai/install.sh | sh
unsloth studio -H 0.0.0.0 -p 8888

llama.cpp 路径（完整控制）——拉取 GGUF 后用 llama-cli 或 llama-server 启动，关键是加上 --spec-type draft-mtp --spec-draft-n-max 6 两个参数：

./llama.cpp/llama-cli \
    -hf unsloth/Qwen3.6-27B-MTP-GGUF:UD-Q4_K_XL \
    --temp 1.0 --top-p 0.95 --top-k 20 \
    --presence-penalty 1.5 --min-p 0.00 \
    --spec-type draft-mtp --spec-draft-n-max 6

注意 llama.cpp 在 5 月 13 日把 MTP 参数命名从 --spec-type mtp 改为 --spec-type draft-mtp，旧文档里的写法会报错。

两个仍未解决的坑要避——不要用 CUDA 13.2（项目方称会输出乱码，NVIDIA 正在修复），Qwen3.6 GGUF 在 Ollama 上跑不通（因为 mmproj 视觉文件是分离的，需走 llama.cpp 兼容后端）。

顺手发布：Qwen3.5 系列也补齐 MTP

除 Qwen3.6 外，Unsloth 这次还回溯发布了 Qwen3.5 系列的 MTP GGUF，覆盖 0.8B、2B、4B、9B、27B、35B-A3B、122B-A10B、397B-A17B 全家族。这意味着已经在用 Qwen3.5 系列做本地推理的开发者可以直接迁到 MTP 版本而不换模型。

另一个相关的背景——Qwen3.6 本身是阿里发布的新一代多模态混合思考模型，27B 稠密 + 35B-A3B MoE 双型号、支持 256K 上下文（YaRN 可扩到 1M）、201 种语言、agentic coding 强化（支持 OpenAI Codex / OpenCode 的 developer role）、改进了 tool calling 的嵌套对象解析。Qwen3.6 本身已经具备做本地编码 agent 后端的能力；MTP 把它的推理速度推到消费级硬件可用的范围。

真正需要记住的是

MTP 不是一个新模型，也不是把模型变小，而是把生成路径并行化——同样的模型权重、同样的输出质量，速度 1.4-2.2 倍。对本地推理用户来说，这是接近“免费午餐”的提升，唯一代价是约 1 GB 的额外内存开销与 llama.cpp 编译版本要够新。

需要 cool down 的部分也清楚——速度数据是 Unsloth 在 RTX 6000 上的测试，不同硬件实际加速比会有差异；--spec-draft-n-max 的最优值要自己调；llama.cpp 持续在优化 MTP 实现，5 月 17 日的 PR 又把 1.8× 推到约 2×，所以后续还会有提升。如果你已经在跑 Qwen3.6 或 Qwen3.5 系列的本地推理，换上 MTP GGUF 是当前性价比最高的一步；如果还没搭过本地推理环境，建议先理解 GGUF、量化档位、llama.cpp 基础再上手。