Gemma 4 这件事最值得看的，不是 Google 又发了一个开放模型。

更有意思的是，它开始补一个很现实的短板：本地推理太慢。

Google 给 Gemma 4 加了实验性的 MTP drafter，用 speculative decoding 先猜后面的 token，再交给主模型验证。官方样例里，Pixel 上 Gemma 4 E2B、E4B 分别约有 2.8 倍、3.1 倍提速；Apple M4 跑 Gemma 4 31B，也有约 2.5 倍提升。

这不是小修小补。它把 Gemma 4 从“可以下载”往“可以日常用”推了一步。

如果只看 Gemma 4 开放、支持本地设备推理，旧判断已经很清楚：模型正在从云端往设备和工作流里下沉。现在 MTP 把这条判断补得更硬了。下沉不是喊口号，真正卡人的变量是延迟、功耗、内存带宽、框架支持，以及开发者愿不愿意为它多折腾一天。

发生了什么：Gemma 4 多了一个“先猜答案”的小模型

Google 发布了面向 Gemma 4 的实验性 MTP drafter。

它的作用很直接：让一个更小的 drafter 先生成候选 token，主 Gemma 模型再验证哪些可以接受。接受得多，速度就上来；猜错太多，提速就缩水。

几个关键信息：

  • Gemma 4 是 Google 面向本地运行的开放模型，许可证已改为 Apache 2.0。
  • 它与 Gemini 共享底层技术来源，但定位不同：Gemini 更偏云端和 TPU 集群，Gemma 更像开发者能放到自己设备里的模型底座。
  • MTP drafter 不负责最终答案，只负责“草拟候选”。
  • 官方说最高接近 3 倍提速，但这是样例结果，不是所有设备、所有任务的保底承诺。
  • 相关 drafter 可通过 MLX、vLLM、SGLang、Ollama 等框架试用。

这比一篇论文更关键。速度优化只有进了推理框架、量化工具和部署脚本，才会变成生产力。否则只是工程师收藏夹里的漂亮链接。

为什么重要：本地 AI 的瓶颈，经常不是算不动，而是吐字太慢

大语言模型生成文本，是一个 token 一个 token 往外吐。

传统自回归生成里，每一步都要主模型跑一遍。下一个 token 是“的”，还是一段复杂推理里的关键字，单步成本差别没那么大。

云端集群有高带宽内存和强互联，能硬扛。个人电脑、手机、边缘设备就没这么阔气。很多时候，芯片不是一直满血计算，而是在等参数搬来搬去。

MTP 的思路，就是利用这些空档。

项目传统生成MTP speculative decoding关键判断
token 产生方式主模型逐个生成小 drafter 先猜多个 token用预测换时间
主模型角色每步直接输出验证候选并接受有效序列答案仍由主模型把关
主要瓶颈内存带宽、逐步生成猜测准确率、验证开销、调度效率不同设备收益不同
质量变化取决于原模型理论上不降低原模型质量不等于回答一定正确

Google 提到，Gemma 4 E2B 的 drafter 约 7400 万参数，并与主模型共享 KV cache，也就是生成过程里的“活动记忆”。这样它不用重复计算上下文。E2B 和 E4B 的 drafter 还使用稀疏解码，缩小候选 token 范围。

这套东西听起来技术味很重，但落到用户体验上就一句话：少等。

本地 AI 最大的敌人不是跑分低，而是用户看着光标一个字一个字蹦出来，三秒后关掉。

谁受影响：开发者和端侧应用团队，最先有感觉

普通用户不会因为 MTP 这个词改变习惯。真正先受影响的是两类人。

一类是本地大模型开发者。

过去做本地 AI 原型，常见状态是：模型能跑，体验不行。打开可以，生成太慢；演示可以，产品不行。MTP 如果在常用框架里稳定，开发者可能不用立刻换更贵的 GPU，也能把交互延迟压到能忍的范围。

另一类是想把 AI 塞进手机、PC、边缘设备的应用团队。

本地运行的价值不只是省云成本，还包括隐私、离线、低延迟、可控部署。问题是这些优点都怕一个东西：慢。一慢，所有叙事都散了。

Google 这次真正补强的，不是 Gemma 4 的“聪明程度”，而是它进入真实工作流的可能性。开放模型只是门票。Apache 2.0 降低许可顾虑，MTP 降低推理成本，框架接入降低动手门槛。三件事叠在一起，才像一个能被采用的东西。

这也是 Google 这次更像做对的地方。

AI 公司最爱发布“更强模型”。但开发者要的是另一套清单：能不能商用，能不能部署，能不能量化，能不能在现有硬件上跑得像个人样。

模型看着更强，产品反而更虚。这种事过去两年见得太多。

3 倍提速要冷静读：快了，不等于问题没了

“最高 3 倍”当然好看，但不能按广告语读。

speculative decoding 的收益取决于几个很具体的变量：

  • drafter 猜得准不准；
  • 主模型验证候选的开销有多大；
  • 框架调度是否成熟；
  • 设备瓶颈到底在内存带宽还是计算；
  • 量化之后接受率和稳定性是否还能保持；
  • 长上下文、复杂推理任务里，候选 token 会不会更容易被拒绝。

如果候选大量被主模型拒绝，提速就会打折。任务越开放、推理越复杂，收益越不能拍胸脯。

还有一个容易被营销话术盖住的边界：Google 所说的 zero quality degradation，意思是 MTP 理论上不应让 Gemma 4 比原模型更差。它不是说 Gemma 4 的答案一定正确。

幻觉还在。事实错误还在。推理失败也还在。

drafter 只是写草稿，主模型负责判卷。判卷老师本身如果会犯错，草稿写得再快，也不会自动变成真理。

我的判断：本地 AI 的分水岭，是“等不等得起”

过去一年，开放模型的竞争很像早期 PC 时代的硬件竞赛：参数、榜单、上下文、MoE、量化，大家都在堆指标。

但技术真正进入日常，往往不是因为最大指标赢了，而是因为某个体验阈值被跨过去。铁路不是因为最快一趟车改变世界，而是因为班次、成本、可靠性一起到位。PC 也不是只靠 CPU 主频进入家庭，而是靠软件、外设、价格、渠道同时变得可用。

本地 AI 也一样。

“天下熙熙，皆为利来。”放在这里不俗。开发者采用一个模型，不是为了给哪家公司鼓掌，而是为了省时间、省钱、少担责、少踩坑。Apache 2.0 解决一部分担责问题，MTP 解决一部分等待问题，框架接入解决一部分踩坑问题。

这才是 Google 这次动作的现实价值。

它不是把 Gemma 4 一夜之间变成开放模型之王。Meta 的 Llama、阿里 Qwen、Mistral 都还在抢本地和私有化部署场景，Gemma 4 也不可能只靠一个 drafter 改写格局。

但它至少说明，Google 开始认真补开放模型生态最烦人的细节。

这比喊“端侧 AI”有用。

端侧 AI 不是把模型塞进手机就完事。真正难的是让它不烫、不慢、不费电、不难集成，还能在开发者熟悉的工具链里跑起来。MTP 只解决其中一块，但这块很硬。

接下来我更看三个变量：

  • 不同量化精度下，提速还能不能接近官方样例；
  • 长上下文和复杂任务里，drafter 的接受率会不会明显下降；
  • Ollama、vLLM、MLX 这些工具能不能把配置压到普通开发者不用折腾。

如果这三件事跑顺，Gemma 4 才算真正从开放模型列表里走出来，进入工作流。

否则它还是一个好看的下载项。

本地 AI 的胜负，经常不在模型多大，而在一字一句吐得多快。用户不会为“理论可用”买单，只会为“现在就能用”停留。