エージェントの推論基盤はワークフローを見ていない、Dyserveが埋める溝

推論エンジン（vLLM、TGI）の視点からエージェント実行の最適化を提起する論文だ。従来の推論エンジンは「1リクエスト＝1LLM呼び出し」を前提に設計され、スループット向上に磨かれてきた。だがエージェント実行時、1リクエストは実は「計画立案→ツール呼び出し→結果検証→まとめ」という複数ステップの有向非巡回グラフ（DAG）になる。ノードごとに異なるモデルを使える、検証ステップを挿入できるが、下層の推論エンジンはこのグラフ全体を見ていない。フレームワークはワークフローを決めるが負荷を知らず、推論エンジンは負荷を知るがワークフローを知らない。この隙間をDyserveは「受付時に全ノード（モデル、検証ポリシー）を整数計画問題として一括最適化」で埋める。興味深いのは、同じ問題に複数の競合仮説が同時並行で出ている点だ。Pythiaは「グラフは予測可能だからプレフィックスキャッシュで先回りする」、HexAGenTは「依存関係は実行時に明らかになるから動的に優先付けする」と主張する。業界の答えがまだ定まっていない。これは「エージェントのワークフローはどこまで予測可能か」という根本問が未決着であることを示している。実務への教訓は明確だ。自前でエージェントを載せているなら、TTFTやトークン毎秒といった呼び出し単位の指標だけを見ていると実コストを見落とす。効いているのはワークフロー全体の完了時間。Pythiaのメタデータ付与（workflow_id、agent_id）のアイデアは、研究成果を待たずに今日から実装できる。営業メール大量生成など同一タイプのリクエストが多い場合、プレフィックスキャッシュ再利用で最初のトークン遅延が削れる。検証ステップ（自己整合性チェック、複数エージェント討論など）は精度向上と引き換えにトークンを消費する。どのノードに何を置くかを測定ベースで設計すれば、無駄な検証が削られ、コスト効率が向上する。