2026-06-06 — 回閲覧

Gemma 4 のマルチトークン予測が llama.cpp に到達：自己投機的デコードがローカル推論で主流に

llama.cpp は 2026 年 5 月にネイティブのマルチトークン予測（MTP）投機的デコードをマージし（PR #22673）、Qwen3.6-27B で約 72% のドラフト受理率にて単一ストリーム生成が約 2.4 倍高速化したと報告。ドラフトヘッドは同じ GGUF から読み込まれ、独自の KV-cache を持つ。2026 年 6 月 6 日、後続の Gemma 4 MTP PR（#23398）がレビュー準備完了とされ、この手

何がリリースされたか

llama.cpp はマルチトークン予測（MTP）投機的デコードをネイティブにサポートするようになった。中核となる基盤は PR #22673（“llama + spec: MTP Support”）で着地し、2026 年 5 月 4 日に開かれ 2026 年 5 月 16 日にマージされた。2026 年 6 月 6 日、後続の Gemma 4 MTP 作業（PR #23398）がレビュー準備完了とされ、同じ仕組みを Google の Gemma 4 ファミリーへ拡張した。

ローカルユーザーにとっての目玉は単一ストリームのレイテンシだ。従来の投機的デコードは、独立した小さなドラフトモデルを実行して次の数トークンを推測し、それを大きなモデルが一度のパスで検証することで生成を高速化する。MTP はその考え方をモデル成果物そのものに折り込む：軽量な予測ヘッドが各フォワードパスで数トークンを提案するため、独立したドラフトモデルを調達し、サイズを合わせ、整合させることなく投機的デコードの高速化が得られる。

マージから得られた数字

マージされた Qwen3.6-27B の経路では、PR #22673 は 3 ドラフトトークンで約 2.4 倍のウォールクロック高速化（83.8 秒対 201 秒のベースライン）を受理率 72.18% で、また 2 ドラフトトークンで約 2.2 倍を受理率 82.58% で報告している。Qwen3.6-35BA3B MoE 変種でも検証された。この設計は同じ GGUF ファイルから MTP ヘッドを読み込むため、追加で配布する必要がなく、独自のコンテキストと KV-cache を保持する。

Gemma 4 PR はこれを別の系統へ押し広げる。密な 31B モデルで 2 倍超を報告し、受理率は設定により約 43% から 70% の範囲で、ある例では約 40 tok/s から約 100 tok/s へと移行している。Q8 量子化の実行は約 1.74 倍から 1.97 倍に着地する。この PR は 31B と 26B-A4B 変種を対象とし、より小さな E4B と E2B を除外する。

モデル / PR	ドラフトトークン	受理率	高速化
Qwen3.6-27B (PR #22673, merged)	3	~72%	~2.4x
Qwen3.6-27B (PR #22673, merged)	2	~83%	~2.2x
Gemma 4 dense 31B (PR #23398, in review)	varies	~43-70%	over 2x
Gemma 4 31B Q8 (PR #23398, in review)	varies	varies	~1.74-1.97x

一つの機微：Gemma はやり方が異なる

知っておく価値のあるアーキテクチャの分岐がある。Qwen 風の経路は同じ重みの中にパッケージされた MTP ヘッドを使う。対照的に Gemma 4 は、Gemma 4 自身の出力分布に整合した、Google が訓練した独立の “assistant” / drafter モデル（Gemma4AssistantForCausalLM クラス）と、ローダーでカスタムマッピングを必要とする新しいスケーリングテンソルを提供する。両方のアプローチは同じ目標、すなわち検証器がめったに却下しない高い受理率を追求するが、配管と取得するファイルは異なる。独立した libllama MTP API（PR #18886）はまだドラフト段階であり、サーバー経路は利用可能であってもこれに対する公開 C API はまだ確定していない。

ローカル機材になぜ重要か

受理率がすべてであり、それはワークロード依存だ。コードや構造化出力のような予測可能なテキストはこれらの範囲の高い端で受理される。自由形式の散文は受理されにくく、実現される高速化もそれに応じて下がる。PR の外のコミュニティ報告は、短く多様な生成については 1.7 倍から 1.9 倍に近いところに集まり、これがバッチのコード補完ではなく対話的チャットに対する正直な期待値だ。この利得は本物だが、一度に一つのストリームに対するレイテンシの利得であって、連続バッチングがすでに GPU を飽和させている多人数の忙しいサーバーに対するスループットの利得ではない。

実務者向けメモ

ローカルで単一ユーザーのコーディングアシスタントを動かすなら、これは今得られる最も安価な高速化だ：最近の llama.cpp ビルドを取得し、MTP 対応の GGUF（今日は Qwen3.6、#23398 が着地すれば Gemma 4）を使い、2-3 ドラフトトークンから始める。マーケティングの倍率ではなく、報告された受理率を真のベンチマークとして注視し、ドラフトトークン数をプロンプトに合わせて調整する。低受理率の散文でドラフトが多すぎると利得が消えかねない。機能が有効だと仮定する前に、ビルドが実際に MTP サーバーフラグを公開しているか検証すること。この機能は新しく、C API はまだ流動的だからだ。

十分に考慮されていない観点

誰もが高速化倍率を引用するが、戦略的な変化は誰がドラフトモデルを所有するかにある。Gemma 4 の assistant 変種のように別途訓練された drafter があると、モデルベンダーが受理品質を制御することになり、それは静かに堀となりうる：正確な出力分布に整合したファーストパーティの drafter は、コミュニティが後付けした汎用の小型モデルに勝るはずだ。これはかつてコミュニティのいじり場だった最適化を集中させ、セルフホスターにとってより静かな問いを提起する。すなわち、ベンダーが強力なベースモデルを意図的に凡庸な drafter と共に出荷し、高速経路を別のライセンスやリリース頻度の背後に置くことができるのか、という問いだ。