Implementing resilience patterns with Amazon Bedrock and LLM gateway

使用 Amazon Bedrock 和 LLM 网关实现弹性模式 | 人工智能

使用 Amazon Bedrock 和 LLM 网关实现弹性模式

随着生成式 AI 工作负载从实验阶段转向大规模生产环境，为大型语言模型（LLM）推理实现弹性模式变得至关重要。如今 LLM 驱动的应用已进入生产环境，组织需要在大规模部署时确保 LLM 推理的高可用性、响应速度和成本效益。现有的弹性最佳实践（如静态稳定性、退避和重试机制）仍然适用。然而，生成式 AI 引入了新的考量因素，包括模型可用性、快速变化的配额、跨多个提供商的令牌限制，以及与新发布模型保持一致性。Amazon Bedrock 提供了完全托管的基础模型，内置跨区域推理等弹性功能。

在设计生产环境推理时，通常有四个维度指导架构决策：可用性、响应时间、成本和吞吐量。可用性指在模型、区域或提供商出现中断时维持推理能力。响应时间衡量用户获取输出的速度，通常以首个令牌生成时间（TTFT）和最后一个令牌生成时间（TTLT）来衡量。成本涵盖每令牌和每请求的支出，以及路由决策对其的影响。吞吐量反映系统在负载下每秒能处理的并发请求数和令牌数。

这些维度相互关联。例如，跨区域路由可提升可用性和吞吐量，但可能增加响应时间。本文的模式主要聚焦于可用性：通过故障转移、地理分布和配额隔离保持推理运行。后续文章将深入探讨响应时间优化和成本感知路由。

在本文中，您将学习在 AWS 上构建弹性生成式 AI 应用的五种实用模式，从原生 Amazon Bedrock 功能逐步过渡到使用 LLM 网关的多模型编排。这些模式解决了实际挑战，例如在突发流量高峰期间防止配额耗尽、通过地理分布推理最大化可用性、在多租户环境中防止噪声邻居问题。它们还通过智能请求路由支持成本优化，并根据您的具体需求提供使用多个模型和提供商的灵活性。

这种“爬行-行走-奔跑”的方法使您能根据应用的成熟度和需求逐步采用这些模式。配套的 GitHub 仓库提供了演示每个模式的代码示例。

推理弹性模式的渐进式方法

您可以通过使用 GitHub 仓库本节提供的代码示例和说明，在自己的环境中测试以下每种模式。

先决条件

在开始演示之前，请通过完成先决条件验证是否已安装适当的软件并正确配置了 AWS 账户。

注意：遵循本文中的模式将创建和使用会产生费用的 AWS 资源，包括 Amazon Bedrock 推理请求和 Amazon CloudWatch 日志。请参阅清理部分以避免测试后持续产生费用。

模式 1：使用 Amazon Bedrock 跨区域推理

Amazon Bedrock 跨区域推理（CRIS）是一项原生功能，默认为弹性推理提供基础支持。您可以使用跨区域推理配置文件来提高吞吐量、降低在特定 AWS 区域内被限流的可能性，并实现模型流量的分布。CRIS 去除了手动管理流量分配的繁琐工作，提升了应用程序的可用性。它会根据实时因素（包括可用性、延迟和当前需求）自动将请求从源区域路由到最优的目标区域。这种机制可以应对高峰使用时段的突发流量，降低服务配额影响推理的可能性。

CRIS 配置文件通常与特定地理区域（如美国或欧盟）内的商业区域绑定，为推理请求提供性能和延迟之间的最佳平衡。这种方法在保持数据驻留于地理边界内的同时，可使总吞吐量超出单区域配额限制。

Amazon Bedrock 跨区域推理

对于某些可以容忍更高推理请求延迟的使用场景，可以选择使用全球跨区域推理配置文件。通过全局配置文件，请求可以路由到多个提供全球推理服务的商业区域，实现比标准跨区域推理配置文件更高的吞吐量。

例如，在我们的演示中，当使用跨区域推理配置文件向 Amazon Bedrock 发送 10 个请求时，命令输出显示 CRIS 如何自动将模型推理分布到三个 AWS 区域：

区域

调用次数

占比

us-east-1

1

10%

us-east-2

7

70%

us-west-2

2

20%

Amazon Bedrock 跨区域推理将 10 个请求分布到三个 AWS 区域

模式 2：使用多个 AWS 账户

虽然 CRIS 可以在单个 AWS 账户内提升吞吐量，但您还可以通过额外的扩展和隔离策略获益。AWS 账户分片技术将请求分布到多个具有独立配额和 CRIS 配置文件的 AWS 账户中。

账户分片创建了自然的故障隔离边界，一个账户中的问题不会影响其他账户，这在需要严格隔离工作负载的多团队和多租户架构中具有特别价值。

AWS 账户分片与 Amazon Bedrock 跨区域推理

在运行账户分片演示时，我们使用跨区域推理配置文件向两个配置的 AWS 账户各发送 10 个请求。输出显示每个账户如何独立地将推理分布到 AWS 区域：

账户 1

3

30%

账户 2

5

50%

两个 AWS 账户通过 CRIS 独立地将请求分布到不同区域

使用 LLM 网关

对于复杂的生产场景，LLM 网关可提供比直接 API 调用更强大的路由、故障转移和治理能力。网关在您的应用程序与 LLM 提供商之间充当智能代理，提供统一的抽象层，使您可以通过单一 API 接口访问多个不同供应商的模型。这种标准化简化了集成，同时嵌入了诸如负责任的 AI 安全保障、审计日志、自动重试和回退逻辑、配额管理等众多功能，帮助您的应用程序在单个模型不可用时仍能保持韧性。

LLM 网关在 AWS 账户和外部提供商之间协调请求

网关支持在多个模型和账户之间进行智能请求路由和负载均衡，在实现按消费者隔离的速率限制和配额管理的同时最大化吞吐量。这有助于在多租户环境中防止噪声邻居问题，同时通过使用分析实现全面的成本跟踪和优化。集中的可观测性和监控功能可让您全面了解 LLM 使用模式，并提供针对每个应用程序的详细洞察，帮助快速识别优化机会并解决问题。

目前有许多开源和商业的 LLM 网关可供选择。在我们的演示中，我们使用 LiteLLM 作为轻量级开源选项，本地运行以展示这些模式。在大规模部署时，AWS 多提供商生成式 AI 网关解决方案提供了一个参考实现和架构，该架构同样使用 LiteLLM，但增加了企业级功能，包括在 Amazon Elastic Container Service (Amazon ECS) 或 Amazon Elastic Kubernetes Service (Amazon EKS) 上的容器化部署、自动扩展、AWS WAF 保护、密钥管理，以及通过 Amazon CloudWatch 实现的全面可观测性。

模式 3：模型降级

模型之间的自动故障转移即使主模型达到速率限制或遇到服务中断，也能支持更高的可用性。该模式旨在自动在用户定义的主模型和备用模型之间路由请求。如果您的降级策略侧重于优化质量和成本而非配额耗尽，Amazon Bedrock 智能提示路由提供了原生选项。它无需外部网关即可动态选择最适合每个请求的模型。当主模型调用失败时，网关会自动使用备用模型重试请求，即使在流量意外激增时也能支持高可用性。降级策略还结合了成本优化和性能考量，例如在适当情况下限制高成本模型的使用，并切换到更具成本效益的替代方案。

具有速率限制主模型和更高容量备用模型的降级演示

在我们的演示中，LiteLLM 配置定义了一个具有严格速率限制（每分钟 3 次请求）的主模型和一个容量更高的备用模型（每分钟 25 次请求）。当客户端通过网关发送 10 个并发请求时，前三个请求会路由到 Amazon Bedrock 中的主模型。当主模型达到其速率限制时，LiteLLM 会自动将剩余的七个请求路由到备用模型。10 个请求在没有人工干预或应用级重试逻辑的情况下成功完成。

演示输出确认了此模式的有效性，显示尽管主模型存在速率限制，10 个请求仍能成功完成，表现出高可靠性。分布情况显示，主模型在达到配额前恰好处理了 3 个请求。其余 7 个请求切换到备用模型，展示了网关通过智能路由保持服务可用性的能力。

降级演示输出显示模型分布

模式 4：跨模型负载均衡

负载均衡模式通过将请求分发到多个模型实例，以优化资源利用率并防止瓶颈的出现。这种方法不仅能够最大化资源利用率，还能根据需要快速扩展，通过添加或移除模型实例来实现。例如，在全面部署新模型之前进行评估时，可以采用加权路由或AB测试策略，仅将一小部分请求导向新模型，而大部分请求继续使用经过验证的模型。

跨主模型的负载均衡与备用溢出处理

在我们的负载均衡演示中，网关成功地通过洗牌策略将10个并发请求分发到两个模型。负载均衡器最初将3个请求分别路由到两个配置的主模型，当达到速率限制后，剩余的4个请求会自动重定向到备用模型。最终结果实现了100%的成功率，展示了负载均衡如何与备用策略协同工作。

负载均衡演示输出

模式5：多租户配额隔离

多租户配额隔离模式通过为每个租户创建具有独立配额和速率限制的逻辑隔离环境，来管理多租户环境中的请求。通过为每个消费者实现独立的速率限制桶，该模式有助于防止“噪声邻居”问题，即一个消费者的请求对其他消费者的性能产生负面影响。无论其他租户的使用模式如何，每个租户都会获得专属的配额，从而支持公平的资源分配并保持消费者间的服务质量一致性。

为每个消费者配置独立速率限制的多租户配额隔离

该模式非常适合需要共享模型资源但又要求可预测性能和隔离保障的环境。

在我们的演示中，三个具有不同速率限制的消费者同时尝试访问同一模型。消费者A仅允许每分钟3个请求（RPM），而消费者B和C各有10个RPM。当三个消费者各自发送5个并发请求时，网关执行了独立的配额控制。消费者A因速率限制仅成功处理3个请求，2个请求被拒绝。消费者B和C则实现了100%的成功率，所有5个请求均被处理。

配额隔离分析

| 用户 | 类型 | 成功率 | 总请求数 | 成功请求数 | 失败请求数 | 速率限制 | |------|------|--------|----------|------------|------------|----------| | A | 噪声型 | 60% | 5 | 3 | 2 | 是 | | B | 正常型 | 100% | 5 | 5 | 0 | 否 | | C | 正常型 | 100% | 5 | 5 | 0 | 否 |

多租户隔离演示输出

清理

警告：以下清理步骤将永久删除CloudWatch日志。如果需要保留日志用于审计或分析，请在执行清理前先导出日志。

为避免账户产生持续费用，请完成以下步骤以停止网关并删除CloudWatch日志。

重要注意事项

上述指导基于对工作负载需求、数据安全和合规义务以及性能需求的某些假设。与大多数问题一样，“何时应使用这些模式？”的答案是“取决于具体情况！”。以下是一些适用这些模式的典型场景和用例。

#### 适用场景和用例

高可用性需求：当应用程序无法容忍停机时，多个模型可提供自动故障转移。如果主模型达到速率限制或发生故障，请求将路由到备用模型，从而保持100%的可用性。

超越单模型配额的扩展性：单个模型存在吞吐量限制。通过使用多个模型（即使是在不同账户/区域中使用相同类型的模型），可以成倍提升总可用容量。这对于高流量应用场景至关重要，因为请求量可能超过单个模型的配额限制。

多租户隔离：在软件即服务（SaaS）应用中，不同客户可以使用不同的模型或模型实例，有助于防止某个客户的使用影响到其他客户。

开发环境与生产环境：无需修改代码即可为测试环境（使用成本更低、速度更快的模型）和生产环境（使用质量更高的模型）配置不同的模型。

结论

本文介绍了多种实现弹性大语言模型（LLM）推理的模式，从亚马逊Bedrock原生的跨区域推理开始，到需要实现LLM网关的更复杂模式。通过使用这些策略，您可以提升生成式AI工作负载的弹性，并对模型可用性和故障转移策略进行精细化控制，包括为特定消费者和应用程序提供专用控制。

我们邀请您使用配套的GitHub仓库详细尝试这些模式，该仓库提供了每个模式的代码示例和逐步测试说明。如需查看生产就绪的生成式LLM网关的完整参考实现，请查阅AWS多提供方生成式AI网关解决方案。

如需了解更多生成式AI架构模式和最佳实践，请访问AWS人工智能博客。

如果您有任何评论或问题，请在评论区留言。

标签：生成式AI，亚马逊Bedrock，弹性，架构

作者简介

'\"