Gemma 4はMTPデータなしでリリースされた — その重要性とは

Googleは2026年4月3日にGemma 4をリリースしました。優れたベンチマーク結果、マルチモーダル機能、最大256Kのコンテキスト長を備えたオープンウェイトモデルファミリーです。スペック上は印象的なリリースですが、数時間のうちにコミュニティはあることに気づきました。公開ウェイトからMulti-Token Predictionヘッドが削除されていたのです。

このモデルはMTPを使って訓練されていました。GoogleのLiteRTフレームワークにはMTPコンポーネントが含まれています。しかし、HuggingFaceからダウンロードできるバージョンは標準的な自己回帰生成のみ。速度向上なし。投機的デコーディングなし。

本記事では、MTPとは何か、なぜ重要なのか、そしてこの決定がGemma 4を自分のハードウェアで実行するすべての人にとって何を意味するのかを解説します。

Gemma 4とは？

Gemma 4はGoogle DeepMindの最新オープンウェイトモデルファミリーで、Apache 2.0ライセンスの下でリリースされました。4つのサイズで提供されています：

主な機能として、ネイティブマルチモーダル対応、ファンクションコール、構造化JSON出力、140以上の言語での訓練が含まれます。31Bバリアントは、LMArenaテキストリーダーボードで第3位にランクインしています。

内部構造として、Gemma 4にはいくつかのアーキテクチャ上の革新が導入されています：交互に配置されたローカルスライディングウィンドウアテンションとグローバルアテンション層、比例RoPE（p-RoPE）、レイヤーごとの埋め込み（PLE）、共有KVキャッシュ、「Keys equal Values」メモリ最適化などです。

数値で見れば、これは優れたリリースです。問題は、公開ウェイトに含まれていないものにあります。

Multi-Token Predictionとは？

標準的な大規模言語モデルは、一度に1トークンずつテキストを生成します。各トークンにはモデル全体のフォワードパスが必要です。前のトークンが完了するまで次のトークンは開始できません。これが自己回帰デコーディングであり、本質的に逐次処理です。

Multi-Token Prediction（MTP） は、モデルに追加の予測ヘッドを加えることでこれを変えます。次のトークンだけでなく、N+1、N+2、N+3といったトークンを1回のフォワードパスですべて予測します。

その仕組みは以下の通りです：

1. 訓練フェーズ: 追加の軽量予測ヘッドがメインモデルと並行して訓練されます。各ヘッドは異なる未来の位置（1つ先、2つ先、3つ先など）を予測するよう学習します。
2. 推論フェーズ: 追加ヘッドが「ドラフト」トークンを並列に生成します。メインモデルが1回のフォワードパスでそれらすべてを検証します。
3. 検証: ドラフトトークンがメインモデルの生成結果と一致すれば、すべて一度に受け入れられ、複数の逐次デコードステップをスキップできます。ドラフトトークンが不正確な場合、その位置から通常の生成に戻ります。

これは投機的デコーディングと密接に関連していますが、重要な利点があります：ドラフトトークンが別の小さな「ドラフトモデル」を必要とせず、モデル自身から生成される点です。

MTPはどれくらい高速化するのか？

高速化の度合いは、ドラフトトークンが正しい頻度（「受け入れ率」）に依存します。DeepSeek V3が実際の効果を実証しました：

受け入れ率2.4とは、平均してメインモデルの1回のフォワードパスで1トークンではなく2.4トークンが生成されることを意味します。出力は標準デコーディングと数学的に同一であり、すべてのトークンが検証されます。同じ品質がほぼ2倍の速度で得られるのです。

ビジネスを成長させる準備はできましたか？

今日から無料トライアルを開始し、数日で結果を確認しましょう。

デモをリクエスト ログイン

Gemma 4で何が起きたのか

HuggingFaceユーザー（@shadowlilac ）が、GoogleのGemma 4用LiteRTパッケージにMTP予測ヘッドとマルチトークン予測機能が含まれていることを発見しました。しかし、HuggingFaceで公開されたウェイトにはそれらが一切ありません。

MTPコンポーネントは意図的に削除されていました：

• チェックポイントにMTPヘッドなし
• モデル設定にMTPなし
• フォワードパスにMTPなし

Googleの説明

Googleのエンジニア（@srikanta-221 ）がこれは意図的であると確認しました：

公開モデルは「幅広い互換性」のために標準的な自己回帰インターフェースのみを公開しています。MTPヘッドはモデル設定、フォワードパス、チェックポイントから除外されています。これにより、HuggingFace Transformers APIとの互換性が確保され、一貫したチェックポイントとランタイムの動作が維持されます。

Googleは、MTPをモデルの中核機能ではなく「デプロイ時の最適化」と位置づけています。MTP予測ヘッドはLiteRTエクスポートモデルにのみ保存されています。これはGoogleの自社オンデバイス推論フレームワークです。

なぜこれが問題なのか

この説明は精査に耐えません：

1. このモデルはMTPで訓練された。 その機能は存在します。リリースから削除するのは技術的制約ではなく、選択です。

2. サードパーティエンジンが実装できない。 vLLM、llama.cpp、SGLang、その他の推論フレームワークは、予測ヘッドなしにはMTPベースの投機的デコーディングを使用できません。これらのエンジンはオープンソースLLMデプロイメントの大多数を担っています。

3. ユーザーは遅いバージョンを使わされる。 MTPなしでは、Gemma 4は標準的な自己回帰速度で動作します。そのパフォーマンス差は実際にすでに表れています：

4. エコシステムのロックインを生む。 Googleの自社LiteRTフレームワークだけが速度の恩恵を受けます。それ以外は遅いモデルを使うことになります。「オープンウェイト」Apache 2.0リリースとしては、重大な非対称性です。

投機的デコーディングの仕組み（そしてなぜMTPが優れているのか）

欠如したMTPヘッドの重要性を理解するには、推論最適化の進化の中でMTPがどこに位置するかを見ることが役立ちます。

アプローチ1：従来の投機的デコーディング

別の小さな「ドラフトモデル」がトークンを提案します。メインモデルがそれらを並列に検証します。ドラフトが正しければ、ステップごとに複数のトークンが受け入れられます。

• 利点: どのモデルペアでも動作する
• 欠点: 2つ目のモデルの維持とロードが必要。ドラフトモデルの品質が高速化を制限。追加のメモリオーバーヘッド

アプローチ2：MTP（組み込み予測ヘッド）

メインモデルが独自の軽量予測ヘッドを持ち、ドラフトトークンを生成します。別のモデルは不要です。

• 利点: 追加モデル不要。より密接な統合による高い受け入れ率。低いメモリオーバーヘッド
• 欠点: リリースに予測ヘッドが含まれている場合にのみ動作する

MTPが優れている理由

MTP予測ヘッドはメインモデルと並行して訓練されます。同じ内部表現を共有し、モデル自身のトークン分布を学習します。これにより、外部ドラフトモデルよりも高い受け入れ率が実現され、検証ステップごとにより多くのトークンが受け入れられ、全体的な生成が高速化します。

予測ヘッドは非常に小さく、通常モデルの総パラメータ数の1〜3%しか追加しません。メモリオーバーヘッドは別のドラフトモデルをロードする場合と比べて無視できるレベルです。

ニュースレターに登録

最新のヒント、トレンド、お得な情報を無料で入手。

メールアドレス

登録する

広範な影響

これはGemma 4だけの問題ではありません。この決定は、「オープン」ウェイトリリースが実際にどれだけオープンかという前例を作ります。

ユーザーが失うもの：

• サードパーティ推論エンジンでのMTPベースの投機的デコーディング
• MTPヘッドのファインチューニングや実験の機会
• Googleの自社デプロイツールとのパフォーマンス同等性

ユーザーが依然として持っているもの：

• ベースモデルのウェイト（これは本当に優れています）
• 別のドラフトモデルを使用した従来の投機的デコーディング（vLLMのissue #38893 がGemma 4向けEagle3対応を追跡中）
• 標準的な量子化と最適化技術

コミュニティの反応は率直でした。24時間のコンセンサスは、Gemma 4のベンチマーク結果は競争力がある — Qwen 3.5と同等かわずかに劣る — が、製品としては「未完成」であるというものでした。速度、安定性、ツーリングに改善が必要です。追加の問題として、HuggingFace Transformersが当初Gemma 4のアーキテクチャをサポートしていなかったこと、PEFTが新しいレイヤータイプに対応していなかったこと、Macユーザーが大型モデルのロード時にクラッシュを経験していることが挙げられています。

何ができるのか？

Gemma 4のデプロイを検討している方に、実用的な選択肢を紹介します：

従来の投機的デコーディングを使用する。 外部ドラフトモデルでGemma 4の推論を高速化できます。vLLMなどのフレームワークがGemma 4専用のEagle3投機的デコーディングサポートを追加中です。組み込みMTPほどの高速化は得られませんが、何もしないよりは良いでしょう。

速度重視のワークロードには代替を検討する。 Qwen 3.5は同等のハードウェアで大幅に高いトークン/秒を実現します。推論速度が最大の制約であれば、Qwenの方が速度対品質比で優れています。

コミュニティの回避策に注目する。 LiteRTエクスポートにはMTPヘッドが含まれています。研究者がそれらを抽出してHuggingFaceウェイトに再接続する方法を見つける可能性がありますが、Googleは公式にはこのパスをサポートしていません。

フィードバックを提供する。 Googleのエンジニアは積極的にHuggingFaceのディスカッションスレッドを監視しています。MTPヘッドのリリースに関する明確で技術的なリクエストは影響力があります。

結論

Gemma 4は真のアーキテクチャ革新と優れたベンチマーク結果を持つ有能なモデルファミリーです。MTP予測ヘッドを公開リリースから削除し、GoogleのLiteRTフレームワークにのみ保持するという決定は、オープンウェイトの「オープン」を損なうものです。

MTPは些細な最適化ではありません。出力品質に影響を与えることなく、1.5〜2倍の推論高速化を実現できます。明らかにMTPで訓練されたモデルの公開ウェイトからそれを除外することは、二層システムを生み出します：Googleのツールには高速推論、それ以外には低速推論という構図です。

オープンソースAIコミュニティにとって、メッセージは明確です：ベンチマークだけでなく、ウェイトの中に実際に何が含まれているかを確認しましょう。オープンライセンスが常にオープンリリースを意味するわけではないのです。

FlowHunt で構築。オープンソースAIの最新動向はブログ でご確認ください。