世界を動かす技術を、日本語で。

Gemma 4の加速:マルチトークン予測ドラフターによる高速推論

2026年5月6日原文(blog.google)

概要

  • Gemma 4 はオープンモデルとして高い人気と性能を誇る
  • Multi-Token Prediction (MTP) drafter により、推論速度を大幅に向上
  • Speculative Decoding 技術で最大3倍の高速化を実現
  • 出力品質や推論論理は 劣化なし
  • 開発者は様々なデバイスで リアルタイム性と効率性 を享受可能

Gemma 4とMTP Drafterの革新

  • Gemma 4 は、Googleが開発した最新のオープン大規模言語モデル

  • リリース直後から 6,000万回超のダウンロード を記録

  • 開発者用ワークステーション、モバイル、クラウドなど幅広い環境で高性能を提供

  • Multi-Token Prediction (MTP) drafter の導入で、推論時の レイテンシー(遅延)を大幅削減

  • Speculative Decoding という手法を活用し、最大 3倍のスピードアップ を実現

  • LiteRT-LM, MLX, Hugging Face Transformers, vLLM など複数のハードウェア・フレームワークで速度向上を確認

Speculative Decodingの仕組みと利点

  • 従来のLLM推論は メモリ帯域幅に依存 しやすく、遅延のボトルネックとなる
  • 標準的なモデルは 1トークンずつ逐次生成 するため、計算資源を十分に活用できない課題
  • Speculative Decoding は、重いターゲットモデル(例:Gemma 4 31B)と軽量なdrafter(MTPモデル)を組み合わせる手法
    • Drafterが複数の未来トークンを予測
    • ターゲットモデルが一括検証し、合致すれば 一度に複数トークンを出力
  • 出力品質や論理精度の劣化なし で、高速化を実現

開発者にもたらすメリット

  • リアルタイムチャットや音声アプリケーション での応答性向上
  • Gemma 4 26B MoEや31B Denseモデル を一般PCやコンシューマーGPU上で高速動作
  • E2B/E4Bモデル を用いたエッジデバイスでのバッテリー消費抑制とパフォーマンス向上
  • 品質維持 :最終検証はGemma 4本体が行うため、推論精度はそのまま

技術的な工夫と最適化

  • Drafterはターゲットモデルの アクティベーションやKVキャッシュ を共有し、再計算を回避
  • E2B/E4Bエッジモデル では、効率的なクラスタリング手法で更なる高速化
  • ハードウェア別の最適化も実施
    • Apple Siliconではバッチサイズを増やすことで ~2.2倍の高速化
    • Nvidia A100でも同様にバッチサイズ増加で速度向上

MTP Drafterの導入方法

  • Gemma 4ファミリー用MTP drafterApache 2.0ライセンス で公開
  • Hugging FaceやKaggle でモデルウェイトをダウンロード可能
  • Transformers, MLX, VLLM, SGLang, Ollama など主要フレームワークに対応
  • Google AI Edge Gallery でAndroid/iOSからも直接体験可能
  • 詳細な技術解説やドキュメントも公開中

まとめ:Gemma 4とMTP Drafterによる新たな可能性

  • Gemma 4 + MTP drafter の組み合わせで、開発者はこれまでにない高速・高品質なAI体験を実現
  • リアルタイム性、バッテリー効率、柔軟なデバイス対応 で幅広い用途に最適
  • 今後のAI開発・活用における Gemma 4エコシステムの拡大 に期待

Hackerたちの意見

MTPサポートが llama.cpp に追加されるみたいだね、少なくとも Qwen モデルには(https://github.com/ggml-org/llama.cpp/pull/20533)。Gemma 4 もすぐに出るんじゃないかな。最近のローカル/セルフホストモデルのパフォーマンス向上は、質も速度もすごいよね。

でも、まだほとんど役に立たない。

これって実際にはどうやって追加されるの?

MTPは単に重みが増えるだけってことを覚えておくのは重要だね。でも、推測デコーディングは、モデルを提供するコードにとって重要なランタイムアルゴリズムなんだ。

最近、もう一つの PR があって、すぐにマージされると思うよ: https://github.com/ggml-org/llama.cpp/pull/22673

ちょっとバカなパフォーマンスの質問なんだけど、モデルにテキストを少し変更するように頼むとき、なぜ運用変換を生成して既存のテキストに適用するのではなく、すべてのトークンを再生成する必要があるのかな?もしかして、ツールはもっとそういうことをやってるのかな?

数日前、Qwen3.6からGemma 4に再度切り替えたんだけど、個人的には26Bバージョンの方が27Bの方よりも平均的なパフォーマンスが良かった。ローカルモデルを長いこと使ってきた人間としては、今は本当にワクワクする時期だね。

コンピュータがテキストを書くのを見てると、昔のモデムで BBS に電話してた頃を思い出すな。300ボーから1200ボーに上がった感じで、かなりの改善だけど、まだまだ遅いよね。いつか、どうしてこんなのに耐えられたんだろうって思う日が来るだろうな。

これについてはずっと考えてたんだけど…今の状況って、まるでダイヤルアップ時代みたいに感じるよね。「ブロードバンド」時代がどんな感じになるのか想像してしまう。トークンがストリーミングされるのを見てると、JPEGが数行ずつピクセルをロードしていくのを思い出すし、アプリが実装してた様々な読み込みや接続のアニメーションも、速くなって relevance が薄れていく前のものだよね。Cerebras や Taalas のような方向性の作業は、何が可能かの興味深い glimpse を見せてくれる。今の最先端モデルが、もし1秒に百万トークンで、すごく低コストで利用できたら、どんなことができるのか考えるのは楽しい思考実験だね。

chatjimmy.aiをチェックしてみて。

確かにダイヤルアップの時代を思い出させるけど、300から1200ってことはないと思うよ。もっと4800に近いかな。Claudeによると、モデムとClaudeの比較はこんな感じだよ:300 @ 2368文字 - 1分19秒、1200 @ 2368文字 - 19.7秒、2400 @ 2368文字 - 9.9秒、14.4K @ 2368文字 - 1.6秒、33.6K @ 2368文字 - 705ミリ秒、56K @ 2368文字 - 447ミリ秒、Claude @ 2368文字 - 7.9秒。

ここに、AIが瞬時に応答できるカスタムハードウェアを作ったスタートアップがあったよ。毎秒何千トークンも処理できるんだ。

Hacker Newsで議論の続きを見る