Bedrock 中模型大小的选择直接影响响应时间和吞吐量，这归因于计算复杂度和资源需求的差异。更大的模型拥有更多的参数和层，需要更多的处理能力和内存来生成响应。这会增加完成单个请求所需的时间（响应时间），并减少可以同时处理的请求数量（吞吐量）。更小的模型参数较少，处理请求更快，可以处理更多并发请求，但在复杂任务中可能会牺牲准确性或细微之处。权衡取决于使用场景：对延迟敏感的应用倾向于选择更小的模型，而需要更深层分析的任务可能需要容忍更大模型较慢的性能。
例如，像 Bedrock 拥有 1000 亿参数的大型语言模型可能需要 2-3 秒来生成详细的技术查询答案，而拥有 10 亿参数的较小模型可以在 200 毫秒内响应更简单的请求。在负载下，吞吐量差异会变得明显：如果较小模型在给定的硬件配置下每秒处理 100 个请求（RPS），则较大模型可能只能处理 10 RPS。批量处理会进一步扩大这种差距。大型模型通常需要专门的硬件（例如，拥有大容量显存的高端 GPU）才能高效运行，而较小模型可以在更廉价、更广泛可用的实例上运行。此外，大型模型可能面临内存瓶颈，导致请求必须顺序处理而不是并行执行，进一步降低吞吐量。
开发者必须根据其应用的需求平衡这些因素。像聊天机器人或 API 集成这样的实时应用通常优先考虑低延迟和高吞吐量，因此较小的模型更受欢迎。像文档分析这样的批量处理任务可以容忍较长的响应时间，允许使用更大的模型来最大化输出质量。模型量化或硬件优化（例如，使用带有张量核心的 GPU）等技术可以减轻一些性能差距，但核心权衡依然存在。使用真实的负载进行测试至关重要：对于需要亚秒级响应的客户服务机器人来说，使用较小模型导致准确率下降 20% 可能是可以接受的，但对于医疗文本分析来说则是不可接受的。Bedrock 灵活切换模型的能力使得团队可以使用较大模型进行原型设计，并在生产扩展时部署较小模型。