ローカルでLLMを動かしていて一番こたえるのは、モデルの賢さよりも待ち時間だ。Macでそこそこの大きさのモデルを走らせると、トークンが一文字ずつポツポツ出てくる速度が頭打ちになり、エージェントに長い作業を任せるほど体感が悪くなる。ここを設定ゼロで縮めたのが、6月30日に出た Ollama v0.31.1 だ。派手な新モデルの発表ではないので日本語ではまだほとんど話題になっていないが、Apple Silicon上でGemma 4を使っている人には効きが大きい変更なので、仕組みごと掘り下げておきたい。
リリースノートの一文が要点を言っている(原文ママ)。
Gemma 4 is now significantly faster in Ollama on Apple Silicon, generating tokens nearly 90% faster on average across a coding-agent benchmark by leveraging multi-token prediction (MTP).
コーディングエージェント系のベンチマークで、Apple Silicon上のGemma 4が平均して約9割(=だいたい1.9倍)速くトークンを吐くようになった、という主張だ。Ollama公式ブログによれば計測は実際のコーディングタスクを回すAider polyglotベンチマークで、しかも「デフォルト有効・設定不要・出力は変わらない」とある。速くなるのに答えは1文字も変わらない。この「タダで速い」がどう成り立つのかが、今回の面白いところだ。
なお前提の確認から。Gemma 4はGoogleが2026年3月末に公開したGemmaの最新世代で、E2B・E4B・12B・26B(MoE)・31B(dense)などの系列がある(Gemmaリリース履歴、モデル概要)。Gemma 3の次にあたる実在の系列で、ここは事実だ。
そもそも、なぜトークンは一個ずつしか出ないのか
Transformerの生成は自己回帰、つまり「次の1トークンを予測して、それを入力に足して、また次を予測する」の繰り返しだ。1トークン出すたびにモデルの全重みを読み直して1回forwardする。問題は、この処理が計算そのものよりメモリ帯域で詰まる点にある。重みをVRAM/ユニファイドメモリから読み出す時間が支配的なので、GPUの演算ユニットは半分眠ったまま、次の1トークンを待つことになる。ローカル生成が「速いGPUを積んでも思ったほど伸びない」のはこれが理由だ。
裏を返せば、1回のforwardで複数トークンをまとめて確定できれば、この待ち時間を丸ごと節約できる。そのための仕掛けが投機的デコード(speculative decoding)であり、今回Gemma 4で効いているのもこの一種だ。
Gemma 4に「付属する下書き役」で先読みする
古典的な投機的デコードは、小さくて速い「下書き用モデル」を自分で別に用意する。下書きモデルが数トークン先まで一気に予測し、本命モデルがそれを1回のforwardでまとめて検証して、合っているところまでを確定する。速いが、どの下書きモデルを選ぶかが悩ましく、相性が悪いと受理率が落ちる。
Gemma 4がやっているのは、この下書き役をGoogleが公式に用意して同梱する形だ。Googleの発表(2026年5月5日)は「Gemma 4ファミリー向けにMulti-Token Prediction(MTP)ドラフターを公開する」とし、これは本体に組み込むのではなく本体とペアで動く小さな専用ドラフトモデルだと明言している。Ollama側の説明も「Gemma 4には本体の隣で走り、数トークン先を提案する小さく速いドラフトモデルが付属する」という表現で一致する。Gemma 4のドキュメントも、全サイズに投機的デコード用の専用ドラフトモデルが用意されていると書いている。
ここは誤解しやすいので区別しておきたい。「MTPヘッドを本体の重みに埋め込み、モデルが自分自身の下書きになる」タイプ(DeepSeek-V3やQwen3-Nextなどが採用)と、「本体とは別の小さなドラフトモデルを添える」タイプは別物だ。Sebastian Raschkaの解説がまとめているMTPは前者の内蔵ヘッド型で、そこにGemmaの名前は挙がっていない。Gemma 4は後者、つまり別モデルだが公式に調整済みの下書きを配る方式だと理解するのが正確だ。手動で相性を探る手間が消えるのが、古典的な投機的デコードに対する実利になる。
| 古典的な投機的デコード | Gemma 4のMTPドラフター | |
|---|---|---|
| 下書きの出所 | 自分で選ぶ別モデル | 公式配布の専用ドラフトモデル |
| 相性合わせ | 自分でチューニング | Googleが本体に合わせて調整済み |
| セットアップ | 下書きモデルの選定が必要 | Gemma 4に同梱、Ollamaでは設定不要 |
| 出力 | 検証で本体と一致 | 検証で本体と一致 |
なぜ答えが1文字も変わらないのか
「予測を先回りしたら精度が落ちるのでは」と身構えるところだが、そうはならない。ポイントは、下書きは候補にすぎず、採用するかどうかは本体モデルの検証が決めることだ。この検証ステップは本体が自分で1トークンずつ生成した結果と一致するように受理・棄却する。合っていれば複数トークンをまとめて確定し、外れたらその手前で打ち切って普通の生成に戻る。だから速度は上下しても、最終的な出力は下書きなし実行と同じになる。Googleが「出力品質にも推論の論理にも劣化はない(no degradation in output quality or reasoning logic)」、Ollamaが「output is unchanged」と言い切れるのはこの性質による。温度やサンプリングの挙動を変える最適化ではない。
なぜ「コーディングベンチで9割」なのか
ここからは私の見立てだが、9割という数字がコーディングエージェントのベンチマークで測られている点に意味がある。投機的デコードの速度は、下書きがどれだけ受理されるか(acceptance rate)でほぼ決まる。予測しやすいトークンが続くほど、まとめ確定できる回数が増えて速くなる。Ollamaのブログも「コードは特に予測しやすい。閉じ括弧、繰り返される識別子、定型的な記述で埋まっている」と同じ理屈を挙げている。散文の日本語チャットより受理率が高く出やすいので、コーディング用途で伸びが大きいのは理にかなっている。逆に、詩や自由な発想の文章では同じ9割は出にくいだろう。自分のワークロードで測り直す価値はある。
数字の出所は分けて見ておきたい。Ollamaの「約9割」はApple Silicon上・単一リクエストのコーディングエージェント計測、Googleが別途挙げる「最大3倍」は複数ハードウェアをまたいだ値で、Apple Siliconではバッチ4〜8の同時処理で最大約2.2倍としている。測り方が違うので、そのまま同じ土俵の数値として並べないほうがいい。
なぜApple Silicon限定なのか
これがApple Silicon中心なのは、高速化がOllamaのMLXエンジン側の作業だからだ。Ollamaの既定エンジンはllama.cpp/GGML系だが、Apple Silicon向けに別途MLXベースのエンジン(ランナー)を持っており、Gemma 4のMTP経路はそのMLXエンジン上で動く。v0.31.1のリリースノートには「MLXエンジンを最新版に更新し、新しいsmall-batch matmulカーネルを追加」「MLXエンジンでのGemma 4 MoEモデルのロードを引き締めた」「Gemma 4のMTP性能を改善」とある。Ollamaブログによれば、この小バッチ向けカーネルは自分たちでMLXに寄贈したもので、Gemma 4の最大の行列積を2〜2.5倍速くするという。MTPの検証はバッチサイズの小さい行列積を大量に回すので、その小バッチ向けカーネルが効いてくる、というのが(ここは私の補足だが)筋の通った説明になる。
試す
必要なのはOllamaを0.31.1以降に上げて、Gemma 4を動かすことだけ。MTPはデフォルトで有効なので、こちらで有効化するフラグはない。モデルタグは Ollamaのライブラリで確認でき、gemma4:12b などのほか gemma4:12b-mlx のようなMLX版タグも並んでいる。
# macOSはHomebrewでOllama本体を更新
brew upgrade ollama
# バージョン確認(0.31.1以降であること)
ollama --version
# Gemma 4 を起動(初回はモデルをダウンロード)
ollama run gemma4
体感で判断せず、--verbose を付けて eval rate(tokens/sec)を更新前後で比べるのが正確だ。コード生成やエージェント的なタスクで投げてみると、受理率が高い分だけ差が分かりやすい。
一次ソースはこのあたり。いずれも公式で、突き合わせて裏が取れる。
- リリースノート: https://github.com/ollama/ollama/releases/tag/v0.31.1
- Ollama公式ブログ: https://ollama.com/blog/faster-gemma-4-mlx-mtp
- Google公式ブログ(MTPドラフター): https://blog.google/innovation-and-ai/technology/developers-tools/multi-token-prediction-gemma-4/
- Gemma 4ドキュメント: https://ai.google.dev/gemma/docs/core
短い見立て
新モデルのニュースに比べると地味だが、MTPドラフターのようなランタイム側の最適化は、同じモデル・同じ出力のまま手元のスループットが上がるという意味で、実務では効きが大きい。しかも仕組み上リスクが小さい。出力が変わらないので、乗り換えの心理的コストがほぼゼロだ。今後Gemma以外にも公式ドラフターや内蔵MTPを備えたモデルが増えれば、ローカル推論の既定路線になっていくはずで、v0.31.1はその入口として見ておくといい。