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

Gemma 4 MTP Drafter

谷歌昨天又出招了——4 月初刚发的 Gemma 4，今天直接送上一个让推理快 3 倍的「外挂」：MTP drafter

官方原话只有一句，但很狠：Same quality, way more speed

Gemma 4 是什么，先简单回顾

几个关键数字：

• 参数覆盖 2B → 31B 全档位 ，从手机能跑的 E2B/E4B 到工作站级别的 31B Dense、26B MoE 都有

• 多模态 ：文本、图像、视频、音频统统支持

• 推理强 ：MMLU Pro 跑到 85%+，开源阵营里站在第一梯队

• 下载量惊人 ：发布前 4 周已经超过 6000 万次下载（Google 自己公布的数据）

但模型再强，跑不起来都是白搭。今天这次更新，谷歌瞄准的就是「跑」这件事

MTP 加速的真实数字

谷歌博客地址：blog.google/innovation-and-ai/technology/developers-tools/multi-token-prediction-gemma-4/

下面是博客里直接给出的速度对比图，横坐标是不同硬件、不同框架、不同模型规格，纵坐标是 tokens/sec 提升倍数：

Gemma 4 MTP drafter speed ups across hardware

测试涵盖 LiteRT-LM、MLX、Hugging Face Transformers、vLLM 四套主流推理栈，最高可达 3 倍提速

为什么能快这么多

要看懂 MTP，先得理解一个反直觉的事实：

❝ 标准 LLM 推理不是算力瓶颈，是显存带宽瓶颈

谷歌博客原话翻译过来是：

❝ CPU/GPU 大部分时间都花在「把几十亿参数从显存挪到计算单元」上，仅仅是为了生成一个 token。计算单元长期闲置，延迟主要被搬运拖死

所以 MTP 这套思路的本质是——用闲着的算力，提前预测多个 token

具体怎么做：

1. 主模型（target，比如 Gemma 4 31B）+ 一个轻量级 drafter（草稿模型）
2. drafter 利用主模型已经计算好的 activations 和 KV cache，一次预测多个 token
3. 主模型并行验证这些 token：对的整段接受，还顺带多生成 1 个
4. 错的丢掉，从分歧点继续

老章用人话翻译一下：

小弟（drafter）打草稿  → 一口气往后猜 4-8 个 token
大哥（target）做审核   → 整段并行打勾，对的全收，错的从那里重来

最关键的是 drafter 复用 target 的 KV cache，不需要重新算上下文，几乎是「白嫖」算力

谷歌还在边缘端做了额外优化：E2B/E4B 这种小模型在 embedder 阶段引入了 efficient clustering，把生成端再压一压，给手机/平板续命

推测解码不是新东西，但谷歌把它做成了开箱即用

熟悉的同学知道，speculative decoding 这套东西最早是谷歌自己 2022 年那篇 Fast Inference from Transformers via Speculative Decoding 提出来的

DeepSeek、Qwen 在自己的推理栈里都用过类似思路。但这次 Gemma 4 的关键贡献是：

1. 官方出 drafter ：每个尺寸的 Gemma 4 都配了对应 drafter，不用自己练

2. 生态全面适配 ：Apache 2.0 协议，HuggingFace、Kaggle 都能下，Day-0 全家桶覆盖

直接看支持的框架矩阵：

框架/平台

状态

入口

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 这次相当上心，直接发了一个开箱即用的 docker 镜像：

docker pull vllm/vllm-openai:gemma4-0505-cu129

完整 recipes 在这：recipes.vllm.ai/Google/gemma-4-26B-A4B-it

网友实测：DGX Spark 跑 31B

光看官方数据没意思，看一份独立的实测

有位老哥在 NVIDIA DGX Spark（GB10 芯片）上跑 Gemma 4 31B，配上对应的 31B drafter，对照组是关掉 MTP 的同一个模型

实测数字（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 路由有挑战

但只要把并发拉到 4-8，本地最高能拿到 ~2.2× 加速——M 系列 Mac 跑模型的人请注意，并发开起来才能吃到这波红利

2. 26B MoE 和 31B Dense 都能在消费级 GPU 上跑

之前这个尺寸基本是数据中心独占。MTP 把延迟压下来之后，本地编程助手、Agent 工作流的可行性大幅提升

3. 边缘端 E2B/E4B 直接续航受益

设备端推理快了，CPU 唤醒时间就短，电池消耗就少。手机上跑大模型不再是噱头

4. 零质量损失

谷歌反复强调：因为最终输出由主模型验证，输出和不开 MTP 完全一致——这点对生产环境很关键

老章的看法

Gemma 4 的剧本其实分两幕：

• 第一幕（4 月初） ：放出全尺寸全模态模型，把开源的智能上限往上推

• 第二幕（5 月 5 日） ：放出 MTP drafter，把同一批模型的速度往上推

把这两件事拼起来看，谷歌想做的是：让开源模型从「能跑」走向「日常可用」

适合谁用：

• 想在自有 GPU 上把 Gemma 4 服务化的团队

• 对延迟敏感的 Agent / 编程助手 / 语音交互场景

• Mac 用户、Android/iOS 边缘开发者

• 显卡不够多但要榨吞吐量的工作室（这个我熟）

不太适合：

• 单纯做超大 batch 离线推理，本来 GPU 就拉满的场景，加速空间会缩水

• 还在等 transformers 4.x 老版本支持的，请先升级

Gemma 4 这波的关键不是「分数又涨多少」，而是同样的模型、同样的输出、速度直接 ×2~×3

这种「不动质量动效率」的更新，对开源生态的实际意义比再发一个更大的模型更大

制作不易，如果这篇文章觉得对你有用，可否点个关注。给我个三连击：点赞、转发和在看。若可以再给我加个，谢谢你看我的文章，我们下篇再见！