はじめに
前回、decode の演算強度は重み1個につき 2 FLOP という不変量から決まり、FP8 なら常に 2 FLOP/byte で、尾根（ridge point）の数百倍下に張り付いている、という話を書きました。そして脱出路はバッチングだけであり、KV がその天井を作る、とも。
ただし、バッチングはデータセンターの解です。他人のリクエストが毎秒何百と飛んでくるから、束ねて行列にできる。個人マシンのローカルLLMは batch=1 で、束ねる相手がいません。では個人マシンは、演算器を9割以上遊ばせたまま、帯域の天井に頭を押さえられ続けるしかないのでしょうか？
実は、脱出路がもう1つあります。他人のリクエストの代わりに、自分の未来のトークンでバッチを組む。投機的デコーディングです。そして Qwen3.6 世代で llama.cpp にマージされた MTP（Multi-Token Prediction）サポートは、これを別のドラフトモデルなしで実現します。
本記事は前回のルーフラインの言葉をそのまま使って、次の4点を整理します。
- MTP の仕組み。ドラフトのデータはどこから来て、検証はなぜタダなのか
- なぜデータセンターでは主役になりにくく、個人マシンの batch=1 でこそ効くのか
- Apple Silicon での現状
- おまけとして、llama-server をひとりで使うなら
-np 1という話
手元での網羅的な実測はまだ行っておらず、公開情報の整理が中心です。数値やフラグ名は執筆時点（2026年7月）のもので、llama.cpp は動きが速いので、お使いのビルドの --help で確認することをおすすめします。
本記事の数値ラベルについて
| ラベル | 意味 |
|---|---|
| 【公式】 | モデルカード・ベンダー公式発表 |
| 【論文】 | arXiv 等の一次研究文献 |
| 【実測報告】 | コミュニティ・個人による実測レポート |
| 【推定】 | 第三者の推定値 |
| 【試算】 | 筆者の計算。前提を明示します |
| 【筆者の解釈】 | 裏付けが取り切れていない読み筋 |
前提：本記事はローカル推論なので Q4 を基準にします
前回は FP8（1 param = 1 byte、演算強度 2）を基準にしました。ローカル推論の主流は Q4 系（1 param ≒ 0.5 byte）なので、本記事の batch=1 decode の演算強度は 4 FLOP/byte とします。不変量「重み1個につき 2 FLOP」は変わらず、分母が半分になっただけです。尾根が百数十のオーダーの世界では、2 も 4 も「数十倍下」であることに変わりありません。
先に結論
- 【試算】batch=1 の decode は演算強度 4（Q4）で、コンシューマGPUの尾根（FP16 dense 基準でおおむね百数十）の数十倍下にいます。RTX 3060 なら演算器の利用率は3%弱です。
- MTP は「自分の未来のトークンでバッチを組む」技術です。小さな追加ヘッドが数トークン先をドラフトし、本体が1回のフォワードパスでまとめて検証します。1回の重み読み出しで確定するトークンが1個から（採択数＋1）個に増え、演算強度が同じ倍率だけ右へ動きます。
- ドラフトの入力は、本体が直前の decode で計算し終えた最終層の隠れ状態です。既にメモリ上にある副産物であり、新しく運ぶデータはヘッド1層分しかありません。
- 検証は本体自身が行うので出力分布は完全に同一（ロスレス）です。外れても不一致位置の正解1トークンは必ず確定するので、最悪ケースは素の decode にヘッド分の微小オーバーヘッドが乗る程度です。
- 【実測報告】CUDA では 27B dense で1.7倍前後。ただし MoE（35B-A3B）は1.17倍にとどまります。主因は、アクティブ3Bゆえに素のデコードが元々軽く、投機が節約できる本体コストが小さいことです。加えて、検証のミニバッチが複数のエキスパートを起動して読み出しを増やす expert scattering も効いてきます。前回 PART 5-6 で書いた「MoE はバッチで殴りにくい」の小規模版です。
- データセンターは他人のリクエストでバッチを組めるため、投機の限界的価値は小さくなります。個人マシンはバッチを組めないため、投機が唯一の「右へ動く」手段です。恩恵の向きが、珍しく個人側に倒れています。
- 【実測報告】Apple Silicon / Metal は現状、実装が追いついておらず逆効果の報告が複数あります。採択率95%でも遅い例があることから、原理ではなく実装の問題に見えます。M5 Max でも手元に届いたら実測したいところです。
- おまけ：llama-server はデフォルトが4スロット起動に変わりました。ひとりで使うなら
-np 1の明示が確実です。
早見表
| 素の decode | MTP（先読み幅 K、採択数 a） | |
|---|---|---|
| 演算の形 | 行列 × ベクトル | 行列 × 幅Kの細い行列 |
| 1回の重み読み出しで確定 | 1 トークン | a＋1 トークン |
| 演算強度 | 4（Q4） | （a＋1）倍側へ移動 |
| 出力分布 | ─ | 素の decode と同一 |
| 追加で必要なもの | ─ | MTPヘッド入り GGUF、メモリ 1〜2.5GB 程度 |
PART 1：個人マシンの動作点 ─ 尾根まで数十倍
まず、個人マシンがルーフラインのどこに住んでいるかを確認します。
batch=1 の decode は、1トークン生成するたびにモデルの全重みを読みます。前回と同じ理屈で、演算強度は Q4 なら 4 FLOP/byte。一方、コンシューマGPUの尾根を1つ出しておきます。
RTX 3060 の尾根【試算】
FP16 dense テンソル演算 約51 TFLOPS【推定】 ÷ 帯域 360 GB/s【公式】 ≒ 142 FLOP/byte
decode（AI = 4）との比 : 36倍 下
演算器の利用率 : 4 ÷ 142 ≒ 2.8%
前回の VR200（398倍下、利用率0.25%）ほど極端ではありませんが、構図は同じです。演算器はほぼ全部遊んでいます。
そして帯域律速なので、生成速度の理論上限は前回と同じ式です。
理論上限 tok/s ≒ メモリ帯域 ÷ 毎トークン読む重みの実効サイズ
| ハードウェア | メモリ帯域【公式】 |
|---|---|
| RTX 4060 8GB | 272 GB/s |
| RTX 3060 12GB | 360 GB/s |
| RTX 5060 Ti 16GB | 448 GB/s |
| M5 Max（40コアGPU） | 614 GB/s |
なお M5 Max の帯域は GPU コア数の構成で変わり、32コアGPU構成では 460 GB/s です【公式】。
たとえば Q4 の 27B dense（実効16GB前後）が VRAM ないしユニファイドメモリに全部乗るなら、M5 Max で 38 tok/s 前後が天井です【試算】。
前回、この天井から逃げる手段を2つ書きました。量子化は「ルーフラインの左端で対角線を登る」手段で、読むバイトを減らすぶん速くなりますが、演算強度と尾根が同じ比率で動くので相対位置は変わりません。右へ動く、つまり compute 側へ寄る手段はバッチングだけでした。
そして個人マシンには、そのバッチングがありません。B=1 に固定されています。ここで詰み、に見えます。
図1が本記事の全体像です。batch=1 の decode は尾根の36倍下に張り付いています。MTP はこの動作点を、バッチングなしで右上へ動かす技術です。どうやって動かすのかを次章で見ます。
PART 2：MTP ─ 自分の未来のトークンでバッチを組む
2-1. 学習時：本体に先読みヘッドを同時学習しておく
MTP は Multi-Token Prediction の略です。本体トランスフォーマの上に、最終層の隠れ状態から2トークン目以降も予測する小さな追加ヘッド（概ね1層分のブロックで、埋め込みテーブルと出力ヘッドは本体と共有）を載せ、事前学習の段階から一緒に訓練しておきます。目的関数としての MTP は Meta の Gloeckle らが2024年に定式化し【論文】、DeepSeek-V3 が本体と同時学習する追加ヘッドという形で広めました【論文】。Qwen3.6 もモデルカードに MTP: trained with multi-steps と明記されています【公式】。
2-2. 推論時：ドラフトと検証
推論時はこのヘッドをドラフタ、本体を検証器とする投機的デコーディングを構成します。
2-3. データはどこから来るのか ─ 検証はなぜタダなのか
投機的実行と聞くと「暇な時間に別の作業を差し込む」印象を受けますが、実際には「同じ重み読み出しに計算を相乗りさせる」操作です。データの出どころを段階ごとに追うと、こうなります。
ドラフト側。MTPヘッドの入力は、本体が直前の decode でちょうど計算し終えた最終層の隠れ状態です。正確に言うと、レジスタや SM の共有メモリはカーネル境界で消えるため、この隠れ状態は decode グラフの出力として VRAM 上の計算バッファに書き出されたものです（書きたてなので L2 キャッシュに残っていることも多いはずですが、そこは本質ではありません）。本質はサイズで、隠れ状態1本は数KB〜十数KB。毎トークン 16GB を読む重みに対して6桁小さく、VRAM から読み直しても帯域的にはタダ同然です。再計算も host からの転送も不要な副産物が、そのままドラフトの入力になります。これに確定トークンの埋め込みを繋いでヘッドを1回まわす。追加で読む重みはヘッド1層分で、数十層ある本体に対して帯域的には誤差です。多段の先読みは、ヘッドが自分の出力を再帰的に食わせて t＋2、t＋3 と伸ばします。
検証側はさらに徹底していて、新しいデータはほぼ要りません。読むのは、どのみち毎トークン読む本体の重みそのものです。変わるのは、1トークンの行列ベクトル積が幅 K の細い行列行列積になることだけ。DRAM から流れるバイト数はほぼ不変で、増えるのは演算量のみ。そしてその演算は、PART 1 で見た通り、もともと97%遊んでいた分です。
図2：素の decode と MTP 検証の違いは、重み行列に掛ける右辺の本数だけです。DRAM から流れるバイト数はほぼ変わりません。
前回の言葉で言えば、これは batch=1 のまま演算強度を（採択数＋1）倍だけ右へ動かす操作です。バッチングと同じ向きの移動を、他人のリクエストではなく自分の未来のトークンで実現しています。移動した先もまだ尾根の遥か左なので、検証の追加演算は帯域の影に隠れて時間コストになりません。ここが「タダ飯」の正体です。
なお長コンテキストでは KV の読み出しも帯域を食いますが、K 個の候補は同じ prefix を見るので、KV 読み出しも1回分を共有します。重みと同じ理屈で相乗りできます。
2-4. 外れても損をしない ─ ロスレスである理由
1回の重み読み出しで、最低でも不一致位置における本体の正解1トークンは必ず確定します。つまり最悪ケースは、素の decode にヘッド分の微小オーバーヘッドが乗った程度です。検証は本体自身が行うため、出力分布は素の decode と完全に同一、つまりロスレスです。結果として、期待採択数がほぼそのまま速度倍率になります。
2-5. 従来の speculative decoding との違い
llama.cpp には以前から -md で小型ドラフトモデルを別に用意する方式がありましたが、MTP は別モデルが不要で、本体と同時学習されているぶん採択率が高くなりやすい、という位置づけです。安いドラフタと厳密な検証器の組み合わせ、という構図自体は同じです。
PART 3：実測と、MoE に効きにくい理由
3-1. 公開されている実測
llama.cpp には PR #22673（2026年5月マージ）で MTP による投機的デコーディングが入り、Unsloth などから MTPヘッド入りの GGUF が配布されています。
| 環境 | モデル | 結果 | 出典 |
|---|---|---|---|
| RTX PRO 6000 | Qwen3.6-27B dense | 45.8 → 79.4 tok/s（約1.73倍） | JarvisLabs【実測報告】 |
| RTX PRO 6000 | Qwen3.6-35B-A3B（Q8_0） | 193.4 → 225.5 tok/s（約1.17倍） | JarvisLabs【実測報告】 |
| RTX 6000 | 27B / 35B-A3B | 160 / 240 tok/s | Unsloth【公式】 |
| RTX 3090 Ti | 35B-A3B | 約150 tok/s、最大2.9倍 | r/LocalLLaMA まとめ。マージ前のカスタムビルドでの報告【実測報告】 |
3-2. dense と MoE で効きが大きく違う理由
27B dense が1.73倍なのに、35B-A3B は1.17倍。理由は2つあると整理できます。
主因は、節約対象がそもそも小さいことです。JarvisLabs 自身がこちらを理由に挙げています。35B-A3B はアクティブ3Bなので素のデコードが元々軽く、実測でもベースラインが 193 tok/s 出ています。投機的デコーディングは本体のデコードコストを節約する技術なので、節約対象が小さければ伸び代も小さくなります【実測報告】。
副因として、前回 PART 5-6 の「MoE はバッチで殴りにくい」も効いてきます。検証はミニバッチなので、K 個の候補トークンがそれぞれ別のエキスパートにルーティングされ得て、読み出す固有エキスパート重みが K に応じて増えます。この現象は expert scattering と呼ばれ、研究文献でも確認されています【論文】。ただし llama.cpp の MTP が使う先読み幅2〜3程度では影響は限定的で、単一ストリームではルーティングの相関が scattering を部分的に打ち消すという指摘もあります【論文】。
dense と共有重みの部分は K 並列でも読み出しバイト数が変わらないので、いずれにせよ MTP の恩恵は dense の方が素直に出ます。
図3：ベースラインが速い MoE ほど、投機が節約できる余地は小さくなります。
3-3. 使い方と注意点
使い方は、MTPヘッド入りの GGUF を用意して spec-type を指定するだけです。
llama-server \
-m Qwen3.6-27B-MTP-UD-Q4_K_XL.gguf \
-ngl 99 -fa on \
-np 1 \
--spec-type draft-mtp \
--spec-draft-n-max 2
- 通常の GGUF には MTPヘッドのテンソルが入っていないため、MTP 用として配布されているもの（unsloth/Qwen3.6-27B-MTP-GGUF など）が必要です
- ヘッドの分でメモリが 1〜2.5GB 程度余分に必要になります【公式・実測報告】
- 先読み幅
--spec-draft-n-maxは Unsloth が 2 を推奨していますが【公式】、ハードウェア依存が大きいので実測して決めるのが良さそうです - 採択率はタスク依存です。コードや定型的な文章は当たりやすく、短い応答では先読みの旨味がそもそも小さいため、長文生成やコーディングエージェント用途向きです
- Qwen3.6 系は Gated DeltaNet の再帰状態が巻き戻せないため、ドラフト棄却時に確定時点の状態へ戻す処理（再帰中間状態のチェックポイント保持とロールバック）が実装上の難所でした。MTP の PR が依存する PR #22400 が、まさにこの処理を追加しています
- なお PR 段階の初期実装では
--spec-type mtpという表記で、マージ時にdraft-mtpへ改名されています。古い解説記事のコマンド例を流用する際は注意してください
マージ後も実装の手直しは続いています。マージ版で速度が落ちたという報告（issue #23230）を受けて、並列デコード時の再帰状態ロールバックのバグ修正と --spec-draft-p-min の再有効化を含むクリーンアップ PR（#23269）が入っており、既定値や速度はビルドによって変わり得ます。
PART 4：データセンターと個人マシンで、恩恵の向きが逆転する
MTP 自体はデータセンターでも使われており、latency 重視の低並列サービングでは本家 DeepSeek をはじめ採用例があるようです。ただ、大規模サービングの主戦場では効果が薄れます。理由は前回の PART 5 そのものです。
データセンターには他人のリクエストが大量に飛んでくるので、バッチングという王道で尾根に向かって右へ登れます。前回試算した通り、VR200 なら B=398 で演算器が飽和します。演算器が既に忙しい場所では、検証に使う追加 FLOPs は他のリクエストのトークン処理と競合し、もはやタダ飯ではありません。スループット最適で運用する場合、投機を切る判断が多いようです。
逆に、個人マシンの batch=1 は帯域律速の極致で、演算器の空きが最大です。そしてバッチングという王道が構造的に使えないため、投機が唯一の「右へ動く」手段になります。
つまり MTP は、データセンターより個人マシンの方が恩恵が大きい。GPU の技術は普通、データセンターで生まれて個人に降りてくるまでに旨味が薄れるものですが、これは珍しく逆向きです。
図4：演算器が飽和しているデータセンターでは検証の FLOPs が競合になり、遊んでいる個人マシンではタダになります。前回書いた鏡像の、投機版です。
PART 5：Apple Silicon（M5 Max）ではどうか
理屈の上では、M5 Max（40コアGPU構成）は 614 GB/s の帯域を持ちつつ【公式】、batch=1 では同じく帯域律速なので、MTP が効いてよいはずです。ただし執筆時点の Metal バックエンドでは、逆効果という報告が目立ちます。
- llama.cpp の issue #23011 では、M1 Pro ＋ Qwen3.6-35B-A3B で採択率95.6%にもかかわらずベースラインより大幅に低速で、MTP のドラフト経路自体が実行時間を支配していると報告されています【実測報告】
- M4 Max での実測では、27B の MTP で生成スループットが約半分になり、end-to-end で1.48倍遅くなったとのことです。採択率33%の議事録要約系ワークロードで、単一環境・単一実行の報告です【実測報告】
- 一方 M2 Ultra では、先読み幅3なら安定して効く、ただし prompt processing は常に少し損をする、という報告もあります【実測報告】
採択率が高いのに遅いケースがあることから、これは原理的な限界というより、Metal 実装の成熟度の問題（ドラフト経路のオーバーヘッドや、小さい行列でのカーネル効率）に見えます【筆者の解釈】。加えて Apple Silicon は NVIDIA の同格GPUに比べて帯域あたりの演算に余裕が少なく、尾根が低め、つまり右に動ける余白が相対的に小さい可能性もあります（Apple は GPU の演算性能を公表していないため、尾根の厳密な試算は控えます）。Unsloth Studio がハードウェア別に MTP 設定を自動調整する仕組みを入れているのも、この辺りの事情の表れかもしれません。
というわけで M5 Max では、現時点では公称倍率を鵜呑みにせず、自分のワークロードで --spec-draft-n-max 2〜3 あたりから実測するのが良さそうです。3-3 で触れた通りマージ後もクリーンアップは続いているので、実装側の問題が大きいのであれば、llama.cpp の最適化が進めば化ける余地はあると考えています。
PART 6（おまけ）：ひとりで使うなら -np 1
もう1つ、batch=1 のローカル運用に固有の小ネタです。
llama-server は2025年末頃の変更でデフォルトが4スロット起動になり、--parallel 1 を渡しても4スロットで初期化されるという issue まで立ちました（#17300、#17989。後者は当時のビルドの不具合報告で、現行ビルドでは明示指定が有効に働きます）。-np 未指定時は n_parallel = 4 と kv_unified = true が自動設定され、スロット分の確保で VRAM 消費が増えることが確認されています。この既定はビルドによって変遷してきた経緯があるため、挙動を仮定せず明示するのが安全です。
なお Qwen3.6 系はハイブリッドアテンション（4層に1層だけフルアテンションで、残りは Gated DeltaNet）なので【公式】、KV キャッシュ自体はかなり軽い部類です。27B の場合、
KV/トークン【試算】
= フルアテンション16層 × 2（K, V） × 4ヘッド × 256次元 × 1 byte（q8_0）
≒ 32 KB/token
32K コンテキストで約1GB、ネイティブ上限の 262K を張っても 8GB 台という計算で、コミュニティの実測報告とも整合します【実測報告】。DeltaNet 層は固定サイズの状態しか持たないため、コンテキスト長に依存しません。前回の式 2P/K で言えば、分母の K を潰して天井を上げにきた設計です。
図5：フルアテンションが16層しかないため、262K を張っても KV は8GB台に収まります。従来型の dense 70B の仮定なら、同じ長さで40GB を超えます。
それでも、小VRAMカードに巨大コンテキストを積む構成では、スロット分の余計な確保が致命傷になり得ます。35B-A3B の UD-Q4_K_XL はファイルサイズ約22.4GB（MTPヘッド入り版は約22.9GB）ありますが【公式】、MoE エキスパートの大半をシステム RAM に逃がせば、12GB クラスの GPU でも次のような構成で 100K 超のコンテキストが動きます。
llama-server \
-m Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf \
-ngl 99 --n-cpu-moe 24 \
-c 131072 -fa on \
-np 1 \
--cache-type-k q8_0 --cache-type-v q8_0
-
-np 1でスロットを1本に固定し、指定したコンテキストを1リクエストに全振りする -
--n-cpu-moeで MoE エキスパートの一部をシステム RAM へ逃がす。層数は VRAM 残量を見ながら調整します。アクティブ3Bの A3B なら、CPU 側が DDR4/DDR5 帯域でも生成速度が保てる算段です【試算】 -
--cache-type-k/v q8_0で KV を半減する。ビジョン付きモデルで mmproj を使う場合は--no-mmproj-offloadでプロジェクタを CPU に置くと、さらに VRAM を温存できます
デフォルト挙動がビルドで揺れている以上、ひとりで使う llama-server には -np 1 を明示しておくのが確実、というのが実務的な結論です。
まとめ
- batch=1 の decode は演算強度 4（Q4）で尾根の数十倍下におり、演算器はほぼ全部遊んでいます。前回書いた脱出路のバッチングは、束ねる相手のいない個人マシンでは使えません
- MTP は自分の未来のトークンでバッチを組む技術です。ドラフトの入力は直前 decode の最終層隠れ状態という既にある副産物で、検証も重み読み出しは1トークン分のまま。外れても最低1トークンは確定するのでロスレスです
- CUDA の実測では dense 27B で1.7倍前後。MoE は元々1トークンあたりのデコードが軽く節約余地が小さいことに加え、検証のミニバッチが複数エキスパートを叩くため、1.17倍にとどまります
- 恩恵が最大化されるのは batch=1 のローカル推論です。バッチングで尾根に登れるデータセンターでは旨味が薄れます
- Apple Silicon / Metal は現状実装が追いついておらず、逆効果の報告が複数あります。M5 Max でも導入前の実測をおすすめします
- llama-server をひとりで使うなら、
-np 1の明示をおすすめします
所感
前回は、ルーフラインに従って正しく設計されたチップが、ルーフラインの外側の制約で消える話でした。今回はその逆で、ルーフラインが示す「遊んでいる資源」を、モデル側の仕掛けが拾いにいく話です。
面白いのは、この技術の恩恵の向きです。データセンターはバッチングという王道で尾根に登れるので、投機は脇役に留まります。個人マシンにはその王道がなく、学習時から仕込まれた小さなヘッドが、自分の未来のトークンで即席のバッチを組む。空いている演算器という隙間を拾って速くする技術が、データセンターより個人マシンで効く。この手の隙間(スキマ)を拾う話は、結構好きです。
もう1つ。Metal の現状が「採択率は高いのに遅い」という症状であることは、それが示すところは改善する可能性もゼロではない、という事だと思っています。原理が破綻しているのではなく、実装が追いついていないだけなら、待てば直る類の問題だからです。M5 Max での実測は、llama.cpp 側の最適化の進み具合を見ながら、改めて記事にするつもりです。
参考リンク
モデル・公式ドキュメント
- Qwen3.6-27B モデルカード https://huggingface.co/Qwen/Qwen3.6-27B
- Unsloth「Qwen3.6 - How to Run Locally」（MTP の設定と公称値） https://unsloth.ai/docs/models/qwen3.6
- unsloth/Qwen3.6-27B-MTP-GGUF https://huggingface.co/unsloth/Qwen3.6-27B-MTP-GGUF
llama.cpp の実装
- MTP サポートの PR https://github.com/ggml-org/llama.cpp/pull/22673
- GDN の再帰状態ロールバックを追加した PR https://github.com/ggml-org/llama.cpp/pull/22400
- マージ後の速度低下報告 https://github.com/ggml-org/llama.cpp/issues/23230
- MTP クリーンアップの PR https://github.com/ggml-org/llama.cpp/pull/23269
- Metal で MTP が遅い件の issue https://github.com/ggml-org/llama.cpp/issues/23011
- llama-server が4スロットで起動する件 https://github.com/ggml-org/llama.cpp/issues/17300
- --parallel 1 でも4スロットになる件 https://github.com/ggml-org/llama.cpp/issues/17989
文献
- Gloeckle et al.「Better and Faster Large Language Models via Multi-token Prediction」 https://arxiv.org/abs/2404.19737
- DeepSeek-V3 Technical Report https://arxiv.org/abs/2412.19437
- MoESD: Unveil Speculative Decoding's Potential for Accelerating Sparse MoE https://arxiv.org/abs/2505.19645
実測報告
- JarvisLabs「Run Qwen3.6 MTP with llama.cpp on RTX PRO 6000」（dense 1.73倍 / MoE 1.17倍） https://jarvislabs.ai/blog/qwen36-mtp-llamacpp-rtxpro6000
- M4 Max での MTP 実測（net loss の報告） https://huggingface.co/unsloth/Qwen3.6-27B-MTP-GGUF/discussions/6
- M2 Ultra での MTP チューニング https://dev.to/someoddcodeguy/llamacpps-new-mtp-on-macos-4ea0
- MTP の設定手順まとめ https://note.com/hacklog_stealth/n/n43be4a291d09
- r/LocalLLaMA の MTP 議論まとめ https://note.com/samehadaonsen/n/n51be8bf1d8a3
- Qwen3.6-27B の VRAM・生成速度実測（KV 32KB/token の整合） https://note.com/high_u/n/n7d6f6fe08b93
前回の記事
- LLM推論を roofline で理解する ─ decode の演算強度はなぜ 2 なのか
前提と注記
本記事の試算は、以下の前提に立っています。
- ローカル推論の文脈のため、重みは Q4（1 param ≒ 0.5 byte、演算強度 4）を基準にしています。前回の FP8 基準（演算強度 2）との違いは分母だけで、不変量「重み1個につき 2 FLOP」は共通です
- RTX 3060 の尾根（約142 FLOP/byte）は、FP16 dense テンソル演算 約51 TFLOPS【推定】と帯域 360 GB/s【公式】から筆者が置いた値です。量子化重みの実効的な演算経路は kernel 実装に依存するため、オーダー感の確認以上の意味はありません
- MTP の速度倍率は「期待採択数＋1」で近似していますが、実際にはドラフトヘッドの逐次実行コストとサンプリング設定に依存します。採択率はタスク・温度・文体に強く依存し、報告値も33%から95%超まで大きくばらついています
- 本文の実測値のうち、最大2.9倍・RTX 3090 Ti 約150 tok/s はマージ前のカスタムビルド、M4 Max の1.48倍遅化は単一環境・単一実行の報告です。環境とビルドが変われば数値は変わり得ます
- KV/トークン 32KB は Qwen3.6-27B の公式アーキテクチャ諸元（フルアテンション16層、KV 4ヘッド × 256次元）と q8_0 を仮定した筆者の試算です。f16 KV ならこの2倍になります
- llama-server のスロットと KV 確保の関係は、kv_unified の既定値やビルドによって挙動が異なります。本文の記述は執筆時点の issue 報告に基づくもので、将来のビルドでは解消されている可能性があります。MTP 実装自体もマージ後のクリーンアップが続いており（#23230、#23269）、既定値や速度はビルドで変わり得ます
更新履歴・出典方針
2026-07-17 初版。
公開前にファクトチェック（一次情報との照合）を行い、初稿から以下を修正・補強しました。読者が他所で異なる説明を目にした際の参考として明記しておきます。
| 項目 | 初稿 | 訂正・補強 |
|---|---|---|
| MoE で効きが薄い理由 | expert scattering を単独の説明として記載 | 主因は「アクティブ3Bで素のデコードが軽く、節約余地が小さい」こと（実測元の JarvisLabs の説明）。expert scattering は副因として併記し、先読み幅2〜3では影響が限定的という文献の指摘も追加 |
| MTP の起源 | DeepSeek-V3 が広めたとのみ記載 | 目的関数の定式化は Gloeckle et al.（Meta、2024）。DeepSeek-V3 はそれを普及させた側 |
| M5 Max の帯域 | 614 GB/s とのみ記載 | 40コアGPU構成の値。32コアGPU構成は 460 GB/s |
| M4 Max の実測報告 | メモリ容量まで記載 | 一次ソースで確認が取り切れない容量表記を削除し、単一環境・単一実行の報告である旨を明記 |
| 35B-A3B のファイルサイズ | 未記載（下書き段階では約21GBと認識） | UD-Q4_K_XL は約22.4GB、MTPヘッド入り版は約22.9GB。約21GBに近いのは UD-Q4_K_S |
| マージ後の実装状況 | 記載なし | 速度低下報告（#23230）とクリーンアップ PR（#23269）、フラグ改名（mtp → draft-mtp）の経緯を追記 |
なお、PR #22673 のマージ日（2026年5月16日）、JarvisLabs の実測値（45.8 → 79.4 tok/s、193.4 → 225.5 tok/s）、Qwen3.6-27B のアーキテクチャ諸元（64層、フルアテンション16層、KV 4ヘッド × 256次元、262,144トークン）、各ハードウェアの帯域値は、いずれも一次情報との照合で一致を確認済みです。