扩展和吞吐量最佳实践

本主题说明了吞吐量限制和调度在 Amazon Bedrock 终端节点上的工作原理，并提供了扩展生成式 AI 应用程序的最佳实践。

Amazon Bedrock 端点

Amazon Bedrock 支持两个用于推理的终端节点：

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

为什么两个端点的行为不同

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

使用 bedrock-mantle，则使用了不同的方法。此端点采用高级调度和工作队列机制架构，可实现公平分配，同时支持更高的初始吞吐量限制。这种设计还bedrock-mantle允许托管各种模型，并提供模型目录中可用的全部功能。在大多数情况下，请求会立即得到满足。在某些情况下，当运行中的工作负载完成且吞吐量可用时，请求可能会短暂排队。以下各节说明了如何处理这些场景。

基岩地幔端点：吞吐量和配额

所有机型都bedrock-mantle有一个硬限制，即每个地区每个账户 10,000 RPM。与其他模型相比，Claude 的吞吐量和配额表现存在一些差异，如下所示。

* 您的输入 TPM 限制取决于您在 Amazon Bedrock 上的使用历史记录。请查看 Amazon Bedrock 控制台中的配额页面，了解您的实际配额。

基层运行时端点：吞吐量和配额

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

* 这些型号的配额因使用情况而异。查看 Amazon Bedrock 控制台中的配额页面，了解您的配额。

了解 HTTP 错误响应

建议的错误处理

暂时错误（偶尔会有 503 个响应）

使用随机抖动实现指数回退：

大多数 AWS SDK 和常用的 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 分配，请使用 S ervice Quotas 控制台。

其他最佳实践

区域可用性和跨区域推断

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

获取帮助

建议摘要