PixelのGemini Nano、frozen MTPでtoken生成50%以上高速化
Original: Accelerating Gemini Nano models on Pixel with frozen Multi-Token Prediction View original →
スマートフォン上のAIで効いてくる制約は、モデルの賢さだけではなくtokenを1つずつ出す遅さと電力だ。Google Researchは2026年6月26日、Pixel 9・10上のGemini Nano v3を高速化するfrozen Multi-Token Prediction(MTP)の設計を公開した。配備済みモデルを作り直さず、on-device inferenceだけを速くする狙いがある。
通常のspeculative decodingでは、小さなdrafterが複数の候補tokenを先に作り、大きなverifierが並列に確認する。ただしスマートフォンでは別drafterがRAMを消費し、main modelがすでに計算した内部状態も直接使えない。Googleはこの部分をstandalone drafterではなく、Gemini Nanoの最終layerに付ける軽量Transformer headへ置き換えた。
frozen backboneという点が実運用では大きい。Googleは学習済みのGemini Nano v3 weightを固定し、未来tokenの予測誤差を小さくするMTP headだけを学習する。verificationで誤ったdraftは捨てられるため、最終出力はmain modelとbit-for-bitで同一になる。つまり品質やsafety alignmentを変える更新ではなく、速度だけを狙う更新として配布できる。
memory設計もmobile向けに詰められている。MTP headはmain modelのfrozen KV cacheへ直接cross-attendし、重複した履歴を作らない。これによりdrafterの追加prefill latencyを避け、standalone drafterと比べてinstanceあたり130MBを節約したという。
実測値は使い勝手に直結する。Pixel 9の実験ではtaskによってtoken generationが50%以上高速化し、AI Notification SummariesやProofreadなどのproduction workloadではinference passごとに平均でほぼ2個の追加tokenを正しく予測した。verification stepが減れば重いprocessorを起こす時間も減り、電池持ちにも効く。一次情報はGoogle Researchの記事で確認できる。
Related Articles
2026-07-28 MCP specification release candidateはtransport-level session managementを取り除いた。GoogleはPython、TypeScript、Go、C#のbeta SDKが対応済みで、GitHub MCP ServerもRedis session storageを削除したとしている。
注目点は大きなモデル名そのものではなく、MoEのexpertを必要な時だけ読み出す設計がApple端末でどこまで実用になるかだった。
GoogleのGemini Flash更新で注目されたのはモデル名の追加だけではない。出力token削減、低価格、CodeMenderと組み合わせたCyberモデルが、agent workflowの経済性を示している。