为生成式 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 区域中进行微调。
————————————————

                        
原文链接：https://blog.csdn.net/ertfafrtrtrtyr/article/details/142412660