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 社區的獨立複現是重要的驗證。