Amazon Bedrockにおける Claude Opus 4 / Claude Sonnet 4 利用時に気をつけるべきクォータ制限

どうも、AWS 大好き芸人の @ken11 です。
Bedrock 、使ってますか？ちょっと前に Anthropic から Claude の 4 系が発表されましたが、さすがにBedrockではすぐサポートされていたので感動しました。 Cross-Region Inference の力もあって、よくある「東京待ち」をしなくてよいのもとても助かりますね。

さて、そんな Bedrock における Claude 4 系の推論ですが、 1 点いままでの 3.7 や 3.5 とは異なる気をつけないといけないポイントがあります。

TL;DR
Claude Opus 4 / Sonnet 4 では「出力トークン × 5」でクォータ (TPM) を消費します。
デフォルト TPM が 200 k でも出力が多いケースでは 実質的に約 40 k 出力トークン/分 が上限。
max_tokens を大きくし過ぎると即 429 になるので要注意。

バーンダウンレートとは

A burndown rate is a ratio that converts the input and output tokens to token quota usage by the throttling system.
This ratio represents the rate at which input and output tokens count toward the token quotas.
—  AWS Quotas for Amazon Bedrock

Bedrock を含む基盤モデルを提供しているサービスには 入力 / 出力トークン と クォータ (TPM, TPD) = “使ったトークン数” の換算係数として “バーンダウンレート” と呼ばれるものがあります。（あくまでクォータ制限の話で、料金計算はまた別）
通常は 1 : 1 の比率（1 token → 1 quota） なのであまり意識することがありませんが、先般リリースされた Anthropic の Claude 4 系では Bedrock では（たぶん）初めてとなる非等価レートが適用されています。

Claude Opus 4 / Claude Sonnet 4 で適用された non‑standard token burndown rates

先般リリースされたこの 2 モデルについてはバーンダウンレートが 1 : 5 となっており、出力 1 token が 5 token 相当で TPM を消費 します。
出力時は 5 倍の速さでクォータを消費するということになるので、入力が多く出力が少ないユースケースでは気にならないかもしれませんが、 出力の多いユースケースでは想定よりかなり早くクォータ制限を迎える 可能性があります。

1 : 5 が意味するところ

• TPM 200 k → 実効 40 k 出力トークン/分
• RPM は 200 req/min と大きいが、ユースケース次第ではトークン総量が先に枯渇 しやすい

max_tokens の予約にも注意

また、 max_tokens の指定にも気をつける必要があります。

We use the max_tokens value specified in the API request to estimate the output burndown toward token quotas when we receive your request… —  AWS Quotas for Amazon Bedrock

ドキュメントではこのように書かれており、実際には次のフローでトークン消費量が計測されます。

• リクエスト受付時に max_tokens × 5 を 消費仮押さえ
• 応答完了後に 実際の出力 × 5 へ精算（差分が返却）

実際の例を見てみましょう

計算例

• TPM = 200,000
• リクエスト①: max_tokens = 20,000
  • 予約 = 20,000 × 5 = 100,000
• リクエスト②: max_tokens = 30,000 (同時実行)
  • 予約 = 30,000 × 5 = 150,000
• 合計 250,000 > 200,000 により ②が 429。
  • ①が完了し、実際の出力が 10,000 token だった場合
    • 精算後に返却 = (20,000 − 10,000) × 5 = 50,000
    • 残量が 50,000 回復した瞬間に ②を再送すれば通る。

ポイント

• max_tokens を実際より大きくすると「仮押さえ」で枯渇しやすい
• 同時実行数 × 5 × max_tokens が TPM を超えないように設計する

対策

では実際にはどのように対策するのがよいでしょうか。 max_tokens を大きく設定せず、適切な値にしておくということはもちろん重要ですが、実際のワークロードにおいては安全マージンを考えて大きめに設定したいことが多いのではないでしょうか。
本質的な対策は通常の設計と同じくリクエスト数を調整することが主になると考えられます。

• ワークロードで平均的に消費するトークン数を見積もる
• 200,000 / ( 1 で見積もった値 × 5 ) を計算し、おおよそ 1 分間にリクエスト可能な数を見積もる
• rate limiter などで 2 の値を超えないように 1 分間のリクエスト数を調整する

このように、通常の設計時より5倍消費する想定で見積もっておくことが重要だと考えます。（身も蓋もない）
実際にこれで計算してみると夢も希望もなく、かなり限定的にしか使えないなという気持ちになる可能性もあるのですが、不安定なサービス提供をするよりもよいでしょう。

まとめ

Claude Sonnet 4 は 3.7 や 3.5 から料金が据え置きだったこともあり、「デメリットが無いならすぐに最新版に乗り換えよう」という気持ちになりますが、今回触れたように実はクォータにおいて過去の 3 系とは大きく異なる制限が存在します。
出力の多いワークロードでは実際に計算してみるといろいろ厳しい結末もあり、まだまだ 3.7 / 3.5 は現役だなあという印象です。

AI を実サービスに適用する際は、このようなクォータ制限などの細部で本当に実リクエスト数などと見合うかどうか、などを考えることがとても重要です。
やはり新しいモデルが出てくると、新しいモデルを使いたくなるものですが、サービスの安定稼働と向き合って適切なものを選択することを忘れないようにしましょう。

グリーエックスでは日々 AI 活用を爆速で進めているところなので、このような AI 活用に興味がある方のご応募をお待ちしています！

👉 [採用情報はこちら]