ローカルLLM推論のデファクトスタンダードであるllama.cppに、マルチトークン予測を可能にするMTP（Multi-Token Prediction）サポートがマージされた。GitHubのプルリクエスト#22673として公開されたこの統合は、投機的デコーディングにおけるチェックポイント再実行の無駄を削減し、オンデバイス推論のスループットを一段引き上げる変更である。

背景

大規模言語モデルの推論高速化手法として投機的デコーディングが普及している。これは小型のドラフトモデルが複数トークンを先回り生成し、大型のターゲットモデルがまとめて検証する方式だ。しかし従来実装では、ドラフトトークンが棄却されるたびにターゲットモデルがチェックポイントから再実行され、計算資源の浪費が発生していた。この問題は特にエッジデバイスやバッチ処理の多い本番環境で顕著だった。

llama.cppはC/C++で書かれたLLM推論エンジンであり、Apple Siliconやx86、Vulkan対応GPUまで幅広いハードウェアをサポートする。2024年以降、GGMLフォーマットのモデル流通量はHugging Face上で指数関数的に増加しており、今回のMTP対応は産業用推論パイプラインの効率に直接影響を与える。

構造

今回の変更の中核は、Gated Delta Net（GDN）モデルにおける部分ロールバック機構の実装である。従来はターゲットモデルの再実行時にシーケンス全体を処理し直していたが、新実装ではGDN中間状態をスナップショットとして保存し、棄却されたドラフトトークン分だけ巻き戻せるようにした。draft_maxまでのトークン範囲でロールバックが可能になり、無駄な再計算が大幅に削減される。

バックエンド別の対応状況を見ると、VulkanとMetalの両方でGDN部分ロールバックが実装された。Metalバックエンドでは、3DステートテンソルにK個のスナップショットスロットを確保し、トークンループ中に中間状態を異なるスロットへ書き込む設計である。K=1の場合は単一スロット動作となり、既存モデルとの後方互換性を維持する。

変換スクリプトにも手が入り、MTPモデルの識別にmtp-プレフィックスを使用する規約が導入された。モデルアーキテクチャの判定にはllama_context_typeが使われ、従来のllama_graph_typeへの依存が整理されている。サーバー実装のチェックポイントロジックも調整され、n-gram方式との互換性が確保された。

影響

この統合がもたらす最大の変化は、投機的デコーディングの実行効率向上である。ドラフト棄約時のターゲット再計算が不要になることで、トークン生成レイテンシのばらつきが抑制され、スループットの平均値が改善する。これはクラウドAPIを介さないオンデバイス推論の競争力を高める要素だ。

ハードウェアレイヤーでは、Apple Silicon搭載Macの優位性がさらに強まる。MetalバックエンドがMTPの恩恵を直接受けるため、Mシリーズチップ上での大規模モデル実行がより現実的になる。一方、NVIDIA GPUに依存するクラウド推論とのコスト差は、この種の最適化によって徐々に縮小していく構造にある。

日本市場では、日本語対応GGMLモデルの開発が活発化しており、今回のMTP統合はローカル推論を用いた企業内AI導入の追い風となる。データ主権を重視する国内エンタープライズにとって、オンプレミス推論の効率化はクラウド依存度を下げる直接的な手段になる。

今後の論点

MTP統合の次に注目すべきは、投機的デコーディングのドラフトモデル選択ロジックである。今回の変更でn-gram方式との互換性は確保されたものの、ドラフト精度とロールバック頻度のトレードオフは引き続きモデル依存の課題として残る。GDN以外のアーキテクチャへの部分ロールバック拡張も、コミュニティの開発動向次第で実現可能性が左右される。

また、llama.cppのサーバー実装がチェックポイント管理を改善したことで、APIサーバーとしての運用負荷が軽減される点も見逃せない。OllamaやLM Studioなど、llama.cppを内部エンジンとして利用する派生プロダクトへの波及は時間の問題である。推論基盤の細かな改良が、上位レイヤーのサービス設計にどのような自由度を与えるかが次の論点となる。