前文：

話音剛落，就看到 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

制作不易，如果這篇文章覺得對你有用，可否點個關注。給我個三連擊：點贊、轉發和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！