llama.cpp b10731、Qwen3.8-Flash-Nextにリカレント状態のロールバックを追加—MTP投機的デコーディングで状態全体の反復転送が不要に

llama.cppのプレリリース版b10731には、Qwen3.8-Flash-Nextのリカレント状態をロールバックする機能がマージされ、MTP（multi-token prediction）による投機的デコーディングが「高速化するほど遅くなる」可能性のあった処理経路が改善された。MTPでは、まずドラフトヘッドが複数のtokenを予測し、ターゲットモデルがそれらを一度に検証する。ドラフトの一部だけが受理された場合、ターゲットモデルは最初に拒否されたtokenの直前の状態へ戻る必要がある。SSM／リカレントキャッシュを備えた`qwen4exp`アーキテクチャでは、これは通常のKV cacheを短縮するだけでは済まない。

修正前のllama.cppは、この状況を`SEQ_RM_TYPE_FULL`として扱い、投機処理のたびにリカレント状態全体をホストメモリへシリアライズしていた。プロジェクトの説明によると、既存のrecurrent cacheにはすでに`n_rs_seq + 1`個のスナップショットプレーンが確保されていたものの、モデル固有の`build_conv_state_at()`は現在のプレーンにしか書き込んでいなかった。このままロールバックを有効にすると、SSM状態は正しい一方で畳み込み履歴が誤っているという不整合が生じる。新しい実装では、ロールバック可能な各位置について1 token前のスナップショットを保存し、delta-net QKVとPLE畳み込み状態の両方を対象とすることで、デバイス上で正しい履歴を復元できるようにした。

メンテナーは、RTX PRO 6000、単一サービススロット、`n-max=3`、Qwen3.8-Flash-Next UD-Q4_K_XLという条件でテストを実施した。修正後の出力速度は、コードで183 token/s、一般テキストで144 token/sに達した。修正前はそれぞれ123 token/sと83 token/sで、ドラフトヘッドをまったく使用しない場合は108 token/sだった。この結果は、従来の一般テキスト処理ではMTPが通常のデコーディングより実際に遅く、ボトルネックがドラフトの受理率そのものではなく、状態転送にあったことも示している。

ただし、この更新によってあらゆるハードウェアで1.5～2倍の性能向上が得られると一般化することはできない。テスト対象はGPU 1基、1種類の量子化バージョン、単一ワークスロットに限られている。複数スロットでの同時実行、異なる`n-max`、CPU／Vulkan／ROCmバックエンド、さらに2.5GBのQ4ドラフトヘッドによるメモリコストは、いずれも結果を変える可能性がある。デプロイ担当者は、b10731がプレリリース版である点にも注意すべきだ。まず固定プロンプトを使用してtoken単位の完全な一致、受理率、デバイスからホストへのトラフィック、テールレイテンシを比較したうえで、本番サービスへの導入を判断する必要がある。