Google 今天在 LiteRT-LM(github.com/google-ai-edge/LiteRT-LM 上的开源生产推理框架)中发布了 Multi-Token Prediction drafters 的原生支持。昨天的 Gemma 4 12B 发布将 MTP drafters 标记为模型中烘焙的延迟减少部件;具体数字今天早上到达。解码速度提升 Gemma 4 E2B 上 1.6x,E4B 上 2.2x,无质量降级声明。端到端,LiteRT-LM 运行时报告比 llama.cpp、MLX、Cactus 和 ONNX 在 Gemma 4 变体的 prefill 加解码上快 1.8x 到 3.7x。API 扩展超出现有的 Kotlin 和 C++ 表面,添加 Swift 和 JavaScript,这将运行时放入 iOS、web 和 Node.js 路径,无需单独的 ports。
机制是通过与主 Gemma 4 模型联合训练的轻量级 MTP drafter 进行 speculative decoding。标准 speculative decoding 在 llama.cpp、vLLM 和 MLX 生态系统中已经存在两年,但瓶颈一直是 drafter 和 verifier 之间的数据交互:如果 drafter 在与主模型不同的 hardware IP 上运行,往返时间会吃掉加速。LiteRT-LM 的具体工程声明是 memory locality 强制执行,轻量级 MTP drafter 和主模型都在同一个 hardware IP(例如 GPU)上执行,这消除了限制 naive 推测实现的跨 IP 往返。这是值得 builders 暂停的部分,考虑 2.2x 是否在他们的 stack 上可重现:取决于你的推理框架是否尊重 locality 约束。数字来自 Google 自己的基准;独立复现在与你的工作负载匹配的工作负载上是在押注基础设施数字之前的标准下一步。
两条值得跟踪的生态线索。首先,MTP-as-acceleration 现在是一个具体的 builder 原语,而不是研究好奇心。模型 ship 时 drafter 已烘焙(Gemma 4 中型变体),推理框架尊重 locality 合同,加速发布时附有与 builders 实际使用的框架的比较。这就是 speculative decoding 功能成为默认开启而不是仅专家可用所需的完整 stack。其他具有 MTP drafters 的模型家族(DeepSeek 的 MTP 工作、Meta 和其他的推测研究)现在有一个参考实现模式可遵循。其次,比较 cohort 在战略上很重要。LiteRT-LM 将自己定位为对抗 llama.cpp(开源本地推理默认)、MLX(Apple Silicon 默认)、Cactus(移动推理框架)和 ONNX(跨平台序列化标准)。Google 正在命名 incumbents 并将具体数字放在旁边,这表明 LiteRT-LM 被定位为默认本地推理槽位的竞争者,而不是研究原型。
周一早上,如果你今天在 llama.cpp、MLX 或 ONNX 上本地运行 Gemma 4:拉取 LiteRT-LM 并在你的实际工作负载上进行基准测试,然后再决定是否切换。2.2x 是 Google 的上限;在消费级硬件上,真实世界数字更常在 1.7x 到 2.2x 范围内,这仍然是有意义的,但值得在你的上下文长度和批量大小上测量。如果你在 iOS 或 web 应用程序中 ship Gemma 4,新的 Swift 和 JavaScript API 改变了这些表面上可行的东西,将其视为新评估,而不是依赖先前的框架结论。如果你为任何 MTP 配备的模型家族构建推理基础设施,locality 强制模式是值得带到其他运行时的工程教训;在同一个 hardware IP 上共置的 drafter 和 verifier 是使 speculative decoding 在实践中而不仅仅在纸上快速的部分。和供应商基准对开放框架的比较一样,1.8x 到 3.7x 的比较数字是供应商发布的;llama.cpp 和 MLX 社区的独立复现是重要的验证。