エージェントのワークロードがインフラストラクチャ計画に与える影響

インフラストラクチャ計画では、一般に需要の形状について何らかの前提を置いています。つまり、需要はユーザーと相関しており、一日を通して予測可能に変化し、あるリクエストのコストは別のリクエストとほぼ同じになります。

エージェントのワークロードは 3 つの前提をすべて破っており、チームは予測が役に立たなくなる四半期にこれを発見する傾向があります。

需要は人員数ではなく信頼に従う

従来の容量は、システムを使用する人の数に応じて拡張されます。エージェントの使用状況は、チームがエージェントをどの程度信頼しているかによって決まりますが、これはまったく異なる変数であり、スムーズではなく段階的に進みます。

1 人のエージェントを信頼するチームが時々それを実行します。 3 か月後、同じチームがそれが機能するのを確認し、カテゴリ全体の作業をそれを通してルーティングしました。組織については何も変わりませんでした。負荷が倍増しました。

これが、1 か月目では快適な容量が 6 か月目では不足することがよくある理由であり、ユーザー数に基づいて構築された予測がコストのかかる方向に誤る理由です。

1 回の実行は 1 回のリクエストではありません

単一のエージェントの実行には、取得、複数のモデル呼び出し、複数のツールの呼び出し、および検証ステップが含まれる場合があります。単純な実行と複雑な実行の間の差異は非常に大きく、平均値ではそれがひどく隠蔽されます。

実行あたりの平均コストを計画するとテールが過小評価され、実際に予算が消費されるのはテールです。日常的に、ごく一部の実行が支出の大部分を占めます。

再試行は目に見えない乗数です

エージェントが途中で失敗して再起動すると、実行全体の料金が 2 回支払われ、1 つの結果が生成されます。成功と再試行を別々に測定しない限り、これは修正可能な失敗としてではなく、より高い平均コストとして現れます。

私たちがこれまで見てきたほとんどの展開では、再試行は対処可能な最大の無駄であり、目に見えて何もエラーがないため、最も見逃しやすいものでもあります。

同時実行は本質的にバースト的です

エージェントの作業は一気に発生します。バッチ ジョブが開始され、インシデントが発生すると 20 件の並行調査がトリガーされ、スケジュールされた実行がチーム間で同時に実行されます。

平均に合わせてサイズ設定された容量はバースト中にキューに入れられ、対話型エージェントでのキューは、機能が壊れていることと区別できません。

計画の前に何を計測するか

ワークスペースごとではなく、エージェントごとのコストと遅延。成功とは別に再試行します。ヘビーテール分布の平均値は計画に有用な数値ではないため、平均値ではなくパーセンタイルを使用します。実行ごとにステップ数がカウントされるため、徘徊エージェントが予算に捕らえられる前に表示されます。

この4つがあれば、予測が可能になります。これらがなければ、キャパシティ プランニングは、それ自身の差異を隠蔽した数値から外挿することになります。

予算が合うところ

サーキットブレーカーの予算は、財務的なものであると同時に容量の管理でもあります。ワークスペースおよびチームごとのハードリミットは、近づくと警告が表示され、到達するとブロックされるため、月次レポートでは不可能な方法で最悪のケースを制限します。

これは、容量の超過が他人のスケーリング問題ではないセルフホスト型の展開において最も重要です。

次へ

AI 可観測性とトークン監視のページではインストルメンテーションについて説明し、展開ページではセルフホスト型およびエアギャップ型の容量に関する考慮事項について説明します。