Frozen Multi-Token Prediction for On-device LLMs

Frozen Multi-Token Prediction 是 google-research-blog 在 Pixel 9 / 10 的 Gemini Nano v3 上採用的 on-device LLM 推論加速做法：不重新訓練主模型，而是在 frozen backbone 的最後層接上一個輕量 MTP head，讓它先草擬多個後續 tokens，再由主模型平行驗證。

核心做法

• Frozen backbone：Gemini Nano v3 主模型權重固定，只訓練新增的 MTP head。這讓改動被限制在效率層，不改變主模型能力與 safety alignment。
• Late exit / deep exit drafter：MTP head 直接使用主模型最後層的 hidden states，比獨立 drafter 更能利用已計算出的語意表徵。
• Zero-copy KV cache：MTP head cross-attend 到主模型既有 KV cache，不另建 drafter cache，避免手機記憶體上的 double tax。
• Verification 保持輸出一致：錯誤 draft 會在驗證階段被丟棄，因此 final output 可維持與主模型 bit-for-bit identical。

為什麼重要

這篇把 llm-model-name-syntax 裡的 MTP 從模型命名縮寫，落到實際 edge deployment 架構。Google 報告 Pixel 9 上部分任務相較同參數級獨立 drafter 可有 50%+ speedup、特定可預測文字結構有最高 55% token acceptance improvement，且每個 instance 相較 standalone drafter 節省約 130MB memory footprint。

對 edge-ai-harness 來說，重點不是「模型變大」，而是如何在 RAM、電力、延遲都受限的裝置上，把推論 stack、cache、draft / verify dependency 與產品功能接成可部署的 harness。這也補上 rtx-spark-edge-ai-box 以外的手機端案例：邊緣 AI 的瓶頸同樣在硬體約束與系統整合，而不只是模型能力。

適用判斷

適合：

• 已部署或已訓練完成、不能大改權重的 production on-device model。
• 需要低延遲、低耗電、低記憶體佔用的手機端摘要、校對、smart reply 類功能。
• 想降低每個任務都 fine-tune standalone drafter 的維運成本。

不等於：

• 一般 speculative decoding 的獨立小模型 drafter。
• 重新訓練整個模型來原生支援 MTP。
• 只靠更大硬體解決延遲問題。

關聯頁面

• llm-model-name-syntax — MTP / quantization / GGUF 等本地模型命名拆解
• edge-ai-harness — 邊緣 AI 落地整合 harness
• google-research-blog — 原始研究發布來源