Googleはオープンモデル「Gemma 4」ファミリー向けに、Multi-Token Prediction（MTP）drafterを公開した。通常は1トークンずつ進むLLM推論に、軽量な下書きモデルが複数トークンを先読みし、主モデルがまとめて検証する仕組みを組み合わせる。Googleは、品質や推論ロジックを落とさず最大3倍の高速化が可能だとしており、ローカル開発、オンデバイスAI、エージェント用途にとって実装上の意味が大きい。
「先読み」と「検証」で待ち時間を減らす
Googleの説明によると、標準的なLLM推論はメモリ帯域に制約されやすい。巨大なパラメータをVRAMから計算ユニットへ移動する時間が支配的になり、計算資源が十分に使われない場面がある。MTP drafterはこの空きやすい計算余地を使い、主モデルが次の1トークンを処理する間に、軽量モデルが複数の将来トークン候補をまとめて予測する。
その後、Gemma 4本体が候補列を並列に検証し、一致した部分を採用する。Googleはこの方式により、LiteRT-LM、MLX、Hugging Face Transformers、vLLMなどの環境でトークン毎秒の改善を確認したとしている。
By using a specialized speculative decoding architecture, these drafters deliver up to a 3x speedup without any degradation in output quality or reasoning logic.──Google公式ブログ
開発者に効く3つの領域
領域 | 期待される効果 |
|---|---|
ローカル開発 | 個人PCやコンシューマGPU上で、31B級モデルの応答待ちを短縮 |
オンデバイスAI | E2B/E4Bなどエッジ向けモデルの応答性と電力効率を改善 |
AIエージェント | 多段推論・コード補完・音声対話など、低レイテンシが重要な処理を高速化 |
特に注目されるのは、MTPが「モデルを小さくする」高速化ではなく、「同じ主モデルで検証する」高速化である点だ。蒸留や量子化と異なり、最終判断を主モデルに残すため、品質劣化を抑えながら体感速度を上げやすい。
Apple Siliconやバッチ処理での差も
Googleは、26B MoEモデルではApple Silicon上のバッチサイズ1でルーティング上の課題がある一方、複数リクエストを同時処理するバッチサイズ4〜8ではローカルで最大約2.2倍の高速化が見られると説明している。NVIDIA A100でもバッチサイズ増加に伴う改善が見られるという。
一方で、MTPは万能ではない。下書きモデルの予測が外れれば採用されるトークン数は減るため、タスクやデコード設定、ハードウェア構成によって効果は変わる。サーバー運用ではスループット、コスト、レイテンシのバランスを個別に測る必要がある。
オープンモデル競争の次は「速さ」へ
Gemma 4のMTP drafterはApache 2.0ライセンスで公開され、Hugging Face、Kaggle、MLX、vLLM、SGLang、Ollamaなどから利用できる。モデル性能そのものの比較だけでなく、実際のプロダクトで待ち時間をどこまで減らせるかが、オープンモデル採用の重要な判断軸になりそうだ。
参考：Google公式ブログ / Gemma MTP documentation / Hacker News discussion
