vLLM セッション認識エージェントルーティング (SAAR) リリース
vLLM セッション認識エージェントルーティング (SAAR) リリース
vLLM は セッション認識エージェントルーティング (SAAR) を導入しました。これは vLLM セマンティックルーター内のセッション認識モデル選択ポリシーです。SAAR は、ルーターオウンドセッションメモリ、ツールループのためのハードロック、およびプリフィックスキャッシュ認識のスイッチ価格設定を導入することにより、長時間範囲のエージェントシナリオにおけるシングルターンプロンプトルーターの失敗に対処し、モデルスイッチを 79.29% 削減し、決定論的テスト全体での安全でないスイッチをなくします。
プロンプトルーティングからセッションルーティングへのシフト
従来のプロンプトルーティングは、現在のリクエストのシグナルに基づいてモデルを選択します。しかし、LLM エージェントはセッションで動作します—計画、ツールの呼び出し、観測の処理—ここでターンは、前の軌跡の文脈の中でのみ意味を持ちます。
SAAR は、ルーターの主要な質問を "このリクエストを処理すべきモデルはどれですか？" から "このセッション内で今、モデルを切り替えることは安全ですか？" に進化させます。
シングルターンルーティングがエージェントで失敗する理由
シングルターンルーティングは局所的に最適ですが、セッションレベルでは不正確です。これにより、いくつかの失敗モードが生じます：
- ツールループの中断: ツール結果が、ツール呼び出しを開始しなかったモデルにルーティングされる可能性があります。
- 状態の損失: ポータブルでないプロバイダー管理の継続 ID が間違った物理バックエンドに送信される可能性があります。
- 非効率性: フロンティアモデルのウォームプリフィックスキャッシュが、特定のターンのメッセージが短いために破棄され、コストが増加する可能性があります。
- 観測可能性のギャップ: 各ターンを提供する物理モデルが不明な場合、論理モデル（例:
auto）のデバッグが困難になります。
SAAR の設計とアーキテクチャ
SAAR は、既存のセマンティックルーターパイプラインにセッションコントロールレイヤーを追加します。モデル選択を管理するために、5 つの主要コンポーネントを利用します：
| コンポーネント | 機能 | 目的 |
|---|---|---|
| ルーターメモリ | 最後の物理モデル、マッチした決定、フェーズ、およびキャッシュ証拠を追跡 | アプリケーションメモリにならずにセッションコンテキストを提供 |
| ハードロック | アクティブなツールループまたはポータブルでないプロバイダー状態中のスイッチを防止 | コスト/品質最適化よりも正確性を確保 |
| リセット境界 | アイドルタイムアウトまたは決定のドリフト後に再選択を許可 | ルーティングが永久に "スティッキー" になるのを防止 |
| スイッチエコノミクス | ハンドオフコストとプリフィックスキャッシュチェックアウトを価格設定 | セッションの長さとモデルティアに基づいてスイッチを非対称にする |
| リプレイトレース | ステイ/スイッチ決定の理由を記録 | auto のような論理モデルを検査可能にする |
ハード継続制約
SAAR は、ベースセレクターのスコアに関係なくルーターがモデルを切り替えることを禁止する "ハードロック" を 2 つ適用します：
- ツールループ継続性: ツール結果は、ツール呼び出しを要求した物理モデルに返却されなければなりません。
- プロバイダー管理状態: ポータブルでない継続状態を持つリクエストは、以前の物理バックエンドにとどまらなければなりません。
逆に、リセット境界 (アイドルタイムアウトと決定のドリフト) は、継続の価値が減衰したりタスクの形状が変化したときに、ルーターがモデル選択を再開できるようにします。
プリフィックスキャッシュとスイッチエコノミクス
長時間のセッションでは、モデルの切り替えはシステムの決定となります。SAAR は キャッシュ入力チェックアウトデルタ を価格設定します—通常のプロンプト入力価格と候補モデルのキャッシュ入力価格の差です。セッションが長くなり、コストが増加するにつれて、ポリシーは高い入力コストを避けるためにプリフィックスローカリティを破棄することに対して厳しくなります。
オペレーショナルワークフローと観測可能性
クライアントが安定した x-session-id を持つリクエストを論理モデル（例: auto）に送信すると、SAAR は次の手順でターンを処理します：
- シグナルを抽出し、セマンティックルーターパイプラインを実行してベースモデル選択を取得します。
- ルーターメモリからセッション状態をロードします。
- ハードロックを適用します（ツールループ／プロバイダー状態）。
- リセット境界を評価します（アイドル／ドリフト）。
- プリフィックスキャッシュコストとスイッチ履歴に基づいてスコアを調整します。
- 物理モデルを選択し、リプレイトレースを出力します。
リプレイトレースにより、オペレーターはルーターがモデルにとどまったか、またはモデルから切り替えたかを監査でき、その決定がハードロック、リセット境界、またはキャッシュエコノミクスによって駆動されたかどうかを答えることができます。
パフォーマンスと評価結果
評価は、決定論的ポリシーマトリックス、ライブ AMD ROCm サービング、およびエージェントタスクトレースで実施されました。
ポリシーマトリックス結果（21,600 ターン）
| ポリシー | スイッチ | 安全でないスイッチ | 推定コスト削減 | 品質デルタ |
|---|---|---|---|---|
| シングルターン | 9,709 | 3,836 | 0.00% | +0.0000 |
| スティッキーセッション | 340 | 0 | 98.65% | -0.1433 |
| フル SAAR | 2,011 | 0 | 78.71% | -0.0453 |
正確性と信頼性
- ハードロックの有効性: ツールループスイッチ違反は 3,404 から 0 に減少し、プロバイダー状態違反は 432 から 0 に減少しました。
- ライブサービング: AMD ROCm 上の 2,896 件のライブリクエストにおいて、継続違反は 0 件観測されました。
- フォールトリカバリ: 影響を受けたセッション (32/32) の 100% が、注入された HTTP 503 バックエンドフォールト後に回復しました。
- タスク完了: 正確にスコアリングされたタスクインスタンス 18/18 が、すべてのルーティングされたターンでリプレイヘッダーが存在する状態で正常に完了しました。