使用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发送10个请求时，命令输出显示CRIS自动将模型推断分布在3个AWS区域：

| 区域 | 调用次数 | 百分比 | |------|----------|--------| | us-east-1 | 1 | 10% | | us-east-2 | 7 | 70% | | us-west-2 | 2 | 20% |

模式2：使用多个AWS账户

虽然CRIS在单个AWS账户内倍增了吞吐量，但您可以从额外的扩展和隔离策略中受益。AWS账户分片将请求分布在多个AWS账户之间，每个账户具有独立的配额和CRIS配置文件。

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

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

账户1 | 区域 | 调用次数 | 百分比 | |------|----------|--------| | us-east-2 | 7 | 70% | | us-west-2 | 3 | 30% |

账户2 | 区域 | 调用次数 | 百分比 | |------|----------|--------| | us-east-1 | 2 | 20% | | us-east-2 | 3 | 30% | | us-west-2 | 5 | 50% |

使用LLM网关

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

网关支持跨多个模型和账户的智能请求路由和负载均衡，通过每消费者隔离的速率限制和配额管理最大化吞吐量，防止多租户环境中的噪声邻居问题。它还通过使用分析提供全面的成本跟踪和优化。集中式可观测性和监控使您能够全面了解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个请求（RPM）的限制性速率限制，以及一个具有更高容量（25 RPM）的故障转移模型。当客户端通过网关发送10个并发请求时，前三个请求路由到Amazon Bedrock中的主模型。当主模型达到速率限制时，LiteLLM自动将剩余的七个请求转向故障转移模型。10个请求成功完成，无需手动干预或应用级重试逻辑。

演示输出确认了此模式的有效性，显示尽管主模型有速率限制，但10个请求成功完成。分布显示恰好3个请求在主模型达到配额前被处理。其余7个请求故障转移到故障转移模型，展示了网关通过智能路由维持服务可用性的能力。

模式4：跨模型负载均衡

负载均衡模式将请求分布到多个模型实例，以优化资源利用并帮助防止瓶颈。这种方法不仅最大化利用率，还允许您根据需要快速添加或删除模型实例。例如，在评估新模型但未完全部署时，您可以实施加权路由或A/B测试策略，仅将一小部分请求定向到新模型，而大部分继续使用经过验证的模型。

在我们的负载均衡演示中，网关成功使用混洗策略将10个并发请求分布到两个模型。负载均衡器最初将3个请求路由到每个配置的主模型，当达到速率限制时，剩余的4个请求自动重定向到故障转移模型。结果是100%的成功率，展示了负载均衡如何与故障转移策略协同工作。

模式5：多租户配额隔离

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

此模式非常适合多个应用共享模型资源的环境。