本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 擴展和輸送量最佳實務
<a name="scaling-throughput-best-practices"></a>

本主題說明輸送量限制和排程如何跨 Amazon Bedrock 端點運作，並提供擴展生成式 AI 應用程式的最佳實務。

## Amazon Bedrock 端點
<a name="scaling-endpoints"></a>

Amazon Bedrock 支援兩個端點進行推論：
+ `bedrock-mantle.{region}.api.aws` — 支援聊天完成和回應 （來自 OpenAI) 和訊息 （來自 Anthropic)。
+ `bedrock-runtime.{region}.amazonaws.com` — 支援 Bedrock 原生 APIs（調用和轉換）、聊天完成和訊息 APIs。

如需這些端點以及如何在這些端點之間進行選擇的詳細資訊，請參閱 [Amazon Bedrock 支援的端點](endpoints.md)。

### 為什麼兩個端點的行為不同
<a name="scaling-endpoint-differences"></a>

在許多傳統多租戶服務中， 架構的設計是以每個帳戶配額為中心，以管理共用資源的公平共用存取。這是與 搭配使用的方法[`bedrock-runtime`](endpoints.md)。

使用 時[`bedrock-mantle`](endpoints.md)，會使用不同的方法。此端點的架構具有進階排程和工作佇列機制，可提供公平共用分佈，同時支援更高的初始輸送量限制。此設計也允許 `bedrock-mantle`託管廣泛的模型，並提供模型目錄中可用的完整功能範圍。在大多數情況下，會立即提供請求。在某些情況下，當傳輸中的工作負載完成且輸送量變為可用時，請求可能會短暫排入佇列。以下各節說明如何處理這些案例。

## `bedrock-mantle` 端點：輸送量和配額
<a name="scaling-mantle-quotas"></a>

上的所有模型`bedrock-mantle`共用每個區域每個帳戶 10，000 RPM 的單一硬性限制。Claude 與其他模型的輸送量和配額行為有一些差異，如下所示。


|   | Claude 4.7\+ | 所有其他模型 | 
| --- | --- | --- | 
| 輸入 TPM | 10M \* | 沒有每個客戶或每個模型的 TPM 限制 | 
| 輸出 TPM | 2M | 沒有每個客戶或每個模型的 TPM 限制 | 
| RPM | 10，000 （在此端點上的所有模型之間共用） | 10，000 （在此端點上的所有模型之間共用） | 
| 隨需方案 | 標準 | 標準、優先、彈性 （某些例外狀況） — 請參閱模型詳細資訊頁面以取得可用性 | 
| 批次 | 否 | 是，適用於支援的模型 — 請參閱模型詳細資訊頁面以取得可用性 | 
| 預留容量 | 無 | 無 | 

\* 您的輸入 TPM 限制取決於 Amazon Bedrock 的使用歷史記錄。檢查 Amazon Bedrock 主控台中的[配額](https://console.aws.amazon.com/bedrock/home#/model-quotas)頁面，了解實際配置。

## `bedrock-runtime` 端點：輸送量和配額
<a name="scaling-runtime-quotas"></a>

下表摘要說明 的輸送量和配額`bedrock-runtime`。


|   | Claude 4.7\+ | 所有其他模型 | 
| --- | --- | --- | 
| 輸入 TPM | 15M \* | 不同 \* | 
| 輸出 TPM | 結合輸入 TPM。套用爆量。 | 無。套用爆量。 | 
| RPM | 10，000 （跨所有模型共用） | 不同 \* | 
| 隨需方案 | 標準 | 標準、優先、彈性 （某些例外狀況） — 請參閱模型詳細資訊頁面以取得可用性 | 
| 批次 | 否 | 是，適用於支援的模型 — 請參閱模型詳細資訊頁面以取得可用性 | 
| 預留容量 | 無 | 預留層/佈建容量 | 

\* 這些模型的配額會根據用量而有所不同。檢查 Amazon Bedrock 主控台中的[配額](https://console.aws.amazon.com/bedrock/home#/model-quotas)頁面，了解您的配置。

## 了解 HTTP 錯誤回應
<a name="scaling-http-errors"></a>

HTTP 429  
429 回應表示您已超過帳戶的 RPM 限制。降低您的請求提交率。如果您需要較高的 RPM 配置，請透過 [Service Quotas 主控台](https://console.aws.amazon.com/servicequotas/home)請求增加，或聯絡 AWS 帳戶 您的團隊。

HTTP 503  
503 回應表示此區域對 Amazon Bedrock 的需求增加。您應該降低請求率，然後以指數退避重試，或將流量分散到各個區域。

## 建議的錯誤處理
<a name="scaling-error-handling"></a>

### 暫時性錯誤 （偶爾 503 回應）
<a name="scaling-transient-errors"></a>

使用隨機抖動實作指數退避：
+ 從短暫延遲開始 （例如 1 秒）。
+ 每次失敗嘗試後，延遲加倍。
+ 將重試次數限制為 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 開發套件）**  

```
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 回應）
<a name="scaling-sustained-errors"></a>

如果您收到持續的 503 錯誤，單獨重試將無法解決問題。您的請求速率超過可用的輸送量。採取下列步驟：
+ 降低應用程式提交新請求的速率。
+ 實作用戶端速率限制或請求佇列。
+ 卸載低優先順序請求，直到輸送量復原為止。

## 提升輸送量
<a name="scaling-ramp-up"></a>

在[`bedrock-mantle`](endpoints.md)端點上消耗隨需輸送量時，可用的輸送量會隨著時間而擴展。並非所有配額內的請求都保證在高需求期間成功，因此逐步漸進很重要。

### 建議的漸進測試程序
<a name="scaling-ramp-procedure"></a>

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)。

## 其他最佳實務
<a name="scaling-additional-best-practices"></a>
+ 使用特徵標記在模型之間逐漸轉換流量，而不是一次切換所有流量。
+ 將大型工作負載分散在數分鐘內，並考慮time-of-day模式，以避免尖峰使用期間。
+ 使用小批次開始測試並逐步擴展。避免同時傳送數千個測試請求。
+ 對於大型離線資料處理，如果您的應用程式可以非同步處理回應，請使用[批次 API](batch-inference.md) 或 [Flex Tier](service-tiers-inference.md)。

## 區域可用性和跨區域推論
<a name="scaling-regional-availability"></a>

隨需輸送量會在區域層級配置，並因區域而異。如果您的工作負載以單一區域為目標，您可能會在高需求期間遇到 503 個回應。若要最大化可用性，如果您使用的是 [`bedrock-runtime`](endpoints.md)，請使用 [全域跨區域推論](global-cross-region-inference.md)。

## 取得說明
<a name="scaling-getting-help"></a>
+ **輸送量規劃** — 請聯絡您的 AWS 帳戶 團隊進行輸送量預測。在擴展事件期間規劃 2 到 3 倍的尖峰輸送量。
+ **效能最佳化** — 監控字符使用效率、最佳化提示以減少字符使用量，並根據使用案例需求選取模型。
+ **支援升級** — 開啟輸送量問題的 AWS 支援案例時，請包含下列項目：特定錯誤代碼、請求 IDs、流量模式 (RPM/TPM) 和擴展時間表。

## 建議摘要
<a name="scaling-summary"></a>


| 案例 | 建議 | 
| --- | --- | 
| 一般工作負載 | 盡可能使用[`bedrock-mantle`端點](endpoints.md)。 | 
| 偶爾 503 錯誤 | 以指數退避和抖動重試。 | 
| 持續的 503 錯誤 | 降低請求提交率。實作用戶端速率限制。 | 
| 429 個錯誤 | 降低請求率。透過 [Service Quotas](https://console.aws.amazon.com/servicequotas/home) 請求更高的 RPM 配置。 | 
| 大型離線處理 | 使用[批次 API](batch-inference.md) 或 [Flex 方案](service-tiers-inference.md)。 |