在使用 AWS Bedrock 时，选择并行请求还是排队请求取决于您的工作负载特性和 Bedrock 的速率限制。对于大多数情况，并行请求可以提高吞吐量，但您必须保持在 Bedrock 的服务配额内，以避免限流。当任务需要按顺序处理、执行时间可变或需要优雅地处理突发流量时，排队是更好的选择。一种混合方法——在速率限制内使用并行，并对溢出部分进行排队——通常是最佳的。
为了有效地使用并行请求，请将您的代码结构化，使用 Bedrock 的 SDK（例如 Python 中的 Boto3）发送多个异步调用。例如，如果 Bedrock 每个账户允许每秒 100 个请求 (RPS)，则一个 Python 脚本可以使用 ThreadPoolExecutor 来处理 10 个并发请求。但是，请查阅 AWS 文档以了解您特定模型的限制——有些模型限制了并发调用次数。如果超出限制，Bedrock 会返回 ThrottlingException 错误，因此请实现带有指数退避的重试机制。AWS SDK 等工具会自动处理重试，但您可以自定义此行为。并行适用于无状态任务，例如处理多个独立的文本提示以进行摘要。
当您需要管理大型工作负载或对任务进行优先级排序时，排队就变得必要。SQS 或 Amazon SNS 等 AWS 服务可以将请求生产者与消费者解耦。例如，由 SQS 队列触发的 Lambda 函数可以批量处理 Bedrock 请求，确保您保持在配额内。如果任务存在依赖关系（例如，在处理步骤 B 之前处理步骤 A）或者您需要跨区域分发工作负载，队列也很有帮助。例如，视频转录服务可以将用户上传排队，通过 Bedrock 按顺序处理，并将结果存储在 DynamoDB 中。CloudWatch 等监控工具可以跟踪队列深度和限流事件，使您能够动态调整并发。将队列与有限的并行（例如，5 个并发 Lambda 调用）结合使用可以平衡吞吐量和稳定性。
在实践中，先在文档规定的限制内使用并行请求，如果遇到限流或工作负载不均衡，再添加排队。例如，处理用户查询的聊天机器人可以在高峰时段使用 20 个并行线程，但在流量高峰期将超额请求路由到 SQS。使用 Bedrock 的指标测试不同的配置以找到合适的平衡点。始终对限流和网络问题实施错误处理，并考虑成本权衡——并行可能增加计算使用量，而排队会增加延迟。通过基于实际使用情况进行监控和调整，您可以在不触及服务限制的情况下优化 Bedrock 的吞吐量。