北京
Gemma 4 MTP Drafter
谷歌昨天又出招了——4 月初剛發(fā)的 Gemma 4，今天直接送上一個讓推理快 3 倍的「外掛」：MTP drafter
官方原話只有一句，但很狠：Same quality, way more speed
Gemma 4 是什么，先簡單回顧
幾個關鍵數(shù)字：
參數(shù)覆蓋 2B → 31B 全檔位 ，從手機能跑的 E2B/E4B 到工作站級別的 31B Dense、26B MoE 都有
多模態(tài) ：文本、圖像、視頻、音頻統(tǒng)統(tǒng)支持
推理強 ：MMLU Pro 跑到 85%+，開源陣營里站在第一梯隊
下載量驚人 ：發(fā)布前 4 周已經超過 6000 萬次下載（Google 自己公布的數(shù)據(jù)）
但模型再強，跑不起來都是白搭。今天這次更新，谷歌瞄準的就是「跑」這件事
MTP 加速的真實數(shù)字
谷歌博客地址：blog.google/innovation-and-ai/technology/developers-tools/multi-token-prediction-gemma-4/
下面是博客里直接給出的速度對比圖，橫坐標是不同硬件、不同框架、不同模型規(guī)格，縱坐標是 tokens/sec 提升倍數(shù)：
Gemma 4 MTP drafter speed ups across hardware
測試涵蓋 LiteRT-LM、MLX、Hugging Face Transformers、vLLM 四套主流推理棧，最高可達 3 倍提速
為什么能快這么多
要看懂 MTP，先得理解一個反直覺的事實：
? 標準 LLM 推理不是算力瓶頸，是顯存帶寬瓶頸
谷歌博客原話翻譯過來是：
? CPU/GPU 大部分時間都花在「把幾十億參數(shù)從顯存挪到計算單元」上，僅僅是為了生成一個 token。計算單元長期閑置，延遲主要被搬運拖死
所以 MTP 這套思路的本質是——用閑著的算力，提前預測多個 token
具體怎么做：
1. 主模型（target，比如 Gemma 4 31B）+ 一個輕量級 drafter（草稿模型）
2. drafter 利用主模型已經計算好的 activations 和 KV cache，一次預測多個 token
3. 主模型并行驗證這些 token：對的整段接受，還順帶多生成 1 個
4. 錯的丟掉，從分歧點繼續(xù)
老章用人話翻譯一下：
小弟（drafter）打草稿 → 一口氣往后猜 4-8 個 token
大哥（target）做審核 → 整段并行打勾，對的全收，錯的從那里重來
最關鍵的是 drafter 復用 target 的 KV cache，不需要重新算上下文，幾乎是「白嫖」算力
谷歌還在邊緣端做了額外優(yōu)化：E2B/E4B 這種小模型在 embedder 階段引入了 efficient clustering，把生成端再壓一壓，給手機/平板續(xù)命
推測解碼不是新東西，但谷歌把它做成了開箱即用
熟悉的同學知道，speculative decoding 這套東西最早是谷歌自己 2022 年那篇 Fast Inference from Transformers via Speculative Decoding 提出來的
DeepSeek、Qwen 在自己的推理棧里都用過類似思路。但這次 Gemma 4 的關鍵貢獻是：
官方出 drafter ：每個尺寸的 Gemma 4 都配了對應 drafter，不用自己練
生態(tài)全面適配 ：Apache 2.0 協(xié)議，HuggingFace、Kaggle 都能下，Day-0 全家桶覆蓋
直接看支持的框架矩陣：
框架/平臺
狀態(tài)
入口
Hugging Face Transformers
? 已支持
https://huggingface.co/collections/google/gemma-4
MLX（Apple Silicon）
? 已支持
https://huggingface.co/collections/mlx-community/gemma-4-assistant-mtp
vLLM
? Day-0
https://docs.vllm.ai/projects/recipes/en/latest/Google/Gemma4.html
SGLang
? Day-0
https://docs.sglang.io/cookbook/autoregressive/Google/Gemma4
Ollama
? 已支持
ollama run gemma4:31b-coding-mtp-bf16
Google AI Edge Gallery
? Android/iOS 直接玩
App Store / Play Store
vLLM 的 Day-0 配合
vLLM 這次相當上心，直接發(fā)了一個開箱即用的 docker 鏡像：
docker pull vllm/vllm-openai:gemma4-0505-cu129
完整 recipes 在這：recipes.vllm.ai/Google/gemma-4-26B-A4B-it
網(wǎng)友實測：DGX Spark 跑 31B
光看官方數(shù)據(jù)沒意思，看一份獨立的實測
有位老哥在 NVIDIA DGX Spark（GB10 芯片）上跑 Gemma 4 31B，配上對應的 31B drafter，對照組是關掉 MTP 的同一個模型
實測數(shù)字（baseline → MTP）：
concurrency=1：3.65 → 6.37 tok/s （1.74×）
concurrency=4：14.34 → 23.59 tok/s （1.65×）
concurrency=8：14.37 → 24.18 tok/s （1.68×）
老哥的原話：
? Google 說 up to 2x，我們沒完全摸到，但提升是實打實的，不是 vapor
技術棧也直接給出來了：
DGX Spark (GB10)
+ gemma-4-31b-it
+ gemma-4-31b-it-assistant # MTP drafter
+ vLLM (PR 41745 自編譯)
谷歌博客里埋了幾個老章覺得很關鍵的點：
1. Apple Silicon 上 batch=1 時 26B MoE 路由有挑戰(zhàn)
但只要把并發(fā)拉到 4-8，本地最高能拿到 ~2.2× 加速——M 系列 Mac 跑模型的人請注意，并發(fā)開起來才能吃到這波紅利
2. 26B MoE 和 31B Dense 都能在消費級 GPU 上跑
之前這個尺寸基本是數(shù)據(jù)中心獨占。MTP 把延遲壓下來之后，本地編程助手、Agent 工作流的可行性大幅提升
3. 邊緣端 E2B/E4B 直接續(xù)航受益
設備端推理快了，CPU 喚醒時間就短，電池消耗就少。手機上跑大模型不再是噱頭
4. 零質量損失
谷歌反復強調：因為最終輸出由主模型驗證，輸出和不開 MTP 完全一致——這點對生產環(huán)境很關鍵
老章的看法
Gemma 4 的劇本其實分兩幕：
第一幕（4 月初） ：放出全尺寸全模態(tài)模型，把開源的智能上限往上推
第二幕（5 月 5 日） ：放出 MTP drafter，把同一批模型的速度往上推
把這兩件事拼起來看，谷歌想做的是：讓開源模型從「能跑」走向「日?？捎谩?/strong>
適合誰用：
想在自有 GPU 上把 Gemma 4 服務化的團隊
對延遲敏感的 Agent / 編程助手 / 語音交互場景
Mac 用戶、Android/iOS 邊緣開發(fā)者
顯卡不夠多但要榨吞吐量的工作室（這個我熟）
不太適合：
單純做超大 batch 離線推理，本來 GPU 就拉滿的場景，加速空間會縮水
還在等 transformers 4.x 老版本支持的，請先升級
Gemma 4 這波的關鍵不是「分數(shù)又漲多少」，而是同樣的模型、同樣的輸出、速度直接 ×2~×3
這種「不動質量動效率」的更新，對開源生態(tài)的實際意義比再發(fā)一個更大的模型更大
制作不易，如果這篇文章覺得對你有用，可否點個關注。給我個三連擊：點贊、轉發(fā)和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
