翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# スケーリングとスループットのベストプラクティス
このトピックでは、Amazon Bedrock エンドポイント全体でスループット制限とスケジューリングがどのように機能するかを説明し、生成 AI アプリケーションをスケーリングするためのベストプラクティスを提供します。
## Amazon Bedrock エンドポイント
Amazon Bedrock は推論用に 2 つのエンドポイントをサポートしています。
+ `bedrock-mantle.{region}.api.aws` — チャットの完了とレスポンス (OpenAI から）、およびメッセージ (Anthropic から) をサポートします。
+ `bedrock-runtime.{region}.amazonaws.com` — Bedrock ネイティブ APIs (呼び出しと会話）、チャット完了、メッセージ APIs をサポートします。
これらのエンドポイントとその選択方法の詳細については、「」を参照してください[Amazon Bedrock でサポートされているエンドポイント](endpoints.md)。
### 2 つのエンドポイントの動作が異なる理由
従来の多くのマルチテナントサービスでは、このアーキテクチャは、共有リソースへの公平な共有アクセスを管理するためにアカウントごとのクォータを中心に設計されています。これは、 で使用されるアプローチです[`bedrock-runtime`](endpoints.md)。
では[`bedrock-mantle`](endpoints.md)、別のアプローチが使用されます。このエンドポイントは、より高い初期スループット制限をサポートしながら公平な配分を実現する高度なスケジューリングとワークキューイングメカニズムで設計されています。また、この設計により`bedrock-mantle`、 はさまざまなモデルをホストし、モデルカタログ全体で利用できる幅広い機能を提供できます。ほとんどの場合、リクエストはすぐに処理されます。場合によっては、処理中のワークロードが完了し、スループットが利用可能になったときに、リクエストが一時的にキューに入れられることがあります。以下のセクションでは、これらのシナリオの処理方法について説明します。
## `bedrock-mantle` エンドポイント: スループットとクォータ
のすべてのモデルは、リージョンごとにアカウントごとに 10,000 RPM という単一のハード制限`bedrock-mantle`を共有します。Claude と他のモデルのスループットとクォータの動作には、次に示すようにいくつかの違いがあります。
| | Claude 4.7 以降 | 他のすべてのモデル |
| --- | --- | --- |
| 入力 TPM | 10M \* | 顧客ごとまたはモデルごとの TPM 制限なし |
| 出力 TPM | 2M | 顧客ごとまたはモデルごとの TPM 制限なし |
| RPM | 10,000 (このエンドポイントのすべてのモデルで共有) | 10,000 (このエンドポイントのすべてのモデルで共有) |
| オンデマンド階層 | 標準 | Standard、Priority、Flex (一部の例外) — 可用性については、モデルの詳細ページを参照してください。 |
| バッチ | いいえ | サポートされているモデルではあり — 可用性についてはモデルの詳細ページを参照してください |
| リザーブドキャパシティ | なし | なし |
\* 入力 TPM 制限は、Amazon Bedrock の使用履歴によって異なります。Amazon Bedrock コンソールの[クォー](https://console.aws.amazon.com/bedrock/home#/model-quotas)タページで、実際の割り当てを確認します。
## `bedrock-runtime` エンドポイント: スループットとクォータ
次の表は、 のスループットとクォータをまとめたものです`bedrock-runtime`。
| | Claude 4.7 以降 | 他のすべてのモデル |
| --- | --- | --- |
| 入力 TPM | 15M \* | 異なる \* |
| 出力 TPM | 入力 TPM との組み合わせ。バーンダウンが適用されます。 | なし。バーンダウンが適用されます。 |
| RPM | 10,000 (すべてのモデルで共有) | 異なる \* |
| オンデマンド階層 | 標準 | Standard、Priority、Flex (一部の例外) — 可用性については、モデルの詳細ページを参照してください。 |
| バッチ | いいえ | サポートされているモデルではあり — 可用性についてはモデルの詳細ページを参照してください |
| リザーブドキャパシティ | なし | リザーブド階層/プロビジョンドキャパシティ |
\* これらのモデルのクォータは使用量によって異なります。Amazon Bedrock コンソールの[クォー](https://console.aws.amazon.com/bedrock/home#/model-quotas)タページで割り当てを確認します。
## HTTP エラーレスポンスについて
HTTP 429
429 レスポンスは、アカウントの RPM 制限を超えたことを意味します。リクエストの送信レートを下げます。より高い RPM 割り当てが必要な場合は、[Service Quotas コンソール](https://console.aws.amazon.com/servicequotas/home)から引き上げをリクエストするか、 AWS アカウント チームにお問い合わせください。
HTTP 503
503 レスポンスは、このリージョンで Amazon Bedrock の需要が増加することを意味します。リクエストレートを下げてから、エクスポネンシャルバックオフで再試行するか、リージョン間でトラフィックを分散する必要があります。
## 推奨されるエラー処理
### 一時的なエラー (時折 503 レスポンス)
ランダムジッターを使用してエクスポネンシャルバックオフを実装します。
+ 短い遅延 (1 秒など) から開始します。
+ 試行が失敗するたびに遅延を 2 倍にします。
+ 再試行回数を 6 回に制限します。
AWS SDKsと一般的な HTTP ライブラリは、このパターンの組み込みサポートを提供します。
**Example (`bedrock-runtime`AWS SDK/boto3) の設定を再試行する**
```
import boto3
from botocore.config import Config
config = Config(retries={"total_max_attempts": 6, "mode": "standard"})
client = boto3.client("bedrock-runtime", config=config)
```
**Example (`bedrock-mantle`OpenAI SDK) の設定を再試行する**
```
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,
)
```
**Example (`bedrock-mantle`Anthropic SDK) の設定を再試行する**
```
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`](endpoints.md) エンドポイントでオンデマンドスループットを消費する場合、使用可能なスループットは時間の経過とともにスケールします。クォータ内のすべてのリクエストが需要の高い期間に成功することが保証されるわけではないため、徐々に増やすことが重要です。
### 推奨されるランプアップ手順
1. 500 RPM など、ターゲットリクエストボリュームから開始します。
1. 503 件のレスポンスを受け取った場合は、たとえば 50% のレートを下げます。
1. リクエストが一貫して成功する定常状態に達するまで、その割合を減らし続けます。
1. その定常状態を 15 分間保持します。
1. 例えば 50% のようにスループットを再度上げ、さらに 15 分間保持します。
1. ターゲットボリュームに到達するまで繰り返します。
たとえば、ターゲットが 2,000 RPM で、503 エラーが発生した場合は、 を 1,000 RPM に減らします。エラーが解決しない場合は、 を 500 RPM に減らします。リクエストが 500 RPM で一貫して成功したら、15 分間長押しし、750、1,125 などにスケールします。
ランプレートは調整できません。より高い RPM 割り当てをリクエストするには、[Service Quotas コンソール](https://console.aws.amazon.com/servicequotas/home)を使用します。
## その他のベストプラクティス
+ 機能フラグを使用して、すべてのトラフィックを一度に切り替えるのではなく、モデル間でトラフィックを徐々に移行します。
+ 大規模なワークロードを数分間に分散し、ピーク使用期間を避けるためにtime-of-dayパターンを検討します。
+ 小さなバッチでテストを開始し、徐々にスケールします。数千のテストリクエストを同時に送信することは避けてください。
+ 大規模なオフラインデータ処理では、アプリケーションが応答を非同期的に処理できる場合は、[Batch API](batch-inference.md) または [Flex Tier](service-tiers-inference.md) を使用します。
## リージョンの可用性とクロスリージョン推論
オンデマンドスループットはリージョンレベルで割り当てられ、リージョンによって異なります。ワークロードが 1 つのリージョンを対象とする場合、需要が高い期間に 503 件のレスポンスが発生する可能性があります。可用性を最大化し、 を使用している場合は[`bedrock-runtime`](endpoints.md)、 を使用します[グローバルクロスリージョン推論](global-cross-region-inference.md)。
## ヘルプの利用
+ **スループット計画** — スループット予測については AWS アカウント 、チームにお問い合わせください。スケーリングイベント中に 2 倍から 3 倍のピークスループットを計画します。
+ **パフォーマンスの最適化** — トークンの使用効率をモニタリングし、プロンプトを最適化してトークンの消費量を減らし、ユースケースの要件に基づいてモデルを選択します。
+ **サポートエスカレーション** — スループットの問題で AWS サポートケースを開くときは、特定のエラーコード、リクエスト IDs、トラフィックパターン (RPM/TPM)、スケーリングタイムラインを含めます。
## レコメンデーションの概要
| シナリオ | 推奨事項 |
| --- | --- |
| 一般的なワークロード | 可能な限り[`bedrock-mantle`エンドポイント](endpoints.md)を使用します。 |
| ときどき 503 エラーが発生する | エクスポネンシャルバックオフとジッターで再試行します。 |
| 持続的な 503 エラー | リクエストの送信レートを下げます。クライアント側のレート制限を実装します。 |
| 429 エラー | リクエストレートを下げます。[Service Quotas](https://console.aws.amazon.com/servicequotas/home) を使用してより高い RPM 割り当てをリクエストします。 |
| 大規模なオフライン処理 | Batch [API](batch-inference.md) または [Flex 階層](service-tiers-inference.md)を使用します。 |