System Design Patterns

日本語

English

日本語

English

Appearance

エージェント推論: マルチステップLLMワークロードのサービング ​

注: この記事は英語版からの翻訳です。コードブロックおよびMermaidダイアグラムは原文のまま保持しています。

TL;DR ​

エージェントループはチャットリクエストをN回繰り返したものではありません — それは独特の推論ワークロードです: 入力過多(各ステップは肥大化し続ける、ほぼ共有されたトランスクリプトを再送する)、ステップ間および兄弟サブエージェント間でのプレフィックス冗長性、タスク内では並列ではなく逐次的、そしてオーケストレーターがファンアウトするとフリートレベルでバースト性を持ちます。サービング上のレバー — キャッシング、バッチング、投機、分離 — はどれも変わりません。変わるのは、作業の単位が単一リクエストではなくマルチステップのセッションになったときにどのレバーが重要で、どうチューニングすべきかです。それらのレバーを支えるハードウェアの算数はGPU推論の内部構造に、それを実装するエンジン機構(RadixAttention、プリフィル/デコード分離、投機的デコーディング)はLLMインフラに、トランスクリプトそのものを形作るクライアント側の規律 — コストの三角形、プレフィックスキャッシングの規則、圧縮 — はコンテキスト管理にあります。この章はセッションおよびフリートレベルの視点です: サービングスタックに当たるトラフィックがチャットではなくエージェントであるとき、オペレーターは何を変えるべきか。

エージェントワークロードの形状 ​

チャットトラフィックはおおよそ1回のプロンプトイン、1回のレスポンスアウトで、リクエスト間は独立しています。エージェントトラフィックはスケジューラが気にするあらゆる軸で見た目が異なります:

プロパティチャットエージェントループ
タスクあたりのリクエスト数1数十〜数百(ステップごとに1回)
リクエスト間のプレフィックス再利用低(新しい会話)非常に高い(ステップNとN+1は最新ターン以前をすべて共有)
入出力比率しばしば1:1に近いしばしば50:1〜100:1(トランスクリプトが支配的で、出力は1つのアクション)
モデル呼び出し間のアイドル時間なし数秒(ツール実行: シェル、検索、コード実行)
レイテンシ契約リクエストごとのTTFT/ITLタスクごとの締め切りを、多数のリクエストにまたがって分配
バースト性滑らか、ユーザーごと急峻: 1回のオーケストレーター呼び出しがN回の並列サブエージェント呼び出しにファンアウト

ここから直接2つの帰結が生まれます。第一に、ステップあたりのトークンヒストグラムはチャットとは正反対です: 4万トークンのステップが200トークンの出力を追加するのは普通のことで、チャットの前提(入出力がおおよそ対称)でチューニングされたスケジューラはエージェントリクエストのコストを見誤ります。第二に、モデル呼び出しの間のギャップ — ツールがシェルコマンドを実行する、APIを叩く、テストスイートを走らせる — はモデルサーバーの視点では死んだ時間ですが、スケジューラにとっては生きた意思決定ポイントです: セッションの状態(KVキャッシュ、コネクション、優先度)を保持するか、他のトラフィックのために解放するか。この章の残りは、ほとんどがこの一つの決定について、異なるサブシステムで具体化したものです。この形状を生むトランスクリプト成長のメカニクス — 追記専用の履歴、キャッシュされないループの二次コスト — はコンテキスト管理で完全な計算例とともに導出されています。この章はその形状を所与として、サービングフリートが何をすべきかを問います。

フリートレベルの単位経済性 ​

コンテキスト管理はすでにクライアント側の算数を導出しています: キャッシュなしのNステップエージェントタスクは、キャッシュありの場合に比べて二次関数的にコストが高くなります。各ステップが肥大化するトランスクリプトを再送するからです。この結果はこのセクションの入力であり、再導出するものではありません。フリートオペレーターの問いは異なります: その形状が与えられたとき、タスクの容量計画と価格付けをどう行うか。

タスクあたりのコストが、トークンあたりのコストではなく容量計画の基本単位です。 チャットフリートはトークン/秒に対してサイズを決めます。エージェントフリートの実際の作業単位はタスクです — Nステップ、各ステップでおおよそ同じ量だけ成長するプレフィックス、ルーティング層がセッションのKVをウォームに保ったかどうかに依存するキャッシュヒットプロファイル。同じ総トークン量を扱う2つのフリートでも、一方が独立した1万件の1ステップチャットとして、もう一方が100件の100ステップエージェントタスクとして処理する場合、GPU時間コストは大きく異なり得ます。後者のプロファイルはキャッシュ再利用にすべてがかかっているからです:

text
Fleet sizing input: 5,000 agent tasks/day, avg 30 steps/task, prefix grows ~3K tok/step
Total tokens/day (uncached-equivalent) ≈ 5,000 × 3K × (30×31/2) ≈ 7.0B token-equivalents
At a 90% steady-state cache-hit rate (typical for a sticky-routed fleet): effective
prefill load ≈ 0.7B token-equivalents — a 10x difference in required prefill GPU-hours
between a fleet that keeps sessions cache-affine and one that doesn't.

この10倍という差が、エージェントフリートの容量計画における問いのすべてです: GPU時間の見積もりは想定されるキャッシュヒット率に支配され、そのキャッシュヒット率はルーティングと保持のポリシーであって、トラフィックの性質ではありません。目標のタスク/日とステップ/タスクを、明示されたキャッシュヒット率の前提のもとでGPU時間やプロバイダー支出に変換することは、MLキャパシティとコスト計画にある他のヘッドルーム計算と同じ演習です — エージェント特有の入力は、キャッシュヒット率を一定と仮定せず明示的にモデル化する必要がある、という点だけです。

キャッシュ書き込みプレミアムはステップ数だけでなくツールレイテンシとも相互作用します。 プロバイダーのプロンプトキャッシュには書き込みプレミアム(5分TTLで一般的にフレッシュ入力価格の約1.25倍、1時間TTLで約2倍)と、階層に関わらずフレッシュ価格の一部(約0.1倍)のキャッシュ読み出しが伴います。遅いツール — ビルド、長時間実行のクエリ、人間参加型の一時停止 — を待つエージェントステップは、次のモデル呼び出し前に5分キャッシュが期限切れになるリスクを負い、そのステップを蓄積されたトランスクリプトのフルプライスのプリフィルと新規書き込みに戻してしまいます:

text
If tool-wait time distribution has P(wait > 5 min) = p, then expected cache-adjusted
cost per step ≈ (1 - p) × (cached_prefix + write_premium_5m × increment)
              + p × (fresh_prefix + write_premium_5m × prefix).
Moving to the 1-hour tier avoids the expiry cost but pays its higher write premium on
every write regardless of p. The two tiers break even at a p* that scales with the
increment-to-prefix ratio (Δ/P) — for typical agent loops, where each step adds a small
increment to a much larger accumulated prefix (Δ/P well under 0.2 after a few steps),
p* works out well under 10%: most agent workloads with any long-running tools clear the
break-even for the longer TTL.

これはワークロードごとにルーティング層が下すべきポリシー判断であり(対話型コーディングエージェント対長時間実行の調査エージェント)、フリート全体に一律のデフォルトを当てるべきものではありません — 両方を扱うフリートは、どちらにも同じTTLを固定すべきではありません。

フリートのサイズを決めるのは集約されたセッション状態であって、集約されたスループットではありません。 それぞれ5万トークンのキャッシュされたプレフィックスを保持する100件の同時実行エージェントセッションは、そのうちいくつが現在トークン/秒を生成しているか(ほとんどはツールを待ってアイドル状態)に関係なく、フリートに一度に存在する500万トークンのKVです。エージェント過多なフリートの制約となるのは、しばしばアイドルセッションのキャッシュされたプレフィックスが占有するHBM(または階層化KVのDRAM/SSD)であり、アクティブなデコードに費やされる計算や帯域ではありません。アクティブデコードのスループットとは別に、同時セッションのKVフットプリントに対してサイズを決めることが、チャット専用の容量モデルが完全に見落とすエージェント特有の項目です。

ルーティングとセッションアフィニティ ​

プレフィックスキャッシングと階層化KVストレージはエンジンの機構であり、LLMインフラ(RadixAttention、HBM→DRAM→SSD階層化)でカバーされています。再プリフィルのコスト算数はGPU推論の内部構造でカバーされています。それらの章がカバーしないのは、エージェントワークロードが強いるオペレーター上の意思決定です: エージェントセッションは特定のレプリカのキャッシュとの複数リクエストにわたる関係であり、あらゆるルーティング決定はその関係を守るか壊すかのどちらかです。

スティッキールーティング対キャッシュ認識ルーティング。 同じ問題に対して2つのポリシーが競合します:

  • セッションハッシュアフィニティ(セッションIDで毎回同じレプリカにルーティングする)はシンプルで実装コストが低いですが、負荷に対して盲目です — セッションがすでに混雑しているレプリカに着地した場合、アフィニティはそれでもそこに固定し続け、長時間実行セッションのバーストが一部のレプリカに集中する一方で他は遊んでしまうことがあります。
  • キャッシュ認識/プレフィックスツリー認識のロードバランシング(SGLangのキャッシュ認識ルーター、他のRadixAttentionベースのスケジューラにも同様のロジック)は、どのレプリカがどのプレフィックスを保持しているかを追跡し、新しいリクエストを最も長く一致するプレフィックスをすでにキャッシュしている可能性が最も高いレプリカに向けてルーティングし、有用な一致がどこにもない場合は負荷ベースのルーティングにフォールバックします。

純粋なハッシュアフィニティの失敗モードは、アフィニティが迂回できないホットレプリカです。アフィニティのフロアなしの純粋なキャッシュ認識ルーティングの失敗モードはキャッシュのスラッシングです: 負荷がかかると、ルーターがセッションの次のステップを、プレフィックスを持たない別の負荷の低いレプリカに送ってしまうことがあり、セッション自体とは無関係な負荷分散上の理由でキャッシュヒットが完全な再プリフィルに変わってしまいます。プロダクションのルーターは両方を組み合わせます: 負荷しきい値まではアフィニティのあるレプリカを優先し、それを超えたらキャッシュ認識の選択にフォールバックします。

フェイルオーバー台帳。 セッションのレプリカが死ぬ、再起動する、あるいはドレインされる(フリート規模では日常的なイベントです — デプロイ、オートスケーリング、スポットプリエンプション)と、セッションのKVキャッシュは失われ、次のステップはそれまでに蓄積したすべてに対してフルの再プリフィルを支払います。GPU推論の内部構造のプリフィル数値に照らして定量化すると: 12万トークンの蓄積トランスクリプトを持つタスクの40ステップ目にいるセッションは、ミリ秒ではなく秒のオーダーで計算律速のプリフィルを失います — そして、そのコストはまさに最も多くを投資したセッション、すなわちプレフィックス長がステップ数とともに増加するセッションによって支払われます。これは、チャットのフェイルオーバーコストが集中する場所(チャットリクエストは状態を蓄積しないため一様に小さい)とは正反対です。

ツール待機中のKVの保持対解放。 セッションがツール呼び出しを待っている間、そのKVは何もせずHBM(またはキャッシュ階層)を占有します。保持すれば次のステップが確実にキャッシュヒットになりますが、解放(より安価な階層への降格、またはメモリ圧力下での完全な立ち退き)すれば他のトラフィックのために容量を解放できますが、セッションの次のステップを部分的または完全な再プリフィルに変えてしまいます。正しいポリシーは前セクションのツール待機時間分布の関数です: 短く予測可能な待機(高速なAPI呼び出し)は保持を好み、長いまたは無制限の待機(人間参加型の承認、非同期バッチジョブ)は、無期限の一時停止のためにプレミアムHBMを人質に取るよりも、より安価な階層への降格を好みます。

アフィニティと負荷分散の緊張関係。 生涯にわたって1つのレプリカにアフィニティを持ち続ける単一の長時間エージェントセッションは、そのレプリカの視点から見ると、決して離れないゆっくり成長するKVテナントです — どのスティッキーセッションシステムも直面する同じレプリカのホットスポット化問題ですが、「セッション」が数時間実行され、そのKVフットプリントが単調に増加し得るためここではより鋭くなります。レプリカごとの容量ヘッドルームは、リクエストレートの均等な分布だけでなく、不釣り合いなKVを消費する少数の非常に長いセッションを考慮に入れる必要があります。

ステップごとのレイテンシ予算 ​

チャットリクエストのレイテンシはTTFTに1回のレスポンスのデコード時間を加えたものです。タスクのレイテンシは各ステップにわたる合計です:

text
Task latency ≈ Σ_i (TTFT_i + k_i · ITL_i + tool_time_i)   for i = 1..N steps

単一リクエストでは問題にならない3つのことがこの合計から生じます:

TTFTは一度支払われるのではなく複利で効いてきます。 チャットユーザーは、能動的に待っている会話のターンごとに1回だけプリフィルレイテンシを支払います。エージェントタスクはそれをN回支払い、トランスクリプトが各ステップで成長するため、プレフィックスキャッシングがあっても後のTTFTは前のTTFTより大きくなります(キャッシュされない増分 — このステップの新しいトークン — は毎回フレッシュにプリフィルされる必要があるからです)。タスクレベルのSLO(「60秒未満で完了する」)はステップごとの数字ではなく、N個のすべてのステップにまたがる予算であり、これはサービング層がリクエストごとのレートリミットだけでなく、タスク認識のアドミッションコントロールを必要とすることを意味します。

ストリーミングと早期ディスパッチは、ツールレイテンシをモデルレイテンシに追加するのではなく、その中に隠します。 ハーネスがツール呼び出しの引数を生成されるそばからストリーミングし、モデルがそのターン全体を終える前に(完全で有効なツール呼び出しオブジェクトが利用可能になり次第)ツール呼び出しのディスパッチを開始すれば、ツールのレイテンシはモデルのデコードの後に始まるのではなく、その末尾と重なります。単一ターン内の並列ツール呼び出しは、これを一段階上げた同じアイデアです: 複数の独立したツール呼び出しを一度にディスパッチすることで、N回の逐次的なツール待機期間が1回になり、トークン数を全く変えなくてもレイテンシの勝利になります。

拡張思考はハーネスが制約すべきステップ時間の変数です。 推論/思考トークンは可視のアクションの前に生成され(かつ課金され)、1つのステップでの無制限の思考予算が、1つの決定にタスクのレイテンシ許容量のほとんどを消費してしまうことがあります。ステップごとの思考トークン上限は、コスト制御であるだけでなく、チャットにおける出力長上限とまさに同じ意味でレイテンシ予算の制御です。

エージェントで投機がより報われる理由 ​

投機的デコーディングそのもの — ドラフター、検証算数、いつ勝つか — はLLMインフラと、GPU推論の内部構造の単一フォワードパス検証コストでカバーされています。エージェントでは機構は変わりません。変わるのは見返りです。エージェントの出力には、チャットの出力には通常ない性質があるからです: 低エントロピーです。

ツール呼び出しの引数オブジェクトを出力する、小さな差分でファイルを書き換える、固定されたJSONスキーマを埋めるモデルは、トークンごとに見ると、自由形式の散文を書くモデルよりもはるかに予測可能です — 次のトークンは、しばしば真に不確実であるというよりも、スキーマ、周囲のコード、編集中のファイルによって決まります。投機的受理率は予測可能性を直接反映するため:

  • nグラム/プロンプトルックアップドラフティングは、ファイル編集のケースに限って言えば、ほぼ無料でほぼ最適です: エージェントがすでに読み込んだファイルを書き換えている場合、ファイルの変更されていない部分自体がドラフトになります — エージェント自身の最近のコンテキストに対するルックアップは、別のドラフターモデルをサービングしたり維持したりすることなく、長く高受理率のランを提案します。
  • EAGLE/Medusaクラスのドラフターは、創造的あるいは会話的なテキストよりもツール呼び出しとコード出力でより高い受理率を示します — チャットトラフィックがどのワークロードよりも投機から得る恩恵が最も少ない理由と同じです。
  • プロバイダーの「予測出力」機能(期待される出力をリクエストとともに提出し、モデルがドラフトした投機と同じ方法で検証する)は、まさにこのエージェントのユースケース — 既知の類似ドラフトでファイルを書き換える — を狙った、これのマネージド版です。

運用上の含意は、投機はフリート全体で一律の設定ではなく、ワークロードごとに有効化・チューニングすべきだということです: オープンエンドなチャットとコード編集エージェントの両方をサービングするフリートは、コード編集トラフィックがチャットトラフィックにはほとんど効かないドラフターから2〜3倍の高速化を引き出すのを目にすることになり、混合された受理率に対してドラフターの計算コスト自体をサイズ決めすると、エージェントの取り分を過小評価することになります。

ファンアウト: マルチエージェント推論の経済性 ​

サブエージェントを生成するオーケストレーターは、上記のワークロード形状を置き換えるのではなく増幅します。新しいコンテキストを受け取る各サブエージェントは、オーケストレーターが渡したもの — タスクの分担分、関連ファイル、共有システムプロンプト — に対してプリフィルを再度支払います。したがってファンアウトは、オーケストレーターのコンテキスト成長(コンテキスト管理での懸念事項)を、サービング層でのN回の並列プリフィルイベントと交換します。

オーケストレーターのトークン増幅。 5つのサブエージェントをディスパッチする単一のオーケストレーターターンは、それぞれ2万トークンのコンテキストを持ち、1つの決定に見えたものからおよそ10万トークンのプリフィル作業を生み出します — これは、単一エージェントループが1つのバーストに集中させる代わりに多くの逐次ステップに分散させたはずの作業です。これは実際のコストですが、実時間を買います: 5つのサブエージェントを並列実行すれば、1つのおよそ5倍のトークンコストで、1つを実行するのとおおよそ同じ時間で完了します — マルチエージェントシステムとオーケストレーションパターンで一般的にカバーされているスループット対レイテンシのトレードオフを、推論フリートに特有のコストに特化させたものです。

兄弟間の共有プレフィックス再利用が、ファンアウトを手頃にするレバーです。 オーケストレーターがすべてのサブエージェントに同じシステムプロンプトと同じベースコンテキスト(共有コードベースのスナップショット、共通の指示セット)を与え、サブエージェントごとのタスク記述のみを変える場合、キャッシュ認識ルーターはN個のサブエージェントすべてのプリフィルを、N個の独立したプレフィックスからではなく、1つの共有キャッシュされたプレフィックスからサービングできます — ファンアウトは共有部分について1回のプリフィルの代金を払うだけで、N回分は払いません。これが機能するのは、ルーティング層が同時に到着するリクエストにまたがる共有プレフィックスを認識し、かつハーネスが実際に共有素材を先に、発散する素材を後にしてサブエージェントのプロンプトを構築している場合に限られます(ターンをまたぐのではなく兄弟をまたぐ、同じキャッシュに敏感なプレフィックス順序の規律です)。

ファンアウトは定常状態ではなく、スケジューラが吸収すべきバースト負荷です。 一度にディスパッチされたN個のサブエージェントは、サービング層の視点からは、通常とは異なる高いプレフィックス重複を持つトラフィックスパイクのように見えます — 同じ瞬間に到着するN人の独立したユーザーとは大きく異なります。これを通常のバーストトラフィックとして扱うスケジューラ(容量を立ち上げ、均等に負荷分散する)は、キャッシュを共有する兄弟を複数のレプリカに分散させてしまい、上記の再利用を失います。兄弟のファンアウトを認識するスケジューラは、それを捉えるために意図的にバッチを同じ場所に配置できます。

ファンアウトが長い単一ループに勝るのはいつか。 並列サブエージェントは、サブタスクが真に独立していて(どのステップも別のステップの出力を先に必要としない)、上記の共有プレフィックス再利用が利用可能な場合に勝ちます。単一の、よりコンテキスト効率の良いループであれば、トークンコストの一部で逐次的に解決できたはずのタスクに対してファンアウトがコストを増幅する場合には負けます。どちらのパターンが適合するかというアーキテクチャ上の問いはオーケストレーションパターンとマルチエージェントシステムに属します。ここでのポイントは、その決定のサービングコスト側は、ステップ数だけでなく、兄弟間のプレフィックス共有が実際に捕捉されるかどうかに支配される、ということです。

エージェントトラフィックのサービング階層 ​

エージェントトラフィックは一様ではなく、それを1つの階層として扱うとそのほとんどの価格付けを誤ります:

  • 対話型エージェント(コーディングエージェントやチャット駆動のアシスタントをリアルタイムで見ているユーザー)は、前セクションのレイテンシ規律を必要とします: スティッキー/キャッシュ認識ルーティング、ステップごとの思考予算の上限、タスクレベルのSLO。
  • バックグラウンドエージェント(リアルタイムで誰も見ていないキューに入ったタスクを処理するエージェント)は、より良いバッチングとより安価な容量と引き換えに、ステップごとのより高いレイテンシを許容できます — レイテンシに鈍感なキューと同じアドミッションコントロールのトレードオフです。
  • バッチAPI(評価、大規模バックフィル、オフラインエージェント実行)は、エージェントのプレフィックスが繰り返されるため、エージェントワークロードに特によく適合します: 共有コードベースや共有指示に対する類似タスクのバッチは、プロバイダーのバッチ割引とキャッシュ再利用の両方にとって理想的なケースに近いです。

プリエンプションのコストはセッションの経過時間とともに増加します。 新規のチャットリクエストをプリエンプトするコストはほぼゼロです — 数百トークンの失われた作業だけです。60ステップ進んだエージェントセッションをプリエンプトすると、タスク全体にわたって蓄積された計算律速のプリフィルから構築されたKVキャッシュが破壊されます。そのセッションの次のアドミッションは、そのすべてを再び支払うことになります。チャットでチューニングされたプリエンプションポリシー(おおよそ経過時間に依存せず、都合の良いものを立ち退かせる)は、エージェントトラフィックに適用すると系統的に最も高価なものを立ち退かせることになります。経過時間を考慮したプリエンプション — 他の条件が同じなら短いセッションを長いセッションより優先して立ち退かせる — がエージェント特有の修正です。

ステップごとのタイムアウト/リトライのセマンティクスは、リクエストではなくループを前提にする必要があります。 失敗したステップのリクエストを再送するリトライポリシーは、ステップ自体が冪等である場合にのみ安全です — ステップにすでに実行済みのツール呼び出し(書き込み、送信済みのメール、試行済みの支払い)が含まれていた場合、素朴なリトライはそれを再実行してしまいます。これはあらゆる分散リトライと同じ冪等性の規律です(リトライ、タイムアウト、ヘッジング、リトライ、冪等性、補償)が、エージェントループはこの失敗モードを見落としやすくします。リトライされている「リクエスト」は、より長く状態を持つタスクに埋め込まれた1回のLLM呼び出しであり、その呼び出しを再試行することは安価で安全に見えますが、ステップの副作用を再試行することはそうではないからです。

エージェント推論の計測 ​

GPU推論の内部構造がチャットとバッチトラフィック向けに定義するリクエストごとの指標は、エージェントが行う個々のモデル呼び出しそれぞれには引き続き適用されますが、ワークロード全体として重要な問いには答えません:

  • リクエストごとではなく、セッションごとのキャッシュヒット率。 生涯平均で80%のヒット率を持つセッションでも、ステップ12で具体的に失敗していることがあります(ルーティングミス、TTL失効) — セッションレベルの追跡は、リクエストレベルの集計が均してしまう、ルーティングによって系統的に失敗させられているセッションを捕捉します。
  • タスクあたりのコスト、タスクがトリガーしたすべてのステップとすべてのサブエージェントのファンアウトにまたがって集約されたもの — トークンあたりやリクエストあたりのコストではなく、容量計画や価格モデルに実際に登場すべき数字です。
  • タスクレベルのグッドプット: エンドツーエンドの締め切り内に完了したタスクを、試行されたタスクで割ったもの — 第11章のリクエストごとのグッドプット指標のタスクレベル版であり、フリートが実際に製品のレイテンシ契約を守れているかどうかを反映する唯一のスループット数値です。
  • タスク内のステップインデックスごとのp99ステップTTFT、ボリュームが許せばステップインデックスごとに追跡します。トランスクリプトはステップをまたいで成長するため、ステップ40のTTFT分布はステップ2のものと同じ母集団ではなく、それらを一緒に平均すると、長いタスクの後半でのみ現れる劣化が隠れてしまいます。

第11章からの一般的な教訓 — フリート全体の平均ではなく、実際のレイテンシ契約に紐づいたパーセンタイルを報告する — はここでも余分な次元を伴って当てはまります: 契約はタスクごとであり、重要な母集団はセッションが経過するにつれて変化します。

障害モード ​

ロードバランサーがセッションを複数のレプリカに分散させる。 アフィニティのフロアを持たないルーターが、負荷がかかった状態でセッションの連続するステップを異なるレプリカに送ります。すべてのレプリカが健全と報告し、集約スループットは問題なく見えますが、唯一目に見える症状はフリートのキャッシュヒット率が静かに崩壊することです — チャットトラフィック向けに構築されたほとんどのダッシュボードはこれを表面化させません。セッションの継続性の関数としてヒット率を追跡していないためです。

サブエージェントストームがフリート全体のプレフィックスキャッシュを立ち退かせる。 大規模なファンアウト(一度に数十のサブエージェントを生成するオーケストレーター、または多くのユーザーが同時にファンアウトをトリガーする)は、すべてのレプリカに新鮮で互いに無関係なプレフィックスを大量に流し込み、その過程で無関係な長時間実行セッションのウォームなプレフィックスを立ち退かせます。結果として、サブエージェントトラフィックのバーストが、それとは無関係なセッションのレイテンシを劣化させます。ファンアウトバースト向けの容量ヘッドルームは、定常状態のセッション容量とは別に計画する必要があります。あらゆる騒がしい隣人問題と同じです。

冪等性のないリトライがタスク支出を(そして最悪の場合、副作用を)倍加させる。 タイムアウトしてリトライされたステップで、根底のツール呼び出しがすでに完了していた場合、副作用が再実行されるだけでなくLLM呼び出しも二重に支払われます。フリートコストのレベルではこれはリクエストごとの指標には現れず、タスクあたりのコストの説明のつかないドリフトとしてのみ現れます。正当性のレベルでは、これは重複した書き込みになり得ます。

思考予算の暴走。 1つのステップの推論ストリームが典型的なものよりはるかに長く続き、タスクのレイテンシ予算のほとんどを消費し、通常より長い期間デコードスロットを固定してしまいます — そのタスクだけでなく、高い同時実行性のもとでは、同じレプリカを共有する他のすべてのセッションへのサービスも劣化させます。

経過したセッションのプリエンプションが再プリフィル負荷にカスケードする。 GPU推論の内部構造で説明されている同じKV圧力カスケード — メモリが埋まり、スケジューラがプリエンプトし、立ち退かされたシーケンスが後で再プリフィルし、それが負荷を追加してさらに誰かを立ち退かせる — は、エージェントトラフィックでは特に悪化します。素朴な(経過時間を無視した)プリエンプションのもとで最も立ち退かされやすいセッションが、まさに長く、失うプレフィックスの蓄積が最も多い、価値の高いセッションだからです。

意思決定フレームワーク ​

状況採るべき対応
対話型エージェント、ユーザーが見ているアフィニティフロア付きのキャッシュ認識スティッキールーティング、ステップごとの思考上限、タスクレベルSLOアドミッションコントロール
バックグラウンド/キューに入ったエージェント作業よりゆるいレイテンシ許容、バッチフレンドリーなスケジューリング、標準(アフィニティフロアなし)の負荷分散
評価、バックフィル、オフラインエージェント実行プロバイダーのバッチAPI。それらが想定する共有プレフィックス、共有指示のケース
長いツール待機ステップが一般的(ビルド、人間の承認、非同期ジョブ)待機中はプレミアムHBMを保持するのではなくより安価な階層にKVを降格させる。1時間のキャッシュTTL階層を検討する
サブエージェント間で共有ベースコンテキストを持つファンアウトすべてのサブエージェントプロンプトで共有素材を先に、発散する素材を後に構築する。ルーターが兄弟間のキャッシュ再利用を捕捉していることを検証する
エージェント出力がスキーマ固定またはファイル書き換え形状(ツール呼び出し、差分)ワークロードごとに投機を有効化する — nグラム/プロンプトルックアップドラフティングや予測出力を、チャット向けにチューニングされたフリート全体のドラフターだけに頼らない
フリートのサイズ決めキャッシュヒット率をGPU時間見積もりへの明示的なポリシー入力としてモデル化する。アクティブデコードのスループットだけでなく、同時実行アイドルセッション向けにKVフットプリントをサイズ決めする
プリエンプションポリシーの選定経過時間を考慮した立ち退き(長いセッションを保護する)を、経過時間を無視した都合優先の立ち退きの代わりに採用する

重要なポイント ​

  1. エージェントは別個のワークロード形状であり、繰り返されるチャットではありません。 入力過多、ステップと兄弟間でのプレフィックス冗長性、タスクごとに逐次的、フリートレベルでバースト性がある — 以下のすべてのレバーはこの形状から従います。
  2. キャッシュヒット率はトラフィックの性質ではなくポリシーであり、フリートのサイズ決めを支配します: キャッシュアフィニティのあるフリートとないフリートの間で必要なプリフィル容量が10倍振れるのは、例外ではなく通常の範囲です。
  3. キャッシュ書き込みプレミアムとTTLはツールレイテンシと相互作用します。 TTL階層を選ぶ前に、ワークロードごとにP(ツール待機がキャッシュTTLを超える)を明示的にモデル化してください。
  4. ルーティングは、チャットフリートにはないがエージェントフリートが行う、負荷を支える意思決定です: スティッキー対キャッシュ認識ルーティング、フェイルオーバー台帳、ツール待機中のKV保持対解放は、すべてセッションをレプリカのキャッシュとの複数リクエストにわたる関係として扱うことから従います。
  5. タスクレイテンシは1つの数字ではなく、ステップにまたがる合計です — TTFTは複利で効き、ストリーミングと並列ツール呼び出しはレイテンシのレバーであり、思考予算にはステップごとの上限が必要です。
  6. エージェントでは投機がより報われます。 ツール呼び出しとファイル編集の出力は低エントロピーだからです。フリート全体ではなくワークロードごとにチューニングしてください。
  7. ファンアウトは並列性のためにプリフィルコストを増幅し、その経済性全体はルーターが兄弟間の共有プレフィックス再利用を捕捉するかどうかにかかっています。
  8. プリエンプションとリトライのポリシーはどちらも経過時間/状態を考慮する必要があります: エージェントステップの立ち退きやリトライは、チャットリクエストのように安価で一様な操作ではありません。
  9. セッションとタスクのレベルで計測してください、リクエストごとだけではなく — セッションごとのキャッシュヒット率、タスクあたりのコスト、タスクレベルのグッドプット、ステップインデックス付きのp99 TTFTが、エージェントサービングの健全性を実際に診断する指標です。

参考文献 ​

  • Zheng et al. — SGLang: Efficient Execution of Structured Language Model Programs (2024) — RadixAttentionとキャッシュ認識ロードバランシング
  • Zhong et al. — DistServe: Disaggregating Prefill and Decoding (2024)
  • Qin et al. — Mooncake: A KVCache-centric Disaggregated Architecture (2024)
  • Leviathan et al. — Fast Inference via Speculative Decoding (2023); Cai et al. — Medusa (2024); Li et al. — EAGLE (2024)
  • Prompt Caching — Anthropic Documentation — TTL階層、書き込みプレミアム
  • Effective Context Engineering for AI Agents — Anthropic, 2025
  • Multi-Agent Research System — Anthropic, 2025 — オーケストレーター/サブエージェントのトークン経済性
  • GPU推論の内部構造 — ハードウェアルーフライン、KVキャッシュ台帳、プリフィル/デコード算数
  • LLMインフラ — この章が基盤とするサービングエンジンの機構
  • コンテキスト管理 — この章が基盤とするクライアント側のコスト三角形とプレフィックスキャッシングの規律

MITライセンスの下で公開。Babushkaiコミュニティが構築。

Copyright 2024-present Babushkai