エージェントワークフローで準備済みターンの投入を遅延、混雑時のP95完了時間を最大71.4%短縮

9月10日に投稿された[新たな論文](https://arxiv.org/abs/2609.10964)によると、エージェントワークフローのレイテンシ問題は、vLLMなどの推論エンジン内部だけでなく、リクエストがエンジンに入る前にも発生する。一般的なエージェント実行基盤は、ツールの処理が完了し、次のモデルターンの準備が整うと即座に投入する。負荷が軽い場合は合理的だが、混雑時には「投入済み・未完了」のターンが大量にエンジン内へ滞留し、ワークフロースケジューラはそれらを並べ替える能力を失う。

研究チームが提案したスケジューラは、readinessとreleaseを意図的に分離する。平均完了時間にConditional Value at Risk（CVaR）を加えた目的関数を使用し、ワークフローの経過時間がオンラインで推定した第95パーセンタイルのしきい値を超えると、優先度を引き上げる。このレイテンシ重みを、現在のターンについて推定したワークロードで割る。ワークロードは、プロンプトtoken数と、完了済みターンだけから推定した出力長で構成され、現在のターンの実際の出力を先読みすることはない。

第2の制御ループは「コミット済みワーク」の予算だ。スケジューラは平均キューイング遅延、P95キューイング遅延、待機中のリクエスト数を監視する。混雑が悪化すると、エンジンへ投入できるtoken換算ワークロードを減らし、容量に余裕ができると再び緩和する。ターンの待機時間が180秒を超えた場合は、starvation防止ルールによって優先処理する。この手法はvLLM内部のスケジューリングを変更せず、エージェント実行基盤と共有推論サービスの間にadmission controlのレイヤーを追加する。

実験では、vLLM 0.20.2を使用してmini-swe-agentのSWE-benchおよびSWE-Gymの軌跡をリプレイした。それぞれ100件のワークフロー、約1,600件のモデルターンを対象とし、Qwen3-8B、Qwen3-32B、Llama-3.3-70Bには、それぞれ80GB A100を1基、2基、4基使用した。最低負荷では、新手法と即時投入のP95比は0.99～1.00だった。最大の改善例では、Llama-3.3-70BのP95を1,986.3秒から568秒へ短縮し、71.4%削減した。アブレーション実験では、主な効果がテールリスクに基づく順位付けから得られ、動的予算がさらに約10.7～11.6%の改善をもたらした。

ただし、これはまだ本番環境全般に適用できる結論ではない。各データポイントには固定された到着シードが1つしか使われておらず、P95も100件のワークフローのうち少数のサンプルによって決まる。また、リプレイされたツールのレイテンシやターン内容は、実際のエージェントのようにスケジューリング結果に応じて挙動を変化させない。今後は、マルチテナント、モデルルーティング、prefix caching、失敗時のretryが併存するオンライン環境で検証し、投入の遅延によって個々の短時間タスクやインタラクティブなリクエストのservice levelが損なわれないかを調べる必要がある。