こんにちは、パレイド技術部です。
Ollama v0.23.1 がリリースされ、Gemma 4 の MTP speculative decoding が Mac (MLX バックエンド) で動くようになりました。
リリースノートには「コーディングタスクで Gemma 4 31B を 2 倍以上高速化できる」と書かれています。手元の MacBook Air M5 (32GB) で早速試したい——と言いたいところですが、結論から言うと今日の記事ではベンチマーク数値は出しません。提供されている MTP 同梱モデルが BF16 の 64GB のみで、物理的に収まらないためです。
無理に動かしても SSD オフロードで I/O 律速になり、MTP の旨味（target+draft の並列受理による出力増速）は測れません。代わりに今回は、リリースの構造と手元の現実のミスマッチを正直に整理することに集中します。Q4/Q8 の MTP 同梱版が出るか、64GB+ の機材が用意できた段階で続編に回します。
本記事はローカル LLM による自動執筆パイプラインで生成されました。現段階ではクラウド AI（Claude 等）の補助や人間の編集が介在していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。
v0.23.1 の主な変更点
リリースノートから今回の主役だけ抜き出します。
| 項目 | 内容 |
|---|---|
| Gemma 4 MTP speculative decoding | Mac (MLX) で対応。コーディングタスクで Gemma 4 31B が 2x 超高速化（Ollama 公式の主張） |
| MLX/MLX-C スレッディング | 推論ランナーの安定性修正 |
| Go 1.26 | 内部ビルドのバージョン更新 |
| 推奨実行コマンド | ollama run gemma4:31b-coding-mtp-bf16 |
リリースノート上、「2x 超」の比較ベースラインは明記されていません。gemma4:31b (Q4_K_M) との比較なのか、同条件 BF16 同士の比較（恐らくはこちら）なのか、コーディングタスク専用モデル間の比較なのかは現時点では不明です。後ほど触れますが、ここは数字を読むときに注意が必要なポイントです。
MTP speculative decoding とは何か
MTP は Multi-Token Prediction の略です。speculative decoding（投機的デコーディング）の一種で、通常の方式は以下の構造を取ります。
- target モデル: 本命の大きなモデル。最終的な出力を担保する
- draft モデル: 軽量な小さいモデル。「次トークン候補」を先回りで予測する
- 流れ: draft が複数トークン候補を並列生成 → target が一気に検証 → 受理されたぶんだけ出力が前進する
通常の speculative decoding は「draft = 別の小さいモデル」ですが、MTP は target モデル自体に複数トークンを並列予測する head を追加する設計です。Gemma 4 の MTP head は Gemma 4 系の重みと一体化しており、PR の解説を読む限り、別モデルではなく同系列の draft 重みを束ねる形で実装されています。
PR #15980 で Ollama 側に追加された具体的な実装は次の通りです。
| 追加項目 | 内容 |
|---|---|
Modelfile の DRAFT コマンド | draft モデルを Modelfile から指定可能に |
ollama create --quantize-draft | draft モデルを量子化するための新フラグ |
| safetensors import | Gemma 4 形式の draft モデルを ollama create で取り込み可 |
| rotating cache の MTP 対応 | KV キャッシュ周りの修正 |
| constant draft token policy | draft が出すトークン数を一定に保つポリシーを採用 |
| 対応モデル | 現状 Gemma 4 のみが MTP モデルとして表示される |
ベンチマーク数値の根拠（どの環境で何 tok/s 出たか）は、リリースノートにも PR にも載っていません。「2x 超」は Ollama 側の主張のみであり、独立した検証はこれから出てくる段階です。
Ollama Hub の Gemma 4 31B variant 一覧
今回の主役 gemma4:31b-coding-mtp-bf16 は、既存の Gemma 4 31B variant 群の中でどう位置付くのか、表で整理します。
| タグ | サイズ | コンテキスト | 入力 | 備考 |
|---|---|---|---|---|
gemma4:31b-it-q4_K_M | 20GB | 256K | Text+Image | instruction-tuned, 量子化 |
gemma4:31b-it-q8_0 | 34GB | 256K | Text+Image | instruction-tuned |
gemma4:31b-it-bf16 | 63GB | 256K | Text+Image | instruction-tuned, 全精度 |
gemma4:31b-mlx-bf16 | 63GB | 256K | Text | MLX 最適化 |
gemma4:31b-coding-mtp-bf16 | 64GB | 256K | Text | coding FT + MTP draft 同梱 |
重要なのは MTP 同梱版が BF16 (64GB) のみである点です。Q4/Q8 の MTP 版は今のところ提供されていません。31b-coding-mtp-bf16 のサイズが 64GB で、target 単体 BF16 (31b-mlx-bf16) の 63GB とほぼ同等であることから、draft はかなり小さい追加重みとして同梱されているように見えます。あくまでサイズからの推測なので、断定は避けておきます。
32GB Mac で何が起きるか
検証環境は以下の通りです。
| 項目 | 内容 |
|---|---|
| マシン | MacBook Air (M5, 32GB Unified Memory) |
| OS | macOS Tahoe 26.4 |
| Ollama | v0.21.0（v0.23.1 へのアップデートは別途検討中） |
| ローカル既存モデル | gemma4:31b (19GB, Q4_K_M 相当), gemma4:26b (17GB), gemma4:e4b/e2b, qwen3.5:9b/27b/35b, qwen3.6:35b-a3b-q4_K_M, gpt-oss:20b ほか |
ここに 64GB の gemma4:31b-coding-mtp-bf16 を投入したらどうなるか。Apple Silicon の Unified Memory は CPU/GPU/Neural Engine が共有するので、モデルがメモリに収まらないと macOS の swap (SSD) にページが落ち始めます。Ollama 自体は起動するでしょうし、推論も始まる可能性はあります。ただし、トークン生成のたびに重みの一部を SSD から読み直す状態になり、評価フェーズが I/O 律速で潰れます。MTP の本質は「target が draft の複数候補をまとめて受理することで 1 ステップあたりの出力トークンを増やす」ことなので、target 側の評価が SSD 待ちで遅くなれば、増えたトークンも一緒に遅くなるだけです。「2x 超」は測れる前にバンド幅で消えます。
過去のベンチマーク連載でも、32GB Mac の上限は何度か顔を出しています。
ただし、実行中のメモリ消費は約 30GB に達します。32GB の Mac ではブラウザを閉じてようやく動く程度で、常用は厳しい印象です。Ollama ブログでも「32GB 以上推奨」と書いていますが、35B を快適に使うには 64GB 以上が現実的でしょう。
23GB の qwen3.5:35b でブラウザを閉じてようやく動いた環境です。そこに 64GB の BF16 モデルが乗らないのは、検証する前から構造的に確定しています。
比較の難しさ — 2x の意味を読み解く
仮に 64GB の Mac Studio が手元にあり、gemma4:31b-coding-mtp-bf16 がフル速度で動いたとしても、「素の MTP の効果」を分離するのは簡単ではありません。このモデルには 3 つの変数が同時に乗っています。
| 変数 | 内容 |
|---|---|
| 量子化 | 既存の主力タグは Q4_K_M (20GB)。MTP 同梱版は BF16 (64GB)。精度違いが混ざる |
| ファインチューニング | MTP 同梱版は coding FT。既存の gemma4:31b-it-q4_K_M は汎用 instruction-tuned |
| MTP head | この記事の主役。target+draft の並列受理 |
つまり gemma4:31b-coding-mtp-bf16 と gemma4:31b-it-q4_K_M を直接比較しても、3 変数のうちどれが効いているのかが分からない。Ollama 側の「コーディングタスクで 2x 超」も、おそらく同じ MTP 同梱版を「MTP 有効」と「MTP 無効」で比較した数字だろうとは推測できますが、リリースノートに明記がない以上、断定はできません。
技術部としては、「Ollama 推奨セット同士の差」と「MTP head そのものの差」は別物として扱うべきだと思います。後者を測るには、同じ BF16 + 同じ FT のモデルで MTP の ON/OFF を切り替える条件が要る。これは現時点では公式には用意されていません。
過去の数字との接続 — MTP は MoE の代わりにはならない
過去の記事生成パイプライン記事で、gemma4:31b (Dense, Q4) の Pass B/C は 2.4 tok/s でした。
| モデル | タイプ | Pass B tok/s | Pass C tok/s | 合計時間 |
|---|---|---|---|---|
| gemma4:31b (Q4) | Dense | 2.4 | 2.4 | 2069s (約34分) |
| gemma4:26b | MoE (活性化4B) | 12.3 | 14.1 | 390s (約6.5分) |
ここに MTP の「2x 超」が乗ったとして、Dense 31B が 4.8 tok/s 前後になる計算です。それでも記事生成パイプラインで Pass あたり 1000 秒級の世界。MoE の gemma4:26b (12〜14 tok/s) との実用差を MTP だけで埋めるのは難しいでしょう。
このことは MTP の意義を否定するものではありません。「32GB Mac クラスでは引き続き MoE 路線が有効、MTP は 64GB+ 機材または Q4 化 MTP が出てきた時の選択肢」と整理しておきます。Mac Studio M5 系のような 64GB/96GB 機を持っている読者にとっては、今すぐ試せる強力な高速化です。
手元での待機戦略
今日からできることを 3 通り整理します。
| 案 | 手順 | 32GB Mac で動くか | 検証の独立性 |
|---|---|---|---|
| (a) Q4/Q8 の MTP 同梱版を待つ | Ollama Hub に Q4/Q8 の coding-mtp 派生が出るのを待つ。コミュニティが --quantize-draft でビルドする可能性もある | ○（Q4 なら 20GB 級に収まる見込み） | 低（FT も同時に変わる） |
| (b) 自前で Modelfile を組む | ollama create + DRAFT gemma4:e4b のような小型 draft 指定で MTP を組む実験。--quantize-draft も検討 | △（target を Q4 に絞れば可能性あり） | 中（target/draft の組み合わせを揃えやすい） |
| (c) 64GB+ Mac を確保 | Mac Studio M5 系などに環境を移して BF16 のまま測る | × (Air では不可) | 高（公式構成のまま測れる） |
(b) が技術部としては一番おもしろい選択肢ですが、Gemma 4 の MTP head が e4b を draft として受け入れるかは PR の記述だけでは確定できていません。「Gemma 4 系の safetensors を import できる」とは書かれているので、構造としては可能性がありますが、互換性の壁はおそらく存在します。ここは続編で実際に Modelfile を書いて確認したいところです。
まとめ
- Ollama v0.23.1 で Gemma 4 の MTP speculative decoding が Mac 対応。コーディングタスクで 2x 超とアナウンスされたが、比較ベースラインは未明示
- MTP（Multi-Token Prediction）は target+draft の並列受理で実出力トークンを増やす仕組み。Gemma 4 では同系列の draft head が一体で扱われる設計
- 公式の MTP 同梱モデルは
gemma4:31b-coding-mtp-bf16(64GB) のみ。Q4/Q8 版はまだない - 32GB Mac には物理的に乗らないため、本記事ではベンチマーク数値を出さない。SSD オフロード混在では MTP の旨味は測れない構造
- 仮に動いても、量子化・FT・MTP の 3 変数が同時に動く設計なので、「素の MTP の差」を分離するには公式条件が足りない
- 過去の Dense 31B (Q4) は 2.4 tok/s。2x 乗っても 4.8 tok/s 前後で、MoE 26B の 12〜14 tok/s には届かない。32GB Mac では引き続き MoE 路線が有効
次回は、(a) Q4 の MTP 同梱版が公開されるのを待って素直に測るか、(b) gemma4:e4b を draft に指定した自前 Modelfile で MTP を組む実験ルートに挑むか、(c) 64GB Mac Studio クラスの機材が手元に来たら BF16 のまま実測するか、いずれかで MTP の効果を Air の延長線上で見える形に持ち込みます。今のところ一番現実味があるのは (a) の待ちですが、Ollama Hub の更新を見ながら判断したいと思います。
