擴展和輸送量最佳實務

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

Amazon Bedrock 端點

Amazon Bedrock 支援兩個端點進行推論：

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

為什麼兩個端點的行為不同

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

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

bedrock-mantle 端點：輸送量和配額

上的所有模型bedrock-mantle共用每個區域每個帳戶 10，000 RPM 的單一硬性限制。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 主控台。

其他最佳實務

區域可用性和跨區域推論

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

取得說明

建議摘要