Google Research、Gemini Nano のオンデバイス推論をMTPで高速化

Google Research は 2026年6月26日、Pixel 上の Gemini Nano v3 に MTP を後付けし、オンデバイス推論を高速化する方法を紹介しました。通知要約や文章校正のようなスマートフォン上のAI機能を、より速く低消費電力で動かすための研究・実装です。

要点

• 既存の Gemini Nano v3 の重みを固定したまま、軽量な MTP head を追加して複数トークンを先読みします。
• 別の小型ドラフトモデルを使う方式と異なり、主モデルの内部状態と KV cache を活用します。
• Pixel 9 / 10 系列に展開され、AI Notification Summaries や Proofread の生成速度と消費電力に効くと説明されています。
• 実験では、同程度の大きさの単独ドラフトモデルと比べ、タスクによって Pixel 9 上で50%以上の高速化が見られたとされています。

今回のブログ記事で語られていること

今回の Google Research Blog は、Gemini Nano のようなオンデバイス大規模言語モデルを、スマートフォンの制約下でどう速く動かすかを説明しています。スマートフォン上で通知を要約したり、文章を校正したりする機能は、ユーザーのデータを端末外へ送らずに使える利点があります。一方で、サーバー環境と違って、端末には厳しい電力予算とメモリ制約があります。通常の言語モデルは1トークンずつ自己回帰的に生成するため、処理能力を使い切れず、メモリ帯域にも負荷がかかり、体感速度やバッテリーに影響します。

記事で紹介されている MTP は、このボトルネックを減らすために、既存の Gemini Nano v3 の重みを固定したまま、追加の軽量なヘッドだけを学習する方式です。一般的な speculative decoding では、小さなドラフトモデルが複数の候補トークンを先に出し、大きなモデルがそれを検証します。しかし、スマートフォンでは別モデルを動かすだけでメモリを消費し、ドラフトモデルが主モデルの内部状態を見られないため、予測精度にも限界があります。Google の方法は、主モデルの最終層に近い内部表現を使って先読みするヘッドを追加し、主モデルがすでに計算した状態を活用します。

特に重要なのは、MTP head が主モデルの KV cache を重複して持たないように設計されている点です。端末上では、重みの共有だけでは十分ではなく、実行時に増える動的メモリが大きな制約になります。記事では、主モデルのキャッシュへ直接参照するゼロコピー構成により、ドラフト側の事前処理待ち時間をなくし、単独ドラフトモデルと比べてインスタンスあたり最大130MBのメモリ節約が見られたと説明されています。生成結果は検証段階で主モデルと一致するものだけが採用されるため、最終出力は主モデルと同一のまま、効率だけを改善できます。

Pixel 9 / 10 系列への展開では、AI Notification Summaries や Proofread のような本番ワークロードで、1回の推論あたり平均で約2トークン多く正しく予測できたとされています。検証回数が減ることで、重いプロセッサを起こす回数も減り、消費電力とバッテリー寿命にも効きます。開発者にとっては、用途ごとに別のドラフトモデルを微調整する負担を減らしながら、端末内AIの速度を上げられる可能性があります。

今回のブログ記事が関係する人

Gemini Nano や端末内AI機能を評価するモバイル開発者、オンデバイス推論の性能・電力を担当するMLエンジニア、プライバシー重視のAI機能を設計するプロダクトチームに関係します。Pixel 上のAI機能の体感速度を重視するチームも確認したい内容です。

実務で確認したいポイント

• 自社アプリのオンデバイスAIが、生成速度、メモリ、電力のどれで詰まっているかを測る。
• 複数トークン予測による高速化が、要約、校正、返信候補などの対象タスクでどの程度効くかを確認する。
• 最終出力が主モデルと一致する検証方式でも、遅延、消費電力、端末温度、メモリ使用量を別々に評価する。
• Pixel 以外の端末や将来のGemini Nano構成で、同じ前提が成り立つかを確認する。

結局、今回のブログ記事をどう読むべきか

今回の記事は、端末内AIの性能改善がモデルサイズだけでなく、生成方式とメモリ設計で大きく変わることを示しています。Gemini Nano を使うチームは、モデル品質だけでなく、ユーザーの端末で速く省電力に動くかを重要な評価軸にしたいです。