Amazon Bedrock でのトークンのカウント方法 - Amazon Bedrock
トークンクォータ管理について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 Opus 4.1

  • Anthropic Claude Sonnet 4.5

  • Anthropic Claude Sonnet 4

  • Anthropic Claude 3.7 Sonnet

  • Anthropic Claude 3 Haiku 4.5

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

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

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

  • リクエストの開始時 – RPM クォータを超過していないと仮定して、次の合計がクォータから差し引かれます。クォータを超えると、リクエストはスロットリングされます。

    Total input tokens + max_tokens

  • 処理中 – リクエストによって消費されたクォータは、生成された出力トークンの実際の数を考慮して定期的に調整されます。

  • リクエストの終了時 – リクエストによって消費されたトークンの合計数は次のように計算され、未使用のトークンがあればクォータに補充されます。

    InputTokenCount + CacheWriteInputTokens + (OutputTokenCount x burndown rate)

    プロンプトキャッシュを使用しない場合、CacheWriteInputTokens は 0 になります。CacheReadInputTokens はこの計算には影響しません。

注記

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

例えば、Anthropic Claude Sonnet 4 を使用して、1,000 個の入力トークンを含むリクエストを送信し、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 マネジメントコンソール で以下を実行します。

  1. https://console.aws.amazon.com/cloudwatch で Amazon CloudWatch コンソールにサインインします。

  2. 左側のナビゲーションパネルで [ダッシュボード] を選択します。

  3. [自動ダッシュボード] タブを選択します。

  4. [Bedrock] を選択します。

  5. [モデル別のトークン数] ダッシュボードで、展開アイコンを選択します。

  6. ピーク使用量を考慮して、メトリクスの期間と範囲パラメータを選択します。

  7. [合計] とラベル付けされたドロップダウンメニューから、異なるメトリクスを選択してトークンの使用量を観察できます。これらのメトリクスを調べて、max_tokens 値の設定に関する決定をガイドします。