オンコールをエージェントに。第7回 サイジング:誰も事前にやらないトークンの算数

このプラットフォームでの1回の深いインシデント調査、トリアージエージェントが診断を提案できるだけの証拠を集めるまでのツール呼び出し8ラウンドは、32,950トークンを消費し、そのうち31,600は入力だ。BedrockのConverse APIは、ラウンドごとに膨らみ続けるトランスクリプト全体を再送するからだ。これに実際のアラーム量を掛けると、プラットフォームの月間オンデマンドモデル請求全体は約$14になり、合計月額コスト約$21の中でも小さい方の項目の1つになる。第1回が明示的に先送りしたProvisioned Throughputを初日に買っていれば、損益分岐に必要な稼働率のおよそ400分の1で走るワークロードのために、月に$15,768を払うことになっていた。どれもダイアグラムからは自明ではない。誰かが算数をやって初めて姿を現す。それをこの回が最初から最後までやる。すべての数字は、Bedrockの料金表か、全文を示した式のどちらかまで遡れる。

第1回はシナリオ、30アカウントで週40ページ、を設定し、選択肢の中からAgentCoreとStrandsを選んだ。第2回はアカウント境界と推論プロファイルの配線を構築し、この回が答えるまさにその問い、Provisioned Throughputの時間料金がオンデマンドのトークン単価に勝つ地点、を名指しした。第3回はトリアージエージェントのツール呼び出しループ、以下でラウンドごとに値付けされるもの、を出荷した。第4回はそれらのツールをAgentCore Gatewayの背後に移した。第5回は、この回の月額請求がカバーしなければならないSupervisor、runbook、costエージェントを追加した。第6回はすべての呼び出しにGuardrailsを付けた。この判断は、この回の請求書にとって予想以上に重要だったことが分かる。以下のすべての数字はコンパニオンリポジトリgithub.com/flightlesstux/agents-on-callのdocs/sizing-model.mdに、この架空の会社の数字ではなく実際の数字に対して再計算するためのチェックリストとともに置いてある。

トークンの算数、実例で

Converse APIはサーバー側に会話状態を一切持たない。ツール呼び出しの各ラウンドは、それまでのトランスクリプト全体、システムプロンプト、ツールスキーマ、過去のすべてのツール呼び出しとその結果を再送する。つまり入力トークンはラウンド数に対して線形には増えず、すでに送ったすべての合計とともに増え、長い調査は自身の履歴の代金を何度も何度も払う。構成要素を、仮定ではなく明示的に宣言する。すべての呼び出しで同一の1,800トークンの静的プレフィックス(システムプロンプト、ツールスキーマ、ガードレール設定)、400トークンの初期アラームペイロード、ラウンドあたり150トークンのアシスタント出力、そしてラウンドあたり350トークンのツール結果の追記、ラウンドごとに500トークンの成長だ。ラウンドrの入力サイズはS + 400 + 500*(r-1)になる。

3ラウンドで解決する浅い調査はこうなる:

8ラウンドを要する深い調査、より多くのアカウント、より多くのツール、証拠が積み上がるまでのより多くの往復、はこうなる:

合計32,950トークン。浅い調査の8,700に対し、ラウンド数2.7倍でコストは3.8倍だ。このギャップこそ再送ペナルティの可視化だ。total_input(N) = N*(S+400) + 500*N*(N-1)/2はラウンド数に対して線形ではなく二次で増える。ラウンド8はラウンド1から7の代金をもう一度払っているからだ。

第1回のオンコールデータがこれに実際の量を突き合わせる。週40ページを、ここでは70/30で浅い調査28件と深い調査12件に分ける。週あたり浅い調査で243,600トークン、深い調査で395,400トークン、合計639,000。トリアージエージェントだけで月およそ277万トークンだ。runbook、costスイープ、Supervisorの各エージェントがさらにおよそ110万を加え、プラットフォーム全体では月およそ387万トークンになる。runbookエージェントのKnowledge Base込みのラウンドやcostエージェントの日次スイープを含むエージェントごとの完全な内訳はコンパニオンドキュメントにある。次のセクションに持ち越す価値のある数字は、この量ではこのどれも大きくない、ということだ。

定常スイープに対するバーストインシデント

costエージェントの量は意図的に滑らかだ。1日1回のスケジュールされたEventBridge実行、業務時間外、インシデントと1分たりとも重ならない。トリアージエージェントの量は滑らかではなく、平均はそれを隠す。均等にならせば、週606,000入力トークンは毎分およそ60トークンだ。実際のインシデントは相関する。1つの上流障害が同じ5分間に8つのアラームへ扇状に広がれば、8つのトリアージセッションが立ち上がり、その第1ラウンドが同じTPMウィンドウに着地する。トリアージだけでその1分間に8 x 2,200 = 17,600入力トークン、Supervisor自身のディスパッチ呼び出しを数える前の話だ。これはならした平均のおよそ290倍であり、まさに障害が進行中で、プラットフォームが応答し続けられるかが最も重要な10分間に起きる。平均ではなくピークに対してサイズを決めること。平均は来月の請求書に現れるものであり、ピークはアラームストームが回答を得るか`ThrottlingException`を得るかを決めるものだ。

クォータ、スロットリング、痛みが来る前のアラーム

Bedrockの2つの呼び出しエンドポイントはクォータの強制の仕方が異なり、その違いはバーストが実際に何にぶつかるかを変える。bedrock-runtimeエンドポイントは入力と出力のトークンを合算してモデルごとの単一のTPMクォータに数え、RPMはモデル固有だ。トップティアのモデルの中にはRPMクォータをまったく持たず、トークンだけで律されるものもある。bedrock-mantleエンドポイントは入力と出力を別々のトークンクォータに分け、RPMを完全に廃している。いずれにせよクォータはアカウントとリージョンのスコープであり、このプラットフォームが走らせるすべてのエージェントで共有され、エージェントごとに割り当てられてはいない。つまり相関したアラームストームの間、Supervisorのディスパッチ呼び出しとトリアージエージェントの8ラウンドの調査は同じプールから引き出している。セルフサービスのクォータ引き上げリクエストは今年前半の変更で両エンドポイントをカバーするようになった。以前はbedrock-mantleにはサポートチケットが必要だった。これは実在したギャップを閉じるが、インシデントが天井を見つける前に天井を知っておく必要をなくしはしない。

Bedrock SDK自身のリトライロジックはスロットリング応答に対してバックオフするが、それはバーストをならすだけで、クォータの余裕を出現させはしない。より有用な一手はどんなリトライよりも上流にある。リトライがすでに吸収した最初のThrottlingExceptionではなく、クォータ使用率そのものにアラームを張ることだ。TPM天井の70%で発火するクォータ使用率アラームは、アラームストームがオンコールエンジニアに劣化したトリアージエージェントを渡す数日前に、キャパシティプランニングにページを渡す。スロットリングエラーを最初のシグナルにするのを待つことは、このプラットフォームの助けを最も必要とするインシデントこそ、プラットフォーム自身のエラーバジェットがツール呼び出しではなくリトライに費やされるインシデントになる、ということだ。

バーストの余裕としてのクロスリージョンプロファイル

第2回はこのプラットフォームを全面的にクロスリージョン推論プロファイルに載せた。信頼性のためであり、トークン単価の追加はない。その判断のサイジング面はこうだ。TPMクォータはリージョンのエンドポイントにスコープされ、クロスリージョンルーティングは、1つのリージョンの天井を使い尽くすはずのバーストが、単一リージョンの上限の後ろで待つ代わりに、隣のリージョンの別の天井に流れ込めることを意味する。無制限の余裕ではないし、本当の天井を知ることの代わりにもならないが、1リージョンのクォータを無料で地理1つ分のクォータに変える。このプラットフォームが買うたいていのキャパシティの余裕よりも良い取引だ。

Provisioned Throughputの経済学:損益分岐点と、今買うのが間違いである理由

Model Unitは、選んだモデルの料金表とMUスループットがどうであれ、固定の入力・出力トークン/分の天井と引き換えに、常時課金されるフラットな時間料金を買うものだ。AWSはそのどちらもモデルから独立した固定値としては公表していないため、以下の式はAWSの事実ではなく宣言されたプレースホルダー値を使っており、誰かが実際のお金を使う前にライブのコンソールの数字が必要だ:

max_monthly_input  = T_in  * 60 * 730   # 730 hours in an average month
max_monthly_output = T_out * 60 * 730

on_demand_equiv_cost = (max_monthly_input  / 1000) * I
                      + (max_monthly_output / 1000) * O

pt_monthly_cost        = P * 730
break_even_utilization = pt_monthly_cost / on_demand_equiv_cost

例示のプレースホルダー(MUあたり毎分200,000入力・100,000出力トークン、オンデマンドで1,000トークンあたり$0.003と$0.015、コミットなしでMU時間あたり$21.60)では、そのMUの天井の100%稼働はオンデマンド換算で月$91,980の価値があり、PT自体は月$15,768かかり、損益分岐点は持続稼働率17.14%に落ちる。その割合を超えればPTの方が安い。下回ればオンデマンドが勝つ。そして仕事をしている単語は「持続」だ。これは月間平均であり、2セクション上のバーストの例は、1分間天井に当たることと天井を持続することが同じではない理由をまさに示している。

このプラットフォームの実際の月間入力量、約365万トークンは、そのMUの月間入力天井の0.042%であり、17.14%の損益分岐点をおよそ411倍下回る。初日に1 MUを買うこと、まさに第1回が先送りし第2回がこの算数が先だと旗を立てた一手は、オンデマンドのモデル請求全体が約$14のワークロードを守るために月$15,768を費やすことになっていた。間違いは算数ではなく、算数を一切やらないこと、そして4エージェントにまたがるリクエストレート分布を測りもしないうちに月額料金にコミットすることだ。測るまではオンデマンド、プロビジョンドはその後で、というのは慎重さのための慎重さではない。損益分岐計算が実際に言っていることだ。

プロンプトキャッシングは同じ算数をどう変えるか

キャッシングは、トークン算数のセクションの再送ペナルティを、ほぼ解決済みの問題に変える。キャッシュされたプレフィックスの読み取りは90%引き。キャッシュへ新しく書き込まれるコンテンツは通常の入力価格の1.25倍で、その係数以外に別料金はない。ラウンドごとに適用すると、ラウンド1は入力全体をキャッシュに書き、以降の各ラウンドは前のラウンドの入力全体を通常価格の10%で読み、新しく追記された500トークンにだけ全額プラス25%を払う:

billing_input(1) = input(1) * 1.25
billing_input(r) = input(r-1) * 0.10 + 500 * 1.25   # r >= 2

浅い調査では、キャッシュ適用後の課金換算入力は8,100から4,490トークンへ、44.6%の削減。深い調査では31,600から9,715へ、69.3%の削減だ。打ち消している再送ペナルティが追加ラウンドごとに複利で効くため、削減幅はより大きい。キャッシングは、キャッシュなしのコストがより痛む場所でこそ、より効く。ドルに直すと、深いインシデントの合計コスト(入力プラス出力。出力はキャッシングの影響を受けない)は$0.1151から$0.0494へ、57.1%の削減。トリアージエージェントの週次ミックス全体に適用すると、このエージェント単体の月間モデルコストは$10.02から$5.29へ、$4.73の節約、47.2%だ。同じ仕組みはrunbookとcostスイープエージェント自身のマルチラウンドループにも、実行頻度がはるかに低いぶん小さな絶対規模で適用される。コンパニオンドキュメントは、量とラウンド数が最も多く効果が最大のエージェントであるトリアージについてのみ、完全な再計算を載せている。

プラットフォーム全体の月額コストモデル

すべてのカテゴリをまとめる。出典のあるAgentCoreとGuardrailsの価格を上のトークン量に当て、モデルトークンの行はトリアージエージェントのキャッシングあり・なしの両方で示す:

じっくり向き合う価値のあることが2つ。Runtime、Gateway、Memoryはこの量では丸め誤差だ。秒単位課金と、モデルを待つアイドル時間への無課金は、同時実行数とセッション長が桁で伸びるまで、マネージドインフラがほとんど計上されないことを意味する。Guardrailsは丸め誤差ではない。キャッシュなし合計のおよそ30%を占め、Runtime、Gateway、Memoryの合計よりおよそ15倍高く、キャッシングがモデルの行を縮めた後では、自分がスキャンしているモデル請求の3分の2近い大きさになる。モデルのトークン数で止まるサイジング演習は、実際の請求書の3分の1を見落とす。それは、たいていの人がコストではなくコンプライアンスのためにサイズを見積もるサービスの中に座っている。

エージェントごとのモデルの適正サイズ

上のトークン算数はすべてのエージェントに1つのモデルを仮定している。それは楽なデフォルトであって、正しい最終形ではない。4体のエージェントはモデルに本当に異なることを求める。トリアージはツール出力からの構造化された診断だ。証拠が入り、もっともらしい根本原因の有界な集合が出る。システムプロンプトとツールスキーマが引き締まっていれば、より小さく安いモデルがうまくこなす仕事であり、第3回の低temperature設定がすでにチューニングされていたワークロードそのものだ。costエージェントの日次スイープは、ツールがすでに取得した数字に対する集計としきい値比較がほとんどで、出力フォーマットに確実に従う最小のモデルにさらに良く合う。runbookエージェントは、より強いモデルがその高いトークン単価に見合う唯一の場所だ。第4回の承認ゲートの背後で人間がまさに承認しようとしているSSMドキュメントとパラメータそのものを起草しており、そこでの間違いは実際の爆発半径を持つ間違いであって、どのみち誰かが再確認する診断の中の間違いではない。すべてのエージェントを同じモデルにデフォルトさせるのではなく、間違いが実際にいくらつくかにモデルサイズを合わせることは、プロンプトキャッシングやPTの背後にあるのと同じ本能だ。タスクが必要としない能力にお金を使わず、誤答が高くつく場所にこそ使う。第8回のevalハーネスが、「うまくこなす」を当て推量から信頼に値する数字に変えるものだ。

注視すべき失敗モード

このモデルが実際のアカウントに対して走る前に知っておく価値のあることが4つ。第一に、上のすべてのドル数字は2つのプレースホルダー入力、オンデマンドのトークン単価とProvisioned ThroughputのMUスループット天井に依存しており、このシリーズは意図してどちらも特定の名前付きBedrockモデルに固定していない。合計を信頼する前にライブの料金ページを差し込むこと。古びたプレースホルダーは、明らかに間違った請求書ではなく、自信ありげに間違った請求書を生む。第二に、ツール結果350トークンという仮定はほぼ確実に控えめだ。実際のCloudWatchメトリクスのダンプやログの抜粋はその5から10倍になりうるし、ラウンド横断で二次的に複利で効く項であるため、そこでの過小評価は下流のすべての数字を固定オフセットではなく比例的に過小にする。第三に、損益分岐計算は月間平均だ。実トラフィックがバーストのセクションのような形、長い静かな区間と鋭い相関スパイク、をしたプラットフォームは、紙の上では損益分岐に遠く及ばないまま、肝心の10分間にスロットリングされうる。これはいずれにせよPT購入よりもクロスリージョンの余裕とクォータアラームを支持する。第四に、プロンプトキャッシングの節約はキャッシュヒットが実際に着地することに依存する。月の途中で編集されたシステムプロンプトやツールスキーマはキャッシュ済みプレフィックスを無効化し、キャッシュが再び埋まるまでの間、キャッシュなしの全額コストを一時的に呼び戻す。プロンプト変更のあとには見張るべきことであり、ないものと仮定してよいことではない。

次に読む

• 第6回 Guardrails:誰もがスキップするパート。この回の月額コストモデルが依拠するGuardrailsの単価と、実際にどれだけのテキストがスキャンされるかを決める呼び出しパターンについて。
• 第8回 プロダクション:可観測性、評価、そして嘘をつく日。上のモデル適正サイズの判断が、正しいと仮定されるのではなく実際のトレースに対してテストされる回だ。
• ercan.cloudのThe AWS Well-Architected Framework: A Key to Cloud Success。この回がまるごと1本の長い実例になっているコスト最適化の柱、コミットする前に測れ、について。

上の表から割愛したrunbookとcostスイープエージェントのエージェントごとの内訳と、すべての数字を実際のアカウントに対して再計算するためのチェックリストを含む完全なdocs/sizing-model.mdは、コンパニオンリポジトリgithub.com/flightlesstux/agents-on-callにある。この種のプラットフォームを大規模に運用する際のデータベースとインフラ側の話はercan.cloudのフィールドノートで、ハブはercanermis.comにある。