Google 今天為 Gemma 4 發布了 Multi-Token Prediction(MTP)起草器 — 與目標 Gemma 配對、開箱即用做推測解碼的預訓練輕量起草模型。頭條 claim:推理速度最多 3 倍,輸出與目標模型逐 token 完全相同。起草器提議一個未來 token 序列;目標並行驗證它們。當驗證拒絕某個起草 token 時,生成回退到目標在該位置的實際預測,因此品質按位精確保留。要緊的架構細節:起草器共享目標的 KV cache 和啟動,這繞過了運行兩個獨立模型(各自快取狀態)的標準推測解碼開銷。邊緣變體(E2B、E4B)有「embedder 層的高效聚類技術」來解決主導小模型推理的 logit 計算瓶頸。Apache 2.0,權重在 Hugging Face 和 Kaggle 上。
推測解碼兩年來一直是熱門推理最佳化,但實踐中,builder 要麼必須訓練自己的起草器(顯著工作量),要麼使用未很好捕獲目標分布的通用 small-model 起草器(平庸的接受率)。Google 提供專門為 Gemma 4 調優的預訓練起草器關閉了這個差距 — 即插即用 3 倍加速,builder 側無訓練成本。KV-cache 共享是架構上有意義的選擇:vLLM 這樣的標準推測解碼實現把任意 draft model 與目標配對,支付重複的 cache 成本。共享 KV 狀態意味著更小的記憶體佔用和更快的驗證輪次。與 EAGLE(使用目標的隱藏狀態做起草)和 Medusa(向目標添加預測 head)的比較未在發布報導中揭露;從描述看,MTP 起草器精神上更接近 EAGLE,但是用單獨的輕量起草器權重而不是額外的目標 head。
生態讀法:推測解碼正成為開源權重模型生產推理的預期基線,在主 checkpoint 旁 ship 預訓練起草器的 lab 顯著降低了門檻。DeepSeek V3 ship 了內建在模型中的 MTP head。Mistral Medium 3.5 的程式層與此相鄰,雖然那邊的起草器方法未揭露。Google 把起草器做成單獨但快取共享的模組是讓 builder 只為現有 Gemma 4 部署 pull 起草器而不是重新載入統一 MTP-enabled checkpoint 的設計選擇。對在生產中運行自架 Gemma 4 的 builder,升級路徑是:下載匹配的 MTP 起草器,如果你的推理框架支援 KV-shared 推測解碼就插入(vLLM 和 TensorRT-LLM 都支援,帶設定),測量你流量上的接受率。接受率決定實際加速 — 3 倍是樂觀情況,真實情況依賴工作負載。
實際動作:如果你在生產中為聊天、程式碼補全或低延遲推理運行 Gemma 4,這是本週要測試的最佳化。拉取 MTP 起草器,換到你的推理 stack,在你的實際 prompt 上測量延遲和接受率。「無品質損失」claim 通過將輸出與非 MTP 目標比較逐 token 可驗證 — 在生產請求樣本上運行那個 diff 作為你的合理性檢查。對 Gemma 4 E2B/E4B 的邊緣部署,embedder 層聚類最佳化專門針對限制行動/邊緣矽小模型延遲的 logit 計算瓶頸 — 那是推測解碼通常不划算的情況,如果你 ship 端側 Gemma 4,Google 的修復是要仔細閱讀的架構細節。Apache 2.0 授權保持商業路徑開放,無需協商摩擦。下一個看點是其他開源權重 lab 是否跟進預訓練起草器模組 — 一旦成為 table stakes,從零做推測解碼的稅在開源生態系統中消失。