本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 扩展和吞吐量最佳实践
<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-native API（调用和交谈）、聊天完成和消息 API。

有关这些终端节点以及如何在它们之间进行选择的更多信息，请参阅[Amazon Bedrock 支持的终端节点](endpoints.md)。

### 为什么两个端点的行为不同
<a name="scaling-endpoint-differences"></a>

在许多传统的多租户服务中，该架构是围绕每个账户的配额设计的，以管理对共享资源的公平共享访问权限。这是与使用的方法[`bedrock-runtime`](endpoints.md)。

使用 [`bedrock-mantle`](endpoints.md)，则使用了不同的方法。此端点采用高级调度和工作队列机制架构，可实现公平分配，同时支持更高的初始吞吐量限制。这种设计还`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（在此端点上的所有模型之间共享） | 
| On-demand 等级 | 标准 | 标准、优先级、弹性（部分例外）— 请查看模型详情页面了解可用性 | 
| Batch | 否 | 支持型号为 “是” — 有关可用性，请参阅型号详情页面 | 
| 预留容量 | 无 | 无 | 

\* 您的输入 TPM 限制取决于您在 Amazon Bedrock 上的使用历史记录。请查看 Amazon Bedrock 控制台中的[配额](https://console.aws.amazon.com/bedrock/home#/model-quotas)页面，了解您的实际配额。

## `基层运行时端`点：吞吐量和配额
<a name="scaling-runtime-quotas"></a>

下表汇总了的吞吐量和配额`bedrock-runtime`。


|   | Claude 4.7\+ | 所有其他型号 | 
| --- | --- | --- | 
| 输入 TPM | 15M \* | 各不相同\* | 
| 输出 TPM | 与输入 TPM 相结合。Burndown 适用。 | 无。Burndown 适用。 | 
| RPM | 10,000（在所有型号之间共享） | 各不相同\* | 
| On-demand 等级 | 标准 | 标准、优先级、弹性（部分例外）— 请查看模型详情页面了解可用性 | 
| Batch | 否 | 支持型号为 “是” — 有关可用性，请参阅型号详情页面 | 
| 预留容量 | 无 | 预留 Tier/Provisioned 容量 | 

\* 这些型号的配额因使用情况而异。查看 Amazon Bedrock 控制台中的[配额](https://console.aws.amazon.com/bedrock/home#/model-quotas)页面，了解您的配额。

## 了解 HTTP 错误响应
<a name="scaling-http-errors"></a>

HTTP 429  
429 的回复表示您已超过账户的 RPM 限制。降低您的请求提交率。如果您需要更高的 RPM 分配，请通过 S [ervice 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 SDK 和常用的 HTTP 库都为这种模式提供了内置支持。

**Example 重试`基岩`运行时的配置 (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 重试配置 b `edrock-man` tle（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 `基岩地幔的重试配置（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 分配，请使用 S [ervice Quotas 控制台](https://console.aws.amazon.com/servicequotas/home)。

## 其他最佳实践
<a name="scaling-additional-best-practices"></a>
+ 使用功能标志在模型之间逐渐转移流量，而不是一次性切换所有流量。
+ 将大型工作负载分散在几分钟内，并考虑一天中的时间模式，以避免使用高峰期。
+ 开始小批量测试并逐步扩大规模。避免同时发送成千上万的测试请求。
+ 对于大型离线数据处理，如果您的应用程序可以异步处理响应，请使用 B [atch API](batch-inference.md) 或 [Flex Tier](service-tiers-inference.md)。

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

On-demand 吞吐量在区域级别分配，并且因区域而异。如果您的工作负载针对单个区域，则在需求旺盛时期，您可能会遇到 503 个响应。要最大限度地提高可用性，如果您正在使用 [`bedrock-runtime`](endpoints.md)，请使用[全球跨区域推理](global-cross-region-inference.md)。

## 获取帮助
<a name="scaling-getting-help"></a>
+ **吞吐量规划** — 请联系您的 AWS 账户 团队进行吞吐量预测。计划在扩展活动期间将峰值吞吐量提高到 2 到 3 倍。
+ **性能优化** — 监控代币使用效率，优化提示以减少代币消耗，并根据您的用例要求选择模型。
+ **支持升级** — 在就吞吐量问题提出 AWS 支持案例时，请提供以下信息：特定的错误代码、请求 ID、流量模式 (RPM/TPM) 和您的扩展时间表。

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


| 场景 | 建议 | 
| --- | --- | 
| 一般工作负载 | 尽可能使用终[`bedrock-mantle`端节点](endpoints.md)。 | 
| 偶尔会出现 503 错误 | 使用指数退避和抖动重试。 | 
| 持续出现 503 个错误 | 降低请求提交率。实现客户端速率限制。 | 
| 429 错误 | 降低请求率。通过 S [ervice Q](https://console.aws.amazon.com/servicequotas/home) uotas 申请更高的 RPM 分配。 | 
| 大型离线处理 | 使用 [Batch API](batch-inference.md) 或[弹性等级](service-tiers-inference.md)。 |