見出し画像

Gemma 4が最大3倍速くなった ─ MTPドラフターで推論を加速する仕組み

Webtech Watcher

この記事でわかること

  • Google が Gemma 4 向けに公開した「MTP（Multi-Token Prediction）ドラフター」の正体

  • そもそも LLM の推論はどこで遅くなっているのか

  • スペキュレーティブデコーディングが速さを生む理屈

  • 自分の環境で試すときに気をつけたいポイント

何が起きたのか

数週間前にリリースされた Gemma 4 に対して、Google から「MTP ドラフター」と呼ばれる追加コンポーネントが公開された。発表によれば、この仕組みを使うことで推論速度が最大 3 倍まで伸びるという。しかも品質を落とさずに、というところがポイントになっている。

Gemma 4 自体はコンテキスト長 256K トークン、140 以上の言語に対応したオープンモデルファミリーで、Dense と MoE（Mixture of Experts）の両構成が用意されている。今回追加されたのは、その本体モデルに寄り添う小さな「下書きモデル」である。

ちなみに MTP は Gemma 4 の初回リリース時に意図的に外されていたという経緯がある。開発者コミュニティでも「なぜ最初から入っていなかったのか」が話題になっていたが、品質保証を優先したうえで、満を持して有効化された格好だ。

なぜ普通の LLM 推論は遅いのか

「GPU は速いはずなのに、なぜトークン生成は待たされるのか」と感じたことのある人は多いはず。実はここに本質的なボトルネックが隠れている。

通常の LLM は autoregressive（自己回帰） にトークンを一つずつ生成する。1 トークンを出すたびに、数十億〜数百億のパラメータを VRAM から計算ユニットへ運ばなければならない。

つまり状況を整理すると、

  • 演算性能ではなくメモリ帯域が律速になっている

  • 計算ユニットの多くは「待ち」の状態に置かれている

  • それでもトークンは 1 つずつしか進まない

ということになる。コンシューマー向けの GPU ほどこの傾向は強い。せっかくの計算資源が遊んでいるのに、出力は遅い、というのはなんとももどかしい話だろう。

スペキュレーティブデコーディングのアイデア

この遊んでいる計算資源を活かすのが、スペキュレーティブデコーディング（投機的復号） と呼ばれる手法になる。原理はシンプルで、

  1. 軽量な「ドラフトモデル（下書き役）」が、先のトークンを複数まとめて予測する

  2. 重い「ターゲットモデル（本体）」が、その予測をまとめて検証する

  3. 検証に通ったぶんは一気に採用され、外れた箇所からはターゲットモデルが正しいトークンを出して仕切り直す

ポイントは、ターゲットモデルが 1 トークン分の計算をする時間で、複数トークンぶんの検証ができること。冒頭で触れた「メモリ帯域がボトルネック」という性質を逆手に取り、空いている計算ユニットで一括検証してしまう発想だ。

検証に通った場合は、ドラフトの提案した数トークンに加え、ターゲットモデル自身もそのまま続きを 1 トークン出力してくれる。「普段なら 1 トークン出るだけの時間」で、数トークンが進む計算になる。

最終的な出力はあくまでターゲットモデルが承認したものなので、品質は通常の生成とまったく同じになる。これは見落とせない性質で、「速くなったが少し賢くなくなった」という妥協が起きない。

Gemma 4 の MTP ドラフターは何が新しいのか

スペキュレーティブデコーディング自体は新しいアイデアではない。それでも Gemma 4 の MTP ドラフターには、いくつか目を引く工夫が組み込まれている。

1. 入力埋め込みの共有

ドラフトモデルは独立した別モデルではなく、ターゲットモデルの入力埋め込みテーブルをそのまま共有する。重複した重みを持たないので、メモリにも優しい。

2. ターゲットモデルの活性化を再利用

ドラフトモデルは、ターゲットモデルの最終層の活性化（中間表現）を借りてくる。これをトークン埋め込みと連結し、自分の次元に縮約してから推論を進める。「すでに本体が文脈を理解している」その理解をそのまま土台にするようなイメージだ。

3. KV キャッシュの共有

文脈を毎回計算し直さず、ターゲットモデルの KV キャッシュを共有する。地味ながら効く工夫といえる。

4. 効率的な埋め込み層（E2B / E4B 向け）

エッジ向けの小型モデルでは、語彙全体に対する最終ロジット計算自体が重くのしかかる。そこで似たトークンをクラスタにまとめ、まず「どのクラスタが有望か」を絞ってから、そのクラスタ内のトークンだけで最終計算をする工夫が入っている。スマートフォンのような環境では、これが効いてくる場面が多いと思われる。

速度改善の目安

公式の発表によると、想定される使い方ごとに大まかなイメージはこうなる。

  • 31B Dense モデル：ワークステーションや高性能 GPU で大きな効果が期待できる

  • 26B MoE モデル：バッチサイズ 4〜8 程度で、ローカル環境でも約 2.2 倍ほどの速度向上が報告されている

  • E2B / E4B のエッジモデル：オンデバイス利用でレスポンスが目に見えて改善し、結果としてバッテリー消費も抑えられる

ここで一点、初心者がつまずきやすい部分を補足しておきたい。MoE モデルはバッチサイズ 1 だと恩恵が小さくなりやすい。理由は、MoE がトークンごとに異なる「エキスパート」を呼び出す構造をしていて、ドラフトの複数トークンを検証する際に、追加でエキスパートの重みをメモリから読み込む必要が生じるからだ。バッチサイズが上がると、複数のリクエスト間でエキスパートが重なる確率が増え、効率が一気に良くなる。

「MoE で試したけれど思ったより速くならなかった」という場合は、まずバッチサイズを増やせる構成かどうかを見直すと、原因の切り分けがしやすい。

どこで動かせるのか

MTP ドラフターは、Gemma 4 本体と同じく Apache 2.0 ライセンスで公開されている。商用利用にも踏み込みやすい条件だ。

対応している実行環境としては、

  • Hugging Face Transformers

  • vLLM

  • SGLang

  • MLX（Apple Silicon 向け）

  • Ollama

  • LiteRT-LM（オンデバイス向け）

  • Google AI Edge Gallery（Android / iOS のアプリ経由で試せる）

といった選択肢がそろっている。普段使っている推論ランタイムをそのまま流用できる可能性が高い、というのは導入の心理的ハードルを大きく下げてくれる。

試すときに意識したいこと

実際に組み込むときには、いくつか押さえておくと良いポイントがある。

まず一つ目は、ターゲットモデルとドラフターのペアを必ず合わせること。Gemma 4 のサイズごとに対応するドラフターが用意されているため、組み合わせを間違えると本来の速度が出ない可能性がある。

次に、ハードウェアによって最適なバッチサイズが異なること。RTX 系の GPU、A100、Apple Silicon、それぞれで挙動が変わってくる。MoE モデルを動かすなら、バッチサイズの調整は早い段階で試したほうが見通しが立てやすい。

最後に、「速くなる代わりに賢さが落ちる」わけではない点は強調しておきたい。スペキュレーティブデコーディングは、検証に最終モデルが必ず関与する仕組み上、出力分布が一致する。安心して導入してよい類の最適化だと言っていい。

まとめ

LLM 推論のボトルネックは「考える力」ではなく「メモリから重みを運ぶ速度」にある。MTP ドラフターはここを巧妙に回避し、遊んでいた計算資源を一括検証に使い切ることで、品質を保ったまま大きな速度向上を実現している。

Gemma 4 のような開かれたモデルでこうした最適化が公式に提供されたことは、ローカル開発やオンデバイス AI を考えている人にとって素直にありがたい話だと思う。手元のマシンでも、これまで「ちょっと厳しいな」と感じていたサイズが現実的な選択肢に変わってくるかもしれない。

まずは普段使っている推論ランタイムで、ドラフターを差し込んでみるところから始めてみるのが良さそうだ。

参考リンク

いいなと思ったら応援しよう！