Amazon Bedrock オンデマンドリソースの使用時に発生する "ThrottlingException" エラーのトラブルシューティング方法を教えてください。

簡単な説明

サービスクォータを超えると、Amazon Bedrock はリクエストを拒否します。

Amazon Bedrock は "ThrottlingException" (HTTP ステータスコード 429) エラーを返し、クライアント側には次のいずれかのエラーメッセージが表示されます。

• "Too many requests, please wait before trying again. You have sent too many requests. Wait before trying again."
• "Your request rate is too high. Reduce the frequency of requests."
• "Too many tokens, please wait before trying again."

解決策

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

AWS サービスクォータを監視する

Amazon Bedrock のサービスクォータを参照し、超過していないことを確認してください。スロットリングパターンを特定するために、Amazon CloudWatch メトリクスを 1 分間隔で確認してください。ピーク時に使用量がクォータを超えると、バッチが以前は正常に実行された場合もスロットリングが発生する可能性があります。アプリケーションのリクエスト量がクォータを超えないようにするには、Amazon Bedrock の実行時メトリクス InputTokenCount および Invocations を監視してください。

一部のモデルでは、Amazon Bedrock が同時に適用する 1 分あたりのリクエスト数 (RPM) と 1 分あたりのトークン数 (TPM) のクォータは、別々に設定されます。

新しいモデルバージョンでは、以前のバージョンとクォータが異なる場合があります。

**注:**サービスクォータダッシュボードには、設定されたクォータのみが表示され、リアルタイムの使用状況は表示されません。リアルタイムの使用状況を監視するには、CloudWatch を使用してください。

クロスリージョン推論プロファイルを使用する

クロスリージョン推論プロファイルを使用してトラフィックを複数の AWS リージョンに動的にルーティングすると、各リクエストの可用性を最適化し、使用率の高い期間のパフォーマンスを向上させることができます。各リージョンは、独立したキャパシティプールを維持します。単一リージョンでのキャパシティプールのスロットリングを回避するには、リクエストを複数のリージョンに分散してください。

Anthropic Claude 3.5 Sonnet などの一部のモデルでは、特定のリージョンに属するクロスリージョン推論プロファイルが必要です。

詳細については、GitHub のウェブサイト amazon-bedrock-workshop でクロスリージョン推論用のコード例を参照してください。

注: 推論プロファイルを使用するには、Amazon Bedrock がサポートするリージョンとモデルを使用する必要があります。

クォータの増加をリクエストする

新しいアカウントの初期クォータは、デフォルトクォータよりも低い場合があります。一部のモデルには、調整できない固定クォータが適用されます。ワークロードのトラフィックがアカウントのオンデマンドクォータを超えている場合は、AWS サポートまたはアカウントマネージャーにお問い合わせのうえ、クォータの増加をリクエストしてください。AWS は、使用パターンやサービス要件に基づいてデフォルトクォータを調整する場合があります。

リクエストには、次の情報を含めてください。

• 増加を希望するクォータの名前
• モデル ID
• クォータ増加の対象リージョン
• ユースケースの簡潔な説明
• 予測される使用量 (例: 安定時およびピーク時のトークン、1 分あたりのリクエスト数、リクエストあたりの平均入出力トークン)。

プロビジョンドスループットを使用する

スループット要件が高い場合は、プロビジョンドスループットを購入してください。

注: プロビジョンドスループットを使用すると、追加コストが発生します。プロビジョンドスループットの料金については、「Amazon Bedrock の料金」の料金モデルセクションを参照してください。

プロビジョンドスループットの使用方法に関する詳細は、「Amazon Bedrock リソースでプロビジョンドスループットを使用する」を参照してください。AWS CLI または Python SDK を使用してプロビジョンドスループットを作成する方法については、「プロビジョンドスループット用のコード例」を参照してください。

注: プロビジョンドスループットを購入する前に、Amazon Bedrockがサポートするリージョンとモデルを使用していることを確認してください。

エクスポネンシャルバックオフで再試行を追加する

オンデマンドモードを使用する場合、Amazon Bedrock は複数の顧客に対し、共有キャパシティプールを使用します。サービスの需要が高い時期には、リクエストがアカウントのクォータ以内の場合も、スロットリングが発生する可能性があります。なお、サービスはすべてのユーザーに対するキャパシティ割り当てを自動的に管理します。

エクスポネンシャルバックオフとランダムジッターを使用して再試行することをおすすめします。AWS SDK を使用する場合は、「再試行の動作」を参照してください。

再試行のバックオフが1 分あたりのクォータに達した際は、1 分間継続させる必要があります。再試行は、60 秒のクォータ更新サイクルと同期させてください。また、1 分の範囲内で、リクエストを複数の秒に分散させてください。

アダプティブ試行モードを使用する Python 設定の例:

from botocore.config import Config

config = Config(
    retries={
        'max_attempts': 10,  # Default is 3
        'mode': 'adaptive'
    }
)
bedrock_runtime = boto3.client('bedrock-runtime', config=config)

"ServiceUnavailable" エラーを解決する

"ServiceUnavailableException" (HTTP ステータスコード 503) エラーは、クォータ超過ではなく、一時的なキャパシティの制約が原因で発生します。通常、このエラーは自動的に解決しますが、重要なワークロードではアーキテクチャの調整が必要になる場合があります。

AWS CloudTrail ログを参照し、"ServiceUnavailable" エラーと "ThrottlingException" エラーが同時発生していないかを確認します。

両方のエラーが発生している場合は、次の手順を実行して "ServiceUnavailableException" エラーを解決します。

• AWS Health ダッシュボードでサービスの中断が発生していないか確認します。
• エクスポネンシャルバックオフとジッターを用いた再試行を実装します。
• CloudWatch Logs を使用して ](https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html) エラーと "ServiceUnavailableException" エラーを個別に[監視"ThrottlingException"します。
• クロスリージョン推論プロファイルを使用すると、あるリージョンが利用できない場合にトラフィックを他のリージョンに分散できます。

クォータ超過以外の予期しないスロットリングを解決する

スロットリングが発生したものの、サービスクォータを超えていない場合は、次の手順を実行してください。

• リージョナルサービスの正常性を確認します。
• アカウント固有の設定に関するトラブルシューティングについては、AWS サポートにお問い合わせください。