【要約】Bedrockのクオーターからrequests-per-minute (RPM)がなくなったらしい [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
従来のAmazon Bedrockのクォータ管理では、リクエストの回数（RPM）が制限の指標であった。しかし、LLMの計算負荷はリクエスト回数よりも、処理するトークン量に強く依存する。この乖離が、リソース管理上の課題となっていた。
- ・リクエスト回数のみでは、実際の計算負荷を正確に制御できない。
- ・短文リクエストの大量送信と、長文リクエストの少回数送信で負荷が異なる。
- ・インフラの負荷予測とクォータ設定の整合性が取りにくい。
// Approach
AWSは、リソース消費量に直結するトークン量による制御へと管理手法を移行させた。具体的には、主要なエンドポイントにおいて以下の変更を実施している。
- ・bedrock-runtimeエンドポイント：RPMクォータを廃止し、トークンベースの管理へ移行。
- ・bedrock-mantleエンドポイント：RPMクォータを適用せず、入力・出力トークン量のみで管理。
- ・管理指標の集約：スロットリング制御をトークン量に一本化する方針。
// Result
最新のモデルでは、RPM制限がなくなりTPM（Tokens Per Minute）のみの管理となる見通しである。筆者の検証により、モデルによって移行状況が異なることが判明した。
- ・Claude Sonnet 4.6：依然としてRPMクォータが存在する。
- ・Opus系の最新モデル（4.7等）：RPMがなくなり、TPMのみの管理となる傾向がある。
- ・今後の展望：新規モデルはTPM管理が標準化される可能性が高い。
Senior Engineer Insight
> LLMアプリケーションの設計思想を、リクエスト回数からトークン消費量へ転換すべきである。リクエスト頻度の設計は容易になるが、ペイロードのサイズに依存するスロットリングのリスクが高まる。特に長文生成を行う場合、TPM制限への抵触を予測したバッファリングや、リトライ戦略の高度化が不可欠となる。スケーラビリティの観点では、トークン消費の予測精度がシステムの安定性を左右する。モデルごとに制限の性質が異なる点にも注意が必要だ。