翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# スケーリングとスループットのベストプラクティス
<a name="scaling-throughput-best-practices"></a>

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

## Amazon Bedrock エンドポイント
<a name="scaling-endpoints"></a>

Amazon Bedrock は推論用に 2 つのエンドポイントをサポートしています。
+ `bedrock-mantle.{region}.api.aws` — OpenAI 互換の Chat Completions and Responses APIs、および Anthropic Messages API をサポートします。
+ `bedrock-runtime.{region}.amazonaws.com` — Bedrock ネイティブの InvokeModel および Converse APIs、OpenAI 互換の Chat Completions and Responses APIs、および Anthropic Messages API をサポートします。

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

### 2 つのエンドポイントの動作が異なる理由
<a name="scaling-endpoint-differences"></a>

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

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

## `bedrock-mantle` エンドポイント: スループットとクォータ
<a name="scaling-mantle-quotas"></a>

`bedrock-mantle` エンドポイントには次のクォータ動作があります。
+ クォータが公開されているモデルには、モデルごと、リージョンごとのinput-tokens-per-minute、output-tokens-per-minuteォータがあります。
+ エンドポイントは RPM クォータを適用しません。同じ RPM を持つ 2 つのワークロードは、非常に異なる容量を消費できるため、RPM のみではなく、トークンと同時実行数による計画とレート制限があります。
+ リクエストが承認されると、入力トークンチェックには入力トークンとリクエストされた`max_tokens`値が含まれます。レスポンスが完了すると、その予約の未使用部分が補充されます。アプリケーションのニーズ以上に設定`max_tokens`しないでください。
+ TPM クォータが公開されていないモデルでは、現時点では Service Quotas でアカウントごとの TPM クォータが公開されていません。これはスループットが無制限であることを意味するわけではありません。内部サービス容量と一時的なレート制限は引き続き適用されます。
+ バッチ推論とプロビジョンドスループットは、 を通じてのみ使用できます`bedrock-runtime`。サービス階層とモデルのサポートはモデルによって異なります。

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

## `bedrock-runtime` エンドポイント: スループットとクォータ
<a name="scaling-runtime-quotas"></a>

`bedrock-runtime` エンドポイントには次のクォータ動作があります。
+ モデルごと、リージョンごとのトークンクォータは、入出力トークンを一緒にカウントします。出力トークンは、モデル固有のバーンダウンレートに従ってクォータを消費します。
+ RPM クォータを持つモデルもあれば、トークンクォータによってのみ管理されるモデルもあります。使用する正確なモデルと推論プロファイルに適用されるクォータを確認します。
+ 1 分あたりのトークンクォータと 1 日あたりのトークンクォータは、このエンドポイントで同じモデルを呼び出す推論 APIs 間で共有されます。`bedrock-runtime` と の割り当て`bedrock-mantle`は独立しています。
+ カスタム推論プロファイル、バッチ推論、プロビジョンドスループットには個別のクォータがあり、 を通じてのみ使用できます`bedrock-runtime`。

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

## HTTP エラーレスポンスについて
<a name="scaling-http-errors"></a>

HTTP 429  
429 レスポンスは、リクエストが受け入れられなかったことを意味します。HTTP ステータスのみに依存するのではなく、API 固有のエラータイプを検査します。`ThrottlingException` または rate-limit エラーは通常、リクエストがアカウントクォータまたはサービスレート制限を超えたことを意味します。一部のランタイムオペレーションでは、 に HTTP 429 も使用されます`ModelNotReadyException`。で`bedrock-mantle`、入出力 TPM の使用状況とリクエスト`max_tokens`の値を確認します。エンドポイントには RPM クォータがありません。で`bedrock-runtime`、モデルに RPM クォータがあるかどうか、トークンクォータと RPM の組み合わせを確認します。

HTTP 503  
503 レスポンスは、需要が高いか容量の制約により、サービスが一時的にリクエストを処理できないことを意味します。アカウントクォータを超えたことを示すものではありません。エクスポネンシャルバックオフとジッターを使用して一時的なレスポンスを再試行します。レスポンスが持続する場合は、トラフィックの増加を停止し、同時実行数を減らし、サポートされている場合は別のリージョンまたはクロスリージョン推論を検討してください。

HTTP 529 (`overloaded_error`)  
一部のモデル APIs は、需要が高いか、サービング容量が不足しているため、モデルが一時的にリクエストを処理できない場合に 529 を返します。一時的な容量エラーとして扱います。レスポンスに`Retry-After`ヘッダーが含まれている場合は、少なくともその期間待ってから再試行し、クライアントが同時に再試行しないようにジッターを追加します。

API 固有の原因と解決手順については、「」を参照してください[Amazon Bedrock API エラーコードのトラブルシューティング](troubleshooting-api-error-codes.md)。

## 推奨されるエラー処理
<a name="scaling-error-handling"></a>

### 一時的なエラー
<a name="scaling-transient-errors"></a>

一時的なスロットリングや容量エラーなど、安全に再試行できるエラーのみを再試行します。サービスが`Retry-After`ヘッダーを返す場合は、それを尊重します。それ以外の場合は、ランダムジッターを使用してエクスポネンシャルバックオフを実装します。
+ 短い遅延 (1 秒など) から開始します。
+ 再試行するたびに遅延を増やし、アプリケーションのレイテンシーバジェットに合わせて最大遅延を制限します。
+ ランダムジッターを追加し、ワーカー間での同期された再試行を回避します。
+ アプリケーションのレイテンシー目標に合った制限付き再試行予算を使用します。たとえば、 オペレーションを最初のリクエストと最大 5 回の再試行の 6 回まで制限します。

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

**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=5,
)
```

**Example (`bedrock-mantle`Anthropic SDK) の設定を再試行する**  

```
import anthropic

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

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

### 持続的なキャパシティエラー
<a name="scaling-sustained-errors"></a>

永続的な 503 または 529 エラーが発生した場合、再試行だけで負荷が増大する可能性があります。サービスで一時的な容量の制約が発生しているか、ワークロードがモデルとリージョンで現在利用可能な容量を超えている可能性があります。次のステップを実行します。
+ ランプを停止し、最後の安定したリクエストレートと同時実行レベルに戻ります。
+ 制限付きクライアント側の同時実行数、レート制限、リクエストキューを使用します。
+ キャパシティが回復するまで、優先度の低いリクエストを延期または拒否します。
+ では`bedrock-runtime`、モデルがサポートしている場合にクロスリージョン推論を使用します。予測可能で持続的なワークロードについては、[プロビジョンドスループット](prov-throughput.md)を評価します。
+ 問題が解決しない場合は、 AWS ヘルスダッシュボードを確認し、リクエスト IDs と UTC タイムスタンプを使用して AWS サポートにお問い合わせください。

## スループットの向上
<a name="scaling-ramp-up"></a>

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

### 推奨されるランプアップ手順
<a name="scaling-ramp-procedure"></a>

1. 各エンドポイント、モデル、リージョンのターゲットトークンレートと同時実行数を見積もります。の場合`bedrock-mantle`、入力トークンと出力トークンを個別に追跡し、入力トークンアドミッションの見積もりにリクエストされた`max_tokens`値を含めます。

1. ターゲットより下の既知の安定したベースラインから開始します。ベースラインがない場合は、ターゲットボリューム全体を送信するのではなく、小さな代表的な負荷から始めます。

1. 各レベルは、リクエストの成功、429/503/529 エラー、レイテンシーパーセンタイル、トークンの消費、同時実行、キューの深さを観察するのに十分な時間保持します。

1. 一度に 1 つの制御ステップを増やします。リグレッションの原因を特定できるように、一度に 1 つの主要な負荷ディメンションのみを変更します。

1. スロットリング、容量エラー、またはレイテンシーがしきい値を超えた場合は、ランプを一時停止し、`Retry-After`ヘッダーを尊重し、最後の安定したレベルに戻ります。

1. ターゲットに到達するまで続行し、本番トラフィックを受信するすべてのモデルとリージョンについて検証を繰り返します。

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

`bedrock-mantle` クォータの引き上げについては、「」に従ってください[クォータ引き上げのリクエスト](quotas-mantle.md#quotas-mantle-increase)。については`bedrock-runtime`、「」に従います[クォータ引き上げのリクエスト](quotas-runtime.md#quotas-runtime-increase)。

## その他のベストプラクティス
<a name="scaling-additional-best-practices"></a>
+ 機能フラグを使用して、すべてのトラフィックを一度に切り替えるのではなく、モデル間でトラフィックを徐々に移行します。
+ 大規模なワークロードを数分間に分散し、ピーク使用期間を避けるためにtime-of-dayパターンを検討します。
+ 入力サイズ、出力サイズ、レイテンシー、同時実行数の代表的な分布を使用してテストします。テストリクエストの突然のバーストを送信しないでください。
+ トークン対応のクライアント側のレート制限、境界付き同時実行数、および境界付きキューを使用します。RPM 専用リミッターは、リクエストサイズの変更から保護しません。
+ 非同期で大量のオフラインジョブの場合は、 で[バッチ推論](batch-inference.md)を使用します`bedrock-runtime`。
+ サポートされているモデルと、可変レイテンシーを許容できるnon-time-sensitiveリクエストについては、[Flex サービス層](service-tiers-inference.md)を検討してください。

## リージョンの可用性とクロスリージョン推論
<a name="scaling-regional-availability"></a>

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

## ヘルプの利用
<a name="scaling-getting-help"></a>
+ **スループット計画** — 各モデルとリージョンのピーク入出力トークン、応答レイテンシー、同時実行数、キューイング許容値を推定します。ワークロード固有のヘッドルームを含め、大規模またはビジネスクリティカルなローンチについては AWS アカウント チームにお問い合わせください。
+ **パフォーマンスの最適化** — サポートされている場合は、プロンプトサイズ、生成されたトークン`max_tokens`、、レイテンシーパーセンタイル、キャッシュ使用状況をモニタリングします。プロンプトと出力制限を最適化して、不要なトークンの予約や消費を回避します。
+ **サポートエスカレーション** — AWS サポートケースを開くときは、エンドポイント、リージョン、モデルまたは推論プロファイル ID、HTTP ステータスと API エラータイプ、リクエスト IDs、UTC タイムスタンプ、トークンレート、リクエストレート、同時実行数、スケーリングタイムラインを含めます。

## レコメンデーションの概要
<a name="scaling-summary"></a>


| シナリオ | 推奨事項 | 
| --- | --- | 
| 一般的なワークロード | 「bedrock-runtime」から開始してください。これを必要とする機能またはモデルbedrock-mantleに を使用します。「[Amazon Bedrock でサポートされているエンドポイント](endpoints.md)」を参照してください。 | 
| 一時的な 429、503、または 529 エラー | API エラータイプを検査します。再試行可能なエラーの場合は、エクスポネンシャルバックオフとジッターRetry-Afterを使用して、制限された再試行予算内で優先して再試行します。 | 
| 持続的なキャパシティエラー | ランプを停止し、最後の安定したレベルに戻り、同時実行とキューをバインドして、優先度の低い作業を延期し、サポートされている場合はクロスリージョン推論を使用します。 | 
| クォータ計画 | には個別の入力 TPM と出力 TPM を使用しますbedrock-mantle。に該当する場合は、トークンクォータ、トークンのバーンダウン、RPM を組み合わせて使用しますbedrock-runtime。 | 
| 大規模なオフライン処理 | 非同期ジョブには[バッチ推論](batch-inference.md)を使用します。可変レイテンシーを許容できる、時間的non-time-sensitiveリクエストには、[Flex サービス層](service-tiers-inference.md)を使用します。 |