你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 上 AI 工作负载的应用程序平台
必须仔细考虑部署 AI 工作负荷的应用程序托管平台，以确保可以最大限度地提高效率、操作的安全性和可靠性。
此设计区域涵盖可能与 AI 工作负载相关的多种应用程序：
- 探索性数据分析 (EDA)
- 模型训练和微调
- 推理
本文提供了为每种功能选择最佳平台以满足业务需求的指导。 还可以向所有这些函数应用一般建议。
建议
下面是本文中提供的建议摘要。
| 建议 | 说明 |
|---|---|
| 重复使用工具。 | 首先，评估已用于了解是否可以重复使用 AI 工作负载的工具。 如果它们支持所需的功能，并且可以满足可靠性、安全性、成本和性能的要求，引入新工具可能不值得成本和工作量。 |
| 考虑对数据以及计划在其中部署的区域的符合性要求。 | 可能需要限制部署的区域，或将工作负荷的各个部分彼此隔离，以满足符合性要求。 使用此信息进入设计阶段有助于防止以后需要重新设计。 |
| 最小化生成。 | 考虑平台即服务（PaaS）或软件即服务（SaaS）解决方案，以尽量减少构建自己的解决方案（如修补和其他维护）带来的操作负担。 最大限度地减少新技术所需的第 2 天负担可简化采用。 许多 AI 函数很复杂，因此不建议构建自己的平台。 |
| 了解配额和限制。 | 设计使用 PaaS 或 SaaS 解决方案时，请了解应用的任何配额或限制。 横向扩展以满足高流量需求的能力可能会受到配额或限制的影响，因此可能需要调整设计，以最大程度地降低这种风险。 |
| 在同一区域中部署。 | 尝试在同一区域中部署所有相关资源，以减少延迟并简化设计。 |
| 练习安全部署。 | 通常，应将 AI 工作负载的 API 视为与环境中的任何其他 API 相同。 所有 API 都应放在网关后面，所有代码都应处理与所有其他代码资产相同的 安全部署做法 。 |
| 通过试验建立性能基准。 | 每个 AI 工作负载都是不同的，所需的计算量取决于用例。 通过执行全面的基准测试来确定最适合工作负荷的计算量和类型。 本指南可帮助你选择一个平台，但在基准测试后，你只会知道哪些 SKU 适用于工作负荷。 |
EDA 平台的注意事项
EDA 是数据科学家在建模或统计分析之前执行的常见初步功能。 因此，它可以被视为一个开发阶段，这意味着可靠性和性能的目标可能明显低于生产资源的目标，保持工作效率是更重要的因素。
本部分提供有关选择 EDA 平台解决方案时要考虑的功能的指导。
功能要求
评估 EDA 平台时，请考虑以下问题：
平台是否支持暂时性使用？
平台应支持暂时性工作区和计算，这意味着在不使用临时工作区时，应该能够停止必要的资源。 此功能有助于控制成本。 EDA 作业通常是交互式的，因此用户需要能够在运行作业时启动 VM 并停止它们。
平台是否支持计算可选性？
平台应根据需要启用对 GPU 的按需访问，并提供各种计算选项来帮助调整平台的大小。
平台是否支持 MLflow？
EDA 平台应能够选择一种技术，以便与 MLflow 集成以跟踪试验。 建议将 MLflow 作为模型开发、部署和管理协议，因为它具有以下优势：
- 试验跟踪。 通过 MLflow，可以通过记录参数、指标和项目来跟踪试验。 此功能在 EDA 期间至关重要，因此可以跟踪不同的数据预处理步骤和特征工程技术及其对模型性能的影响。
- 再现性。 由于它记录了试验的所有详细信息，因此 MLflow 有助于确保可以重现结果，这对于验证结果至关重要。
- 数据和模型版本控制。 MLflow 有助于对数据集和模型进行版本控制，从而更轻松地管理不同版本的数据转换和测试模型。
- 协作工作。 MLflow 提供了一个集中式平台，数据科学家可在其中共享其实验和结果，从而促进协作和知识共享。
非功能需求
请考虑以下问题：
平台如何帮助控制成本？
该平台应使数据科学家能够根据其计划要求执行其工作，但应适当调整大小，以确保满足成本预期。
平台必须遵循哪些安全要求？
在 EDA 阶段使用的数据可能是生产数据，这要求你遵循生产做法来保护该数据并监视平台。 为此，平台应支持所有必要的安全控制，包括：
- 访问和授权。
- 静态加密和传输中加密。
- 区域数据保护要求。
- 可靠的监视和警报功能，包括日志记录和可审核性。
- 对容器映像、数据和代码资产的集中式存储库进行专用网络访问。
工具
将具有团队级文件共享的Azure 机器学习计算实例用作 EDA 平台。 一个例外是，如果你的团队或组织已经在使用合适的托管平台，例如 Databricks 中启用了 GPU 的计算群集。 在这种情况下，留在该平台可能更合适。
注意
除非需要，否则不要生成完整的 EDA 平台。 GPU 优化计算成本高昂，如果用例不需要，则不合适。
模型训练和微调平台的注意事项
移动到模型训练和微调时，可能需要高性能 GPU 优化计算，才能完成这些活动所需的计算密集型工作。 可靠性通常不如性能那么重要，因为大部分工作都发生在后台。 如果要求较高的可靠性，请评估是否需要跨可用性区域或区域分散工作负荷。 当频繁更新模型新鲜度时，可靠性会变得更加重要，这要求按照更严格的计划完成训练。 RTO 应确定所选的可靠性设计。
本部分中的指南适用于模型训练和微调。 除非被迫为这些函数使用单独的平台，否则应使用单个平台。
功能要求
评估用于模型训练和微调的平台时，请考虑以下问题：
平台是否支持暂时性使用？
与 EDA 活动一样，模型训练和微调通常不会全职运行，因此应使用一个平台，当平台未用于帮助控制成本时可以停止。 但是，与 EDA 不同，模型训练通常是一个批处理进程，因此仅在批处理运行时需要计算，并且可以在下一次运行之前关闭计算。
平台是否提供业务流程？
由于管理模型训练和微调计算所需的复杂性，建议使用业务流程协调程序。
环境中的现有技术能否成为解决方案的一部分？
如果现有数据平台具有机器学习功能（如 Azure Databricks），则可以将其用于某些步骤，例如数据转换和特征工程、训练、微调和其他机器学习步骤。 组合技术可帮助你最大程度地降低使用数据平台处理它可能不适合的函数的成本和复杂性。
非功能需求
同时考虑此问题：
成本和性能之间的可容忍权衡是什么？
鉴于高性能的 GPU 优化计算要求，请确保广泛测试和对训练和微调进行基准测试，以确定将性能与成本相平衡的理想 SKU。
工具
建议为模型训练和微调平台Azure 机器学习，因为它为业务流程功能提供批处理计算支持。 有两个计算选项可供选择：
- 无服务器计算 非常适合短、不频繁的运行，可以容忍干扰邻居效应。 可以选择标准定价或现成定价。 仅建议使用现成定价进行高度中断的培训。 不要将无服务器计算用于全职操作。 成本可以快速上报。
- 计算群集 可显著控制可用硬件，并针对并行或分布式训练进行优化。
注意
对于基础模型，选择的模型托管平台可能会限制微调选项。 例如，将 Azure OpenAI 服务用于模型托管将微调选项限制为内置的 Azure OpenAI 微调功能。
模型托管和推理平台的注意事项
模型托管和推理函数构成了 AI 工作负载的服务层。 这些函数是使用特定于所用软件的终结点执行的。 模型服务软件解决方案（如 NVIDIA Triton、TorchServe 和 TensorFlow 服务）实质上是 Python SDK，它前面是一个具有 API 的模型，并添加特定于解决方案的功能。 可以根据所选的软件选择托管平台，或根据所选的托管平台选择软件。
将 SaaS 或 PaaS 解决方案用于预打包模型（如 Azure OpenAI 中提供的大型语言模型）时，几乎没有机会选择服务软件。 相反，你正在使用的服务提供 API。 这样可以降低创建模型部署的灵活性，从而提供优点和缺点。 例如，它可以简化工作负荷的开发过程。 另一方面，它减少了应用程序如何调用和与模型交互的灵活性。
从根本上讲，服务层的 API 是微服务，因此应遵循针对环境中其他微服务遵循的相同做法。 它们应容器化、 从其他服务批量传输 ，并具有独立于其他服务和 API 的自己的生命周期。 但是，请记住，服务层 API 通常需要比传统 API 更多的基于 GPU 的计算能力和更大的容器映像。
本部分提供有关选择模型托管和推理平台时要考虑的功能的指导。
功能要求
评估用于模型托管和推理的平台时，请考虑以下问题：
工作负荷是否需要批处理或联机推理？
推理终结点用于批处理或联机推理进程，推理方法有助于确定正确的托管平台。 批处理推理最好托管在支持暂时性使用的平台上，并允许在不使用计算时关闭计算。 联机推理最好托管在支持弹性计算利用率的平台上，该利用率可根据任何给定时间的负载自动缩放。
平台是否支持可跟踪性？
可跟踪性对于维护工作负荷中使用的模型的完整性至关重要。 了解有关模型的信息非常重要，例如当前版本、部署模型、部署时间以及模型的数据世系。
将有意义的标记应用于容器注册表中的映像，以确保模型托管服务拉取团队可以轻松识别的特定版本。 此方法通过降低生产环境中使用过时或不正确的模型的风险来帮助进行数据管理。
你的托管平台是否会是集中式资源？
许多组织使用由不同团队用于自己的工作负荷的集中式模型托管平台。 如果托管平台是集中式的，则应考虑是否需要支持退款。 此功能允许你按团队和工作负荷跟踪平台利用率。
非功能需求
请考虑以下问题：
平台的可靠性要求是什么？
服务层 API 是生产资源，因此应将相同的可靠性要求应用于符合其 关键性 评级的其他工作负荷流。 如果关键性需要高可用性，托管平台应支持可用性区域或多区域设计。
平台需要哪些网络控制？
确定是需要专用网络还是出口防火墙来为平台提供保护。
平台的标识和访问安全要求是什么？
确定终结点所需的标识和访问控制。 请考虑是否需要本机基于角色的访问控制（RBAC）或对标识和访问平台的内置支持，例如，Microsoft Entra ID。
平台支持哪些监视功能？
确定终结点所需的监视功能。 根据平台，你可能对日志和指标的访问权限有限，这可能会限制审核活动或检测故障的能力。
平台的性能要求是什么？
推理延迟是常见的问题，不同的平台具有不同的性能配置文件。 使用实用工具模型的无服务器和 PaaS 服务可能会受到干扰邻居问题的影响，并且通常没有吞吐量保证。 另一方面，同一平台可能会提供自承载选项，该选项通过预购买模型提供有保证的吞吐量。 还可以考虑在 Kubernetes 上自行托管，以便更可预测的延迟行为。
请注意可能会影响性能的服务限制和配额，例如 Azure OpenAI 的服务限制和配额。 通常，这些配额和限制被积极设置为满足容量需求，因此，如果你选择的平台不提供所需的性能，则可能需要采用策略来将计算需求分散到实例之间。
高级体系结构可以合并多个部署，以实现针对大部分工作负荷的固定吞吐量和更灵活的计算突发功能。
工具
批处理推理
如果要对驻留在支持模型托管的平台中的数据执行推理，例如 Databricks，请考虑使用该平台进行推理。 请务必将推理计算与数据平台执行的其他函数隔离开来。
建议为基础模型使用 Azure OpenAI Batch API 。
对于非基础模型，请考虑以下建议：
请考虑对以下方案使用Azure 机器学习批处理终结点：
你需要对分布在多个文件中的大型数据集执行推理，并且不需要低延迟。
需要对大型数据集执行长时间运行的批处理操作，并可以利用并行化。
需要部署管道组件进行批处理。
如果需要运行 Spark 作业进行分布式数据处理，请考虑使用 Azure Synapse Analytics、Databricks 或 机器学习无服务器 Spark 计算。
如果这些方案均不适用，建议机器学习批处理终结点。
联机推理
将平台 PaaS 和无服务器解决方案评估为第一步。 这些服务通常是最简单的采用和管理服务，因为它们简化了设计，并最大限度地减少了运营负担。 例如，Azure OpenAI 是基础模型的一个不错的选择。
- 请考虑使用 Azure 机器学习 无服务器 API 来聚合终结点访问，即使使用 Azure OpenAI 或其他基础模型托管解决方案也是如此。
当 PaaS 或无服务器解决方案不适合时，请考虑使用托管计算群集机器学习。 由机器学习管理的计算支持用于 A/B 测试、调试和可靠审核的流量拆分和镜像。 由于计算由服务管理，因此自承载模型时，第 2 天操作更容易。 托管计算还提供广泛的计算配置和缩放功能。
如果选择在附加到机器学习或其他基于容器的平台的 Azure Kubernetes 服务 （AKS） 群集上自行托管模型，请确保节点池独立于群集上的其他 API 或任何其他工作负荷，以实现可预测的性能并优化安全性。 避免对 AI 工作负荷函数以外的任何内容使用基于 GPU 或 GPU 优化的计算来降低成本。 相反，通过测试和正确调整计算大小来建立性能基线，以满足性能要求，而无需过度预配。
还可以使用基础结构即服务（IaaS）解决方案（例如 Azure 数据科学 虚拟机）自行托管模型。
业务流程平台的注意事项
业务流程在 AI 工作负荷应用程序平台的上下文中是指机器学习和 Azure AI Studio 中的提示流等工具。 这些工具旨在通过自动化许多常见工作流函数来简化 AI 应用程序的整个开发周期。
非功能需求
与云资产中的所有其他生产工作负荷一样，评估业务流程工具时，需要考虑：
可靠性、安全性和监视。 业务流程工具应遵循生产工作负荷的可靠性、安全性和监视标准。
性能。 业务流程工具不需要 GPU 优化或基于 GPU 的计算，请考虑常规用途 SKU。
成本优化。 业务流程工具始终 处于开启状态，请考虑弹性计算选项，以最大程度地降低利用率成本。
工具
首选现成的解决方案，例如提示流。 在使用 LangChain 或语义内核等工具查看自定义托管之前，确定其功能是否符合业务流程需求。
解决方案的主机终结点，例如使用计算实例的机器学习上的提示流，或者在具有自承载的 AKS 上。