Gemma 4のMTP drafterで最大3倍高速化、ただし26B MoEはbatch 1で伸びにくい

追記 (2026-05-07): M1 Max 64GBで実機検証したら、26B A4B (MoE) だけ+13%速くなり、31B DenseとE4Bは逆に遅くなる結果で、公式予測3つすべてとずれた。→ Gemma 4 MTP drafterをM1 Max 64GBで実測、26B A4Bだけ速くなって31BとE4Bは遅くなった

GoogleがGemma 4向けのMulti-Token Prediction drafterを公開した。
公式ブログでは「最大3倍高速化、品質劣化なし」とかなり強い言い方をしているが、速度の出方はモデルサイズと実行環境でかなり変わる。
手元の実測ではなく、公式ブログ、Google AI for DevelopersのMTPドキュメント、vLLM recipeを読んだメモ。

Gemma 4本体の記事では、26B A4BのMoE構成、31B Dense、E2B/E4Bのエッジ向け設計を見た。
今回のMTP drafterはモデル本体の再リリースではなく、既存Gemma 4に付ける推論用の補助モデルだ。

1トークンずつ待つところを補助モデルで先読みする

通常のLLMは、次の1トークンを出し、その結果を見てさらに次の1トークンを出す。
この自己回帰生成は分かりやすいが、1トークンごとに大きなモデルの重みをメモリから読み直すので、GPUの計算能力よりメモリ帯域が詰まりやすい。

MTP drafterは、軽い補助モデルで先の数トークンをまとめて予測する。
Gemma 4本体はその候補を並列に検証し、合っていれば複数トークンを一気に受け入れる。
外れた位置では本体モデルが正しいトークンを出すので、出力品質は通常生成と同じになる、というのがGoogleの説明だ。

この仕組みはspeculative decodingそのものだが、Gemma 4向けのdrafterは完全に独立した小型モデルではない。
Googleのドキュメントによると、入力埋め込みを本体モデルと共有し、本体の最終層activationを使い、KV cacheも共有する。
文脈をもう一度読み直す補助モデルではなく、本体モデルの途中結果に乗る補助ヘッドに近い。

flowchart LR
  A[入力と過去文脈] --> B[Gemma 4本体]
  B --> C[最終層activation]
  C --> D[MTP drafter]
  D --> E[数トークン先を提案]
  B --> F[提案を並列検証]
  E --> F
  F --> G[受理された分だけ出力]

E2BとE4Bでは、語彙262K全体に対して毎回logitを計算する代わりに、クラスタから約4K候補へ絞るcentroids maskingも使う。
vLLM recipeでは、この部分でlm_head計算がおよそ45倍軽くなると説明している。
小型モデルほど最終logit計算の比重が大きくなるので、E2B/E4B向けに別の高速化を入れているのは自然だ。

公式の最大3倍は全モデル一律ではない

Google公式ブログは、LiteRT-LM、MLX、Hugging Face Transformers、vLLMでtokens per secondの改善を測ったとしている。
MTP drafter自体はApache 2.0で公開され、Hugging Face、Kaggle、MLX変換、vLLM、SGLang、Ollama、Google AI Edge Galleryから触れる流れになっている。

ただし、Gemma 4 26B A4Bは少し癖がある。
Google AI for DevelopersのMTPドキュメントは、MoEモデルでは各トークンが別のexpertを叩くため、複数候補の検証で追加expert weightのロードが発生し、draftの得が相殺されることがある、と書いている。
特にbatch size 1ではexpertの重なりが少なく、並列性の低い環境だと速度が伸びない。

Google公式ブログ側でも、26B MoEはApple Siliconのbatch size 1でroutingが難しく、batch size 4から8にするとローカルで最大約2.2倍まで伸びる、と補足している。
NVIDIA A100でもbatch sizeを上げると似た改善が見えるという話なので、対話用途の単発リクエストより、複数リクエストをまとめるサーバー運用のほうが効きやすい。

この点は、Qwen3.5-35B-A3Bでctx-sizeを伸ばしても速度が落ちなかった話と比べると見えやすい。
Qwen3.5はSSM+AttentionハイブリッドでKV cache自体を小さくする方向だった。
Gemma 4 MTPは、重い本体モデルを毎トークン動かす回数を減らす方向。
どちらも推論の詰まりを減らすが、効くボトルネックが違う。

vLLMの推奨値は31B寄りに見える

vLLM recipeでは、MTPのassistant modelとしてE2B、E4B、26B A4B、31Bの4種類が並んでいる。
推奨の num_speculative_tokens はE2Bが2、E4Bと26B A4Bが4、31Bが4から8。
26B A4Bと31Bではtensor parallel 2も推奨されている。

遅いtarget modelほど、drafterが先読みする価値は大きい。
31B Denseは毎トークン30.7Bを読むので、4から8トークン先読みしても補助モデルのコストを回収しやすい。
E2Bは本体が軽いぶん、先読みを増やしすぎるとdrafterのオーバーヘッドが目立つ。

26B A4Bはその中間に見えるが、実際にはMoE routingが絡む。
vLLMの推奨値はA100/H100で測られたもので、手元のMac、ゲーミングGPU、Ollama量子化モデルでそのまま同じ値になるとは限らない。
num_speculative_tokens を増やせば速くなる、ではなく、受理率とdrafterの計算量とexpert weightのロードが釣り合う点を探す話になる。

ローカル用途で効くのは出力が長い処理

MTP drafterはTime to First Tokenを魔法みたいに消すものではない。
先読みで効くのは、最初の応答が始まった後のdecode部分だ。
短いチャットで20トークンだけ返すなら体感差は小さいが、コード生成、長い要約、ローカルエージェントの複数ステップ出力では待ち時間に出る。

ローカルLLMでMCPやtool callingを使う場合も、この差は地味に効く。
OllamaとローカルLLMでMCPサーバーを使うならブリッジが要るで書いた通り、ツール定義やtool結果を抱えるとコンテキストと出力が重くなる。
Gemma 4のtool callingやthinkingを有効にするなら、生成トークン数は普通のチャットより膨らむ。

一方で、MTPはメモリ使用量をゼロにする技術ではない。
target model本体に加えてassistant modelを読むし、vLLMでは31Bや26Bでtensor parallel 2が推奨されている。
24GB VRAMの単体GPUやApple Siliconのユニファイドメモリでは、モデル量子化、コンテキスト長、batch sizeのどれかを詰める必要が残る。

GemmaがMoEに来た経緯

Gemma 4で26B A4BがMoEになったのは唐突な方針転換ではない。
Google自身がMoEの先駆者で、2017年のSparsely-Gated MoE Layer（Shazeer et al.）から研究が続いている。
2020年のGShard、2021年のSwitch Transformer、2022年のGLaM（1.2Tパラメータ、GPT-3の1/3の計算量で同等品質）と、社内でMoEの知見は積み上がっていた。
GeminiシリーズもMoE構成を使っていると広く指摘されている。

むしろGemma 1から3までDense一本だった3世代のほうが不自然で、オープンウェイト向けのMoE設計が固まるまで出さなかったと見るのが自然だ。
Gemma 4本体の記事で書いた通り、Dense FFNとMoEを並列実行してルーティングの不安定さを吸収する設計は、他のMoEモデルにはないGemma独自の構造。
GLaMやSwitch Transformerでの経験が「MoEの弱点をどう潰すか」に反映された結果だろう。

MistralのMixtral、QwenのMoEシリーズ、Kimi K2.5の1T MoEと、2024年以降はアクティブパラメータを絞るMoEがオープンウェイトの主流になった。
GemmaもGemma 4でこの流れに乗った。

MoEと自己回帰は別の軸

MTPの話をしていると「MoEだから遅い」「Denseのほうが速い」という混同が起きがちだが、自己回帰生成とMoEは直交する概念だ。

自己回帰はトークンの生成方法。前のトークン列を見て次の1トークンを出し、それをまた入力に戻して次を出す。
Gemma 4もQwen3.5もKimi K2.5もLlamaもGPTも、生成部分は全部自己回帰だ。
MTP drafterが解決しようとしているのはこの「1トークンずつ本体モデルを動かす」ボトルネックで、モデルがMoEかDenseかとは直接関係ない。

MoEは各forward pass内の計算の分配方法。
1トークンを処理するとき、全パラメータを動かす（Dense）か、ルーターが選んだexpertだけを動かすか（MoE）という選択であって、「前のトークンを見て次を出す」という自己回帰の仕組み自体は同じ。

ではなぜMoEでMTPの速度が伸びにくくなるのか。
この記事の前半で書いた通り、問題はspeculative decodingの検証フェーズにある。
drafterが提案した複数トークンの候補を本体モデルが並列に検証するとき、各候補トークンが異なるexpertを叩く。
Denseモデルなら全候補で同じ重みを使うのでメモリ読み込みは1回で済むが、MoEでは候補ごとに別のexpert weightをロードする可能性がある。
「MoEだから自己回帰が遅い」のではなく、「MoEだと投機的並列検証のメモリI/Oが増える」というのが正確な話。

思考タスクでDenseとMoEにどれだけ差が出るか

Gemma 4は31B Denseと26B A4B MoEを同時にリリースしているので、同一世代でアーキテクチャの差だけを比較できる珍しいケースだ。
本体記事のベンチマークから思考系に絞って見る。

AIME 2026（数学推論）は31Bが89.2%、26B A4Bが88.3%。差は0.9ポイントしかない。
数学は問題構造がはっきりしていて、推論の各ステップで必要な計算の種類が似通っているため、MoEのルーティングが安定しやすい。
Dense FFN並列が効いて、routingが揺れてもベースラインの計算が推論を支えている。

LiveCodeBench v6（コーディング）は80.0% vs 77.1%で2.9ポイント差。
数学より差が広がるが、アクティブ3.8Bで77%という数字自体は強い。
コーディングは数学よりタスクの幅が広く、routingのばらつきが出やすいぶん差が開いた。

BigBench Extra Hard（複雑推論の詰め合わせ）になると74.4% vs 64.8%で9.6ポイント差。
数学やコーディングと違って問題の種類が多岐にわたるため、「正しいexpertを選べるかどうか」の影響が大きくなる。
Dense FFNが吸収しきれない種類の推論タスクがある、ということだ。

長コンテキスト（MRCR v2 128K）は66.4% vs 44.1%で22ポイント以上の差がつく。
これはMoEというよりグローバルアテンション層の数の差が支配的で、31Bはレイヤー数60に対して26B A4Bは30。
長距離の情報参照が必要な推論では、層の深さとグローバルアテンションの割合が直接効く。

単一テーマの深い推論（数学、コード）ではMoEでもDenseに肉薄する。
タスクの種類が散らばる複合推論や、長いコンテキストに依存する推論ではDenseが有利。
MTP drafterを付けても、この品質差自体は変わらない。
drafterが外れたときは本体モデルが正しいトークンを出すので、最終出力は通常生成と同一になるのがGoogleの説明。
品質には影響しないが、MoEの場合はdraftの受理率が下がりやすく、速度のゲインが減る。
batch 1でMoEが伸びにくいのはこの構造的な問題が効いている。