谷歌亮招，Gemma 4加速3倍，vLLM Day0 支持

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 的關鍵貢獻是：

1. 官方出 drafter ：每個尺寸的 Gemma 4 都配了對應 drafter，不用自己練

2. 生態(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 老版本支持的，請先升級