スケーリングとスループットのベストプラクティス

このトピックでは、Amazon Bedrock エンドポイント全体でスループット制限とスケジューリングがどのように機能するかを説明し、生成 AI アプリケーションをスケーリングするためのベストプラクティスを提供します。

Amazon Bedrock エンドポイント

Amazon Bedrock は推論用に 2 つのエンドポイントをサポートしています。

ほとんどの新しいアプリケーションでは、 から始めますbedrock-runtime。サーバー側のツール、バックグラウンド推論、プロジェクト、ワークスペース、 でのみ使用可能なモデルなど、そのエンドポイントでのみ使用可能な機能bedrock-mantleが必要な場合は、 を使用しますbedrock-mantle。両方のエンドポイントを同じアプリケーションで使用できます。完全な比較については、「」を参照してくださいAmazon Bedrock でサポートされているエンドポイント。

2 つのエンドポイントの動作が異なる理由

どちらのエンドポイント表面も同じ基盤となる推論エンジンを使用しますが、クォータのアカウンティングと容量のオプションは異なります。 bedrock-runtimeはモデルごとのトークンクォータを使用し、一部のモデルでは 1 requests-per-minute数 (RPM) クォータを使用します。 bedrock-mantleは RPM クォータを適用せず、クォータを発行したモデルには個別の入力トークンクォータと出力トークンクォータを使用します。の他のモデルでは、Service Quotas でアカウントごとのクォータが公開されていないbedrock-mantle場合がありますが、スループットは引き続き内部サービス容量によって管理されます。

クォータは上限であり、すべてのオンデマンドリクエストがすぐに処理されることを保証するものではありません。需要が高い期間中は、リクエストをキューに入れるか、一時的な容量エラーを受け取ることができます。同時実行数の制限、キュー作業、および再試行サージを発生させずに一時的なエラーを再試行するようにアプリケーションを設計します。

bedrock-mantle エンドポイント: スループットとクォータ

bedrock-mantle エンドポイントには次のクォータ動作があります。

デフォルト値とアカウントの割り当ては、モデル、リージョン、使用履歴によって異なる場合があります。現在の値、クォータ評価の詳細、および引き上げをリクエストするための AWS サポートプロセスについては、「」を参照してくださいbedrock-mantle エンドポイントのクォータ。モデル固有のエンドポイント、サービス層、機能のサポートモデルの概要については、該当する を参照してください。

bedrock-runtime エンドポイント: スループットとクォータ

bedrock-runtime エンドポイントには次のクォータ動作があります。

現在のクォータ値、トークンのバーンダウンの詳細、およびクォータの増加プロセスについては、「」を参照してくださいbedrock-runtime エンドポイントのクォータ。モデル固有のエンドポイント、サービス層、機能のサポートモデルの概要については、該当する を参照してください。

HTTP エラーレスポンスについて

API 固有の原因と解決手順については、「」を参照してくださいAmazon Bedrock API エラーコードのトラブルシューティング。

推奨されるエラー処理

一時的なエラー

一時的なスロットリングや容量エラーなど、安全に再試行できるエラーのみを再試行します。サービスがRetry-Afterヘッダーを返す場合は、それを尊重します。それ以外の場合は、ランダムジッターを使用してエクスポネンシャルバックオフを実装します。

AWS SDKsと一般的な HTTP ライブラリは、このパターンの組み込みサポートを提供します。再試行設定名は異なります。botocore の には最初のリクエストtotal_max_attemptsが含まれますが、OpenAI と Anthropic SDKsは再試行のみmax_retriesカウントします。したがって、次の例では、異なる数値を使用して、同じサンプル 6-attempt 予算を提供します。

import boto3
from botocore.config import Config

config = Config(retries={"total_max_attempts": 6, "mode": "standard"})
client = boto3.client("bedrock-runtime", config=config)

from openai import OpenAI

client = OpenAI(
    api_key=api_key,
    base_url=f"https://bedrock-mantle.{region}.api.aws/v1",
    max_retries=5,
)

import anthropic

client = anthropic.Anthropic(
    api_key=api_key,
    base_url=f"https://bedrock-mantle.{region}.api.aws/anthropic",
    max_retries=5,
)

モデルとオペレーションの文書化された最大推論期間に基づいて、再試行とは別に接続タイムアウトと読み取りタイムアウトを設定します。有効な長時間実行される推論リクエストよりも短いタイムアウトは、回避可能な再試行や作業の重複を引き起こす可能性があります。

持続的なキャパシティエラー

永続的な 503 または 529 エラーが発生した場合、再試行だけで負荷が増大する可能性があります。サービスで一時的な容量の制約が発生しているか、ワークロードがモデルとリージョンで現在利用可能な容量を超えている可能性があります。次のステップを実行します。

スループットの向上

オンデマンド容量は、モデル、リージョン、時間によって異なる場合があります。クォータ内のすべてのリクエストが需要の高い期間に成功することが保証されるわけではないため、ワークロードの起動、モデルやリージョンの変更、または大規模なトラフィックの増加時に徐々に増加します。これは、アカウントごとのクォータが公開されていないbedrock-mantleモデルでは特に重要です。

推奨されるランプアップ手順

ワークロードのレイテンシーとトラフィックパターンからステップサイズと観測期間を選択します。RPM を唯一の制御シグナルとして使用しないでください。RPM が一定であっても、リクエストトークンのサイズとレスポンスの長さによって容量の消費量が大幅に変わる可能性があります。

bedrock-mantle クォータの引き上げについては、「」に従ってくださいクォータ引き上げのリクエスト。についてはbedrock-runtime、「」に従いますクォータ引き上げのリクエスト。

その他のベストプラクティス

リージョンの可用性とクロスリージョン推論

オンデマンド容量はリージョンごとに異なり、リージョンによって異なる場合があります。ワークロードが 1 つのリージョンをターゲットとしている場合、需要が高い時間帯に容量エラーが発生する可能性があります。ではbedrock-runtime、モデルとデータレジデンシー要件がモデルをサポートするグローバルクロスリージョン推論ときに を使用します。独自のリージョンフェイルオーバーを実装する場合は、すべてのターゲットリージョンでモデルの可用性を確認し、フェイルオーバーによってトラフィックが急増しないように、制限付き再試行を適用します。

ヘルプの利用

レコメンデーションの概要