Unsloth 给 Qwen3.6 上了MTP，本地推理速度起飞，消费级显卡轻松跑

前文：

话音刚落，就看到 Unsloth 放出了 Qwen3.6-27B-MTP-GGUF 和 Qwen3.6-35B-A3B-MTP-GGUF

先放出它们的显存需求

unsloth/Qwen3.6-27B-MTP-GGUF unsloth/Qwen3.6-35B-A3B-MTP-GGUF 简介

先把概念捋清楚：什么是 MTP？

传统大模型解码是「一次预测一个 token」，串行往后吐字，慢得让人着急

MTP 的思路是：训练时让模型同时学会预测未来好几个 token，推理时拿这几个预测当 draft（草稿），一次性塞回主模型校验。校验通过的就直接接受，不通过的回退到正常生成

说白了，这是把 投机解码（Speculative Decoding） 从「需要额外训一个小模型当 draft」简化成了「主模型自己当 draft」，省心、省显存

Qwen3.6 这一代在训练阶段就内置了 MTP

unsloth 把这部分权重也量化进了 GGUF，再加上 llama.cpp 端的 kernel 支持，就有了今天这个 1.5–2 倍 解码加速的成果

核心亮点：

• 解码速度 ~1.5-2x 提升 ：这是 unsloth 官方给的数字，实测有人在 1 张 5090 上跑 Qwen3.6-27B Q4_0，从 63.72 tok/s 直接干到 105.47 tok/s （详见后文 PR 实测数据）

• 草稿接受率 ~80%： MTP 自己当 draft，省去了维护小模型的麻烦，接受率比传统 EAGLE/Medusa 那套通常还高

• 预填充略有代价 ：MTP 头会让 prompt 处理阶段多吃点算力，长上下文场景请权衡

• 覆盖两个尺寸 ：27B 稠密 + 35B-A3B（256 专家 / 激活 8+1），消费级显卡和服务器都能挑

前置：必须用这个特定分支的 llama.cpp（主仓的 PR 还没合，写这篇时是 PR #22673）

apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y


 git clone -b mtp-clean https://github.com/am17an/llama.cpp.git
cmake llama.cpp -B llama.cpp/build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j --clean-first --target llama-cli llama-server
cp llama.cpp/build/bin/llama-* llama.cpp

CPU / Mac Metal 用户把 -DGGML_CUDA=ON 改成 -DGGML_CUDA=OFF

使用

跑 27B 版本（推荐配置）：

export LLAMA_CACHE="unsloth/Qwen3.6-27B-GGUF-MTP"


 ./llama.cpp/llama-server \
    -hf unsloth/Qwen3.6-27B-MTP-GGUF:UD-Q4_K_XL \
    -ngl 99 -c 8192 -fa on -np 1 \
    --spec-type mtp --spec-draft-n-max 3

跑 35B-A3B（MoE）版本：

export LLAMA_CACHE="unsloth/Qwen3.6-35B-A3B-GGUF-MTP"


 ./llama.cpp/llama-server \
    -hf unsloth/Qwen3.6-35B-A3B-MTP-GGUF:UD-Q4_K_XL \
    -ngl 99 -c 8192 -fa on -np 1 \
    --spec-type mtp --spec-draft-n-max 3

两个关键参数解释：

• --spec-type mtp ：启用 MTP 投机解码

• --spec-draft-n-max 3 ：每次最多猜 3 个 token，再多收益边际递减

⚠️ 有两个坑提前说：

• -np > 1 （并行槽位）暂不支持

• --mmproj （多模态）暂不支持

也就是说，目前 MTP 主要适合单用户、本地纯文本场景，多并发 server 部署得等后续更新

实测

社区里已经有人在 1 张 5090 上跑了实测，用的是 Qwen3.6-27B + Q4_0 量化、KV cache 也走 Q4_0、prompt 是「写一个 flappy bird 克隆」

开启 MTP：

prompt eval: 253.34 tok/s
eval (decode): 105.47 tok/s
draft acceptance rate: 79.7% (4169 / 5229)
total: 5929 tokens / 56.1s

关闭 MTP（相同模型、相同配置）：

prompt eval: 174.20 tok/s
eval (decode): 63.72 tok/s
total: 6587 tokens / 103.2s

解码从 63.72 提到 105.47，整整快了 65%，草稿接受率接近 80%——这说明 MTP 头训得很扎实，「猜得准」是大头

至于预填充，这一组数据看着 MTP 还更快，但这通常是因为缓存差异；按 unsloth 官方说法和 MTP 原理，长上下文 prefill 阶段会因为多算了一份 MTP 头而略有损耗，10% 上下的开销是合理预期

老章观点：

• 对 本地单用户日常对话 / 写代码 这类「解码占大头」的场景，MTP 几乎是白送的速度，没理由不开

• 对 长文档总结 / RAG 检索后回答 这种 prompt 动辄几万 token 的场景，prefill 拖累会被放大，需要权衡

• 5090 跑 27B 都能 100+ tok/s，4090 / 3090 用户也基本能踩到「日常无感」线

• MoE 的 35B-A3B 只激活 3B，显存占用比 27B 稠密版还友好（实际 4bit 量化下大概 20G 出头），单卡 24G 就能上

之前我们用 GGUF，基本就是「量化 + 跑」两件事

这次 unsloth 把 训练时就要保留的 MTP 头权重也一并量化打包，这意味着：

模型原生 MTP 头  →  GGUF 量化保留  →  llama.cpp kernel 适配  →  端侧投机解码

整条链路打通了，普通用户不需要懂什么 EAGLE、Medusa、Lookahead，一行参数就能开

这就是 unsloth 的价值——把模型团队埋的金矿，挖出来给普通人用

总结

如果你：

• 在本地跑 Qwen3.6 系列

• 主要是单用户对话、代码生成场景

• 用得起 24G+ 显存的 N 卡（或 Mac M 系列）

那这个 MTP 版的 GGUF 基本是无脑切，65% 的解码提速是肉眼可见的爽

如果你：

• 跑长文档 RAG / 大量 prefill 任务

• 需要多并发 server

• 用 mmproj 多模态

那再等等，等 PR 合并主线、并发支持补齐再用

.6 .cpp

制作不易，如果这篇文章觉得对你有用，可否点个关注。给我个三连击：点赞、转发和在看。若可以再给我加个，谢谢你看我的文章，我们下篇再见！