通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 上的 AI 工作负载的设计原则

  • 项目

本文概述了 Azure 上的 AI 工作负载的核心原则，重点介绍体系结构的 AI 方面。 必须一起考虑 Azure Well-Architected 框架的所有支柱，包括它们的权衡。 将每个支柱应用于工作负荷的功能和非功能要求。

可靠性

在 Azure 中运行的 AI 工作负荷必须考虑许多与其他工作负荷类相同的可靠性要求。 模型训练、部署和推理的具体注意事项尤为重要，主要在这一原则中得到解决。 此处概述的实践除了适用于云应用程序的标准设计最佳做法外，还应相应地集成。

查看 可靠性设计原则，大致了解此处介绍的概念。

设计原则 注意事项
缓解单一故障点。 依赖关键组件的单个实例可能会导致重大问题。 为防止问题，请在所有关键组件中生成冗余。 使用具有内置容错和高可用性功能的平台。 部署多个实例或节点以实现冗余。
执行故障模式分析。

利用已知的设计模式。		 定期分析系统组件中的潜在故障模式，并针对这些故障构建复原能力。 使用已知的设计模式隔离系统的各个部分，并防止级联故障。 例如，隔舱模式可以帮助隔离故障。 重试机制和断路器可以处理暂时性错误，例如限制请求。
跨依赖组件平衡可靠性目标。 确保推理终结点或模型以及数据存储在可靠性方面保持一致。 即使出现意外情况（例如并发用户激增），应用程序组件也必须保持可用。 如果发生故障，工作负载还应能够切换到备份系统。 如果一个组件发生故障，它将影响另一个组件的可靠性。

同样，由于服务层 API 是关键的生产资源，因此它们应遵循与其他高关键工作负荷流相同的可靠性标准。 如果这些 API 需要高可用性，托管平台必须支持可用性区域或多区域设计，以确保持续操作和复原能力。
设计操作可靠性。 通过确保更新频繁且及时地维护模型响应的可靠性。 确定是否使用最近的数据，或者是否稍旧的数据已足够。 平衡对最新信息的需求和更新频率的实用性。 由于其频率和可靠性要求，自动执行联机培训。 通过成本效益分析来证明脱机培训的合理性，并使用更便宜的资源执行它。
设计可靠的用户体验。 使用负载测试来评估工作负荷如何处理压力，并设计用户界面来管理有关响应时间的用户期望。 实现 UI 元素，告知用户潜在的等待时间，并采用异步云设计原则来解决省际、延迟或故障。

安全性

模型通常使用敏感的生产数据来生成相关结果。 因此，必须在体系结构的所有层使用可靠的安全措施。 在生命周期早期实施安全的应用程序设计，加密静态数据和传输中的数据，并遵循行业标准标准。 定期安全评估对于识别和缓解漏洞至关重要。 高级威胁检测机制可确保及时响应潜在威胁。

安全原则 是 AI 解决方案保护数据完整性、设计完整性和用户隐私的基础。 作为工作负荷所有者，你负责构建信任和保护敏感信息，以确保安全的用户体验。

设计原则 注意事项
赢得用户信任。 使用自定义代码、适当的工具和有效的安全控制，在生命周期的每个阶段集成内容安全。

删除所有数据存储点（例如聚合数据存储、搜索索引、缓存和应用程序）中不需要的个人和机密信息。 在整个体系结构中一致地保持这种安全级别。

确保彻底的内容审查检查两个方向的数据，并筛选出不适当的和冒犯性的内容。
根据工作负荷的敏感度要求保护静态数据、传输中的数据和使用数据。 至少，在体系结构中使用的所有数据存储上使用具有Microsoft托管或客户管理的密钥的平台级加密。 根据需要评估需要更高级别的加密并使用双重加密的位置。

确保所有流量都使用 HTTPS 进行加密。 确定每个跃点的 TLS 终止点。

必须保护模型本身，以防止攻击者提取训练期间使用的敏感信息。 此保护需要最高级别的安全措施。 请考虑使用允许推断加密数据的同态加密。
投资可靠的访问管理来保留访问系统的标识（用户和系统）。 为控制和数据平面实现基于角色的访问控制或基于属性的访问控制。

维护适当的身份分隔以保护隐私。 只允许访问他们有权查看的内容。
通过分段保护设计的完整性。 提供专用网络，以便访问容器映像、数据和代码资产的集中式存储库。

当与其他工作负荷共享基础结构创建分段时，例如，当在 Azure Kubernetes 服务中托管推理服务器时，将节点池与其他 API 或任何其他工作负荷隔离开来。
进行安全测试。 制定详细的测试计划，包括每当引入系统更改时检测不道德行为的测试。

将 AI 组件集成到现有的安全测试中。 例如，将推理终结点与其他公共终结点合并到例程测试中。

考虑对实时系统（如渗透测试或红队练习）进行测试，以有效识别和解决潜在漏洞。
通过强制实施严格的用户访问和 API 设计来减少攻击面。 要求对所有推理终结点（包括系统到系统调用）进行身份验证。 避免匿名终结点。

首选受约束的 API 设计，但代价是客户端灵活性。

权衡。 提供最高安全性在成本和准确性方面存在权衡，因为分析、检查或记录加密数据的能力有限。 在高度安全的环境中，内容安全检查和实现可解释性也可能具有挑战性。

以下设计区域提供有关上述原则和注意事项的详细信息：

成本优化

成本优化支柱旨在最大化投资，但不一定降低成本。 每个体系结构选择都有直接和间接的财务影响。 了解与各种选项相关的成本，包括生成与购买决策、技术选择、计费模型、许可、培训和运营费用。 最大化所选层的投资，并持续重新评估计费模型。 持续评估与体系结构、业务需求、流程和团队结构变化相关的成本。

查看成本优化原则，重点关注费率和使用情况优化。

设计原则 注意事项
通过执行全面的成本建模练习来确定成本驱动因素。 考虑数据和应用程序平台的关键因素：
- 数据量。 估计要编制索引和处理的数据量。 较大的卷会增加存储和处理成本。
- 查询数。 预测查询的频率和复杂性。 较高的查询卷可能会增加成本，尤其是在需要大量计算资源的情况下。
吞吐量- 。 评估预期的吞吐量，这会影响所需的性能层。 更高的吞吐量需求可能导致更高的成本。
- 依赖项成本。 依赖项中可能存在隐藏成本。 例如，计算索引的成本时，包括技能集的成本，该成本是数据处理的一部分，但超出了索引范围。
支付要使用的费用。 选择满足需求的技术解决方案，而无需产生不必要的费用。 如果不需要高级功能，请考虑更经济的选项和开源工具。

考虑使用频率。 为业务流程工具选择弹性计算选项，以尽量减少使用成本，因为它们始终开启。 避免对全职操作进行无服务器计算，因为可能会导致成本上升。

在未充分利用其容量的情况下，不要为更高层级付费。 确保所选层与生产使用模式保持一致，以优化支出。 对常规任务使用标准定价，并针对高度中断性训练使用现成定价。 仅对 AI 工作负荷函数使用基于 GPU 的计算来降低成本。

对培训和微调进行广泛的测试和基准测试，以找到平衡性能和成本的理想产品版本。
使用你支付的内容。 尽量减少浪费。 密切监视利用率指标。 如果资源未关闭、纵向缩减或解除分配，则 AI 工作负载可能很昂贵，如果资源未关闭、缩减或解除分配，则成本可能会很快升级。

优化系统以写入 一次，读取许多 内容以避免在数据存储上超支。 训练数据不需要生产数据库的即时响应能力。

由于每次调用都会产生费用，对 Azure OpenAI 服务推理终结点进行压力测试可能会非常昂贵。 若要降低成本，请在测试环境中使用 Azure OpenAI 的未使用的 PTU，或改为模拟推理终结点。

探索数据分析（EDA）、模型训练和微调等活动通常不会全职运行。 首选可以在不使用时停止的系统。 例如，EDA 作业通常是交互式的，因此用户需要能够在运行作业时启动 VM 并停止它们。

在运营团队中设置成本责任。 它们应通过主动监视和管理资源利用率来确保成本保持在预期参数内。
优化运营成本。 由于在线培训的频繁性，在线培训成本可能很高。 自动化此过程有助于保持一致性，并最大限度地减少人为错误带来的成本。 尽可能使用略旧的数据来训练和延迟更新，以进一步减少开支，而不会显著影响模型准确性。

对于脱机培训，请评估是否可以使用更便宜的资源，例如脱机硬件。

通常，从功能存储中删除数据以减少功能混乱和存储成本。

权衡：成本优化与性能效率。 在数据库管理中，平衡成本与性能需要考虑权衡。 高效的索引设计加快了查询速度，但由于元数据管理和索引大小，可能会增加成本。 同样，分区大型表可以提高查询性能并减少存储负载，但会产生额外的成本。 相反，避免过度编制索引的技术可以降低成本，但如果未正确管理，可能会影响性能。

权衡：成本优化和卓越运营。 模型训练的两种主要方法都有利弊。 在具有完整生产数据的开发环境中进行训练可以通过训练一次模型并仅推广工件来降低计算成本。 在较低的环境中处理生产数据需要严格的安全措施。 该过程可能比较复杂，资源密集型。 相反，通过彻底的代码评审和测试来训练每个环境中的模型可增强稳定性和可靠性，但由于多次训练运行，计算成本会增加。

卓越运营

卓越运营的主要目标是在整个开发生命周期内高效地提供功能。 必须建立支持试验设计方法并产生结果的可重复过程，以提高模型性能。 卓越运营还涉及观察模型随时间推移的持续准确性，实施有效的监视做法和治理，以尽量减少风险，并制定适应模型偏移的变更管理流程。

尽管所有 卓越运营原则 适用于 AI 工作负载，但将自动化和监视作为基础运营策略的优先级。

设计原则 注意事项
在整个应用程序开发、数据处理和 AI 模型管理生命周期中培养持续学习和试验思维模式。 工作负荷操作应基于行业证明的方法，如 DevOps、DataOps、MLOps 和 GenAIOps。

运营、应用程序开发和数据团队之间的早期协作对于建立对可接受的模型性能的相互了解至关重要。 运营团队提供质量信号和可操作警报。 应用程序和数据团队有助于有效地诊断和解决问题。
选择尽量减少操作负担的技术。 选择平台解决方案时，首选平台即服务（PaaS）而不是自承载选项，以简化设计、自动化工作流业务流程以及简化第 2 天操作。
构建支持警报功能的自动化监视系统，包括日志记录和可审核性。 鉴于 AI 的非确定性特征，在生命周期早期建立质量度量是非常重要的。 与数据科学家合作，定义质量指标，并在全面的仪表板中可视化持续的见解。

通过可捕获代码版本、环境、参数、运行和结果等详细信息的工具跟踪试验。

实现具有足够信息的可操作警报，使操作员能够快速响应。
自动检测和缓解模型衰减。 使用自动测试来评估随时间推移的偏差。 确保监视系统在响应开始偏离预期结果时发送警报，并定期开始这样做。 使用可自动发现和更新新模型的工具。

根据需要调整数据处理和模型训练逻辑，适应新的用例。
练习安全部署。 在并行部署或就地更新之间进行选择，以最大程度地减少停机时间。 在部署之前实施彻底的测试，以确保模型正确配置并满足目标、用户期望和质量标准。 无论部署策略如何，始终规划紧急操作。
持续评估生产中的用户体验。 使工作负荷用户能够提供有关其体验的反馈，并同意在关联的日志中共享部分或所有对话，以便进行故障排除。 考虑用户交互的哪些部分是可行的、合规的、安全的以及值得捕获的。 谨慎地使用数据，通过实际用户交互评估工作负载的性能。

以下设计区域提供有关上述原则和注意事项的详细信息：

性能效率

AI 模型性能评估的目标是确定模型如何有效地完成其预期任务。 评估涉及评估各种指标，例如准确性、精度和公平性。 支持模型的平台和应用程序组件的性能至关重要。

模型性能也受试验跟踪和数据处理等操作效率的影响。 应用 性能效率原则 来帮助根据可接受的质量条来衡量性能，这是检测退化或衰减的关键。 若要维护工作负荷（包括 AI 组件），必须执行用于持续监视和评估的自动化过程。

设计原则 注意事项
建立性能基准。 在不同体系结构区域执行严格的性能测试，并设置可接受的目标。 此持续评估应是运营流程的一部分，而不仅仅是一次性测试。

基准测试适用于预测性能。 从基线开始，了解初始模型性能并持续重新评估，以确保它符合预期。
评估资源需要满足性能目标。 了解负载特征，以便选择正确的平台和正确的资源大小。 请将这些数据纳入考虑以进行容量规划，实现大规模运行。

例如，使用负载测试来确定最佳计算平台和产品版本。 模型训练和微调通常需要高性能 GPU 优化计算。 通用产品版本适用于编排工具。

同样，选择一个数据平台，该平台可以有效地处理数据引入、管理并发写入，并维护单个写入性能，而不会降低。

不同的推理服务器具有影响运行时模型性能的各种性能特征。 选择满足基线预期的服务器。
收集和分析性能指标并识别瓶颈。

评估来自数据管道的遥测数据，以确保满足吞吐量和读/写操作的性能目标。
对于搜索索引，请考虑诸如查询延迟、吞吐量和结果准确性等指标。 随着数据量的增加，错误率不应上升。

分析来自代码组件（例如业务流程协调程序）的遥测数据，该业务流程协调程序从服务调用收集数据。 分析这些数据，帮助你了解在本地处理与网络调用上花费的时间，并确定其他组件的潜在延迟。

使用参与指标评估 UI 体验，以确定用户是否积极参与或感到沮丧。 页面停留时间增加可能表明两种情况之一。 多模式功能（如语音或视频响应）可能会经历大量的延迟，这会导致响应时间更长。
使用生产质量度量持续提高基准性能。 需要自动收集和分析性能指标、警报和模型重新训练，以保持模型有效性。

权衡。 考虑平台功能时，请确保平衡成本和性能。 例如，GPU 版本成本高昂，因此需要持续监视资源的使用情况，并根据需求对资源大小进行适当调整。 调整后，测试资源利用率，以确保根据基线在平台资源的成本与其操作与预期性能之间进行平衡。 有关成本优化策略，请参阅 有关优化组件成本的建议。

以下设计区域提供有关上述原则和注意事项的详细信息：

下一步

设计区域：应用程序设计