设计生成性AI工作负载以提高弹性 机器学习博客

---

设计具有韧性的生成 AI 工作负载

关键要点

韧性在生成 AI 工作负载的开发中至关重要，需要特别关注。整体解决方案不仅包括模型，还涉及人员、技能和多个域的工具。探讨了在不同层面上如何构建生成 AI 工作负载的韧性。

韧性在任何工作负载的开发中都发挥着关键作用，而生成 AI 工作负载也不例外。从韧性的角度考虑的工程设计要素非常独特，理解并优先考虑韧性对于满足组织的可用性和业务连续性要求至关重要。本文将讨论生成 AI 工作负载的不同层次及相关的关键考虑因素。

全栈生成 AI

尽管生成 AI 的兴奋点多集中在模型上，但完整的解决方案还包括来自多个领域的人员、技能和工具。考虑以下图片，它展示了 AWS 对 a16z 新兴大型语言模型 (LLM) 应用栈的视图。

与围绕 AI 和机器学习 (ML) 建立的传统解决方案相比，生成 AI 解决方案现在涉及以下方面：

新角色 除了模型构建者和模型集成者，还需要考虑模型调优人员。新工具 传统的 MLOps 栈无法覆盖提示工程或与其他系统交互工具的实验跟踪或可观察性需求。

代理推理

与传统 AI 模型不同，增强检索生成 (RAG) 通过集成外部知识来源，允许更准确、上下文相关的响应。使用 RAG 时需要注意以下几点：

设置适当的超时时间对于客户体验很重要。在聊天过程中断开连接是糟糕用户体验的典型表现。确保验证提示输入数据及其大小是否符合模型定义的字数限制。如果进行提示工程，应该将提示持续存储在可靠的数据存储中。这将保障提示的安全，以防意外丢失，或作为整体灾难恢复策略的一部分。

数据管道

在需要通过 RAG 模式向基础模型提供上下文数据时，需要一个数据管道来摄取源数据，并将其转换为嵌入向量，最后将嵌入向量存储在向量数据库中。根据准备上下文数据的方式，该管道可以是批处理管道，或是实时低延迟管道。在批处理的情况下，与典型数据管道相比，有以下挑战：

数据源可能是文件系统中的 PDF 文档、来自诸如 CRM 工具之类的软件即服务SaaS系统的数据，或是来自现有维基或知识库的数据。与传统的数据源如存储在 Amazon S3 桶中的日志数据或来自关系数据库的结构化数据摄取有所不同。可并行化的程度可能受制于源系统，因此需要考虑速率限制，并使用退避技巧。一些源系统可能不够稳健，因此需要构建错误处理和重试逻辑。

嵌入模型可能成为性能瓶颈，无论你是在管道本地运行它，还是调用外部模型。嵌入模型是运行在 GPU 上的基础模型，但其容量是有限的。如果模型在本地运行，需要根据 GPU 容量分配工作；如果模型在外部运行，需要确保不会饱和外部模型。在这两种情况下，可并行化的程度主要由嵌入模型决定，而不是批处理系统中可用的 CPU 和 RAM。

在低延迟的情况下，必须考虑生成嵌入向量所需的时间。调用应用应以异步方式调用管道。

向量数据库

向量数据库有两个主要功能：存储嵌入向量和运行相似性搜索以查找与新向量最接近的 k 个匹配。通常有三种类型的向量数据库：

专用的 SaaS 选项，如 Pinecone。内部服务中构建的向量数据库功能。这包括 AWS 原生服务，如 Amazon OpenSearch Service 和 Amazon Aurora。可用于低延迟场景中瞬态数据的内存选项。

本文并未详细讨论相似性搜索的能力。尽管这很重要，但它们是系统的功能方面，并不会直接影响韧性。相反，我们重点关注向量数据库作为存储系统的韧性特性：

延迟 向量数据库能否在高负载或不可预测负载下表现良好？否则，调用应用需要处理速率限制、退避和重试。可扩展性 系统可以容纳多少个向量？如果超出向量数据库的容量，则需要考虑拆分或其他解决方案。高可用性和灾难恢复 嵌入向量是有价值的数据，重建它们可能成本高昂。你的向量数据库在某个 AWS 区域是否高可用？是否可以将数据复制到其他区域以用于灾难恢复？

应用层

在集成生成 AI 解决方案时，应用层有三项独特的考虑因素：

鲸鱼加速器官方版下载潜在的高延迟 基础模型通常在大型 GPU 实例上运行，且容量有限。确保采用最佳实践进行速率限制、退避和重试以及负载削减。使用异步设计，以避免高延迟影响应用的主要界面。安全策略 如果使用代理、工具、插件或其他连接模型与其他系统的方法，请特别关注你的安全策略。模型可能会以意想不到的方式与这些系统交互。遵循最小权限访问的常规做法，例如限制来自其他系统的输入提示。快速演变的框架 开源框架如 LangChain 正在快速发展。使用微服务方法将其他组件与这些不成熟的框架隔离开。

容量

容量可以在两个上下文中思考：推断和训练模型数据管道。容量是在组织构建自己的管道时的一个重要考量。选择运行工作负载的实例时，CPU 和内存需求是最主要的要求之一。

支持生成 AI 工作负载的实例获取可能比普通通用实例类型更困难。实例的灵活性可以帮助应对容量和容量规划。根据所运行的 AWS 区域，不同的实例类型会有所不同。

对于关键的用户旅程，组织应考虑保留或预配置实例类型，以确保在需要时的可用性。这种模式实现了稳定的架构，这是韧性最佳实践之一。如需了解 AWS WellArchitected Framework 中有关静态稳定性的更多信息，请参见利用静态稳定性防止双模行为。

可观察性

除了通常收集的资源指标如 CPU 和 RAM 使用率外，还需要密切监测 GPU 的使用率，特别是当你在 Amazon SageMaker 或 Amazon Elastic Compute CloudAmazon EC2上托管模型时。GPU 的利用率可能会因为基础模型或输入数据的改变而意外变化，而 GPU 内存耗尽则会让系统处于不稳定状态。

在更高的层面上，你还希望追踪系统中的调用流程，捕获代理和工具之间的交互。由于代理与工具之间的接口不如 API 合同那样正式定义，因此应监测这些跟踪，不仅关注性能，还要捕获新的错误场景。要监测模型或代理是否存在安全风险和威胁，可以使用 Amazon GuardDuty 等工具。

你还应记录嵌入向量、提示、上下文和输出的基线，以及它们之间的交互。如果这些随时间变化，可能表示用户正在以新的方式使用系统，参考数据无法涵盖相同的问题空间，或者模型输出突然不同。

灾难恢复

为任何工作负载制定业务连续性计划和灾难恢复策略是必不可少的。生成 AI 工作负载也不例外。了解适用于你工作负载的故障模式将有助于指导你的策略。如果你使用 AWS 管理的服务，如 Amazon Bedrock 和 SageMaker，请确保该服务在你的恢复 AWS 区域可用。截至目前，这些 AWS 服务不支持原生跨 AWS 区域数据复制，因此需要考虑灾难恢复的数据管理策略，并可能需要在多个 AWS 区域进行精细调优。

结论

本文描述了在构建生成 AI 解决方案时如何考虑韧性。尽管生成 AI 应用具有一些有趣的细微差别，但现有的韧性模式和最佳实践仍然适用。关键在于评估生成 AI 应用的每个部分并应用相关的最佳实践。

有关生成 AI 及其在 AWS 服务中使用的更多信息，请参见以下资源：

保护生成 AI：生成 AI 安全范围矩阵简介Amazon Bedrock Guardrails 有助于实现符合用例和负责任 AI 政策的安全措施预览Llama Guard 现已在 Amazon SageMaker JumpStart 中上线

关于作者

Jennifer Moran 是 AWS 高级韧性专家解决方案架构师，常驻纽约市。她拥有丰富的背景，曾在多个技术领域工作，包括软件开发、敏捷领导和 DevOps，并且是女性科技从业者的倡导者。她热衷于帮助客户设计韧性解决方案，以改善韧性战略，并在各种与韧性相关的话题上进行公开演讲。

Randy DeFauw 是 AWS 的高级首席解决方案架构师。他拥有密歇根大学的电子工程硕士学位，曾研究自主车辆的计算机视觉问题。还拥有科罗拉多州立大学的工商管理硕士学位。Randy 在技术领域担任过多种职位，从软件工程到产品管理。他于2013年进入大数据领域，至今仍在持续探索这一领域。目前积极参与机器学习项目，并在包括 Strata 和 GlueCon 在内的多个会议上做过演讲。

加载评论中

• • 2026-01-27 14:45:47
  • 35