Amazon Bedrock、RPM クォータとトークン制限の読み分けを明確化

Amazon Bedrock の クォータ ページでは、モデル推論の利用量がトークン使用量のクォータで制御されることに加え、bedrock-runtime と bedrock-mantle の2つの推論エンドポイントでクォータ配分が分かれることが説明されています。Bedrock で複数モデルや複数エンドポイントを運用するチームは、RPM だけを見て容量を判断しない方が安全です。

要点

• Bedrock のモデル推論は、トークン使用量に関するクォータで制御されます。
• bedrock-runtime と bedrock-mantle は、それぞれ別の モデル単位 クォータ配分を持つ推論エンドポイントとして説明されています。
• 同じ基盤モデルを呼び出しても、2つのエンドポイントへのトラフィックは別々のクォータとして扱われます。
• サービスクォータは AWS のクォータ管理コンソールまたは AWS General Reference で確認し、必要に応じて引き上げ申請を検討します。

今回の更新で変わること

今回の クォータ ページは、Bedrock の利用制限を「1分あたりリクエスト数」だけで読むと誤解が出やすいことを示しています。ページ本文では、AWSアカウントに Amazon Bedrock の既定クォータがあること、AWS のクォータ管理 で Amazon Bedrock を選んで確認できること、AWS General Reference の Bedrock サービスクォータを参照できることが説明されています。そのうえで、モデル推論はトークン使用量のクォータで制御され、モデルによってトークン消費の速度が異なるため、トークンの数え方や最適化も確認する必要があります。

特に重要なのは、bedrock-runtime と bedrock-mantle の扱いです。公式ページでは、Bedrock がこの2つの推論エンドポイントを提供し、それぞれが独自の モデル単位 クォータ配分を持つと説明しています。同じ基盤モデルを呼び出す場合でも、どちらのエンドポイントを使うかによってトラフィックの集計先が変わります。つまり、アプリケーションが複数のSDK、互換API、ワークロードを混在させている場合、実際の制限到達点は単一のRPM表だけでは判断できません。

運用面では、Bedrock を使うアプリケーションごとに、どのエンドポイントを使っているか、どのモデルを呼び出しているか、入力トークンと出力トークンのどちらが先に上限へ近づくかを分けて見る必要があります。高頻度のチャット、エージェントのツール呼び出し、バッチ推論、長文生成、互換API経由の移行ワークロードでは、リクエスト数よりもトークン量や並列度が制約になることがあります。スロットリングが起きた場合も、モデル固有のRPMなのか、入力/出力トークンなのか、エンドポイント別のクォータなのかを切り分けたいです。

Bedrock のクォータは、リージョン要因、支払い履歴、不正利用対策、クォータ引き上げ承認などによって更新される場合があると説明されています。したがって、本番前の負荷試験では、アカウントとリージョンごとの現行値を確認し、想定ピーク、リトライ、フォールバック、エージェントの連続呼び出しを含めた設計にする必要があります。クォータ引き上げ申請を行う場合も、単にRPMを増やすだけでなく、どのエンドポイントとどのモデルのどの制限を上げたいのかを明確にしておくと、運用判断がしやすくなります。

今回の更新が関係する人

Bedrock 上で生成AIアプリ、エージェント、互換API移行、バッチ推論を運用する開発チーム、SRE、クラウド基盤担当に関係します。複数モデルや複数エンドポイントを使い分けている組織では、特に確認したい更新です。

実務で確認したいポイント

• アプリケーションごとに bedrock-runtime と bedrock-mantle のどちらを使っているかを整理する。
• モデル別に、RPM、入力トークン、出力トークン、バッチや プロビジョンドスループット の制限を確認する。
• スロットリング時のリトライ、バックオフ、フォールバック、利用者向けエラー表示を決める。
• 負荷試験の結果をもとに、必要なクォータ引き上げ対象をエンドポイントとモデル単位で特定する。

結局、今回の更新をどう読むべきか

今回の更新は、Bedrock の容量設計をRPMだけで単純化しないための注意喚起です。Bedrock を本番利用するチームは、エンドポイント、モデル、トークン量、リクエスト数を分けて監視し、クォータ到達時の挙動まで運用手順に入れておきたいです。