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

# 容量とパフォーマンス
<a name="capacity-limits-cost-optimization"></a>

Amazon Bedrock には、ワークロードの要件と予算に合わせて柔軟な容量オプションが用意されています。オンデマンド階層 (Flex、Priority、Standard)、リザーブド階層、バッチ処理、クロスリージョン推論の違いを理解することで、パフォーマンスとコストの両方を最適化できます。

## キャパシティオプション
<a name="capacity-options"></a>


| キャパシティタイプ | ユースケース | 主な特徴 | 
| --- | --- | --- | 
| オンデマンド: Flex | 散発的で少量のワークロード |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/capacity-limits-cost-optimization.html)  | 
| オンデマンド: 標準 | 通常の本稼働ワークロード |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/capacity-limits-cost-optimization.html)  | 
| オンデマンド: Priority | 優先度が高くレイテンシーの影響を受けやすいアプリケーション |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/capacity-limits-cost-optimization.html)  | 
| 予約済み階層 | 一貫性のある大量のワークロード |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/capacity-limits-cost-optimization.html)  | 
| バッチ | 時間non-time-sensitive大規模な処理 |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/capacity-limits-cost-optimization.html)  | 
| クロスリージョン推論 | 高可用性、トラフィックバースト |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/capacity-limits-cost-optimization.html)  | 

## 制限とクォータ
<a name="limits-quotas"></a>

### オンデマンド制限 (階層別)
<a name="on-demand-limits"></a>


| Tier | RPM 範囲 | TPM 範囲 | スロットリングリスク | 
| --- | --- | --- | --- | 
| Flex | 10-100 | 5K-50K | 高 | 
| 標準 | 100-500 | 50K-150K | 中 | 
| 優先度 | 500-1000\+ | 150K-300K 以上 | 低 | 
+ バースト容量: ショートスパイクですべての階層で使用可能
+ ソフト制限: サービスクォータリクエストを介して増加可能
+ モデル固有: 実際の制限は基盤モデルによって異なります

### リザーブド階層の制限
<a name="reserved-tier-limits"></a>
+ 最小コミットメント: 1 モデルユニット
+ 最大単位: アカウントとリージョン固有
+ 入出力トークンの制限: 購入単位に基づく
+ 購入した容量内に RPM スロットリングがない

### バッチ処理の制限
<a name="batch-processing-limits"></a>
+ ジョブサイズ: バッチあたり最大 10,000 レコード
+ ファイルサイズ: 最大 200 MB の入力ファイル
+ 処理時間: 24 時間完了ウィンドウ
+ 同時ジョブ: リージョン固有のクォータ

### クロスリージョン推論
<a name="cross-region-inference-limits"></a>
+ リージョンごとにオンデマンド階層制限を継承します
+ 追加のクォータオーバーヘッドなし
+ 自動ルーティング (手動制限管理なし)

## 階層の選択
<a name="cost-optimization"></a>

### 決定フレームワーク
<a name="decision-framework"></a>


| シナリオ | 推奨オプション | なぜ | 
| --- | --- | --- | 
| 開発/テスト | Flex | 最低コスト、非本番環境でも許容可能 | 
| 標準本番稼働 | 標準 | 最高のコストパフォーマンスバランス | 
| 重要なユーザー向けアプリケーション | 優先度 | コストに対する信頼性とパフォーマンス | 
| 大量の負荷が安定している | 予約済み階層 | コミットメントによる 30～50% の節約 | 
| 一括データ処理 | バッチ | 50% 割引、緊急ではないワークロード | 
| ミッションクリティカルな稼働時間 | クロスリージョン推論 | 可用性 > コスト | 

### 最適化戦略
<a name="optimization-strategies"></a>

**適切なオンデマンド階層を選択する**
+ ほとんどのワークロードで Standard から開始する
+ 開発/テスト環境の Flex にダウングレードする
+ スロットリングがユーザーに影響する場合にのみ Priority にアップグレードする
+ CloudWatch スロットルメトリクスをモニタリングして決定事項を通知する

**リザーブド階層への移行**
+ 一貫した負荷がオンデマンドコストの 40% を超える場合
+ 損益分岐点を計算する: (毎月のオンデマンドコスト) と (予約済みコミットメント)
+ 最初に 1 か月のコミットメントを使用する
+ 予約済み階層は、任意のオンデマンド階層と連携できます。

**にバッチを使用する**
+ トレーニングデータ生成
+ コンテンツモデレーションバックログ
+ レポートの生成
+ データエンリッチメントパイプライン

**アプローチを組み合わせる**
+ ベースライントラフィックの予約済み階層
+ 中程度のバーストの標準オンデマンド
+ 重要なピーク期間のオンデマンドの優先度
+ オフライン処理用のバッチ
+ フェイルオーバーのみのクロスリージョン

**コストモニタリング**
+ 階層コストの比較: Flex < Standard < Priority
+ リクエストごとにトークンを追跡する (プロンプトを最適化)
+ CloudWatch メトリクスの使用とスロットリング
+ 予期しないスパイクに対する請求アラームを設定する
+ リザーブド階層の使用を毎月確認する
+ スロットリングが発生した場合にのみ階層のアップグレードを評価する