ハクソク

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

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

5日前原文(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 drafter は Apache 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が瞬時に応答できるカスタムハードウェアを作ったスタートアップがあったよ。毎秒何千トークンも処理できるんだ。

最近、RTX3090（4ビット）で vLLM に 26B A4B モデルをセットアップしたんだ。ローカルモデルからしばらく離れてたけど、今の速度と質には完全に驚かされたよ。最初は Qwen で試したけど、不安定で、信じられないくらい長いスリムトレースが出た！

└

A4Bモデルはめちゃくちゃ速いし、一般的な質問にはすごく強いよ。ただ、コーディングタスクに関してはQwen 3.6の方が明らかに優れてるけど、それはQwenモデルの方がすごいってことだね。

└

Qwen 3.6の初期のクオンタは壊れてたよ。まだちょっと扱いづらいけど、少しサポートがあればすごいことになる。ローカルモデルが未来だし、最高だね。

Googleは西洋のオープンソースモデルを一手に支えてるね。Gemma 4 31Bは素晴らしい。ただ、ビジョンとこのドラフターを合わせて24GBのVRAMに最適なバージョンを収めるのはちょっと辛い。私の構成ではこれ以上GPUをサポートできないし、最高のパフォーマンスを得るにはもう一台4090（高すぎるけど）を欲しいか、そうでなければ全部取り替えちゃうかも。

└

でも、Qwenの方がGemmaよりもまだ優れてるよ。タスクに応じて調整できるから、思考や精度を優先するか、推論速度を優先するか選べるんだ。

私のテストでは、Gemma 4 31bモデルがOllamaのMLXランナーでコーディングタスクにおいて最大のスピードブーストを得たよ（約2倍）。残念ながら、量子化が受け入れ率に大きく影響するから、かなりパワフルなMacが必要になる。小さい他の3つのモデルは、ドラフトモデルの検証時間がパフォーマンス向上をほとんど食ってしまったから、あまり良くなかった。まだパフォーマンスを向上させるために調整を試みてるところ。ollama run gemma4:31b-coding-mtp-bf16でOllama 0.23.1を使って試してみて。

あんまり話題になってないけど、Gemma（とGemini）は他のモデルに比べて出力ごとのトークン使用量がめっちゃ少ないんだよね。それでもトップのベンチマーク性能に近い感じ。GemmaとQwenの比較を見ることが多いけど、Qwenはちょっと良い結果出すけど、タスクに22分もかかってる。一方でGemmaはボタンの配置を間違えたけど、同じプロンプトで4分しかかからなかった。だから、単純に見ると、Gemmaは今、主要なオープンモデルに対して5-10%劣ってるけど、時間は1/10で済んでるってことだね。

└

体感的には、月15ドルの基本Geminiプランで一日中コーディングできるよ。他の人たちがClaudeやCodexで月100ドルのプランにアップグレードしてるのに対して、私は限界に達したりしないし。注意点として、Geminiは去年の間に何度か簡素化されてるし、レート制限も厳しくなったから、将来的にはこんなに良くないかもしれない。

└

確かにそうだけど、公平に考えるなら累積トークン出力を考慮しないとね。そのアライメントの問題には、修正するために別の入力と出力トークンが必要なんだ。

Googleの戦略は他のフロンティアプロバイダーとはちょっと違う気がする。純粋な性能よりも、計算効率に焦点を当ててる感じ。だからGeminiが（見た目上は）遅れをとってるのかも？他のプロバイダーはキャパシティに達して、推論を補助してるけど、Googleの戦略は既存の数十億のユーザーにこれらのモデルをスケールさせて分配することにあるみたい。

└

みんなの戦略がそこにシフトしてるってことじゃない？

もし自分のハードウェアでそんなスピードアップが見られたら、ゲームチェンジャーだね。今のところ、Gemma 4よりもQwen 3.6の方がツールの扱いが良いから好きなんだけど、モデルテンプレートが更新されたって聞いたから、今はもっと良くなってるはず。llama.cppで試すのが楽しみ！

└

gemma4には、ほとんどのランタイムに影響を与えるツールコールに関する特定の問題があるんだ。ollamaとvllmの修正が今進行中だよ。

これは新しいGemma 4モデルがMTPと一緒にリリースされるってこと？それとも既存のモデルやクオンタにすでに含まれてるのかな？

これって、以前の投機的デコーディングとはどう違うの？大きいモデルと小さいモデル、例えばqwen 32bとqwen 4bを組み合わせて、小さいモデルがトークンを生成して、大きいモデルがそれを「認証」するみたいなダイナミクスがあったよね。ブログには大きいモデルのデータを再利用することについて何か書いてあった？

└

私が見る限り、MTPは通常の投機的デコーディングとは違って、小さいモデルが大きいモデルの隠れ状態を使って予測するように訓練されているんだ。