用于支持基础模型生命周期的设计

基础模型是您在 AI 工作负载中使用的带有版本的依赖项。 每个基础模型都有一个必须考虑的生命周期。 与工作负荷中的代码库和其他依赖项一样，基础模型接收提供性能增强和优化的次要版本更新。 主要版本更新对功能、性能或训练数据新鲜度进行了实质性更改。 随着时间的推移，基础模型可能会因为过时或模型托管方的首选项而被弃用，这些因素超出了你的控制范围。

您必须设计您的工作负载，以支持您选择作为依赖项的模型的已记录生命周期。 如果不考虑模型的生命周期，则可能不必要地执行有风险的升级、引入未经测试的行为更改、造成不必要的工作负荷停机或遇到中断，因为托管平台处理生命周期结束模型的方式。

旨在支持其模型的生命周期的工作负荷使在进入市场时更容易试验并安全地迁移到新的基础模型。

模型更新的类型

生成式 AI 解决方案中模型更新的范围可能大不相同，从对次要修订的升级到选择新的模型系列。 你可能选择升级解决方案中的模型的原因有多种。 下表列出了不同的更新范围，以及进行此升级的示例和优点。

如表中所示，迁移到新模型的好处通常是以下因素的组合：

• 性能，例如速度和延迟

• 容量，例如以每分钟交易数来衡量的吞吐量

• 配额可用性

• 成本效益

• 区域可用性

• 多模式功能

• 更新了培训知识

• 故障修复

• 专用化或去专用化，以便更好地适应您的用例

• 为了避免工作负载中断，应考虑模型主机生命周期策略

模型退役行为

模型退出行为取决于模型部署策略。 部署模型有三个关键策略。 理解每个策略处理版本停用的方式很重要。

• MaaS（模型即服务）解决方案 是预先训练的模型，公开为 API，可提供可伸缩性和易于集成。 它们权衡了可能更高的成本和较低的模型控制。 MaaS 解决方案的示例包括 Azure OpenAI 服务中部署的模型和部署为无服务器 API 的模型目录中的模型。

• MaaP（模型即平台）解决方案 是在更大的平台中部署和管理的模型，例如托管 计算中部署的 Azure 模型目录中的模型。 此解决方案通常可以更好地控制模型，但需要比 MaaS 解决方案更多的管理。

• 自承载模型 是在自己的基础结构上部署的模型。 此部署提供对模型的最大控制，但需要对基础结构、管理和维护负有重大责任。

Azure AI 模型目录中的源模型是 Azure 中 MaaS 和 MaaP 策略的基础。 模型目录中的模型遵循一个生命周期，其中模型已 弃用 ，然后 停用。 必须在工作负荷中规划应对这些可能的情况。

自托管模型或使用托管计算服务时，可以保持完全控制，且不需要更新模型。 但你可能想要遵循模型生命周期，以便获得新模型为你的工作负荷带来的好处。

模型更新的更改范围

需要评估模型更新如何影响工作负荷，以便规划从旧模型到新模型的转换。 工作负荷更改的程度取决于旧模型与新模型之间的功能差异和非功能差异。 此图显示了一个简化的聊天体系结构，该体系结构包含编号部分，这些部分突出显示了模型更新可能会产生影响的区域。

对于每个区域，请考虑由更新导致的停机时间，以及如何处理系统正在处理的任何请求。 如果适用于您的工作负荷的维护时段可用，请在当修改幅度较大时使用这些时段。 如果无法安排维护时段，请在模型更新期间处理这些领域的变更，以确保您的工作负荷功能和服务级别目标得到维护。

1. 模型： 模型本身发生了明显的变化。 使用所选的模型部署策略部署新模型。 需要评估就地升级与并行部署之间的权衡。

   从微调的模型移动到新模型修订版时，需要在使用新模型版本之前再次对新模型版本执行微调。 更新为使用不同的模型时，需要确定是否需要微调。

2. 模型配置： 在 AI 解决方案中更新基础模型时，可能需要调整超参数或配置，以优化新模型的体系结构和功能的性能。 例如，从基于转换器的模型切换到循环神经网络可能需要不同的学习速率和批大小才能获得最佳结果。

3. 提示： 在工作负载中更改基础模型时，可能需要调整业务流程协调程序或代理中的系统提示，以符合新模型的优势和功能。

   更新模型配置的同时，更新提示是更新模型时最常见的更改之一。 在评估新模型时，即使是针对小版本更新，如果提示不符合你的要求，也要测试对其进行的更改。 此方法确保您在着手进行其他修改之前，先应对性能问题。 更换到新模型时，需要处理提示。 在进行大型修订更改时，可能需要处理提示。

4. 业务流程逻辑： 某些模型更新，尤其是在利用新功能时，需要对业务流程或代理逻辑进行更改。

   例如，如果将模型更新为 GPT-4 以利用 函数调用，则必须更改业务流程逻辑。 您的旧模型返回了一个可以返回给调用方的结果。 通过函数调用，对模型的调用将返回业务流程逻辑必须调用的函数。 在 Azure 中，通常通过在 Azure AI 代理服务 中或使用 Azure 中托管的基于代码的解决方案（如 语义内核 或 LangChain ）来实现业务流程逻辑。

5. 基础数据： 某些模型更新和范围更大的更改可能需要对您的基础或微调数据进行更改，或者改变您检索这些数据的方式。

   例如，从通用模型移动到特定于域的模型（例如专注于财务或医学的模型）时，可能不再需要将特定于域的地面数据传递给模型。 另一个示例是新模型可以处理更大的上下文窗口。 在此方案中，你可能想要检索其他相关区块或调整区块的大小。 有关详细信息，请参阅 设计和开发检索扩充生成（RAG）解决方案。

6. 硬件： 对于在 MaaP 中运行的模型，模型更改可能需要新的硬件。 仅为目录中的模型启用特定的计算 SKU。 此外，硬件可以弃用，这要求在新硬件上运行模型。

变化型设计

你很可能在工作任务中更新模型。 如果在 Azure 中使用 MaaS 部署策略，模型将停用，需要升级到较新版本。 还可以选择移动到不同的模型或模型版本，以利用新功能、较低的定价或改进的性能。 无论哪种方式，体系结构都必须支持更新生成 AI 工作负荷使用的模型。

上一部分讨论了 不同的更改范围。 应遵循适当的机器学习操作（MLOps）、数据操作（DataOps）和生成式 AI 操作（GenAIOps）做法，以构建和维护自动化管道，从而进行模型微调、构建提示、更改超参数和管理编排逻辑。

对超参数和提示的更新在大多数模型更新中很常见。 由于这些更改非常常见，因此体系结构应支持这些区域的受控更改机制。 一个重要考虑因素是，提示和超参数是为特定模型版本设计的。 需要确保提示和超参数始终与正确的模型和版本一起使用。

自动化管道

实现自动化管道来测试和评估生成 AI 应用程序的不同方面：

• MLOps： 按照 Azure MLOps 指南 生成用于模型微调的管道（如果适用）。

• GenAIOps： 实现 GenAIOps 管道，以 测试和评估模型、模型超参数、提示和业务流程逻辑的更改。

• DataOps： 实现 DataOps 管道，以测试和评估对 RAG 基础数据的更改。

以下是您应该实施管道流程的原因：

• 帮助你进行迭代开发和试验（内部循环）
• 进行生成型 AI 解决方案的安全部署和运作（外环流程）

如果可能，请使用与生产应用程序一起使用的相同基线数据来测试对生成 AI 应用程序的更改。 如果更新的应用程序使用需要更改数据的新模型功能，则可能无法使用此方法。

体系结构注意事项

在简单的体系结构（如以下体系结构）中，客户端直接使用正确的提示版本和配置调用模型。 如果提示发生了更改，则会使用新提示部署新客户端，并调用新模型。 关联提示、配置和模型版本并不是一个难题。

生产体系结构并不简单。 通常实现业务流程协调程序或代理，其责任是管理任何知识数据库和模型之间的交互流。 体系结构还可以实现一个或多个抽象层，例如路由器或网关：

• 路由器： 路由器将流量定向到不同的业务流程协调程序部署。 路由器在部署策略（例如蓝绿部署）中非常有用，你可以在其中选择将特定百分比的流量路由到新的业务流程协调程序版本，作为安全部署实践的一部分。 此组件还可用于 A/B 测试或流量镜像，以评估已测试但未经验证的更改对生产流量的影响。

• 网关： 出于 各种原因，代理访问 AI 模型很常见。 例如，可以对多个后端实例进行负载均衡或启用故障转移，实现自定义身份验证和授权，或者为模型实现日志记录和监视。

鉴于涉及多重间接指令，您的体系结构必须设计得能够支持向特定模型或模型版本发送特定版本的提示。 例如，你可能在生产环境中有一个提示，例如 prompt1，该提示是专为某个模型（例如 model1）设计的。 如果升级到 model1.1，您可能需要将 prompt1 更新为 prompt2。 在此示例中，体系结构需要始终将 prompt1 与 model1 和 prompt2 与 model1.1 配合使用。

路由器

下图演示了一个体系结构，该体系结构使用路由器将请求路由到多个部署。 此体系结构的另一个示例包括 Azure AI Foundry，并使用托管联机终结点作为路由器。 业务流程协调器的不同版本将部署到托管计算资源。

以下流程描述协调程序的不同部署如何调用正确的模型。 每个部署都有自己的模型配置版本和提示：

1. 用户从智能应用程序发出请求，并将该请求发送到路由器。

2. 根据其逻辑，路由器会路由到编排器的部署 1 或部署 2。

3. 每个部署都有自己的提示和配置版本。

4. 业务流程协调程序配置了特定的模型和版本。 它使用此信息直接调用相应的模型和版本。

5. 由于特定版本的提示随配置了特定模型和版本的业务流程协调程序一起部署，因此会将正确的提示发送到正确的模型版本。

网关

下图演示了一个体系结构，该体系结构使用路由器将请求路由到多个部署。 但是，在此体系结构中，所有模型请求都通过网关路由。 通常为了各种原因，需要代理对AI模型的访问，包括实现负载均衡、在单个或多个区域中启用多个后端实例之间的故障转移，以及通过即用即付溢出策略实现预定的吞吐量单元。

以下流程描述了协调器的不同部署方式如何通过网关调用正确的模型。 每个部署都有自己的模型配置版本和提示：

1. 用户从智能应用程序发出请求，并将该请求发送到路由器。

2. 路由器将路由到部署 1 或部署 2，具体取决于其逻辑。

3. 每个部署都有其独特的提示版本。

4. 业务流程协调程序配置了特定的模型和版本。 它使用此信息设置一个 HTTP 标头，该标头指示要调用的正确模型和版本。

5. 调度程序调用网关。 请求包含 HTTP 标头，指示要使用的模型的名称和版本。

6. 网关使用 HTTP 标头将请求路由到相应的模型和版本。 它还可能应用在网关上定义的配置。

外部化配置

外部配置存储云设计模式是处理存储提示和配置的好方法。 对于某些模型更改范围，如果它们存储在您的业务流程管理器或代理程序代码之外的可更新位置，您可能能够通过系统提示和配置更改来协调模型部署。 如果你需要调整业务流程逻辑，此方法不起作用，但在许多较小范围的模型更新中非常有用。

计算选择

对于 MaaP 托管，模型通常仅限于主机提供的计算资源的子集。 所有计算都受配额、可用性约束和生命周期终止公告的约束。 当当前硬件不再受支持或存在阻止额外横向扩展的约束时，请使用路由模式来支持过渡到新硬件。

终止公告的一个示例是 NC A100 v4 系列计算公告。 如果在此硬件上托管模型，则必须过渡到另一个支持的 SKU，该 SKU 不是生命周期结束并且具有更多可用性。 如果新 SKU 不支持当前模型，此转换可能还需要更改模型。

建议

• 添加抽象层和间接层，以便对工作负荷的特定区域进行受控修改。 这些领域包括客户端、智能应用程序 API、业务流程、模型托管和基础知识。

• 在生产环境中使用之前，必须测试对模型版本、提示、配置、业务流程逻辑和基础知识检索所做的所有更改。 确保测试的组合在生产环境中是密切绑定的，这意味着它们在部署时保持紧密链接。 A/B 测试、负载均衡和蓝绿部署不得混合组件，以避免向用户公开未经测试的组合。

• 使用自动化管道测试和评估新版本和新模型。 应将结果与基线的结果进行比较，以确保获得所需的结果。

• 有意更新模型。 避免使用自动将生产模型升级到新版本的平台功能，而无需有机会进行测试。 需要了解每个模型更新如何影响工作负荷。 如果使用 Azure AI 模型推理，请使用特定版本设置部署，并且不提供升级策略。 如果新版本发布，此设置需要手动升级。 对于 Azure OpenAI，请将部署设置为 “无自动升级 ”以关闭自动升级。

• 确保可观测性和日志记录解决方案收集足够的元数据，以将观察到的行为与涉及的特定提示、配置、模型和数据检索解决方案相关联。 通过此关联，可以识别系统性能中的意外回归。

概要

在生成工作负荷中更新基础模型有多种原因。 这些原因包括模型停用时的必要版本升级到选择切换到其他模型的决定等。 根据模型更新的范围，可能需要实现和评估对模型的更改，包括对提示、模型配置、业务流程逻辑或数据管道的更改。 应遵循 MLOps、DataOps 和 GenAIOps 指南，为解决方案的不同方面构建自动化工作流。 通过自动化工作流，可以测试、评估和部署新版本。 还需要确保体系结构支持运行多个版本的业务流程协调程序，其中每个版本将配置和提示版本链接到特定模型版本。

体系结构应支持更新新的或不同的模型，以及对提示或模型配置所做的任何必要更改，而无需修改智能应用程序或用户体验。 这些更新应封装在其相应的组件中，你的操作流程应自动执行这些更改的测试、评估和部署。

供稿人

Microsoft维护本文。 以下参与者撰写了本文。

• Ritesh Modi | 首席软件工程师

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。

后续步骤

• Azure OpenAI 模型弃用和停用

相关资源

• 基线 AI Foundry 聊天参考架构
• MLOps
• GenAIOps 为 MLOps 从业者而设计