部署

在软件工程中，将代码投入生产需要尽职调查，因为代码可能会出现意外行为，不可预见的用户行为可能会破坏软件，并且会发现意想不到的边缘情况。软件工程师和 DevOps 工程师通常采用单元测试和回滚策略来降低这些风险。使用机器学习，将模型投入生产需要更多的规划，因为实际环境预计会发生变化，而且在许多情况下，模型是根据指标进行验证的，这些指标代表了他们想要改进的实际业务指标。

请遵循本节中的最佳实践，以帮助应对这些挑战。

自动化部署周期

培训和部署过程应完全自动化，以防止人为错误并确保始终如一地运行构建检查。用户不应拥有生产环境的写入权限。

Amazon SageMaker AI Pipelines 和AWS CodePipeline帮助创建CI/CD pipelines for ML projects. One of the advantages of using a CI/CD管道是，所有用于采集数据、训练模型和执行监控的代码都可以使用 Git 等工具进行版本控制。有时，你必须使用相同的算法和超参数，但数据不同，来重新训练模型。验证你使用的算法版本是否正确，唯一的方法是使用源代码控制和标签。您可以使用 A SageMaker I 提供的默认项目模板作为 MLOps 练习的起点。

在创建 CI/CD 管道来部署模型时，请务必使用构建标识符、代码版本或提交以及数据版本来标记构建工件。此练习可帮助您解决任何部署问题。在高度监管的领域进行预测的模型有时也需要标记。能够向后工作并识别与机器学习模型相关的确切数据、代码、构建、检查和批准，可以帮助显著改善治理。

CI/CD 管道的部分工作是对其正在构建的内容进行测试。尽管预计数据单元测试将在feature store摄取数据之前进行，但管道仍负责对给定模型的输入和输出执行测试并检查关键指标。此类检查的一个例子是在固定验证集上验证新模型，并使用既定阈值确认其性能与以前的模型相似。如果性能明显低于预期，则构建应该失败，模型不应投入生产。

CI/CD 管道的广泛使用还支持拉取请求，这有助于防止人为错误。使用拉取请求时，每项代码更改都必须经过至少一名其他团队成员的审核和批准，然后才能投入生产。拉取请求对于识别不符合业务规则的代码以及在团队中传播知识也很有用。

选择部署策略

MLOps 部署策略包括blue/green, canary, shadow, and A/B测试。

蓝/绿

Blue/green deployments are very common in software development. In this mode, two systems are kept running during development: blue is the old environment (in this case, the model that is being replaced) and green is the newly released model that is going to production. Changes can easily be rolled back with minimum downtime, because the old system is kept alive. For more in-depth information about blue/green在的背景下部署 SageMaker，请参阅 M AWS achine Learning 博客 AWS CodeDeploy上的 “安全部署和监控 SageMaker Amazon AI 终端节点” 的博客文章。 AWS CodePipeline

金丝雀

Canary 部署与blue/green deployments in that both keep two models running together. However, in canary deployments, the new model is rolled out to users incrementally, until all traffic eventually shifts over to the new model. As in blue/green部署类似，风险可以降低，因为新的（可能存在故障）模型在初始部署期间会受到密切监控，并且可以在出现问题时回滚。在 SageMaker AI 中，您可以使用 InitialVariantWeightAPI 指定初始流量分布。

影子

您可以使用影子部署将模型安全地投入生产。在此模式下，新模型可与旧模型或业务流程配合使用，并且在不影响任何决策的情况下进行推断。在将模型升级到生产之前，此模式可用作最终检查或更高保真度的实验。

当你不需要任何用户推理反馈时，暗影模式非常有用。您可以通过执行误差分析并将新模型与旧模型进行比较来评估预测的质量，也可以监控输出分布以验证其是否符合预期。要了解如何使用 SageMaker AI 进行影子部署，请参阅 Machine Learning 博客上的博客文章 “在 Amazon SageMaker AI 中部署影子 AWS 机器学习模型”。

A/B 测试

当机器学习从业者在其环境中开发模型时，他们优化的指标通常是真正重要的业务指标的代名词。这使得很难确定新模式是否真的会改善业务成果，例如收入和点击率，并减少用户投诉的数量。

以电子商务网站为例，该网站的业务目标是销售尽可能多的产品。审核小组知道，销售和客户满意度与内容丰富且准确的评论直接相关。团队成员可能会提出一种新的评论排名算法来提高销量。通过使用A/B测试，他们可以将新旧算法推广到不同但相似的用户组，并监控结果，以查看从新模型中获得预测的用户是否更有可能进行购买。

A/B 测试还有助于衡量模型过时和漂移对业务的影响。团队可以将新模型投入生产并重复使用，对每个模型进行 A/B 测试，并创建年龄与性能对比图表。这将有助于团队了解其生产数据中的数据漂移波动性。

有关如何使用 SageMaker AI 执行 A/B 测试的更多信息，请参阅 Machine Learning 博客上的博客文章 “使用 Amazon A SageMaker I 在生产环境中测试 ML 模型 A/B 测试 ML 模型” AWS 。

考虑您的推理要求

借 SageMaker 助 AI，您可以选择底层基础架构，以不同的方式部署模型。这些推理调用功能支持不同的用例和成本概况。您的选项包括实时推理、异步推理和批量转换，如以下各节所述。

实时推理

实时推理非常适合需要实时、交互式、低延迟的推理工作负载。您可以将模型部署到 SageMaker AI 托管服务，并获得可用于推理的终端节点。这些终端节点是完全托管的，支持自动扩展（参见自动扩展 SageMaker Amazon AI 模型），并且可以部署在多个可用区中。

如果你有使用 Apache MXNet、或构建的深度学习模型 PyTorch TensorFlow，你也可以使用 A mazon A SageMaker I Elastic Inference (EI)。借助 EI，您可以将分数附加 GPUs 到任何 SageMaker AI 实例以加快推理。您可以选择客户端实例来运行您的应用程序，并连接 EI 加速器以使用正确的 GPU 加速量来满足您的推理需求。

另一种选择是使用多模型端点，它为部署大量模型提供了一种可扩展且经济实惠的解决方案。这些端点使用可托管多个模型的共享服务容器。与使用单模型端点相比，多模型端点通过提高端点利用率来降低托管成本。它们还可以减少部署开销，因为 SageMaker AI 可以管理在内存中加载模型并根据流量模式对其进行扩展。

有关在 SageMaker AI 中部署 ML 模型的其他最佳实践，请参阅 A SageMaker I 文档中的部署最佳实践。

异步推理

Amazon SageMaker AI 异步推理是 SageMaker AI 中的一项功能，用于对传入的请求进行排队并异步处理这些请求。此选项非常适合负载大小高达 1 GB、处理时间长、延迟要求接近实时的请求。异步推断使您能够在没有请求要处理时自动将实例数缩放到零，从而节省成本，因此您只需在终端节点处理请求时才付费。

批量转换

要执行以下操作时，请使用批量转换：

• 预处理数据集以从数据集中删除可能干扰训练或推理的噪声或偏差。

• 从大型数据集获取推理。

• 当您不需要持续性终端节点时运行推理。

• 将输入记录与推理相关联，以帮助解释结果。