在 Amazon SageMaker 上使用多框架模型进行经济高效的 ML 推理 

机器学习 (ML) 已被证明是最成功、最广泛的技术应用之一，影响着众多行业，每天影响着数十亿用户。随着机器学习在各个行业的快速采用，公司在支持低延迟预测和高可用性、同时最大限度地提高资源利用率和降低相关成本方面面临着挑战。由于每个机器学习框架都有自己的依赖项，并且每个框架的部署步骤都不同，因此在生产中部署在不同框架中构建的模型以及管理每个端点变得越来越复杂。

亚马逊SageMaker 多容器端点（MCE）使我们能够将不同框架上的模型分组并将它们部署到同一主机，从而创建单个端点。您可以为用于构建模型的不同框架提供容器，SageMaker 会获取所有这些容器并将它们放在一个端点后面。例如，您可以在两个专用端点上加载 PyTorch 和 TensorFlow 模型，以服务相同或完全不同的用例，并且这两个模型都具有间歇性传入流量，未充分利用资源。在这种情况下，您可以使用容器将它们组合到一个使用 MCE 的端点中，从而提高资源利用率，同时降低两个模型从不同端点提供服务所产生的成本。

多容器端点提供了一个可扩展且经济高效的解决方案，可部署多达 15 个基于不同 ML 框架、模型服务器和服务于相同或不同用例的算法构建的模型，这意味着您可以拥有基于不同 ML 框架或中介构建的模型跨所有这些容器和模型的步骤。所有这些模型都可以通过直接调用单独访问，或者使用串行调用缝合到管道中，其中一个模型的输出是下一个模型的输入。

在这篇文章中，我们讨论如何在 SageMaker 上使用多框架模型执行经济高效的机器学习推理。

MCE 调用模式

如果您已将不相关的模型合并到 MCE 端点中，或者您在 MCE 端点后面的模型之间运行 A/B 测试以衡量其性能，则 SageMaker MCE 直接调用非常有用。您可以直接在 API 调用中调用特定容器并从该模型中获取预测。

通过串行调用，您可以将 2-15 个容器拼接在一起，其中一个容器的输出将依次成为下一个容器的输入。例如，如果您有一个多步预测管道，其中使用 Scikit-learn 模型进行中间预测，并将结果输入 TensorFlow 模型进行最终推理，那么这是一个理想的用例。您无需将它们部署为不同的端点，由另一个应用程序或作业编排它们并进行多个 API 调用，您可以将它们部署为 SageMaker MCE，抽象逻辑并将它们设置为串行调用，其中 SageMaker 管理一个容器之间的数据传输自动发送到另一个容器，并将最终容器的输出发送给发出 API 请求的客户端。

SageMaker MCE 串行调用与 SageMaker 串行推理管道有根本不同（更多详细信息请参阅下面的部分）。串行推理管道的目标更多的是编排复杂的机器学习工作流程，例如数据预处理、构建模型集成、实施条件检查以确定要调用哪个模型，或对预测进行后处理，在将预测发送到下游应用程序之前涉及业务逻辑。相比之下，MCE 串行调用旨在将 2-14 个模型拼接到一个管道中进行推理，每个模型都将前一个模型的预测作为输入。

MCE 中的所有容器始终处于服务状态并位于内存中，因此调用端点时不会出现冷启动。 MCE 还可以提高端点利用率并降低成本，因为模型部署在一个端点后面并共享底层计算实例，而不是每个模型占用单独的计算资源。

让我们看几个用例，看看如何使用 SageMaker MCE 来优化 ML 推理。

SageMaker MCE 的用例

假设您有两个用于情感分类的模型，一个用于英语，另一个用于德语，并且这些模型服务于不同的地理位置，流量在一天的不同时间进入。您可以使用 MCE 将两个端点部署到一个端点中，并使用直接调用来访问它们，从而优化您的资源利用率和成本，而不是让两个端点 24/7 运行。请看下面的代码：

englishModel = {
   'Image': container1,
   'ContainerHostname': englishModel }; ...
 
germanModel = {
   'Image': container2,
   'ContainerHostname': germanModel }; ...
 
sm.create_model(
   InferenceExecutionConfig = {'Mode': 'Direct'},
   Containers = [englishModel, germanModel], ...)
sm.create_endpoint_config(EndpointConfigName = ‘my-mce-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])
sm.create_endpoint(EndpointName = ‘my-mce-endpoint’, 
                  EndpointConfigName = ‘my-mce-epc’)

在此示例中，我们有两个模型（englishModel 和 germanModel），然后我们在 SageMaker 中定义容器 create_model 构建并定义 InferenceExecutionConfig 作为“直接”。现在我们可以调用端点进行推理并定义 TargetContainerHostname 作为 englishModel or germanModel 取决于进行 API 调用的客户端：

sm.invoke_endpoint(        
   EndpointName = endpoint_name,
   TargetContainerHostname = englishModel,
   Body = body, ...)

您还可以在 MCE 中使用直接调用来运行 A/B 测试，以比较模型之间的性能。

下图说明了我们的体系结构。

同样，在其他 ML 用例中，当训练后的模型用于处理请求时，模型接收的数据格式需要进行预处理（例如特征化），然后才能传递给算法进行推理。当机器学习算法链接在一起时，一个模型的输出将充当下一个模型的输入，然后才能得出最终结果。在这种情况下，您可以构建 SageMaker MCE 串行管道，其中容器按照在 create_model 构建而不是将每个模型部署到不同的端点并编写独立的逻辑来促进所有这些模型和 API 调用之间的数据流。下图说明了这种架构。

对于此用例，我们使用以下代码：

sm_model = PipelineModel(name=model_name, role=aws_role, models=[Processing-1, Processing-2, Inference-1, Inference-2]) 

predictor = sm_model.deploy(initial_instance_count=1, instance_type="ml.c4.xlarge")                  
response = runtime.invoke_endpoint( 
EndpointName=predictor.endpoint,                                
    Body=body,...)

在此示例中，我们有两个处理容器（Processing-1 和 Processing-2）用于特征处理和数据转换，以及两个推理容器（Inference-1 和 Inference-2）对预处理的数据运行 ML 模型预测。这 PipelineModel 实例允许您定义由四个容器的线性序列组成的推理管道，用于处理数据推理请求。这些容器位于同一实例上，使您能够以低延迟运行推理。

为大量模型扩展多模型端点

SageMaker 多模型端点的优势随着模型整合的规模而增加。当使用一个端点托管两个模型时，您可以看到成本节省，而对于具有数百或数千个模型的用例，节省的成本要大得多。

使用以下命令扩展 MCE 端点也很简单 SageMakerVariantInvocationsPerInstance 预定义的指标，它给出了模型端点的每个实例每分钟被调用来定义的平均次数 TargetScaling 政策。 SageMaker 动态调整为模型预置的实例数量，以响应工作负载的变化。当工作负载增加时，自动缩放会带来更多实例在线并加载目标模型和容器以继续满足请求。当工作负载减少时，自动缩放会删除不必要的实例并卸载模型容器，以便容器不会耗尽资源，并且您无需为不使用的实例付费。完成针对给定模型的第一个请求的时间会经历额外的延迟（称为冷启动）来下载模型 亚马逊简单存储服务 （Amazon S3）并将其加载到内存中。后续调用完成时不会产生任何额外开销，因为模型已加载。请看下面的代码：

# AutoScaling client
asg = boto3.client('application-autoscaling')

# Resource type is variant and the unique identifier is the resource ID.
resource_id=f"endpoint/{endpoint_name}/variant/AllTraffic"

# scaling configuration
response = asg.register_scalable_target(
    ServiceNamespace='sagemaker', #
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    MinCapacity=1,
    MaxCapacity=4
)
#Target Scaling
response = asg.put_scaling_policy(
    PolicyName=f'Request-ScalingPolicy-{endpoint_name}',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 70.0, # Threshold
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance',
        },
        'ScaleInCooldown': 300, # duration until scale in
        'ScaleOutCooldown': 60 # duration between scale out
    }
)

按照前面的策略配置示例，我们使用 SageMakerVariantInvocationsPerInstance 预定义的指标来调整变体实例的数量，以便每个实例都有一个 InvocationsPerInstance 公制为 70。

我们还可以根据我们自己的自定义指标来扩展 SageMaker MCE，例如 CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilization或 DiskUtilization，根据特定资源的利用率增加或减少实例数量。欲了解更多信息，请参阅 自动缩放Amazon SageMaker模型.

建议每个容器中的模型对每个推理请求表现出类似的计算和延迟要求，因为如果到 MCE 的流量从高 CPU 利用率模型转变为低 CPU 利用率模型，但总体调用量保持不变，则端点无法横向扩展，并且可能没有足够的实例来处理对高 CPU 利用率模型的所有请求。

安全 MCE

对于直接调用的 MCE，多个容器通过共享内存和存储卷托管在单个实例中。保护容器的安全、维护请求到目标容器的正确映射以及为用户提供对目标容器的正确访问权限非常重要。你可以限制 invoke_endpoint 使用以下命令访问 MCE 内的一组有限容器 sagemaker:TargetContainerHostname AWS身份和访问管理 (IAM) 条件键。 SageMaker 使用 IAM角色 提供 IAM 基于身份的策略，用于指定允许或拒绝的操作和资源以及允许或拒绝操作的条件。以下策略显示如何限制对端点内特定容器的调用：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sagemaker:InvokeEndpoint"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:sagemaker:region:account-id:endpoint/endpoint_name",
            "Condition": {
                "StringLike": {
                    "sagemaker:TargetContainerHostname": ["customIps*", "common*"]
                }
            }
        }
    ]
}

使用 Amazon CloudWatch 指标监控多模型终端节点

为了权衡价格和性能，您需要使用来自您自己的应用程序的模型和代表性流量来测试多模型端点。 SageMaker 提供了额外的指标 亚马逊CloudWatch 对于多模型端点，以便您可以确定端点使用情况和缓存命中率并优化您的端点。指标如下：

• 模型加载等待时间 – 调用请求等待下载或加载目标模型以执行推理的时间间隔。
• 模型卸载时间 – 通过容器卸载模型所需的时间间隔 UnloadModel API调用。
• 模型下载时间 – 从 Amazon S3 下载模型所需的时间间隔。
• 模型加载时间 – 通过容器加载模型所需的时间间隔 LoadModel API调用。
• 模型缓存命中 - 的数量 InvokeEndpoint 请求发送到已加载模型的端点。采取 Average 统计数据显示已加载模型的请求的比率。
• 加载模型计数 – 端点容器中加载的模型数量。该指标是按实例发出的。这 Average 1 分钟的统计数据告诉您每个实例加载的模型的平均数量，以及 Sum 统计数据告诉您端点中所有实例加载的模型总数。该指标跟踪的模型不一定是唯一的，因为您可以将模型加载到端点的多个容器中。

实例上运行的每个容器还使用其他几个指标，例如 Invocations 表示数量 InvokeEndpoint 发送到端点内容器的请求， ContainerLatency 给出从 SageMaker 中查看端点响应目标容器或串行调用中的所有容器所花费的时间，以及 CPUUtilization 和 MemoryUtilizaton 指示 CPU 单元和内存百分比。

结论

在博文中，我们讨论了 SageMaker 多容器端点如何有助于优化成本和资源利用率。何时使用 MCE 的示例包括但不限于以下内容：

• 跨不同框架（例如 TensorFlow、PyTorch 和 Scikit-learn）托管模型，这些框架没有足够的流量来使实例的全部容量饱和
• 托管来自具有不同 ML 算法（例如推荐、预测或分类）和处理函数的同一框架的模型
• 针对 A/B 测试等场景，在不同框架版本（例如 TensorFlow 1.x 与 TensorFlow 2.x）上运行的类似架构的比较

SageMaker MCE 支持在实时端点上部署最多 15 个容器并独立调用它们以实现低延迟推理并节省成本。这些模型可以是完全异构的，具有自己独立的服务堆栈。您可以针对每个请求顺序或独立地调用这些容器。与在专用单实例端点中托管模型相比，在单个实例上安全地托管来自不同框架的多个模型可以节省高达 90% 的成本。

关于作者

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

维克拉姆·埃兰戈 是位于美国弗吉尼亚州的 Amazon Web Services 的高级 AI/ML 专家解决方案架构师。 Vikram 通过设计和思想领导力帮助全球金融和保险行业客户大规模构建和部署机器学习应用程序。他目前专注于自然语言处理、负责任的人工智能、推理优化以及在整个企业中扩展机器学习。业余时间，他喜欢与家人一起旅行、徒步旅行、烹饪和露营。

索拉布·特里坎德 是 Amazon SageMaker Inference 的高级产品经理。 他热衷于与客户合作，并以机器学习民主化的目标为动力。 他专注于与部署复杂的 ML 应用程序、多租户 ML 模型、成本优化以及使深度学习模型的部署更易于访问相关的核心挑战。 在业余时间，Saurabh 喜欢徒步旅行、学习创新技术、关注 TechCrunch 以及与家人共度时光。