Amazon Bedrock 对模型使用、请求速率和有效负载大小施加了具体的限制和配额，以确保服务可靠性和公平的资源分配。这些限制因模型提供商（例如，Anthropic、Cohere、Amazon Titan）和您使用的 AWS 区域而异。开发人员需要了解这些限制，以便设计可有效扩展并避免服务中断的应用程序。
对于模型使用，Bedrock 强制执行**每分钟请求配额**和**基于 token 的限制**。 例如，Anthropic 的 Claude 模型默认情况下可能允许每分钟 1,000 个请求和每分钟 100,000 个输入 token，而 Amazon Titan Text 可能具有不同的阈值。 这些配额可以防止单个用户垄断共享资源。 Token 限制还限制了单个请求的输入和输出长度。 例如，Claude 模型可能会将输入限制为每个请求 10,000 个 token，将输出限制为 4,000 个 token。 超过这些限制会触发错误，要求开发人员截断或拆分数据。 AWS 允许通过支持票证增加配额，但批准取决于容量。
请求速率限制控制您可以调用 Bedrock API 的频率。 每个模型都有一个**每秒事务数 (TPS)** 上限，例如某些区域中 Cohere Command 的 10 TPS。 突发容量可能暂时允许更高的速率，但持续的超额使用会导致限流（HTTP 429 错误）。 例如，一个每秒向 Titan Text 发送 15 个请求的实时翻译应用程序需要实施具有指数退避的重试逻辑，或将流量分配到多个 AWS 账户。 速率限制通常与模型的复杂性相关——像 Claude 2 这样的大型模型通常比小型模型具有更严格的 TPS 上限。
有效负载大小限制适用于输入和输出数据。 大多数 Bedrock 模型强制执行每个请求**最大有效负载大小为 8-16 MB**，包括文本、图像或嵌入。 例如，Amazon Titan Multimodal Embeddings 可能会拒绝大于 5 MB 的图像输入。 此外，某些模型施加**上下文窗口限制**——Claude 3 的 200,000 个 token 上下文窗口需要将冗长的文档拆分为块。 开发人员必须预处理数据（例如，压缩图像、截断文本）并处理像 ValidationException 这样针对超大有效负载的错误。 这些限制确保低延迟响应并防止网络瓶颈，但它们需要在数据密集型工作流程（如文档分析或批量处理）中进行仔细处理。