Gemma 4 を高速化：マルチトークン予測 drafter によるより高速な推論
(blog.google)- Google は Gemma 4 公開から数週間でダウンロード数が 6,000 万回を超えたとし、Gemma 4 ファミリー向けのマルチトークン予測（MTP）drafterを公開
- MTP drafter は特化型の**推測デコーディング（speculative decoding）**アーキテクチャで、出力品質や推論ロジックを損なうことなく推論速度を最大 3 倍向上させ、LiteRT-LM、MLX、Hugging Face Transformers、vLLM を使用するハードウェアでテスト済み
- 標準的な LLM 推論では、単一トークン生成のために数十億のパラメータを VRAM から演算ユニットへ移動させる必要があり、メモリ帯域幅のボトルネックが大きい一方、MTP は軽量な drafter が複数の将来トークンを提案し、その後で対象モデルが並列に検証する仕組み
- 対象モデルがドラフトトークンに同意すると、シーケンス全体を単一の順伝播で受け入れ、追加トークンも 1 つ生成するため、アプリケーションは通常は 1 トークン分の時間でドラフトシーケンスと追加トークンを出力可能
- MTP drafter は対象モデルの活性値とKV キャッシュを共有し、E2B・E4B のエッジモデルには効率的なエンベッダ（embedder）クラスタリングを適用、重みは Hugging Face と Kaggle で Apache 2.0 ライセンスのもと提供
推測デコーディングが必要な理由
- 標準的な LLM 推論はメモリ帯域幅に縛られ、レイテンシのボトルネックが大きい
- プロセッサは単一トークンを生成するために、数十億個のパラメータを VRAM から演算ユニットへ移動させることに大半の時間を費やす
- この構造は特にコンシューマ向けハードウェアで演算資源を十分に活用できず、レイテンシを高める
- 推測デコーディングはトークン生成と検証を分離する
- 重い対象モデル、たとえば Gemma 4 31B を軽量な drafter である MTP モデルと組み合わせ、空いている演算資源で複数の将来トークンを一度に予測する
- drafter は対象モデルが 1 トークンを処理する時間より短い時間で複数トークンを提案し、対象モデルは提案されたトークンを並列に検証する
MTP の動作方式
- 標準的な大規模言語モデルは自己回帰方式でテキストを生成し、一度に正確に 1 つのトークンしか生成しない
- この方式では、「Actions speak louder than…」の後に「words」を予測するような簡単な続きの生成と、複雑な論理パズルの解法に同じ量の計算を投入してしまう
- MTP は Google の研究者が Fast Inference from Transformers via Speculative Decoding で導入した推測デコーディングにより、この非効率を減らす
- 対象モデルがドラフトトークンに同意すると、シーケンス全体を単一の順伝播で受け入れ、対象モデル自身も追加トークンを 1 つ同時に生成する
- アプリケーションは通常、単一トークンを生成する時間でドラフトシーケンス全体と追加トークン 1 つを出力できる
開発者にもたらす性能効果
- 開発者にとって推論速度は、プロダクション配備の主要なボトルネックになることが多い
- 高速な多段階計画が必要な自律エージェント、コーディングアシスタント、オンデバイスで完全に動作する応答性の高いモバイルアプリケーションでは、ミリ秒単位のレイテンシも重要
- Gemma 4 モデルをこの drafter と併用すると、次の効果が得られる
-
応答性の改善
- ほぼリアルタイムのチャット、没入型音声アプリケーション、エージェント型ワークフローのレイテンシを大幅に削減できる
-
ローカル開発の加速
- 個人用コンピュータとコンシューマ向け GPU で 26B MoE および 31B Dense モデルを高速に実行し、複雑なオフラインコーディングやエージェント型ワークフローを支援
-
オンデバイス性能の向上
- E2B および E4B モデルをエッジデバイス上でより高速に出力できるようにし、デバイスのバッテリー消費削減にも役立つ
-
品質低下なし
- ベースとなる Gemma 4 モデルが最終検証を維持するため、同等の推論性能と精度をはるかに高速に提供する
- NVIDIA RTX PRO 6000 で Gemma 4 26B を実行した例では、標準推論と MTP drafter のトークン毎秒の違いを比較し、同じ出力品質で待ち時間が半分程度になることを示している
- 比較動画は ダウンロード して確認できる
MTP drafter の内部最適化
- MTP drafter を高速かつ高精度にするため、複数のアーキテクチャ改善が適用されている
- ドラフトモデルは対象モデルの活性値を自然に活用し、対象モデルの KV キャッシュを共有する
- KV キャッシュ共有により、大規模モデルがすでに処理した文脈を再計算する時間を無駄にしない
- E2B と E4B のエッジモデルでは最終ロジット計算が大きなボトルネックになるため、エンベッダに効率的なクラスタリング手法を実装して生成を高速化している
- ハードウェア別の最適化も分析されている
- Apple Silicon では 26B mixture-of-experts モデルがバッチサイズ 1 のとき固有のルーティング課題を持つが、複数リクエストを同時処理するとローカルで最大約 2.2 倍の高速化が得られる
- 例のバッチサイズは 4〜8 で、NVIDIA A100 でもバッチサイズを増やすと同様の改善が見られる
- 視覚的アーキテクチャ、KV キャッシュ共有、効率的なエンベッダの動作方式は 詳細な技術説明 で確認できる
使い方と提供場所
- Gemma 4 ファミリー向け MTP drafter は、Gemma 4 と同じオープンソースの Apache 2.0 ライセンスで提供される
- MTP を Gemma 4 とともに使う方法は ドキュメント で確認できる
- モデルの重みは Hugging Face と Kaggle からダウンロードできる
- より高速な推論は transformers、MLX、vLLM、SGLang、Ollama で試せる
- Google AI Edge Gallery では Android または iOS で直接試用できる
- Google は Gemma エコシステムである Gemmaverse において、この高速化が開発を加速することを期待している
1件のコメント
Hacker Newsのコメント
GemmaとGeminiは、他のモデルよりも出力トークンをはるかに少なく使いながら、最上位のベンチマーク性能にかなり近い水準にある
GemmaとQwenを比べるとQwenのほうがやや優れているが、タスクに22分かける一方で、Gemmaはボタンの配置を間違えることがあっても同じプロンプトを4分で終えることがよくある
見かけ上はGemmaの性能は先頭のオープンモデルより5〜10%低いが、時間は1/10しか使っていない計算になる
ClaudeやCodexで他の人たちが月100ドルプランに上げているようなアップグレードの必要性も感じない
ただしGeminiはこの1年で何度か性能が落ち、レート制限も厳しくなってきたので、今後もこれほど良いかは分からない
同じ知能単位あたりでは大きなモデルほど通常は必要トークンが少ないため、トークン使用量の差を説明できそうだ
4070で動かしてみたが、出力はものすごく速いわけではないにせよ実用的だった
まだ複雑な作業には使っていないので、その場合は違うかもしれない
Google I/O以降は、Geminiがどれほど良いかを知る人がもっと増えるかもしれない
配置の問題が起きたら、それを直すために入出力トークンをもう一度使う必要がある
llama.cppにMTPサポートが追加されつつあり、少なくともQwenモデル向けには進行中だ(https://github.com/ggml-org/llama.cpp/pull/20533)
Gemma 4もまもなく続きそうだ
この数か月のローカル・セルフホストモデルの品質と速度の向上は驚くべきものだ
長いことローカルモデルを動かしてきた身としては、本当に興味深い時期だ
MTPと比べてどうなるのか早く見てみたい
かなり良いツールだった
Googleは西側のオープンソースモデルをほぼ単独で支えている
Gemma 4 31Bは素晴らしい
ただし視覚機能と、もうすぐ出るドラフターまで含めて最良の版を24GB VRAMに収めるのはかなりつらい
自分のビルドではGPUをこれ以上追加できず、最高性能を出すには4090をもう1枚買う必要がありそうだが高すぎるか、いっそ総入れ替えになりそうだ
--no-mmproj-offloadを使えば、マルチモーダルプロジェクタ、つまり音声・画像・PDF理解の部分をシステムRAMに置けるもちろんその場合GPUアクセラレーションは効かないが、VRAMは節約できる
タスクごとにより細かく調整できるので、思考と正確さを優先するか、推論速度を優先するかを選べる
コンピュータが文章を書くのを見ていると、昔BBSにモデムで接続していた時代を思い出す
これは300ボーから1200ボーに上がったような感覚なので大きな改善ではあるが、それでもまだかなり遅く、いつか自分たちがどうやってこれを我慢して使っていたのか不思議に思うはずだ
トークンが流れ出るのを見るのは、JPEGが数行ずつピクセルを読み込むのを見ている感じで、アプリが十分に高速になる前にそれぞれ実装していたさまざまなローディング・接続アニメーションも思い出させる
CerebrasやTaalasの取り組みは、その方向で何が可能かを示す興味深い手がかりだ
現在の最先端モデルでも、毎秒100万トークンを非常に低コストで使えるとしたら何が可能か想像するのも面白い
Claudeが計算したモデム対Claudeの比較はこうだ: 2368文字基準で300は1分19秒、1200は19.7秒、2400は9.9秒、14.4Kは1.6秒、33.6Kは705ms、56Kは447ms、Claudeは7.9秒だ
毎秒数千トークン級だった
Googleの戦略は他のフロンティア提供者とは少し違うように見える
純粋な性能よりも計算当たりの性能効率に重点を置いているようで、そのためGeminiが見かけ上は遅れて見えるのかもしれない
他の提供者は容量の限界にぶつかりつつあり、推論コスト補助にも限界が来ている
Googleの戦略は、これらのモデルを既存の何十億ものユーザーへスケールさせて配布することにあるようだ
むしろ最新のGPT-5やClaude系とは別種の知性のように感じる
後者はますます生産性と業務自動化に集中し、長いエージェント的な自己修正推論ループに最適化されている
Geminiはずっと賢いベースモデルのようで、特にDeep Thinkモードでは直感がはるかに深く感じられるが、長距離の自己修正型エージェントループはそこまで得意ではない
この数か月、自分のワークフローでは創造的な飛躍や洞察にはGeminiを使い、反復的または精密な作業にはCodex、Claude、GPT-5.5 Proを好む形になっていた
ローカルモデルをしばらく休んでいたが、最近26B A4BモデルをRTX 3090でvLLMの4ビット設定にしたところ、1000ドル未満の投資で得られる速度と品質に完全に驚いた
最初はQwenで試したが不安定で、思考の痕跡がばかげて長かった
まだ気難しいところはあるが、少し手を入れるだけで本当にすごい
ローカルモデルが未来なのは最高だ
コーディング作業ではQwen 3.6より明らかに劣るが、それはむしろQwenモデルが優秀だという意味に近い
自分のマシンでは他の30Bモデルと比べてtgが期待より少なくとも2倍速く、たぶんハイブリッドアテンションのおかげだと思う
ただし入力処理のほうは少し遅い
これをLM Studioで動かすことに成功した人がいるのか気になる
UIにはオプションがあるが、有効になっているように見えない
[1] https://github.com/ml-explore/mlx-lm/pull/990
[2] https://github.com/ggml-org/llama.cpp/pull/22673
小さいモデルがないので、Gemma疎モデルを使っていないか確認したほうがいい
それからワークスペースから画像モデルをすべて削除した
これらを消すと表示されることがある
これらのファイルはどういうわけか視覚機能とつながっていて、推測デコーディングを妨げているようだが、理由は聞かないでほしい
GemmaではLM Studioよりllama-server経由で推測デコーディングを使うほうがうまくいった
たいてい提供者や量子化などで完全に噛み合っている必要がある
合う組み合わせを見つけるには少し時間がかかることがある
自分のテストでは、Gemma 4 31Bモデルはコーディング作業でOllamaのMLXランナーを使うと最も大きな速度向上を見せ、およそ2倍だった
ただし量子化が受理率を大きく落とすため、かなり強力なMacが必要になる
他の3つのより小さなモデルは、ドラフトモデル検証時間が性能向上の大半を食ってしまうので、それほど良くなかった
より良い性能が出せるかまだ調整中だ
Ollama 0.23.1で
ollama run gemma4:31b-coding-mtp-bf16を実行して試せるllama.cppにマージされたら本当にすぐ使ってみたい
自分の環境ではGemma 4 26B-A4BがQwen3.6-35B-A3Bより約3倍速いので、ここに1.5倍の加速が加わると考えるだけでも魅力的だ
ドラフトモデルも試したが成果は限定的で、より小さい3Bドラフトモデルと密な14B Ministralモデルでもすでにオーバーヘッドが大きすぎた
Gemma4 26Bは同じ量子化で200TPSを超える
Qwenは推論効率が極端に低い点も重要だ
思考連鎖が平均してGemmaより約3倍長い
これはOSの分岐予測のようなものなのだろうか
ただし確率がモデル自体に内蔵されているぶん、はるかに信頼できる形だ
分岐予測ミスはサイクルを浪費するが、ここでの悪い推測は通常ボーナストークンを得られない程度で済む
https://arxiv.org/abs/2211.17192