亚马逊AWS官方博客
为生成式 AI 工作负载设计弹性
弹性在任何工作负载的开发中都扮演着关键角色,而生成式AI工作负载也不例外。从弹性的角度来设计生成式 AI 工作负载时有一些独特的考虑因素。理解并优先考虑弹性对于生成式 AI 工作负载来满足组织的可用性和业务连续性要求至关重要。在这篇文章中,我们讨论了生成式AI工作负载的不同技术栈以及应该考虑的因素。
全栈生成式 AI
尽管围绕生成式 AI 的很多兴奋点都集中在模型上,但一个完整的解决方案涉及来自多个领域的人员、技能和工具。考虑下图,这是 AWS 对 a16z 新兴应用程序栈在大语言模型(LLM)方面的看法。
Taxonomy of LLM App Stack on AWS
与传统的围绕 AI 和机器学习(ML)构建的解决方案相比,生成式 AI 解决方案现在涉及以下内容:
- 新角色 – 除了模型构建者和模型集成者,你还必须考虑模型调优者
- 新工具 – 传统的 MLOps 技术栈无法覆盖 prompt engineering 或调用工具与其他系统交互的 agent 所需的实验跟踪或可观察性类型
Agent 推理
与传统的 AI 模型不同,Retrieval Augmented Generation(RAG)通过集成外部知识源,可以提供更准确、更符合上下文的响应。使用 RAG 时需要考虑以下几点:
- 设置适当的超时对用户体验很重要。没有什么比在聊天过程中突然断开连接更能说明糟糕的用户体验了。
- 确保根据模型定义的分配字符限制来验证 prompt 输入数据和 prompt 输入大小。
- 如果你在进行 prompt engineering, 你应该将 prompts 持久化到可靠的数据存储中。 这将在意外丢失的情况下保护你的 prompts,或作为整体灾难恢复策略的一部分。
数据管道
在需要使用 RAG 模式为基础模型提供上下文数据的情况下,你需要一个数据管道,可以摄取源数据,将其转换为 embedding vectors,并将 embedding vectors 存储在向量数据库中。如果你提前准备上下文数据,这个管道可以是批处理管道;如果你即时合并新的上下文数据,则可以是低延迟管道。在批处理的情况下,与典型的数据管道相比有几个挑战。
数据源可能是文件系统上的 PDF 文档、来自 CRM 工具等 SaaS 系统的数据,或来自现有 wiki 或知识库的数据。从这些源摄取数据与从典型数据源(如 Amazon S3 存储桶中的日志数据或关系数据库中的结构化数据)摄取数据不同。你可以实现的并行级别可能受源系统的限制,因此你需要考虑限流并使用退避技术。一些源系统可能很脆弱,因此你需要构建错误处理和重试逻辑。
无论你是在管道中本地运行 embedding 模型还是调用外部模型,embedding 模型都可能成为性能瓶颈。embedding 模型是在 GPU 上运行的基础模型,没有无限的容量。如果模型在本地运行,你需要根据 GPU 容量分配工作。如果模型在外部运行,你需要确保不会使外部模型饱和。在任何一种情况下,你可以实现的并行级别都将由 embedding 模型决定,而不是批处理系统中可用的 CPU 和 RAM 数量。
在低延迟的情况下,你需要考虑生成 embedding vectors 所需的时间。调用应用程序应该异步调用管道。
向量数据库
向量数据库有两个功能:存储 embedding vectors,以及运行相似性搜索以找到与新向量最接近的 k 个匹配项。向量数据库通常有三种类型:
- 专用的 SaaS 选项,如 Pinecone
- 内置于其他服务中的向量数据库功能,包括原生 AWS 服务,如 Amazon OpenSearch Service 和 Amazon Aurora
- 可用于低延迟场景中瞬态数据的内存选项
在这篇文章中,我们不会详细介绍相似性搜索功能。尽管它们很重要,但它们是系统的功能方面,不会直接影响弹性。相反,我们关注向量数据库作为存储系统的弹性方面:
- 延迟 – 向量数据库能否在高负载或不可预测的负载下表现良好?如果不能,调用应用程序需要处理速率限制、退避和重试。
- 可扩展性 – 系统可以容纳多少个向量?如果超过向量数据库的容量,你将需要研究分片或其他解决方案。
- 高可用性和灾难恢复 – Embedding vectors 是有价值的数据,重新创建它们可能很昂贵。你的向量数据库在单个 AWS 区域内是否具有高可用性?它是否能够将数据复制到另一个区域以用于灾难恢复?
应用层
在集成生成式 AI 解决方案时,应用层有三个独特的考虑因素:
- 潜在的高延迟 – 基础模型通常在大型 GPU 实例上运行,可能有有限的容量。确保使用最佳实践进行速率限制、退避和重试以及负载削减。使用异步设计,以便高延迟不会干扰应用程序的主界面。
- 安全态势 – 如果你使用 agent、工具、插件或其他方法将模型连接到其他系统,请特别注意你的安全态势。模型可能会以意想不到的方式与这些系统交互。遵循最小特权访问的常规做法,例如限制来自其他系统的传入 prompts。
- 快速发展的框架 – 像 LangChain 这样的开源框架正在快速发展。使用微服务方法将其他组件与这些不太成熟的框架隔离开来。
容量
我们可以在两个上下文中考虑容量:推理和训练模型数据管道。当组织构建自己的管道时,容量是一个考虑因素。在选择运行工作负载的实例时,CPU 和内存需求是最大的两个需求。
能够支持生成式 AI 工作负载的实例可能比普通的通用实例类型更难获得。实例灵活性可以帮助容量和容量规划。根据你运行工作负载的 AWS 区域,可以使用不同的实例类型。
对于关键的用户旅程,组织需要考虑预留或预配置实例类型,以确保在需要时的可用性。这种模式实现了静态稳定的架构,这是一种弹性最佳实践。要了解更多关于 AWS Well-Architected Framework 可靠性支柱中的静态稳定性,请参阅使用静态稳定性防止双峰行为。
可观察性
除了通常收集的资源指标(如 CPU 和 RAM 利用率)之外,如果你在 Amazon SageMaker 或 Amazon EC2 上托管模型,还需要密切监控 GPU 利用率。如果基础模型或输入数据发生变化,GPU 利用率可能会出现意外变化,而 GPU 内存耗尽可能会使系统进入不稳定状态。
在更高的技术栈中,你还需要跟踪系统中的调用流,捕获 agent 和工具之间的交互。由于 agent 和工具之间的接口没有 API 契约那样正式定义,因此你应该监控这些跟踪,不仅要监控性能,还要捕获新的错误场景。要监控模型或 agent 的任何安全风险和威胁,你可以使用 Amazon GuardDuty 等工具。
你还应该捕获 embedding vectors、prompts、上下文和输出的基线,以及它们之间的交互。如果这些随时间变化,可能表明用户正在以新的方式使用系统,参考数据没有以相同的方式覆盖问题空间,或者模型的输出突然不同。
灾难恢复
对于任何工作负载,拥有具有灾难恢复策略的业务连续性计划都是必须的。生成式 AI 工作负载也不例外。了解适用于你的工作负载的故障模式将有助于指导你的策略。如果你为工作负载使用 AWS 托管服务,如 Amazon Bedrock 和 SageMaker,请确保该服务在你的恢复 AWS 区域中可用。在撰写本文时,这些 AWS 服务本身不支持跨 AWS 区域复制数据,因此你需要考虑灾难恢复的数据管理策略,并且可能还需要在多个 AWS 区域中进行微调。
结论
这篇文章描述了在构建生成式 AI 解决方案时如何考虑弹性。尽管生成式 AI 应用程序有一些有趣的细微差别,但现有的弹性模式和最佳实践仍然适用。这只是评估生成式 AI 应用程序的每个部分并应用相关最佳实践的问题。
有关生成式 AI 以及如何将其与 AWS 服务一起使用的更多信息,请参考以下资源:
- 保护生成式 AI:生成式 AI 安全范围矩阵简介
- Amazon Bedrock 的护栏有助于实施针对你的用例和负责任 AI 策略定制的保护措施(预览版)
- Llama Guard 现已在 Amazon SageMaker JumpStart 中提供
Original URL: https://aws.amazon.com/blogs/machine-learning/designing-generative-ai-workloads-for-resilience/