Gemma 4 推論加速 3 倍：Multi-Token Prediction Drafters 完整技術解析

2026-05-05，Google 為 Gemma 4 全系列釋出 Multi-Token Prediction（MTP）drafter 模型。headline 是「最高 3 倍加速，輸出品質零損失」。但這件事比表面上更值得細看：Google 不是在做 trick，而是在重新設計「大模型旁邊應該站著什麼」這件事。

本文把四層東西說清楚：LLM 推論慢的真正原因、Gemma 4 drafter 的架構設計、各硬體的實測數字、以及這跟其他 speculative decoding 方法（包括 DeepSeek MTP）的本質差異。

LLM 推論的瓶頸從來不是算力不夠，是資料搬運太貴

先建立一個直覺。現代 GPU 有兩個數字：計算能力（TFLOPS）和記憶體頻寬（TB/s）。

問題是：LLM 推論「每次只生成一個 token」的設計，讓模型每生成一個字，就必須把幾十億個參數從 VRAM 搬運到計算單元一次。搬完算完，再搬再算。這叫 memory-bandwidth bound（記憶體頻寬瓶頸）。

最反直覺的地方是：「把下一個明顯的詞猜出來」和「解一道難數學題」，這兩件事消耗的搬運成本完全一樣。所有計算週期裡，大量時間花在等資料搬運，而不是真正在算困難的東西。

Google 在 2022 年的論文 Fast Inference from Transformers via Speculative Decoding（Leviathan et al., ICML 2023）就把這個問題的解法說清楚了：把「猜 token」和「驗證 token」這兩件事拆開給不同模型做。

這就是 Gemma 4 MTP Drafters 的技術基礎。

Speculative Decoding 的基本機制

標準 autoregressive 解碼的流程是：大模型每次前向傳播生成一個 token，再把這個 token 接回去重跑，再生一個，循環往復。

Speculative decoding 改變這個節奏：

1. 輕量 drafter 連續猜 N 個 token（比大模型快很多倍）
2. 大模型一次並行驗證這 N 個 token（一次前向傳播）
3. 接受全部猜對的 token，從第一個猜錯的地方重新開始

關鍵保證：不管 drafter 猜得多準或多爛，大模型都只做驗證，最終輸出分布與純 autoregressive 解碼數學上完全等價——這是一個可以被證明的定理，不是「差不多一樣」。

為什麼這樣更快？因為大模型驗證 N 個 token 的計算成本，只比驗證 1 個 token 多一點點——記憶體搬運的成本是固定的，搬一次可以驗多個。所以只要 drafter 猜對的比例夠高，等效速度就會顯著提升。

drafter 的猜中率通常在 70 到 90%（依任務類型而異）。對話類、程式碼中的明確模式、結構化輸出，猜中率高；高創意、長尾生成，猜中率低。

Gemma 4 Drafter 的三個核心設計

Gemma 4 的 drafter 不是「把一個小模型拿來配著大模型用」這種通用方案，而是針對 Gemma 4 架構深度共設計的。三個關鍵設計讓它比一般 speculative decoding 更有效率：

1. 共用 Target Activations

Drafter 的第一輪預測不是從零開始猜。它會取得 target model 最後一層的 activation（256 維），把它 project 到自己的輸入維度（1,536 維），與 token embedding 拼接後才開始預測。

意義是什麼？Drafter 知道「target 模型此刻對語意的理解狀態」，再去猜下一個 token。這和一個什麼都不知道的小模型盲猜，猜中率差別很大。

從第二輪開始，drafter 把自己上一輪生成的 activation 代入，繼續自回歸地往下猜。

2. 共用 KV Cache

Transformer 模型在推論時會維護一個 KV cache（key-value cache）：把已經算過的 context 的 key 和 value 存起來，後面的 token 就不用重新計算。

Gemma 4 的 drafter 直接讀取 target model 的 KV cache，而不是建自己的。具體來說：

• Drafter 的 local attention 層直接讀 target 最新的 local KV cache
• Drafter 的 global attention 層讀 target 的 global KV cache（Gemma 4 的最後一層永遠是 global attention）

這讓 drafter 完全不需要重新處理 prompt context，省去一大塊計算。

3. Efficient Embedder（僅 E2B 和 E4B 邊緣模型）

邊緣模型的最大瓶頸是 softmax 計算：在整個詞彙表（幾萬個 token）上計算概率分布。

E2B 和 E4B 的 drafter 用了一個兩階段預測：先把相似的 token 預先分群，先預測最可能的 cluster，再只在這些 cluster 內做最終的 token 預測。這大幅削減了 softmax 的計算量，在手機和邊緣設備上效果顯著。

各硬體實測加速倍數

以下數字來自 Google 官方 benchmark，測試框架包含 LiteRT-LM、MLX、Hugging Face Transformers 和 vLLM（來源：blog.google，2026-05-05；硬體細節來自 Ars Technica 及 Belitsoft 報導）。

幾個值得注意的規律：

邊緣模型加速比大模型更顯著：E4B 在 Pixel 手機上達到 3.1x，高於 31B Dense 在 Apple M4 上的 2.5x。邊緣模型的 Efficient Embedder 設計，加上手機端 memory bandwidth 瓶頸更嚴重，讓相對加速空間更大。

MoE 在低 batch size 有特殊限制：26B A4B（MoE 架構）在 batch=1 的 Apple Silicon 上加速有限，但 batch size 提高到 4 到 8 後可達 2.2x。MoE 的 expert routing 在低 batch 時 overhead 相對大，增加 batch 後 expert 重疊度提高，加速效果才出來。

H100 約 1.9x：H100 上 31B Dense 從約 14 TPS 提升到約 27 TPS（數字來自 buildfastwithai.com）。H100 自身 memory bandwidth 本來就高，瓶頸相對不那麼嚴重，所以 MTP 帶來的相對提升不如消費級硬體。

社群實測（HN 用戶 VHRanger，vLLM + RTX 5090 + AWQ 4-bit 量化）：31B 約 120 至 180 TPS，26B MoE 超過 200 TPS。量化 + MTP 疊加的效果供參考。

誠實的預期：3x 是 best-case upper bound，大多數開發者硬體上的實際提升約在 1.7x 至 2.2x（buildfastwithai.com 分析）。依然是從「勉強可用」到「流暢」的門檻差距。

模型對照：四個 Target，四個 Drafter

全部 Apache 2.0 授權。命名規則：target model ID 後加 -assistant。

這跟 DeepSeek 的 MTP 是同一件事嗎

不是。名字相同，用途本質不同。

DeepSeek V3 的 MTP：訓練技術。在預訓練時加入輔助 prediction head，讓模型同時預測「下一個 token」和「再下一個」，增加訓練訊號密度，提升資料效率。MTP module 在推論時預設丟掉，也可以接 speculative decoding，但只是 optional。

Google Gemma 4 的 MTP Drafter：推論技術。一個獨立訓練的輕量模型，整個設計目標就是在推論時給 target 當猜測員，透過 shared KV cache 和 target activations 深度整合進 Gemma 4 架構。

一句話區別：DeepSeek 在模型內部加了「預見未來的觸角」用於訓練，Google 在模型外部裝了「不用進修就能猜你答案的助理」用於推論。

各方法對比：

EAGLE-3 在 Llama 等模型上可達 3.0x 至 6.5x（arXiv:2503.01840，EMNLP 2025），但需要針對特定模型自行訓練 draft head。Gemma 4 的 drafter 是官方釋出，不需要額外訓練。

四個框架的實際用法

Hugging Face Transformers

from transformers import AutoModelForCausalLM, AutoProcessor

TARGET_MODEL_ID = "google/gemma-4-31B-it"
ASSISTANT_MODEL_ID = TARGET_MODEL_ID + "-assistant"

model = AutoModelForCausalLM.from_pretrained(TARGET_MODEL_ID)
assistant = AutoModelForCausalLM.from_pretrained(ASSISTANT_MODEL_ID)

outputs = model.generate(
    **inputs,
    assistant_model=assistant,
    num_assistant_tokens=4,
)

num_assistant_tokens 建議：對話 / 自然語言用 4 到 5，程式碼生成用 3 到 4，結構化輸出（JSON）用 5 到 6。

vLLM（伺服器端部署）

vllm serve google/gemma-4-31B-it \
  --tensor-parallel-size 2 \
  --speculative-config "{\"model\": \"google/gemma-4-31B-it-assistant\", \"num_speculative_tokens\": 4}"

也可用 model 內建的 MTP 層（不需要獨立 drafter 模型）：

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

Ollama

ollama run gemma4:31b-coding-mtp-bf16

Ollama 0.23.1 起支援（HN 社群確認）。建議跑 bf16 或 8-bit 以上量化；4-bit 量化會降低 drafter acceptance rate，效益縮小。

MLX（Apple Silicon）

MLX 原生支援 Gemma 4 MTP。在 model load 時指定 drafter 模型 ID，shared KV cache 整合由框架自動處理。

推論加速對開發者的實際意義

Agentic loop：一個 agent 要跑 10 至 20 個推論步驟才完成一個任務。每步從 3 秒降到 1.5 秒，整個 task 從 30 至 60 秒降到 15 至 30 秒——這是「能用」和「太慢了換 API 吧」的差距。

即時對話：H100 上串流速度從約 14 TPS 升到約 27 TPS。27 TPS 超過多數人閱讀速度的門檻，視覺上從「一個字一個字卡卡跳出來」變成「流暢輸出」。

手機 / 邊緣裝置：E2B / E4B 在 Pixel 上 2.8x / 3.1x，官方說同時降低電池消耗——因為完成同樣任務花更少時間，GPU 開著的時間短了。

基礎設施成本：businessanalytics.substack.com 分析指出，對 on-prem 運行 Gemma 4 的團隊，MTP 等效於在不換硬體的情況下把 QPS 提高 1.7x 至 3x，估計可降低 60 至 70% 基礎設施成本（前提是 batch 夠大）。

為什麼 Speculative Decoding 現在才普及

Speculative decoding 從 2022 年論文到現在已經四年，為什麼以前沒有大規模普及？

主要原因是「通用 draft model 的 acceptance rate 不夠高」——隨便找一個小模型配大模型，distribution 差異太大，猜中率低於 60%，速度甚至可能比不用 draft 更慢（drafter 本身也要計算）。

Gemma 4 MTP Drafter 的答案是：把「drafter 是誰」這個問題解決掉。讓 drafter 讀 target 的 activation 和 KV cache，讓它「知道 target 在想什麼」之後再猜，acceptance rate 才能穩定在 70 至 90%。

同樣的思路，EAGLE 系列在 Llama 模型上做了類似的事，但那是社群各自訓練的解法。Gemma 4 是 Google 官方釋出，開箱即用，這個差距對大部分開發者才是真正有意義的。

Gemma 4 自 2026-04-02 發布以來已有超過 6000 萬次下載（來源：Google Blog）。MTP Drafters 是後續補丁，但對試用後覺得太慢的那部分人，可能是重新拿起來的理由。

如果你在本地跑 Gemma 4，加上 drafter 幾乎沒有門檻，今天就可以試。

如果你在考慮建一台能本地跑 Gemma 4 31B 的機器，ROG GR70 迷你主機（R9 + RTX 5070） 是目前桌面空間只佔一個衛生紙盒、但跑得動 31B 模型的少數選擇之一。

利益揭露：本文部分連結為聯盟連結，點擊購買我會獲得回饋，不影響你的價格。