2026-05-24 — 回閲覧
llama.cpp がネイティブ MTP 投機的デコードをマージ — Qwen3.6 の単一リクエストで約 2.16 倍、DGX Spark が恩恵
PR #22673 が llama.cpp にネイティブ多トークン予測（MTP）投機的デコードを追加（build b9180 以降）。GB10 DGX Spark で Qwen3.6-27B Q4_K_M の単一リクエストが 13.1 から 28.3 tok/s へ — ただし並行処理では逆に低下。
家庭・個人セルフホスターが待ち望んでいた機能が今月上流に入った：ネイティブ多トークン予測（MTP）投機的デコードが PR #22673（“llama + spec: MTP Support”、作者 am17an）として 2026-05-16 に master へマージされ、build b9180 以降に収録された。GB10 DGX Spark では Qwen3.6 の単一リクエストのデコード throughput がおよそ倍増する — ただし負荷時に価値を反転させる重要な注意点がある。
MTP 投機的デコードとは
投機的デコードは、まず複数の候補トークンを安価に「ドラフト」し、それを 1 回の forward パスで検証することで生成を高速化する。従来の手法では別の小さなドラフトモデルを並行して動かす必要があった — 追加メモリ、追加設定、そして品質マッチングの面倒さが伴う。
MTP は 2 つ目のモデルを不要にする。 Qwen3.6 はネイティブの多トークン予測ヘッドを備えており、モデル自身が複数の将来トークンを予測する。llama.cpp の新しい --spec-type draft-mtp モードはこの内蔵ヘッドをドラフト元として使うため、同じ重みがドラフトと検証の両方を担う。ドラフトモデルを探す必要がなく、不一致リスクもなく、ドラフトはターゲットモデル自身から来るため品質も高い。
積極度を制御する 2 つのパラメータ：
--spec-draft-n-max— ステップごとに何トークンをドラフトするか（下記実測では 5 がスイートスポット）--spec-draft-p-min— ドラフトトークンが採用される最低受理確率
実測 — GB10 DGX Spark
NVIDIA 開発者フォーラムのコミュニティ実測（2026-05-15）は DGX Spark 上で Qwen3.6-27B dense、Q4_K_M を実行した：
| シナリオ | MTP なし | MTP あり（ドラフト 5） | 変化 |
|---|---|---|---|
| 単一リクエスト | 13.1 tok/s | 28.3 tok/s | +2.16× |
| 4 並行リクエスト | 41.5 tok/s | 29.9 tok/s | −28% |
単一ストリームの向上は本物で大きい。だが 2 行目に注目：4 並行リクエストでは MTP は総 throughput をむしろ下げる。これはバグではなく、投機的デコードの根本的なトレードオフである。
注意点：レイテンシ vs throughput
投機的デコードは余剰計算を低レイテンシと引き換えにする。一度に 1 リクエストだけを処理するとき、GB10 の Tensor コアはデコードループの大半で遊んでいる（Spark の 273 GB/s LPDDR5X ではデコードがメモリ帯域律速）ため、余分なトークンのドラフトはほぼ無料で、2 倍の高速化が得られる。
バッチ処理では逆になる：並行リクエストがすでに計算を飽和させているため、ドラフトがサイクルを奪い合い、却下されたトークンの無駄な作業が総 throughput を引き下げる。これにより MTP は単一ユーザーの対話型セルフホストにとってのキラー機能 — だが多ユーザーのサービング機にとっては誤ったデフォルトとなる。DGX Spark を個人のコーディング/アシスタント用エンドポイントにしているなら有効化すべき。複数の同僚に提供しているなら無効のままに。
ハードウェアを越えて再現
この効果は Spark 固有ではない。RTX 3090 上のクロスプラットフォーム記事は **Qwen3.6-27B で 38 → 65 tok/s（1.71×）**を品質劣化なしで計測し、Qwen3.6-35B-A3B でも確認した。MTP 対応 GGUF はすでに Hugging Face にある（例：froggeric/Qwen3.6-27B-MTP-GGUF）ので、自分で重みを変換する必要はない — MTP build を取得し、MTP GGUF を入手し、--spec-type draft-mtp フラグを加えるだけ。
関連動向：TensorRT-LLM v1.3.0rc15
Spark エコシステムの本番推論側では、NVIDIA が 2026-05-21 に TensorRT-LLM v1.3.0rc15 をリリースした（プロジェクトはおよそ週次の rc ケイデンス — rc14 は 2026-05-07）。GB10（SM 12.1）に関連する要点：
- Gemma4 をテキスト・ビジョン・音声・chunked-prefill 対応で追加 — Blackwell 推論の新しいマルチモーダルファミリー。
- SM120/121 向け INT4-AWQ カーネル、Spark 級ハードウェアを直接カバー。
- 拡張された NVFP4 / MXFP4 MoE バックエンド（MegaMoE DeepGEMM、Nemotron-H 用 CUTEDSL MoE、W4A8_MXFP4_FP8）と FP4/FP8 デコードカーネルのインデックス最適化。
2 つの路線は補完的だ：llama.cpp MTP は今日の単一ユーザー対話用途で最も手軽な道であり、TensorRT-LLM は量子化 MoE とマルチモーダルサービングの性能が Blackwell で成熟していく場である。
まとめ
DGX Spark を個人 LLM エンドポイントとして運用しているなら、MTP のマージは今月最もレバレッジの高い更新だ：build を上げてフラグ 1 つで Qwen3.6 が約 2 倍の対話高速化、ドラフトモデル不要。ただし単一ストリーム最適化であることを忘れずに — 共有マシンで有効化する前に、自分の並行レベルでベンチマークを取ること。