Gemma 4 assistant-MTP 是什麼：多 Token 預測草稿模型怎麼加速推理

在 Gemma 4 相關模型裡看到 assistant-MTP、assistant、MTP drafter 這類名字時，不要把它當成一個獨立聊天模型。

它更準確的定位是：Gemma 4 主模型配套的多 Token 預測草稿模型，用來做 Speculative Decoding，也就是投機解碼。

一句話概括：主模型負責最終判斷，assistant-MTP 負責提前打草稿。如果草稿猜對了，主模型一次確認多個 token，生成速度就能提高。

它到底是什麼

MTP 是 Multi-Token Prediction，意思是多 Token 預測。

Gemma 4 的 assistant-MTP 可以理解成一個輕量級輔助模型，也常被叫作 drafter、draft model 或草稿模型。它通常和對應的 Gemma 4 主模型配對使用，例如：

• Gemma 4 12B 搭配對應的 12B assistant-MTP
• Gemma 4 26B 搭配對應的 26B assistant-MTP
• Gemma 4 31B 搭配對應的 31B assistant-MTP

它的作用不是直接回答使用者問題，而是替主模型預測接下來幾個可能出現的 token。

最終輸出仍然由主模型驗證後決定。所以 assistant-MTP 更像一個「預讀器」或「草稿頭」，不是新的聊天模型。

為什麼普通生成會慢

傳統自回歸語言模型生成文字時，一般是這樣：

1. 根據已有上下文預測下一個 token。
2. 把這個 token 加回上下文。
3. 再預測下一個 token。
4. 重複直到生成完成。

這個過程很穩，但天然是串行的。哪怕後面幾個 token 很容易猜，比如固定格式、程式碼模板、常見短語，模型也要一個一個算。

在本地推理或消費級顯卡上，這種逐 token 生成會放大顯存頻寬瓶頸：每生成一個 token，都要重複搬運大量模型權重，計算單元不一定被充分利用。

MTP 的思路就是利用這個空檔：讓更輕的草稿模型先猜多個 token，再交給主模型並行驗證。

投機解碼怎麼工作

可以把流程拆成四步：

1. assistant-MTP 先預測未來幾個 token。

   例如一次猜 4 個候選 token。

2. 主模型讀取這些候選 token。

   主模型不盲信草稿，而是並行檢查這些 token 是否符合自己的分布。

3. 猜對的 token 被接受。

   如果前 3 個都通過驗證，就相當於主模型一次生成了 3 個 token。

4. 猜錯的位置回退。

   如果第 4 個不被接受，就從那裡重新按主模型邏輯繼續生成。

所以它不是「犧牲品質換速度」。主模型仍然負責最終驗證，只是把可能正確的後續 token 提前拿來檢查。

為什麼輸出可以保持一致

投機解碼最容易誤解的一點是：是不是用了小模型，結果就變差？

在標準 speculative decoding 裡，答案通常是否定的。因為草稿模型只負責提出候選，主模型負責驗收。被接受的 token 必須符合主模型的採樣邏輯；不符合的 token 會被拒絕。

這意味著理論上最終輸出分布可以保持與不使用草稿模型時一致。Google 對 Gemma 4 MTP drafter 的定位也是：在不降低輸出品質和推理邏輯的前提下提升速度。

實際工程裡，最終效果還取決於推理框架實作、採樣參數、MTP 支援是否完整、主模型和 assistant 模型是否正確配對。

它為什麼能加速

加速來自兩個因素：

• 草稿模型更輕，預測候選 token 的成本低。
• 主模型可以一次驗證多個候選 token，減少逐 token 等待。

如果 assistant-MTP 猜得準，一次主模型前向就能接受多個 token，吞吐會明顯提高。Google 發布時提到，Gemma 4 搭配 MTP drafter 在部分硬體和框架中最高可獲得約 3 倍速度提升。

但這個數字不是任何場景都能穩定復現。加速效果取決於：

• 主模型大小。
• assistant 模型和主模型的匹配程度。
• 每次預測多少 speculative tokens。
• prompt 類型。
• 採樣溫度。
• 推理框架實作。
• GPU / CPU / 記憶體頻寬。

通常來說，格式化文字、程式碼、固定結構、常見短語更容易被草稿模型猜中；高度開放、隨機性強、temperature 很高的生成，加速效果可能變弱。

如何使用

assistant-MTP 需要推理框架支援。不是下載了 assistant 模型就能直接聊天。

常見使用方式有兩類。

方式一：主模型內建 MTP 支援

部分框架會直接讀取 Gemma 4 的 MTP 相關結構，透過參數開啟。例如 vLLM 社群裡常見的方向是用 speculative config：

1
2

vllm serve google/gemma-4-31B-it \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}'

這種方式不一定需要單獨指定 assistant 模型，具體取決於模型格式和框架實作。

方式二：單獨載入 assistant / drafter 模型

在 GGUF / llama.cpp 這類本地推理場景裡，更常見的是主模型和 draft 模型分開載入。思路類似：

1
2
3
4
5
6

llama-server \
  -m gemma-4-12B-it-Q4_K_M.gguf \
  --model-draft gemma-4-12B-it-assistant-MTP-Q8_0.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 4 \
  --ctx-size 8192

這裡的重點是：

• -m 指主模型。
• --model-draft 指 assistant-MTP 草稿模型。
• --spec-type draft-mtp 開啟 MTP 草稿模式。
• --spec-draft-n-max 4 表示最多草擬 4 個 token。

不同 llama.cpp 版本參數可能會變化，實際使用前要以目前版本 --help 和模型卡說明為準。

參數怎麼調

--spec-draft-n-max

這個參數控制一次最多讓 assistant-MTP 草擬多少 token。

可以從小值開始：

1

--spec-draft-n-max 2

再嘗試：

1

--spec-draft-n-max 4

值越大，不一定越快。如果草稿命中率下降，主模型會頻繁拒絕候選，反而浪費計算。

temperature

temperature 越高，輸出越隨機，assistant-MTP 越難猜中主模型後續 token。

如果目標是加速和穩定，可以先用：

1

--temp 0.7

或者更低：

1

--temp 0.4

程式碼補全、格式修復、結構化輸出任務，低 temperature 通常更適合。

上下文長度

MTP 不是顯存魔法。主模型和草稿模型都需要占資源，長上下文仍然會吃 KV cache。

8GB 或 12GB 顯存機器不要一上來就開 64K / 128K。可以先用：

1

--ctx-size 8192

確認穩定後再往上調。

適合哪些任務

assistant-MTP 更適合這些場景：

• 程式碼補全。
• JSON / Markdown / XML 這類結構化輸出。
• 固定格式報告。
• 數學步驟或表格類輸出。
• 低溫度、確定性較強的問答。
• 本地模型聊天時降低延遲。

這些任務的共同點是：後續 token 有較強規律，草稿模型更容易猜中。

不適合哪些任務

它不適合被當作「提高模型智商」的工具。

assistant-MTP 不會讓主模型更聰明，也不會改善事實準確性。它解決的是生成速度問題，不是推理品質問題。

這些場景收益可能不明顯：

• temperature 很高的創意寫作。
• 強隨機採樣。
• 草稿模型和主模型不匹配。
• 推理框架 MTP 支援不完整。
• 顯存已經非常緊張，還要額外載入 draft 模型。

尤其是小顯存機器，要注意 assistant-MTP 也會占顯存或記憶體。速度收益可能被額外資源占用抵消。

常見誤區

誤區一：assistant-MTP 是聊天模型

不是。它是給主模型做 speculative decoding 的輔助模型。直接拿它聊天，沒有實際意義，也可能效果很差。

誤區二：用了 MTP 輸出一定不變

理論目標是保持主模型輸出分布一致，因為最終由主模型驗證。但工程實作、採樣參數、框架版本都會影響實際行為。生產使用前仍要對比測試。

誤區三：--spec-draft-n-max 越大越好

不一定。草擬越多，猜錯機率也可能越高。要看接受率和 tokens/s，不能只看參數值。

誤區四：它能解決顯存不足

不能。MTP 是推理加速，不是顯存壓縮。小顯存機器更應該先解決量化、上下文長度、GPU 卸載層數，再考慮 MTP。

怎麼判斷是否真的加速

不要只憑體感。建議對同一組 prompt 做 A/B 測試：

1. 不開啟 MTP，記錄 tokens/s。
2. 開啟 MTP，記錄 tokens/s。
3. 保持相同模型、上下文、temperature、prompt。
4. 比較輸出品質和延遲。

可以用三類 prompt 測：

1

寫一個 Python 函數，把 Markdown 表格轉換成 CSV。

1
2

修復下面 JSON，只輸出合法 JSON：
{"name":"demo","items":[{"id":1,"tags":["a","b",],},]}

1

用固定格式輸出 5 條 Linux 故障排查步驟，每條包含：問題、命令、判斷標準。

如果這些結構化任務明顯變快，而且輸出品質沒有下降，說明 assistant-MTP 在你的環境裡值得保留。

小結

Gemma 4 的 assistant-MTP 是配合主模型使用的多 Token 預測草稿模型。它透過 speculative decoding 提前預測多個 token，再由主模型並行驗證，從而減少逐 token 生成帶來的延遲。

它的價值是加速，不是提升模型能力。正確使用方式是：主模型負責最終輸出，assistant-MTP 負責提前草擬；推理框架負責驗證和接受候選 token。

如果你已經能穩定跑 Gemma 4，再考慮 MTP。先從較小的 speculative token 數開始，觀察 tokens/s、顯存占用和輸出品質，再決定是否把它加入日常運行腳本。

參考資料：

• Multi-token-prediction in Gemma 4 - Google Blog
• google/gemma-4-31B-it-assistant - Hugging Face
• google/gemma-4-E4B-it-assistant - Hugging Face