谷歌昨天又出招了——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 提升倍数：
测试涵盖 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 的关键贡献是：
官方出 drafter ：每个尺寸的 Gemma 4 都配了对应 drafter，不用自己练
生态全面适配 ：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 镜像：
完整 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
这种「不动质量动效率」的更新，对开源生态的实际意义比再发一个更大的模型更大
制作不易，如果这篇文章觉得对你有用，可否点个关注。给我个三连击：点赞、转发和在看。若可以再给我加个，谢谢你看我的文章，我们下篇再见！
热门跟贴