扩展和吞吐量最佳实践

本主题介绍了 Amazon Bedrock 终端节点的吞吐量限制和调度是如何运作的，并提供了扩展生成式 AI 应用程序的最佳实践。

Amazon Bedrock 端点

亚马逊 Bedrock 支持两个终端节点进行推理：

对于大多数新应用程序，从开始bedrock-runtime。bedrock-mantle当您需要仅在该端点上可用的功能（例如服务器端工具、后台推理、项目、工作区或仅在该端点上可用的模型）时使用。bedrock-mantle你可以在同一个应用程序中使用这两个端点。要进行完整比较，请参阅亚马逊 Bedrock 支持的终端节点。

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

两个端点表面使用相同的底层推理引擎，但它们的配额核算和容量选项不同。bedrock-runtime使用每个型号的代币配额，对于某些模型，使用每分钟请求数 (RPM) 配额。bedrock-mantle不强制执行 RPM 配额，并对已发布配额的模型使用单独的输入令牌和输出代币配额。其他模型bedrock-mantle可能不会在服务配额中公开每个账户的配额，但其吞吐量仍受内部服务容量的控制。

配额是上限，并不保证所有按需请求都能立即得到满足。在需求旺盛的时期，请求可能会排队或收到暂时的容量错误。将应用程序设计为限制并发性、队列工作和重试暂时性错误，而不会造成重试激增。

bedrock-mantle 终端：吞吐量和配额

终bedrock-mantle端节点具有以下配额行为：

默认值和您的账户分配可能因型号、地区和使用历史记录而异。有关当前值、配额评估详细信息以及申请增加配额的 AWS 支持流程，请参阅基岩地幔端点的配额。有关特定型号模型一览的终端节点、服务级别和功能支持，请参阅适用条款。

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

终bedrock-runtime端节点具有以下配额行为：

有关当前配额值、代币销毁详情和配额增加流程，请参阅。基岩运行时端点的配额有关特定型号模型一览的终端节点、服务级别和功能支持，请参阅适用条款。

了解 HTTP 错误响应

有关 API-specific 原因和解决步骤，请参阅Amazon Bedrock API 错误代码故障排除。

推荐的错误处理

暂时性错误

仅重试可以安全重试的错误，例如瞬态限制和容量错误。如果服务返回Retry-After标头，请兑现该标题。否则，使用随机抖动实现指数退避：

大多数 AWS SDK 和流行的 HTTP 库都为这种模式提供了内置支持。 Retry-setting 名称不同：botocore total_max_attempts 包含初始请求，而OpenAI和Anthropic SD max_retries Ks仅计算重试次数。因此，以下示例使用不同的数值来提供相同的示例六次尝试预算。

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=5,
)

import anthropic

client = anthropic.Anthropic(
    api_key=api_key,
    base_url=f"https://bedrock-mantle.{region}.api.aws/anthropic",
    max_retries=5,
)

根据模型和操作记录的最大推理持续时间，将连接和读取超时与重试分开配置。超时时间短于有效的长时间运行推理请求可能会导致可避免的重试和重复工作。

持续的容量错误

如果您持续收到 503 或 529 错误，则仅重试即可放大负载。该服务可能遇到临时容量限制，或者工作负载可能超过该模型和区域的当前可用容量。执行以下步骤：

提高吞吐量

On-demand 容量可能因型号、地区和时间而异。并非配额内的所有请求都能保证在需求旺盛的时期内成功，因此在启动工作负载、更改模型或区域或大幅增加流量时，应逐渐增加配额。这对于没有公布的每账户配额的bedrock-mantle模型尤其重要。

推荐的升级程序

从工作负载的延迟和流量模式中选择步长和观察周期。不要使用 RPM 作为唯一的控制信号：即使 RPM 保持不变，请求令牌大小和响应长度也可能显著改变容量消耗。

如需增加bedrock-mantle配额，请关注请求提高配额。对于bedrock-runtime，关注请求提高配额。

其他最佳实践

区域可用性和跨区域推断

On-demand 容量是区域性的，可能因地区而异。如果您的工作负载以单个区域为目标，则在需求旺盛的时期可能会遇到容量错误。使用 bedrock-runtime，在模型和您的数据驻留要求支持全球跨区域推理时使用。如果您实施自己的区域故障转移，请验证模型在每个目标区域的可用性并进行限定重试，这样故障转移就不会造成流量激增。

获取帮助

建议总结