トークンクォータ管理について max_tokens パラメータの影響を理解する max_tokens パラメータの最適化

Amazon Bedrock でのトークンのカウント方法

モデル推論を実行する場合、使用する Amazon Bedrock モデルに応じて処理できるトークンの数にクォータがあります。トークンクォータに関連する次の用語を確認してください。

用語	定義
`InputTokenCount`	モデルへの入力として提供されたリクエスト内のトークンの数を表す CloudWatch Amazon Bedrock ランタイムメトリクス。
`OutputTokenCount`	リクエストに応じてモデルによって生成されたトークンの数を表す CloudWatch Amazon Bedrock ランタイムメトリクス。
`CacheReadInputTokens`	モデルによって再処理されるのではなく、キャッシュから正常に取得された入力トークンの数を表す CloudWatch Amazon Bedrock ランタイムメトリクス。プロンプトキャッシュを使用しない場合、この値は 0 です。
`CacheWriteInputTokens`	キャッシュに正常に書き込まれた入力トークンの数を表す CloudWatch Amazon Bedrock ランタイムメトリクス。プロンプトキャッシュを使用しない場合、この値は 0 です。
1 分あたりのトークン数 (TPM)	1 分間で使用できるトークンの数 (入力と出力の両方を含む) のモデルレベルで AWS によって設定されたクォータ。
1 日あたりのトークン数 (TPD)	1 日に使用できるトークンの数 (入力と出力の両方を含む) のモデルレベルで AWS によって設定されたクォータ。デフォルトでは、この値は TPM x 24 x 60 です。ただし、新しい AWS アカウントではクォータが削減されました。
1 分あたりのリクエスト数 (RPM)	1 分間に送信できるリクエスト数に対してモデルレベルで AWS によって設定されたクォータ。
`max_tokens`	モデルが生成できる出力トークンの最大量を設定するリクエストで指定するパラメータ。
バーンダウン率	入力トークンと出力トークンがスロットリングシステムのトークンクォータ使用量に変換されるレート。

次のモデルのバーンダウンレートは、出力トークンに対して 5 倍です (1 つの出力トークンはクォータから 5 つのトークンを消費します）。

Anthropic Claude Opus 4
Anthropic Claude Sonnet 4
Anthropic Claude 3.7 Sonnet

他のすべてのモデルでは、バーンダウンレートは 1:1 です (1 つの出力トークンはクォータから 1 つのトークンを消費します）。

トークンクォータ管理について

リクエストを行うと、トークンは TPM および TPD クォータから差し引かれます。計算は以下の段階で行われます。

リクエストの開始時に – RPM クォータを超えていないと仮定すると、次の合計がクォータから差し引かれます。クォータを超えると、リクエストはスロットリングされます。
```
Total input tokens + max_tokens
```
処理中 – リクエストによって消費されるクォータは、生成された出力トークンの実際の数を考慮して定期的に調整されます。
リクエストの最後に – リクエストによって消費されたトークンの合計数は次のように計算され、未使用のトークンはクォータに補充されます。
```
InputTokenCount + CacheWriteInputTokens + (OutputTokenCount x burndown rate)
```
プロンプトキャッシュを使用しない場合、は 0 CacheWriteInputTokensになります。この計算には影響CacheReadInputTokensしません。

注記

実際のトークン使用量に対してのみ課金されます。

たとえば、を使用して 1,000 個の入力トークンを含むリクエストAnthropicClaude Sonnet 4を送信し、100 個のトークンに相当するレスポンスを生成するとします。

1,500 トークン (1,000 + 100 x 5) が TPM および TPD クォータから枯渇します。
1,100 トークンに対してのみ請求されます。

max_tokens パラメータの影響を理解する

max_tokens 値は、各リクエストの開始時にクォータから差し引かれます。予想よりも早く TPM クォータに達している場合は、を小さくmax_tokensして完了のサイズに近づけてみてください。

次のシナリオでは、出力トークンのバーンダウン率が 5 倍であるモデルを使用して、完了したリクエストに対してクォータ控除がどのように機能したかの例を示します。

次のパラメータを想定します。

InputTokenCount: 3,000
CacheReadInputTokens: 4,000
CacheWriteInputTokens: 1,000
OutputTokenCount: 1,000
max_tokens: 32,000

次のクォータの控除が行われます。

リクエスト作成時の初回控除： 40,000 (= 3,000 + 4,000 + 1,000 + 32,000)
レスポンス生成後の最終調整済み控除： 9,000 (= 3,000 + 1,000 + 1,000 x 5)

このシナリオでは、 max_tokensパラメータの設定が高すぎるため、同時に実行できるリクエストが少なくなります。これにより、TPM クォータ容量にすばやく到達するため、リクエストの同時実行、スループット、クォータ使用率が低下します。

次のパラメータを想定します。

InputTokenCount: 3,000
CacheReadInputTokens: 4,000
CacheWriteInputTokens: 1,000
OutputTokenCount: 1,000
max_tokens: 1,250

次のクォータの控除が行われます。

リクエスト作成時の初回控除： 9,250 (= 3,000 + 4,000 + 1,000 + 1,250)
レスポンス生成後の最終調整済み控除： 9,000 (= 3,000 + 1,000 + 1,000 x 5)

このシナリオでは、最初の減算が最終調整済み減算よりもわずかに高いため、 max_tokensパラメータが最適化されました。これにより、リクエストの同時実行数、スループット、クォータ使用率が向上します。

max_tokens パラメータの最適化

max_tokens パラメータを最適化することで、割り当てられたクォータ容量を効率的に活用できます。このパラメータの決定を通知するために、Amazon CloudWatch を使用できます。Amazon CloudWatch は、Amazon Bedrock のトークン使用状況データなど、 AWS サービスからメトリクスを自動的に収集します。

トークンは InputTokenCountおよびOutputTokenCountランタイムメトリクスに記録されます (メトリクスの詳細については、「」を参照してくださいAmazon Bedrock ランタイムメトリクス。

CloudWatch モニタリングを使用して max_tokensパラメータの決定を通知するには、で以下を実行します AWS Management Console。

https://console.aws.amazon.com/cloudwatch で Amazon CloudWatch コンソールにサインインします。
左側のナビゲーションペインから、ダッシュボードを選択します。
自動ダッシュボードタブを選択します。
Bedrock を選択します。
モデル別のトークン数ダッシュボードで、展開アイコンを選択します。
ピーク使用量を考慮して、メトリクスの期間と範囲パラメータを選択します。
Sum というラベルのドロップダウンメニューから、さまざまなメトリクスを選択してトークンの使用状況を確認できます。これらのメトリクスを調べて、max_tokens値の設定に関する決定をガイドします。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

クォータ

Amazon Bedrock クォータの引き上げをリクエストする