通过

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

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

  • 项目

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

可靠性

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

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

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

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

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

安全性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

成本优化

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

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

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

考虑使用频率。 首选业务流程工具的弹性计算选项，以最大程度地降低利用率成本，因为它们 始终处于开启状态。 避免由于潜在的成本升级而导致全职操作的无服务器计算。

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

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

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

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

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

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

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

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

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

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

卓越运营

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

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

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

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

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

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

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

权衡：卓越运营和复杂性成本。

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

性能效率

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

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

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

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

例如，使用负载测试来确定最佳计算平台和 SKU。 模型训练和微调通常需要高性能 GPU 优化计算，而常规用途 SKU 适用于业务流程工具。

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

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

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

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

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

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

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

下一步

设计区域：应用程序设计