Nexus、ツール仕様の再読み込みを避けるエージェント推論

背景

MCP を利用するツール型エージェントでは、ターンごとに多数のツールスキーマを読み直す構成になりやすい。ツール登録数が増えると、長い入力のプレフィルに時間がかかり、time-to-first-token（TTFT）が大きくなる。Nexus は、利用するツールの選択と、全スキーマをモデルに読み込ませる処理を分離することで、この負荷を抑えようとする。

Nexus の構成

• 検索で候補を絞る。 INT8 のセマンティック・ルックアサイド・バッファ（SLB）にツール情報を格納し、校正済みクロスエンコーダーの margin gate で候補を選ぶ。毎回、登録された全スキーマをメインコンテキストへ入れる必要を減らす。
• 短い署名から引数を生成する。 引数生成には完全な KV キャッシュではなく、テキスト化した圧縮署名を使う。署名の中央値は約 19 トークンで、スキーマによるコンテキスト消費を抑えられる。
• KV 連結は補助策に限定する。 コンパイル済みのスキーマ KV ブロックを実行中のコンテキストへ移す方法も検討する。ただし RoPE は位置に応じて位相が変わるため、基準位置から外れた挿入では注意の計算が乱れる可能性がある。
• 深い位置では再デコードする。 P=256 を超える場合、Nexus は深さに応じて後方部分を再デコードし、必要なら完全な再プレフィルへ戻る。ここで保証される「退行なし」は出力の一致性であり、遅延が常に短くなるという意味ではない。

結果と限界

Apple Silicon の統合メモリ上で Qwen2.5-14B-Instruct Q4_K_M を使った評価では、登録ツールが 250 個に増えても検索ルーティングの精度は約 89%を維持した。完全なスキーマ再プレフィルと比べ、最初の引数トークンは 1.66 倍早く生成され、メインコンテキストのトークン使用量は約 80%減少した。この規模では、全スキーマを連結するベースラインはコンテキスト上限を超える。

KV 連結による TTFT 改善は中程度の深さで 1.1〜1.7 倍だが、深いコンテキストでは基準方式との同等水準へ近づく。修復処理後の top-1 出力一致率は保たれ、KL ダイバージェンスもほぼ 0 だった。一方、遅延は一時的にベースラインの 0.98 倍まで低下することがある。また、参照なしの drift gate は位置ずれの予測に向かず、Spearman の相関は 0.193 にとどまった。

意味すること

Nexus が示す実務的な方向性は、KV キャッシュを自由に移動できるということではない。大規模なツール登録表では、まず検索によってルーティングと全スキーマのプレフィルを分離し、KV 連結は検証とフォールバックを備えた限定的な最適化として扱うべきだという点にある。ただし数値は一つのモデル、量子化設定、ハードウェアに基づく。別のモデルや RoPE 実装、長さ、実運用のツール分布での検証が必要になる。

arXiv