ローカルLLMの世界では、毎週のように「最大◯倍速」という見出しが流れてきます。今週飛び込んできたのは二本立てでした。
一つはGoogle純正、Gemma 4ファミリー向けの「Multi-Token Prediction（MTP）ドラフター」。もう一つはApple Silicon専用の「MTPLX」というMLXフォーク。前者は最大3倍、後者は2.24倍。数字だけ見るととても魅力的です。
いつものように、8GBのMacBook Neoで動くのか確かめてみました。結論から言うと、両方とも今の私の環境では動きません。ただ、その「動かない理由」がそれぞれ違っていて、ローカルLLMの最適化トレンドを読むには面白い題材だったので、整理して書いておきます。
その1：Gemma 4 MTPドラフター（Google純正）
Googleが2026年5月に出したブログ記事「Accelerating Gemma 4: faster inference with multi-token prediction drafters」で発表された技術です。Gemma 4ファミリー（E2B、E4B、26B MoE、31B Dense）すべてに対して、専用の「MTPドラフター」をペアで使うと、最大3倍速くなる、と謳っています。
仕組みはSpeculative Decodingの一種です。本体のモデル（ターゲット）の隣に、ぐっと小さいドラフターモデルを並べる。ドラフターが先に何トークンか予測して、本体がそれをまとめて検証する。当たればそのまま採用、外れたら本体の予測で上書き。アイドル時間を圧縮することで、品質を一切落とさずに速くなる、というアイデアです。
ここで思い出すのは、IntelがPentiumで導入した動的分岐予測と、その後のPentium Proで実装した投機的実行。CPUの進化で使われてきた技術がLLMの高速化でも効いてくるとはちょっとワクワクするではないですか。
さて、筆者がMacBook Neo上で動かしている自作のエージェンティックAIであるmazzaineoで使っているGemma 4は、Ollama経由のgemma4:e2bです。これに対応するドラフターは、ブログ公開の翌日にひっそりとHuggingFaceに上がっていました。
ドラフター:google/gemma-4-E2B-it-assistant
パラメータ数: 78M（本体の2.3Bに対して約30分の1）
重みサイズ: BF16で150MB
KVキャッシュは本体と共有
ファイルサイズが軽く、KVキャッシュも共有してくれるので、メモリ的には8GB Macでもギリギリ収まる計算。本体6.83GB＋ドラフター0.15GBで、合計約7GB。余裕はないけれど、入ります。
問題はランタイムでした。
ランタイム | MTP対応状況 |
Ollama 0.20.2（mazzaineoの現用） | 未対応。speculative decodingのPR #8134がドラフト中 |
mlx-lm | Gemma4AssistantForCausalLMという独自アーキテクチャに未対応 |
llama.cpp | 同上、GGUF変換とカスタム対応が必要 |
HuggingFace Transformers | 公式対応（assistant_model=パラメータで指定） |
つまり、8GBのMacBook Neoで動かせる選択肢は事実上、HuggingFace Transformers のみ。しかもPyTorch + MPSバックエンドで5.1B（埋め込み込み）のGemma 4 E2B-itを動かすのは、メモリとしても速度としても現実的ではありません。試そうとした瞬間にスワップが始まるのが目に見えています。
ベースラインの実測値を取っておきました。
モデル: gemma4:e2b @ Ollama 0.20.2
速度: 16.83 tok/s（256トークン生成、eval phase）
メモリ: 6.83 GB
Gemma 4 E2B-itのモデルカードに書かれているMTP適用後の見込みは「最大2倍」。ブログの「最大3倍」は31B Denseでの値で、E2B級では2倍が上限です。仮にこれが効いたら 16.83 → 33～35 tok/s。十分ありがたい数字なんですが、現状のランタイムでは指をくわえて待つしかありません。
Ollama PR #8134がマージされ、コミュニティがgemma4:e2b-mtpのようなタグをアップロードする日を待つ、というのが現時点での最短ルートです。
その2：MTPLX（コミュニティのMLX高速化フォーク）
もう一つの話題、MTPLXです。これはGoogleではなく、youssofalというGitHubユーザーが公開しているプロジェクトで、Reddit r/LocalLLaMA で「2.24x faster TPS」と話題になっていました。MLXのソースをフォークして、Metalカーネルを書き直し、verify-MLPの内側ループをunroll_count(4)、4-simdgroupに変更することで、Speculative Decodingの検証フェーズを短縮した、という実装です。
Reddit で踊っていた数字はこれです。
•M5 MaxでQwen3.6-27B: 28 tok/s → 63 tok/s（2.24倍）
この数字は本当に立派です。ただ、自分の8GB Macに当てはめようとすると、いくつもの壁にぶつかります。
壁その1：48GB必要
MTPLXには起動前のプリフライトチェックがあり、unified memoryが48GiB未満なら警告、80%を超えたらエラー停止する設計になっています。8GB MacBook Neoは、ドキュメントを読む段階で対象外と告げられます。
壁その2：Gemma 4用のチューニング済みモデルがない
Youssofalが公開しているHuggingFaceのモデルは現状この4つです。
•Qwen3.6-27B-MTPLX-Optimized-Speed
•Qwen3.6-27B-MTPLX-Optimized
•Qwen3.5-4B-MTPLX-Optimized-Speed
•Qwen3.5-4B-Optimized-MTPLX
Qwenだけ。Gemma 4 E2B/E4B用の最適化モデルは存在しません。MTPLXは「MTPヘッドがモデル本体に組み込まれている」前提のランタイムなので、別ファイル方式のgemma-4-E2B-it-assistantとは設計思想が噛み合いません。
壁その3：小型モデルだと倍率が伸びない
これが地味に重要なところです。Qwen3.5-4B-MTPLX-Optimized-Speed のモデルカードに書かれている実測値を見ると、
•AR（通常生成）: 108.41 tok/s
•MTP深さ2: 120.06 tok/s
速度向上:約1.11倍
タイトルの「2.24x」は27Bモデルの話で、4Bでは1.11倍に落ち込みます。Speculative Decodingというのは、本体の検証コストがドラフトコストより大きいときに効く技術なので、本体が小さいほど旨味が薄くなる。Gemma 4 E2B（2.3B）に当てたら、4Bよりさらに渋い数字になることが予想されます。
3つの壁のどれか一つでも倒せれば話は変わるのですが、3つ同時に立ちはだかっているのが現実です。
8GBマシンから見る最適化トレンド
2つの技術を並べて気づくのは、ローカルLLM最適化のフロンティアが、もう一段上のスペック層に移ってしまったという事実です。
MTPLXが想定するのはMac Studio級の48GB以上。Gemma 4 MTPの本領（3倍）が出るのも31Bや26Bといった、8GBマシンでは触れない大きさのモデルです。E2BのようなエッジモデルでもMTPは効きますが、倍率は2倍に落ち、しかもランタイム側の対応が追いついていない。
去年から今年にかけて、8GB Macでも動くLLMが急速に増えました。1ビットBonsai、Ternary Bonsai、Qwen3 8B（kv-cache量子化）、Gemma 4 E2B。「8GBでも十分賢い」を実現する流れです。一方で、最新の高速化技術はだいたい「64GB以上のMacを持っている人向け」にチューニングされ始めています。8GB勢にとっては「これ以上速くする」よりも「いま動いているものをちゃんと使い切る」フェーズに入りつつある、ということかもしれません。
筆者の場合は128GBのメモリを積んだM4 Max MacBook Proで恩恵を受けることができるのですが、8GBという最低限のメモリしか搭載されていないMacBook Neo、そして同じメモリ容量のM4 Mac miniでは無理な相談となります。
現時点でのおすすめ
両方の技術を試そうとして空振りしたあと、mazzaineoのモデル選択は結局こうなりました。
用途 | 選択 | 理由 |
速度重視のチャット | Ternary Bonsai 8B (1.58-bit) | 19.3 tok/s、メモリ2.37GB、Tool Calling動く |
Vision | Gemma 4 E2B（Ollama） | 16.83 tok/s、画像入力対応 |
エージェント | Qwen3 8B（Ollama） | kv-cache量子化が効く |
Gemma 4 MTPに関しては、Ollamaのspeculative decoding対応PRの動向を注視しておく価値があります。マージされてコミュニティMTPタグが整えば、何も変えずに2倍近く速くなる可能性がある。MTPLXに関しては、残念ながら8GB機のロードマップには載りません。
「最大3倍」「2.24倍」という見出しは魅力的ですが、その倍率の前提条件まで読み込むと、自分の8GB機に何が降ってくるかが見えてきます。今回はどちらも空振り。次の波が来るのを楽しみに待つことにします。
ただ、希望はあります。Googleはすでに Android と iPhone 向けに最適化した Gemma 4 のエッジ向けモデルをリリースしていて、Edge Gallery アプリ経由で実際に手元のスマホで動かせるようになっています。
筆者もiPhone Airで試してみましたが、体感の処理速度は確かに高速化されているようで、画面の中をトークンが流れていく速さに「ああ、MTPが効いているのはこういうことか」と納得させられました。
iPhone Airで動くものが、同じApple Silicon系列のMacBook Neoで動かない理由はないはずです（世代的にはiPhone Airの方が上ですが）。Neoでも使えるようになる日を、心待ちにしています。
128GBのM4 Maxで両方とも動かしてみた
8GB機からは空振りに見えた2つの高速化技術ですが、せっかく筆者の手元には128GBのM4 Max MacBook Proがあるので、同じ机の上で両方とも実際に走らせてみました。
結論から言うと、両方とも「動きます」。ただし、数字の出方は8GB機から眺めていたときの想像とは少し違っていました。
Gemma 4 MTPドラフター（HF Transformers + MPS）
google/gemma-4-E2B-it（5.10B）に google/gemma-4-E2B-it-assistant（77.7M）を assistant_model= で組み合わせ、temperature 0.6 / top_p 0.95 / シード固定で計測しました。
プロンプト | AR | MTP | 倍率 |
短いコード（fib） | 18.92 tok/s | 19.72 tok/s | 1.04× |
256トークンのコード（BST） | 24.73 tok/s | 38.41 tok/s | 1.55× |
256トークンの散文（解説文） | 27.73 tok/s | 18.52 tok/s | 0.67× ⚠ |
平均1.09×、中央値1.04×。コードでは1.55×まで伸びる一方、散文では0.67×とむしろ遅くなります。draftの当たり率が低いプロンプトでは、棄却された下書きを捨てるロスが上回るためで、教科書通りの挙動です。モデルカードの「最大2倍」は当たりやすいコード/構造化出力での上限値、実用平均は1～1.1倍程度、というのが今回見えた像でした。
MTPLX（Qwen3.6-27B-MTPLX-Optimized-Speed, MLX）
pip install --pre mtplx で v0.1.4 を導入し、`mtplx pull` で 16.4GB のverified モデルを落として、`mtplx ask` で AR と MTP-D3 を同条件で並べました（profile は既定の performance-cold）。
プロンプト | AR | MTP-D3 | 倍率 | 受理率 D1/D2/D3 |
Fibonacci（98トークン） | 20.98 tok/s | 37.29 tok/s | 1.78× | 96 / 79 / 75 % |
BST（800トークン） | 26.11 tok/s | 42.55 tok/s | 1.63× | 96 / 90 / 81 % |
M5 Maxで記録された 28.156 → 63.056 tok/s（2.24×）に対し、M4 Max では 26 → 43 tok/s（1.6～1.8×）でした。AR 側の絶対値はメモリ帯域比（M4 Max 546GB/s ÷ M5 Max 614GB/s ≒ 0.89）にほぼ一致します。倍率がREADMEの2.24×に届かなかった理由は単純で、今回はファンを固定する `--max`（ThermalForge）を入れていないためです。README自身が「Mediumモードはファン制御なしでは持続しない」と明記しています。
つまずいた点
MTPLX 0.1.4 の wheel に Phase 0H exactness スクリプトが同梱されておらず、`mtplx bench run` がプリフライトで落ちます。今回は手動の `mtplx ask` で同シード比較。
MTPLX は `--depth` が現状 1～3 に制限されており、最大スイートスポットは D3。
Gemma 4 MTP は transformers 5.5 以降が必須。グローバル環境ではなく venv を切るのが安全。
Gemma 4 + MPS + 散文の組み合わせは負の倍率（0.67×）が出るので、用途を選びます。
「8GB機にはどちらも降ってこない」という結論は変わりません。
128GB機側から見ると、MTPLX は買ってきたメモリで素直に1.6～1.8倍速くなる「メモリで殴れば報われる」型の最適化、Gemma 4 MTP ドラフターは「メモリがあっても用途次第で逆効果になりうる」型の最適化、という非対称性が見えました。
最大3倍・2.24倍といった見出しの倍率は、ハードウェアとワークロードの条件が揃ってはじめて立ち上がる数字だ、というのが両方を並べて回した素直な感想です。
最大で3倍。当たらなければどうということはない、ではなくて、当たってこそ意味がある、ということでしょうか。
※この記事は、Claude Codeでの調査作業の記録を元に、筆者が修正・加筆したものです。
