スキップしてコンテンツを表示
AWS re:Postを使用することにより、以下に同意したことになります AWS re:Post 利用規約
AWS re:Postre:Post
re:Postに関して

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

所要時間2分
0

Amazon Bedrock オンデマンドリソースを使用すると、"ThrottlingException" (429 HTTP ステータスコード) エラーが発生するため、トラブルシューティングしたいと考えています。

簡単な説明

サービスクォータを超えると、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 分間隔で確認してください。ピーク時に使用量がクォータを超えると、バッチが以前は正常に実行された場合でもリソースのスロットリングが発生する可能性があります。アプリケーションのリクエスト量がクォータを超えないようにするには、InputTokenCount、Invocations、Amazon Bedrock のランタイムメトリクスを監視してください。

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

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

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

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

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

Anthropic Claude 3.5 Sonnet などの一部のモデルでは、特定のリージョンに属するクロスリージョン推論プロファイルが必要です。Anthropic Claude 4.5 Sonnet などのモデルには、予期しないトラフィックバーストの管理に役立つグローバル推論プロファイルも用意されています。

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

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

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

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

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

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

プロビジョニングされたスループットを使用する

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

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

プロビジョニングされたスループットの使用方法に関する詳細は、「Use a Provisioned Throughput with an Amazon Bedrock resource」(Amazon Bedrock リソースでプロビジョニングされたスループットを使用する) を参照してください。AWS CLI または Python SDK を使用してプロビジョニングされたスループットを作成する方法については、「Code examples for Provisioned Throughput」(プロビジョニングされたスループット用のコード例) を参照してください。

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

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

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

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

再試行のバックオフが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" エラーを解決する

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

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

両方のエラーが発生している場合は、次の手順で "ServiceUnavailable" エラーを解決してください。

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

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

トピック
Machine Learning & AIGenerative AI on AWS
タグ
Amazon Bedrock
言語
日本語
AWS公式更新しました 9ヶ月前
コメントはありません

関連するコンテンツ