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

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

Amazon Bedrock エンドポイント

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

これらのエンドポイントとその選択方法の詳細については、「」を参照してくださいAmazon Bedrock でサポートされているエンドポイント。

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

従来の多くのマルチテナントサービスでは、このアーキテクチャは、共有リソースへの公平な共有アクセスを管理するためにアカウントごとのクォータを中心に設計されています。これは、 で使用されるアプローチですbedrock-runtime。

ではbedrock-mantle、別のアプローチが使用されます。このエンドポイントは、より高い初期スループット制限をサポートしながら公平な配分を実現する高度なスケジューリングとワークキューイングメカニズムで設計されています。また、この設計によりbedrock-mantle、 はさまざまなモデルをホストし、モデルカタログ全体で利用できる幅広い機能を提供できます。ほとんどの場合、リクエストはすぐに処理されます。場合によっては、処理中のワークロードが完了し、スループットが利用可能になったときに、リクエストが一時的にキューに入れられることがあります。以下のセクションでは、これらのシナリオの処理方法について説明します。

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

のすべてのモデルは、リージョンごとにアカウントごとに 10,000 RPM という単一のハード制限bedrock-mantleを共有します。Claude と他のモデルのスループットとクォータの動作には、次に示すようにいくつかの違いがあります。

* 入力 TPM 制限は、Amazon Bedrock の使用履歴によって異なります。Amazon Bedrock コンソールのクォータページで、実際の割り当てを確認します。

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

次の表は、 のスループットとクォータをまとめたものですbedrock-runtime。

* これらのモデルのクォータは使用量によって異なります。Amazon Bedrock コンソールのクォータページで割り当てを確認します。

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

推奨されるエラー処理

一時的なエラー (時折 503 レスポンス)

ランダムジッターを使用してエクスポネンシャルバックオフを実装します。

AWS SDKsと一般的な HTTP ライブラリは、このパターンの組み込みサポートを提供します。

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=6,
    timeout=60.0,
)

import anthropic

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

持続的なエラー (永続的な 503 レスポンス)

持続的な 503 エラーが発生した場合、単独で再試行しても問題は解決されません。リクエストレートが使用可能なスループットを超えています。次のステップを実行します。

スループットの向上

bedrock-mantle エンドポイントでオンデマンドスループットを消費する場合、使用可能なスループットは時間の経過とともにスケールします。クォータ内のすべてのリクエストが需要の高い期間に成功することが保証されるわけではないため、徐々に増やすことが重要です。

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

たとえば、ターゲットが 2,000 RPM で、503 エラーが発生した場合は、 を 1,000 RPM に減らします。エラーが解決しない場合は、 を 500 RPM に減らします。リクエストが 500 RPM で一貫して成功したら、15 分間長押しし、750、1,125 などにスケールします。

ランプレートは調整できません。より高い RPM 割り当てをリクエストするには、Service Quotas コンソールを使用します。

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

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

オンデマンドスループットはリージョンレベルで割り当てられ、リージョンによって異なります。ワークロードが 1 つのリージョンを対象とする場合、需要が高い期間に 503 件のレスポンスが発生する可能性があります。可用性を最大化し、 を使用している場合はbedrock-runtime、 を使用しますグローバルクロスリージョン推論。

ヘルプの利用

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