Gemma 4 MTP 實測調參：用 assistant 草稿模型衝 120 tokens/s

如果主模型、assistant 草稿模型和推理框架都配對正確，MTP 可以讓 Gemma 4 在本地顯卡上明顯提速。一些 12GB 顯存的顯卡，例如 RTX 4070，在合適量化和參數下，有機會看到接近 120 tokens/s 的生成速度。

但這不是一個「複製命令就必然得到」的數字。它更適合作為調參目標：跑得起來、顯存夠、草稿命中率高、採樣參數穩定，速度才會漂亮。

MTP 在這裡做什麼

MTP 是 Multi-Token Prediction，也就是多 Token 預測。

普通自回歸模型一次生成一個 token。assistant-MTP 則先替主模型草擬未來幾個 token，再由主模型並行驗證。如果草稿猜對，主模型就能一次接受多個 token，減少逐 token 等待。

這套機制常叫：

Speculative Decoding
投機解碼
草稿模型加速
draft model / drafter

它的目標是加速，不是提升模型能力。最後是否接受某個 token，仍然由主模型決定。

命令列範例

下面是一個偏進階的 llama-cli 參考命令：

1
2
3
4
5
6


./llama-cli \
  -m gemma-4-12b-it-qat-GGUF.gguf \
  --draft-max 2 \
  -md gemma-4-12b-it-qat-assistant-MTP-Q8_0-GGUF.gguf \
  -ngl 99 \
  -p "<|think|>\n写一篇关于量子计算的短文。"

這條命令的意思是：

用 gemma-4-12b-it-qat-GGUF.gguf 作為主模型。
用 gemma-4-12b-it-qat-assistant-MTP-Q8_0-GGUF.gguf 作為草稿模型。
每輪最多讓草稿模型預測 2 個 token。
盡量把模型層卸載到 GPU。
直接傳入一個 prompt 測試生成速度。

注意：不同 llama.cpp 版本的參數名可能不同。有的版本用 -md，有的版本更推薦 --model-draft；有的版本用 --draft-max，有的版本用 --spec-draft-n-max。實測前先看：

1

./llama-cli --help

或者：

1

./llama-server --help

參數解釋

`-m`

1

-m gemma-4-12b-it-qat-GGUF.gguf

這是主模型。最終輸出由它驗證和決定。

assistant-MTP 必須和主模型匹配。不要隨便拿一個 assistant 模型去配另一個尺寸或版本的主模型，否則輕則沒有速度收益，重則直接載入失敗或輸出異常。

`-md`

1

-md gemma-4-12b-it-qat-assistant-MTP-Q8_0-GGUF.gguf

-md 用來掛載 draft model，也就是 assistant-MTP 草稿模型。

可以把它理解成「預測候選答案的小助手」。它先猜接下來幾個 token，主模型再決定是否接受。

如果你的 llama.cpp 版本不認識 -md，試試：

1

--model-draft gemma-4-12b-it-qat-assistant-MTP-Q8_0-GGUF.gguf

`--draft-max`

1

--draft-max 2

它控制草稿模型一次最多預測多少 token。

建議從 2 開始，而不是一上來拉很大。草稿 token 越多，不代表越快；如果猜錯率上升，主模型會頻繁拒絕，反而浪費計算。

可以這樣試：

1

--draft-max 1

1

--draft-max 2

1

--draft-max 4

觀察 tokens/s 和輸出品質，再決定保留哪個值。

`-ngl 99`

1

-ngl 99

這個參數表示盡量把模型層卸載到 GPU。對 12GB 顯存來說，如果模型量化足夠小，可能可以把大部分甚至全部層放進顯卡。

但 8GB 顯存通常不要照抄。因為 MTP 會多載入一個 assistant 模型，顯存壓力比只跑主模型更高。

如果 OOM，可以按這個順序降：

1

-ngl 80

1

-ngl 60

1

-ngl 40

真正穩定的值要看模型量化、上下文長度、顯卡剩餘顯存和系統桌面占用。

`-p`

1

-p "<|think|>\n写一篇关于量子计算的短文。"

-p 是直接傳入 prompt。

這裡的 <|think|> 是否需要，取決於目前 GGUF 模型的聊天模板和模型說明。它不是所有 Gemma 4 模型的通用開關。為了做速度測試，可以先用更簡單的 prompt：

1

-p "写一篇关于量子计算的短文。"

先確認 MTP 本身能跑，再討論模板和特殊 token。

更穩的測試命令

第一次測試建議把參數寫保守一點：

1
2
3
4
5
6
7
8
9


./llama-cli \
  -m gemma-4-12b-it-qat-GGUF.gguf \
  -md gemma-4-12b-it-qat-assistant-MTP-Q8_0-GGUF.gguf \
  --draft-max 2 \
  -ngl 60 \
  -c 8192 \
  -n 512 \
  --temp 0.7 \
  -p "用三段话解释量子计算。"

如果能穩定跑，再逐步提高 -ngl：

1

-ngl 80

再試：

1

-ngl 99

不要第一次就把 -ngl 拉滿。MTP 多了一個 draft 模型，顯存餘量比普通運行更重要。

為什麼 120 tokens/s 不一定復現

120 tokens/s 很誘人，但它依賴很多條件。

影響因素	說明
顯卡	RTX 4070 這類 12GB 顯卡比 8GB 顯卡更容易跑高 `-ngl`
量化	QAT / Q4 / Q8 draft 模型組合會影響顯存和速度
draft 命中率	草稿猜得越準，主模型一次接受的 token 越多
prompt 類型	結構化文字、程式碼、固定格式通常更容易加速
temperature	越隨機，草稿越難猜中
上下文長度	上下文越長，KV cache 壓力越大
llama.cpp 版本	MTP 支援仍在演進，參數和效能可能變化

因此，文章裡更建議把它當成「可以衝的速度目標」，而不是承諾值。

適合用來測速的 prompt

MTP 最容易在結構化、低隨機性的輸出裡體現價值。測速時別只讓模型自由寫散文，可以多試這些：

1

写一个 Python 函数，把 Markdown 表格转换成 CSV，只输出代码。

1
2


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

1

用固定格式输出 10 条 Linux 故障排查步骤，每条包含：问题、命令、判断标准。

如果這些任務的 tokens/s 明顯提升，並且輸出結構沒有變差，說明 assistant-MTP 在你的機器上是有價值的。

常見問題

加了 `-md` 反而 OOM

正常。assistant-MTP 也要占顯存或記憶體。

先降：

1

-ngl 60

再降上下文：

1

-c 4096

如果還不穩，就換更小量化，或者先不用 MTP。

參數不識別

說明 llama.cpp 版本和文章裡的命令不一致。先看幫助：

1

./llama-cli --help

重點搜尋：

1

draft

1

spec

如果目前版本沒有 MTP / draft 支援，需要更新 llama.cpp。

輸出變奇怪

先去掉 <|think|>，用普通 prompt 測試。再把 temperature 降低：

1

--temp 0.4

然後把 draft 數量降到：

1

--draft-max 1

如果這樣恢復正常，說明之前的模板、採樣或 draft 參數太激進。

小結

Gemma 4 assistant-MTP 的高速度玩法，本質是主模型加草稿模型的投機解碼。-md 掛載草稿模型，--draft-max 控制一次草擬多少 token，-ngl 決定 GPU 卸載程度。

12GB 顯存機器可以嘗試衝更高速度，120 tokens/s 可以作為調參目標；8GB 顯存機器則要更保守，因為 draft 模型會額外占資源。

最穩的做法是先跑通，再加速：先低 -ngl、短上下文、低 draft 數量，確認穩定後再逐步提高。