Amazon SageMaker 上的串行推理设计模式

随着机器学习 (ML) 成为主流并获得更广泛的采用，基于 ML 的应用程序在解决一系列复杂的业务问题方面变得越来越普遍。 这些复杂业务问题的解决方案通常需要使用多个 ML 模型。 这些模型可以顺序组合以执行各种任务，例如预处理、数据转换、模型选择、推理生成、推理整合和后处理。 组织需要灵活的选项来编排这些复杂的 ML 工作流。 串行推理管道就是这样一种设计模式，将这些工作流程安排成一系列步骤，每个步骤都丰富或进一步处理前面步骤生成的输出，并将输出传递到管道中的下一步。

此外，这些串行推理管道应提供以下内容：

• 灵活定制的实现（依赖、算法、业务逻辑等）
• 可重复且一致的生产实施
• 通过最小化基础设施管理实现无差别的繁重工作

在这篇文章中，我们将研究串行推理管道的一些常见用例，并使用以下方法介绍每个用例的一些实现选项 亚马逊SageMaker. 我们还讨论了每个实施选项的注意事项。

下表总结了串行推理、实施注意事项和选项的不同用例。 这些将在这篇文章中讨论。

在以下部分中，我们将更详细地讨论每个用例。

使用推理容器的串行推理管道

串行推理管道用例要求在调用预训练的 ML 模型以生成推理之前对传入数据进行预处理。 此外，在某些情况下，生成的推理可能需要进一步处理，以便下游应用程序可以轻松使用它们。 对于需要实时处理流式数据源才能在其上拟合模型的用例，这是一种常见场景。 但是，此用例也可以用于批量推理。

SageMaker 提供了一个选项来自定义推理容器并使用它们来构建串行推理管道。 推理容器使用 SageMaker 推理工具包 并且建立在 SageMaker 多模型服务器 (MMS)，它提供了一种灵活的机制来服务于 ML 模型。 下图说明了如何使用推理容器实现串行推理管道的参考模式。

SageMaker MMS 需要一个 Python 脚本来实现以下函数来加载模型、预处理输入数据、从模型中获取预测以及后处理输出数据：

• input_fn（） – 负责对输入数据进行反序列化和预处理
• 模型_fn() – 负责从工件中加载训练好的模型 亚马逊简单存储服务 （亚马逊 S3）
• Forecast_fn（） – 负责从模型中产生推论
• output_fn（） – 负责序列化和后处理输出数据（推理）

有关自定义推理容器的详细步骤，请参阅 调整您自己的推理容器.

推理容器是串行推理管道用例的理想设计模式，主要考虑以下几点：

• 高内聚力 – 处理逻辑和对应模型驱动单一业务功能，需要共存
• 整体延迟低 – 从发出推理请求到收到响应之间经过的时间

在串行推理管道中，处理逻辑和模型封装在同一个容器中，因此大部分调用调用都保留在容器中。 这有助于减少总跳数，从而提高管道的整体延迟和响应能力。

此外，对于易于实施是重要标准的用例，推理容器可以提供帮助，因为管道的各种处理步骤位于同一容器内。

使用 SageMaker 推理管道的串行推理管道

串行推理管道用例的另一种变体要求管道中的各个步骤（例如数据预处理、推理生成、数据后处理以及格式化和序列化）之间进行更清晰的解耦。 这可能是由于多种原因造成的：

• 去耦 – 管道的各个步骤都有明确定义的目的，并且由于涉及到底层依赖关系，需要在单独的容器上运行。 这也有助于保持管道结构良好。
• 框架 – 管道的各个步骤使用特定的适合用途的框架（例如 scikit 或 Spark ML），因此需要在单独的容器上运行。
• 资源隔离 – 管道的各个步骤具有不同的资源消耗要求，因此需要在单独的容器上运行以获得更大的灵活性和控制力。

此外，对于稍微复杂的串行推理管道，可能涉及多个步骤来处理请求并生成推理。 因此，从操作的角度来看，将这些步骤托管在单独的容器上以实现更好的功能隔离，并促进更轻松的升级和增强（更改一个步骤而不影响其他模型或处理步骤）可能是有益的。

如果您的用例符合其中一些考虑因素，则 SageMaker 推理管道 提供了一个简单灵活的选项来构建串行推理管道。 下图说明了如何使用 SageMaker 推理管道托管在专用容器上的多个步骤来实现串行推理管道的参考模式。

SageMaker 推理管道由 2-15 个容器的线性序列组成，这些容器处理数据推理请求。 推理管道提供了使用预先训练的 SageMaker 内置算法或打包在 Docker 容器中的自定义算法的选项。 这些容器托管在同一个底层实例上，这有助于减少整体延迟并最大限度地降低成本。

以下代码片段显示了如何组合多个处理步骤和模型来创建串行推理管道。

我们首先构建和指定我们打算用作管道一部分的基于 Spark ML 和 XGBoost 的模型：

from sagemaker.model import Model
from sagemaker.pipeline_model import PipelineModel
from sagemaker.sparkml.model import SparkMLModel
sparkml_data = 's3://{}/{}/{}'.format(s3_model_bucket, s3_model_key_prefix, 'model.tar.gz')
sparkml_model = SparkMLModel(model_data=sparkml_data)
xgb_model = Model(model_data=xgb_model.model_data, image=training_image)

然后在管道模型定义中按顺序排列模型：

model_name = 'serial-inference-' + timestamp_prefix
endpoint_name = 'serial-inference-ep-' + timestamp_prefix
sm_model = PipelineModel(name=model_name, role=role, models=[sparkml_model, xgb_model])

然后通过指定主机 ML 实例的类型和数量，将推理管道部署在端点后面以进行实时推理：

sm_model.deploy(initial_instance_count=1, instance_type='ml.c4.xlarge', endpoint_name=endpoint_name)

整个组装的推理管道可以被视为一个 SageMaker 模型，您可以使用它来进行实时预测或直接处理批量转换，而无需任何外部预处理。 在推理管道模型中，SageMaker 将调用处理为源自外部应用程序的一系列 HTTP 请求。 管道中的第一个容器处理初始请求，执行一些处理，然后将中间响应作为请求分派给管道中的第二个容器。 这发生在管道中的每个容器上，并最终将最终响应返回给调用客户端应用程序。

SageMaker 推理管道是完全托管的。 部署管道后，SageMaker 会在每个管道上安装并运行所有定义的容器 亚马逊弹性计算云 (Amazon EC2) 实例预置为终端节点或批量转换作业的一部分。 此外，由于容器位于同一 EC2 实例上并托管在同一位置，因此整体管道延迟降低了。

使用 SageMaker 推理管道的串行模型集成

集成模型是 ML 中的一种方法，其中多个 ML 模型被组合并用作推理过程的一部分以生成最终推理。 集成模型的动机可能包括提高准确性、降低模型对特定输入特征的敏感性以及减少单一模型偏差等。 在这篇文章中，我们关注与串行模型集成相关的用例，其中多个 ML 模型按顺序组合为串行推理管道的一部分。

让我们考虑一个与串行模型集成相关的特定示例，我们需要根据某些主题或主题对用户上传的图像进行分组。 该管道可能包含三个 ML 模型：

• 型号1 – 接受图像作为输入，并根据图像分辨率、方向等评估图像质量。 然后该模型尝试提升图像质量并将满足一定质量阈值的处理后的图像发送到下一个模型（模型 2）。
• 型号2 – 接受通过模型 1 验证的图像并执行 图像识别 识别图像中的对象、地点、人物、文本和其他自定义操作和概念。 包含已识别对象的模型 2 的输出被发送到模型 3。
• 型号3 – 接受模型 2 的输出并执行自然语言处理 (NLP) 任务，例如基于主题将图像分组在一起的主题建模。 例如，可以根据位置或识别的人对图像进行分组。 输出（分组）被发送回客户端应用程序。

下图说明了如何使用 SageMaker 推理管道实现托管在串行模型集合上的多个 ML 模型的参考模式。

如前所述，管理 SageMaker 推理管道，使您能够专注于 ML 模型选择和开发，同时减少与构建串行集成管道相关的无差别繁重工作。

此外，前面讨论的一些关于模型开发和部署的解耦、算法和框架选择的考虑在这里也很重要。 例如，由于每个模型都托管在一个单独的容器上，因此您可以灵活地选择最适合每个模型和整个用例的 ML 框架。 此外，从解耦和操作的角度来看，您可以更轻松地继续升级或修改各个步骤，而不会影响其他模型。

SageMaker 推理管道还与 SageMaker模型注册表 用于模型编目、版本控制、元数据管理和受控部署到生产环境，以支持一致的操作最佳实践。 SageMaker 推理管道还与 亚马逊CloudWatch 启用监控推理管道中的多容器模型。 您还可以了解 实时指标 更好地了解管道中每个容器的调用和延迟，这有助于故障排除和资源优化。

使用 SageMaker 推理管道的串行推理管道（具有来自组的目标模型调用）

SageMaker 多模型端点 (MME) 提供了一种经济高效的解决方案，可以在单个端点后面部署大量 ML 模型。 使用多模型端点的动机可能包括根据请求特征（例如来源、地理位置、用户个性化等）调用特定的自定义模型，或者只是在同一端点后面托管多个模型以实现成本优化。

当您在一个启用了多模型的端点上部署多个模型时，所有模型都共享计算资源和模型服务容器。 SageMaker 推理管道可以部署在 MME 上，其中管道中的一个容器可以根据被调用的特定模型动态服务请求。 从管道的角度来看，模型具有相同的预处理要求并期望相同的特征集，但经过训练以与特定行为保持一致。 下图说明了此集成管道如何工作的参考模式。

对于 MME，源自客户端应用程序的推理请求应指定需要调用的目标模型。 管道中的第一个容器处理初始请求，执行一些处理，然后将中间响应作为请求分派给管道中的第二个容器，该容器托管多个模型。 根据推理请求中指定的目标模型，调用模型生成推理。 生成的推理被发送到管道中的下一个容器进行进一步处理。 管道中的每个后续容器都会发生这种情况，最后 SageMaker 将最终响应返回给调用客户端应用程序。

多个模型工件保存在 S3 存储桶中。 调用特定模型时，SageMaker 会将其动态加载到托管端点的容器中。 如果模型已经加载到容器的内存中，调用会更快，因为 SageMaker 不需要从 Amazon S3 下载模型。 如果实例内存利用率很高，并且调用了新模型并因此需要加载，则将从内存中卸载未使用的模型。 但是，卸载的模型仍保留在实例的存储卷中，稍后可以再次加载到容器的内存中，而无需再次从 S3 存储桶下载。

使用 MME 时的关键考虑因素之一是了解模型调用延迟行为。 如前所述，模型在调用时动态加载到托管端点的实例的容器内存中。 因此，模型调用在第一次调用时可能需要更长的时间。 当模型已经在实例容器的内存中时，后续调用会更快。 如果实例内存利用率很高并且需要加载新模型，则会卸载未使用的模型。 如果实例的存储卷已满，则从存储卷中删除未使用的模型。 SageMaker 完全管理模型的加载和卸载，您无需执行任何特定操作。 但是，了解这种行为很重要，因为它会影响模型调用延迟，从而影响整体端到端延迟。

管道托管选项

SageMaker 提供多种 实例类型 根据您的用例、吞吐量和成本要求，选择用于部署 ML 模型和构建推理管道的选项。 例如，您可以选择 CPU 或 GPU 优化实例来构建串行推理管道，在单个容器上或跨多个容器。 但是，有时需要具有灵活性并支持在同一管道内基于 CPU 或 GPU 的实例上运行模型以获得额外的灵活性。

您现在可以使用 NVIDIA Triton 推理服务器为 SageMaker 上的推理模型提供异构计算需求。 查看 在 Amazon SageMaker 中使用 NVIDIA Triton 推理服务器部署快速且可扩展的 AI 了解更多详细信息。

结论

随着组织发现和构建由 ML 提供支持的新解决方案，编排这些管道所需的工具应该足够灵活，以根据给定的用例提供支持，同时简化和减少持续的运营开销。 SageMaker 提供多种选项来根据您的要求设计和构建这些串行推理工作流程。

我们期待收到您的来信，了解您正在使用串行推理管道构建哪些用例。 如果您有任何问题或反馈，请在评论中分享。

关于作者

拉胡尔·沙玛 是 AWS 数据实验室的高级解决方案架构师，帮助 AWS 客户设计和构建 AI/ML 解决方案。 在加入 AWS 之前，Rahul 在金融和保险领域工作了数年，帮助客户构建数据和分析平台。

阿南德·普拉卡什（Anand Prakash） 是 AWS 数据实验室的高级解决方案架构师。 Anand 专注于帮助客户设计和构建 AI/ML、数据分析和数据库解决方案，以加快他们的生产之路。

达瓦尔·帕特尔 是 AWS 的首席机器学习架构师。 他曾与从大型企业到中型初创公司的组织合作，解决与分布式计算和人工智能相关的问题。 他专注于深度学习，包括 NLP 和计算机视觉领域。 他帮助客户在 SageMaker 上实现高性能模型推理。

索拉布·特里坎德 是 Amazon SageMaker Inference 的高级产品经理。 他热衷于与客户合作并使机器学习更易于访问。 在业余时间，Saurabh 喜欢徒步旅行、学习创新技术、关注 TechCrunch 以及与家人共度时光。