Amazon Bedrock は、Mantle エンドポイントのトークン毎分クォータを標準の AWS Service Quotas コンソールに表示するようになった。モデルごとの入力トークン毎分と出力トークン毎分の上限を直接読み取れるようになり、AWS の他のあらゆるものと同じワークフローで引き上げをリクエストできる。これは小さなコンソールの変更のように聞こえる。だが本番環境でマルチエージェントシステムを運用している人にとっては、キャパシティを計画するか、それとも 429 の壁として発見するかの違いだ。

役立つ捉え直しはこうだ。エージェント型のワークロードにとって、本当のスケーリング上限はリクエスト毎分ではなくトークン毎分である。ほとんどのチームは、デモでは問題なく動いていたエージェント群が実際のトラフィックでスロットリングされ始めるまで、それを腹に落とさない。今やその数字が見えるようになったのだから、サプライズではなくキャパシティ計画として扱うのが仕事だ。

Mantle とは何か、手短に

Bedrock の Mantle エンドポイント(bedrock-mantle)は、OpenAI Responses API、OpenAI Chat Completions API、Anthropic Messages API を Bedrock 上で提供してくれるものであり、それらのネイティブ API に対して書かれたコードへの変更は最小限で済む。これにより、既存の OpenAI 形式や Anthropic 形式の agent を、呼び出し箇所を書き直すことなく Bedrock に向けられる。今回のクォータの変更は、そのエンドポイントの背後にある各モデルが、入力 TPM と出力 TPM の上限を第一級の Service Quotas エントリとして報告するようになったことを意味する。

なぜエージェントにとっての上限は RPM ではなく TPM なのか

従来の API バックエンドのアプリは、ユーザー数におおよそ比例してトークンを消費する。1 リクエスト、1 レスポンス、予測可能なサイズ。注視すべきはリクエスト毎分の上限だ。

エージェント型のシステムはその比例関係を壊す。1 つのユーザータスクが扇状に広がる。プランナー agent がそれを分解し、サブエージェントを生成し、各サブエージェントがいくつものツール呼び出しを行い、各呼び出しがシステムプロンプト、蓄積されたコンテキスト、ツールスキーマ、そしてモデルの推論を再び持ち運ぶ。1 つのユーザーに見えるタスクの token コストは、1 プロンプトと 1 補完ではない。それは数十個分であり、しかもコンテキストはホップごとに膨らむ傾向がある。

したがってあなたの token 消費は、ユーザー数ではなくエージェント数 × ステップ数 × コンテキストサイズに比例してスケールする。どのリクエストレート上限にもまったく近づいていないのに、トークン毎分の上限を一気に突き抜けてしまうことがあり得る。なぜなら各リクエストが大きく、タスクごとにそれが多数あるからだ。これこそが、モデルごとの TPM の数値が注視すべきものであり、それが Service Quotas にあることが重要である理由だ。

障害のモード、順を追って

TPM のラインを越えると、Bedrock は ThrottlingException(HTTP 429)を返す。それ自体は問題ない。問題は、マルチエージェントシステムが次に何をするかだ。

  • スロットリングされた呼び出しが backoff 付きでリトライする。同じ分に同じモデルごとのクォータに当たった他の agent も同様だ。
  • リトライ自体が同じ上限に対する token 消費なので、負荷の高いエージェント群は自らをスロットリングし続けかねない。
  • 呼び出しが backoff タイマーの後ろにキューイングされるにつれてレイテンシが上昇する。8 秒で済んでいたタスクが 40 秒かかる、あるいはタイムアウトする。
  • 部分的な失敗が agent を不整合な状態に残す。プランナーはサブタスクが実行されたと考えているが、サブエージェントは出力のトークンを 1 つも受け取っていない。

これらのどれも、シングルユーザーの開発環境には現れない。なぜなら 1 人の開発者が上限に達するほどのトークン毎分を生み出すことは決してないからだ。現れるのは、実際の並行性が初めて到来したときであり、それは自分の上限を学ぶには最悪のタイミングだ。

出荷する前に token 予算をモデル化せよ

計算は難しくないし、インシデントによってではなく紙の上でやっておく価値がある。あるモデルについて、次を見積もる。

tokens_per_minute =
    concurrent_tasks
  × agents_per_task
  × model_calls_per_agent
  × avg_tokens_per_call        # input + output
  × (1 / task_duration_minutes)

そのうえで、入力と出力を別々に、今読み取れるようになった入力 TPM と出力 TPM のクォータと比較せよ。両者は独立して管理されており、エージェント型の出力(推論、長いツール引数)は過小評価しやすいからだ。予測した数値が、想定ピーク時のクォータのおよそ 70 パーセントを少しでも超えるところに位置するなら、それはヘッドルームがあるのではなく、日付の付いた将来のインシデントを抱えているということだ。

注視せよ、思い込むな

コンソールをクリックして回るのではなく、CLI から直接クォータを一覧できる。

aws service-quotas list-service-quotas \
  --service-code bedrock \
  --query "Quotas[?contains(QuotaName, 'tokens per minute')].[QuotaName,Value]" \
  --output table

それを CloudWatch の Bedrock 使用量メトリクスと組み合わせ、各モデルの TPM の 70 から 80 パーセントにアラームを設定せよ。目標は、金曜の夜にユーザーからではなく、火曜にダッシュボードから、上限に近づいていると知ることだ。

「もっとクォータをくれ」ではない緩和策

引き上げをリクエストするのは明白なレバーであり、ときには正しい。だが数字を上げても、token を無造作に消費するアーキテクチャは直らない。チケットを起票する前に。

  • コンテキストを刈り込め。最大のエージェント型 token の浪費は、全履歴とあらゆるツールスキーマをすべてのホップに引きずり込むことだ。そのステップが必要とするものだけを渡せ。
  • プロンプトをキャッシュせよ。安定したシステムプロンプトとツール定義は、どの呼び出しでも同じトークンだ。prompt caching はそれらをメーターから外す。
  • 並行性に上限を設けてキューイングせよ。モデルの前に有界なワーカープールを置けば、token のスパイクは、スロットリングの嵐ではなく、少し遅いが生き残るシステムに変わる。
  • 難易度でルーティングせよ。すべてのステップにフロンティアモデルが必要なわけではない。安価で機械的なステップは小さく安いモデルに送り、高価なモデルはそれに値する推論のために取っておけ。
  • 入力と出力の規律を分けよ。長い出力は独自のクォータで課金され、スロットリングされる。ステップごとの最大出力トークンに上限を設け、暴走した生成だけで出力 TPM を食い潰せないようにせよ。

引き上げをリクエストするとき

そのモデルの特定の入力 TPM または出力 TPM エントリに対して Service Quotas でリクエストを開き、上記の予算計算を携えていけ。楽観から抜き出した切りのいい数字ではなく、予測ピーク負荷とタスクごとの token 内訳を示せるとき、AWS は引き上げをより速く承認する。それをキャパシティリクエストとして扱え。実際それがそうなのだから。

要点

Mantle の token クォータを Service Quotas に表示することは、必要だが十分ではない。数字が見えることがあなたを守るわけではない。それはただ、その数字に驚かされることの言い訳がもう効かないという意味だ。エージェント型のシステムにとって、トークン毎分が荷重を支える上限であり、信頼できる agent を出荷するチームとは、その予算をモデル化し、監視し、AWS に上限の引き上げを頼む前に token 消費を設計で下げているチームだ。

次に読む

これを大規模に安全に運用するためのインフラとプラットフォームの側面については、クラウドのフィールドノートが ercan.cloud にある。agent が単独で決して実行すべきでない高リスクの操作のための multi-party approval も含まれる。AWS、AI、プラットフォーム業務のコンサルティングについて、あるいはただ挨拶するために、まずは ercanermis.com から始めてほしい。