导读：谷歌今年春天开源的Gemma 4刚换完Apache 2.0许可证，现在又扔出一组实验性附件——能让生成速度翻倍的"草稿模型"。本地跑大模型的瓶颈从来不是算力不够，而是内存太慢。

正方：草稿模型是边缘AI的务实解法

打开网易新闻 查看精彩图片

谷歌这次发布的Multi-Token Prediction（多词元预测）草稿器，核心逻辑很直白：用一个74M参数的轻量模型（E2B/E4B）提前"猜"后面几个词元，猜对了直接采用，猜错了让主模型纠正。

这个思路叫推测解码（speculative decoding）。主模型（Gemma 4最大27B参数）生成每个词元都要从显存搬运参数，而消费级显卡的内存带宽远不如企业级HBM，搬运期间算力其实是闲置的。草稿器就利用这段等待时间干活。

谷歌做了几层优化让这套机制在本地跑通。草稿器共享主模型的键值缓存（key value cache），不用重复计算上下文；E2B和E4B还用了稀疏解码技术减少计算量。官方数据称最高能到3倍加速——当然这是理想情况，实际取决于草稿命中率。

更关键的是许可条款。Gemma 4改用Apache 2.0，比前几代的自定义宽松得多。这意味着开发者可以把加速方案揉进自己的商业产品，不用看谷歌脸色。

反方：加速的代价是复杂度飙升

推测解码不是新东西，但落地到开源本地模型里问题很多。

第一，草稿器和主模型必须强耦合。E2B/E4B是专为Gemma 4训练的，换别的架构就失效。开发者如果微调了Gemma 4，草稿器可能直接报废——或者更隐蔽地失效，输出质量下滑但很难定位。

第二，内存占用反而增加。虽然草稿器只有74M参数，但运行时要同时驻留主模型和草稿器，显存压力更大。对本来就卡在12G/16G显存边缘的消费级显卡，这可能是压垮骆驼的最后一根稻草。

打开网易新闻 查看精彩图片

第三，加速效果高度依赖任务类型。代码生成、数学推理这类需要精确词元的场景，草稿命中率低，加速有限；闲聊类文本可能快很多，但这类场景对速度本来就不敏感。

谷歌自己标注这是"实验性"（experimental）功能，暗示稳定性未经验证。本地AI的核心卖点是可控和隐私，加一层黑箱机制反而稀释了这个优势。

我的判断：这是谷歌的边缘AI战略锚点

看这件事不能只看技术参数，要看谷歌在补哪块拼图。

Gemini系模型主攻云端TPU集群，Gemma系则押注本地和边缘。但本地推理的体验瓶颈一直很尴尬：27B参数模型在单卡上跑，生成速度接近阅读速度，用户体感就是"卡"。MTP草稿器不是追求完美方案，是用工程技巧把体验拉到"可用"阈值以上。

更深层信号在许可证变更。Apache 2.0+加速工具包，谷歌明显在拉拢开发者生态对抗Meta的Llama和Mistral。后两者虽然也是开源，但Llama的许可条款仍有商业限制，Mistral则偏向企业合作。

对25-40岁的技术从业者，这件事的真正价值是验证了一条路径：大模型瘦身+推测解码+宽松许可，可能让"本地优先"的AI产品从demo走向量产。不是所有人都需要云端GPT-4级别的智能，但几乎所有人都需要数据不出设备。

谷歌给出的数据是最高3倍加速。这个数字会随硬件和场景波动，但它证明了一件事：本地模型的速度问题，可以用架构创新而不是堆硬件来解决。这对边缘AI的商业化时间表，可能比任何参数规模的增长都更重要。