给每一个用户建立一个独有 ML 模型，这是一种怎样的体验？

根据业务需求建立一种或几种 ML 模型，而后根据模型的推理得到业务所需的决策依据，这种作法想必你们都很熟悉了。然而具体到特定应用场景，这种作法可能会存在一些弊端。

举例来讲，若是咱们须要经过一个 ML 模型来预测某个地区的将来市场趋势，那么只要模型自己足够优秀，而且有必要的数据，这个目标仍是很好实现的。但若是咱们但愿经过 ML 模型来学习用户在线听歌时候的喜爱，而后给用户提供个性化的音乐推荐，那么为全部用户使用同一个模型，很明显，并不能得到最好的结果。

此时的问题就变成了：咱们可否不要基于群组或细分市场来创建模型，而是基于个体用户的数据来创建，以便得到更准确的结果。这也是能够作到的，但必须注意成本问题。

虽然构建自定义机器学习模型较好地提升了单个使用案例推理的准确性，但缺点在于部署模型的成本大幅提升，并且在生产中管理如此多的模型很困难。当咱们不用同时访问全部模型，但仍然须要能够随时使用这些模型时，这些问题变得尤其突出。Amazon SageMaker 的多模型终端节点能够解决这些痛点，而且能为企业提供一个可扩展但经济高效的解决方案用于部署多个机器学习模型。

Amazon SageMaker 是一项模块化的端到端服务，可用于轻松地大规模构建、训练和部署机器学习模型。在训练获得一个机器学习模型后，咱们能够将它部署到彻底托管的 Amazon SageMaker 终端节点上，该终端节点能够实时提供低延迟的推理。而在多模型终端节点功能的帮助下，咱们能够在一个公共终端节点中部署多个模型，并经过一个使用多模型终端节点的服务容器向外提供服务。如此一来，即可以轻松地大规模管理机器学习模型的部署，并经过提升终端节点及其下层的基础计算实例的使用率来下降模型部署成本。

下文将介绍 Amazon SageMaker 多模型终端节点，并演示如何应用这项新功能经过 XGBoost 来预测各个细分市场的房屋价格。下文演示了在多模型终端节点上同时部署10个模型，也演示了在10个独立的终端节点上分别部署10个模型，并对这两种使用情形进行了对比。以下图所示，前者相比后者每个月节省了3000美圆的成本。

多模型终端节点能够轻松扩展到数百至数千个模型。下文还将讨论终端节点配置和监控须要考虑的因素，并将重点介绍在1000个模型规模的部署样例中，如何节省超过90%的成本。

Amazon SageMaker 多模型终端节点概述

Amazon SageMaker 可以使咱们跨多个可用区将模型一键式部署到自动扩展的 Amazon 机器学习实例上，以实现高冗余性。咱们只需指定实例类型及所需的最大数和最小值，剩下的部分都将由 Amazon SageMaker 解决。

Amazon SageMaker 将启动实例、部署模型并设置安全的 HTTPS 终端节点。应用程序须要包含到此终端节点的 API 调用，以实现低延迟和高吞吐量推理。此架构可以使咱们在几分钟内将新模型集成到应用程序中，由于模型更改再也不须要应用程序代码同步更改。Amazon SageMaker 是彻底托管的服务，可代为管理生产计算基础设施，包括执行运行情况检查、应用安全补丁及执行其余的常规维护，这一切均可以使用内置的 Amazon CloudWatch 监控和日志记录来进行。

Amazon SageMaker 多模型终端节点可以使咱们在一个终端节点中部署多个通过训练的模型，并使用一个服务容器向外提供服务。多模型终端节点彻底托管，具备高可用性，可实时提供推理服务。咱们能够在推理请求中经过参数设置目标模型名称来轻松调用指定模型。若是拥有大量可经过共享服务容器提供服务，且不须要同时访问全部模型的类似模型，该项功能是不二之选。例如，法律应用程序可能须要全面覆盖一组普遍的监管辖区，若是有大量不常常访问的模型，那么一个多模型终端节点就能够高效的提供服务，而且显著的下降成本。

要在 Amazon SageMaker 中建立多模型终端节点，请选择多模型选项，提供推理服务容器镜像的路径，而后提供用于存储训练好的模型构件的 Amazon S3 前缀。只要模型所有使用相同前缀，便可按任何方式在 S3 中组织它们。调用多模型终端节点时，使用 InvokeEndpoint 的新 TargetModel 参数提供特定模型的相对路径。要在多模型终端节点中添加模型，只需将新训练的模型构件存储在与该终端节点关联的 S3 前缀下，而后该模型将当即可用于调用。要更新已在使用的模型，用新名称命名模型，并添加到 S3 中，而后用新模型名称调用终端节点。要中止使用在多模型终端节点上部署的模型，请中止调用该模型，并将它从 S3 中删除。

Amazon SageMaker 多模型终端节点将在调用时从 S3 中动态加载模型，而不是在建立终端节点时将全部模型从 S3 下载到容器中。所以，初次调用模型的推理延迟可能高于后续推理，后续推理将以低延迟返回调用。若是模型在调用时已加载到容器中，则能够跳过下载步骤，模型推理将以低延迟返回调用。例如，假设有一个一天只使用几回的模型，它将根据须要自动加载；而频繁访问的模型将保留在内存中，并持续以低延迟返回调用。下图显示了从 S3 动态加载到多模型终端节点中的模型。

使用 Amazon SageMaker 多模型终端节点预测房价

下文基于房屋订价领域带领你们逐步了解多模型终端节点的使用场景示例。有关更多信息，请参阅 GitHub 上的完整工做笔记本。它使用生成的合成数据让咱们可使用任意数量的模型进行实验。每一个城市都使用随机生成的特征在必定数量的房子上进行了模型训练。

该实验包含如下步骤：

1. 使训练好的模型可用于多模型终端节点
2. 准备容器
3. 建立和部署多模型终端节点
4. 调用多模型终端节点
5. 动态加载新模型

使训练好的模型可用于多模型终端节点

咱们能够在不对模型或模型训练过程进行任何更改的状况下利用多模型部署，并继续生成将要保存在 S3 中的模型构件（如model.tar.gz文件）。
在示例笔记本中，将并行训练一组模型，且每一个训练做业的模型构件都将复制到S3中指定的位置。训练并复制一组模型后，文件夹将拥有如下内容：
 

2019-11-15 14:40:04   11.2 KiB Chicago_IL.tar.gz
  2019-11-15 14:40:04   11.9 KiB Houston_TX.tar.gz
  2019-11-15 14:40:04   11.4 KiB LosAngeles_CA.tar.gz
 
  对象总数：3
     总大小：34.5 KiB

每一个文件都根据原有的model.tar.gz名称进行重命名，以使每一个模型都具备惟一的名称。发送请求作预测时，可经过名称指定目标模型。

准备容器

要使用 Amazon SageMaker 多模型终端节点，可使用通用型多模型服务器功能在 GitHub 上构建 Docker 容器。该容器是一个灵活易用的框架，可托管基于任何框架的机器学习模型并对外提供服务。XGBoost 示例笔记本演示了如何将开源 Amazon SageMaker XGBoost 容器用做基础来构建容器。

建立多模型终端节点

下一步是建立多模型终端节点，该终端节点知道如何在S3中查找目标模型。本文使用 boto3（适用于 Python 的 AWS 开发工具包）建立模型元数据。将其模式设置为 MultiModel 并告知 Amazon SageMaker 包含全部模型构件的 S3 文件夹的位置，而不是指定某个模型。

此外，指定模型用于推理的框架镜像。本文使用在上一步构建的 XGBoost 容器。咱们能够在为该框架配置的多模型终端节点中托管使用相同框架构建的模型。请参阅如下代码来建立模型实体：

container = {
   'Image':        XGB_CONTAINER,
   'ModelDataUrl': ‘s3://my-bucket/path/to/artifacts/’,
   'Mode':         'MultiModel'
  }
 
  response = sm_client.create_model(
              ModelName        = ‘my-multi-model-name’,
              ExecutionRoleArn = role,
              Containers       = [container])

有了适当的模型定义后，还须要一个终端节点配置，该配置引用上面建立的模型实体名称。请参阅如下代码：

  response = sm_client.create_endpoint_config(
    EndpointConfigName = ‘my-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])

最后，使用如下代码建立终端节点：
 

response = sm_client.create_endpoint(
              EndpointName       = ‘my-endpoint’,
              EndpointConfigName = ‘my-epc’)

调用多模型终端节点

要调用多模型终端节点，只须要传递一个新参数，该参数表示要调用的目标模型。如下示例代码为使用boto3的预测请求：

  response = runtime_sm_client.invoke_endpoint(
                        EndpointName = ’my-endpoint’,
                        ContentType  = 'text/csv',
                        TargetModel  = ’Houston_TX.tar.gz’,
                        Body         = body)

针对单一终端节点后托管的多个目标模型，示例笔记本经过一组随机调用进行迭代。它显示了终端节点如何按需动态加载目标模型。请参阅如下输出：

Using model Houston_TX.tar.gz to predict price of this house：
 
[1994, 3188, 5, 1.5, 1.62, 3]
 
486551.41 USD，took 1375 ms
 
Using model Chicago_IL.tar.gz to predict price of this house：
 
[1990, 3047, 5, 1.0, 1.11, 2]
 
428404.88 USD，took 850 ms
 
Using model Chicago_IL.tar.gz to predict price of this house：
 
[1995, 3514, 6, 2.0, 0.79, 2]
 
512149.66 USD，took 17 ms
 
Using model Houston_TX.tar.gz to predict price of this house：
 
[1978, 2973, 2, 1.5, 0.99, 1]
 
328904.12 USD，took 17 ms

因为要从 S3 下载特定模型并将其加载到内存中，针对该模型完成第一次请求的时间有更多延迟（称为冷启动）。后续，由于该模型已加载完成，调用不会产生额外的开销。

动态加载新模型到现有终端节点中

将新模型部署到现有的多模型终端节点中很简单。在终端节点已在运行的状况下，将一组新的模型构件复制到早前设置的相同的 S3 位置，而后客户端应用程序能够自由地请求来自于该目标模型的预测，剩余工做则交由 Amazon SageMaker 处理。下面的示例代码为纽约建立了一个能够当即投入使用的新模型：
 

!aws s3 cp NewYork_NY.tar.gz s3://my-bucket/path/to/artifacts/
 
  response = runtime_sm_client.invoke_endpoint(
                        EndpointName=endpoint_name,
                        ContentType='text/csv',
                        TargetModel=’NewYork_NY.tar.gz’,
                        Body=body)

使用多模型终端节点，咱们无需进行完整的终端节点更新，只需部署新模型（即一个 S3 副本），而且能够避免为每一个新模型单独设置终端节点的成本开销。

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

随着捆绑模型的规模增大，Amazon SageMaker 多模型终端节点的好处也随之增长。使用一个终端节点托管两个模型时，能够节省成本，对于具备数百个甚至数千个模型的使用案例，节省幅度会更高。

例如，假设有1000个小型XGBoost模型，每一个模型自己均可以由ml.c5.large终端节点（4GiB内存）提供服务，在 us-east-1 每实例小时的成本为0.119USD。若是为所有1000个模型各自提供终端节点，每个月将花费171,360 USD。若是使用 Amazon SageMaker 多模型终端节点，使用ml.r5.2xlarge 实例的单个终端节点（64GiB内存）便可以托管所有1000个模型。这能够将生产推理成本下降99%，使每月的成本仅为1,017 USD。下表总结了本示例中单个终端节点与多模型终端节点之间的区别。请注意，对每一个目标模型进行冷启动调用后，多模型案例实现了7毫秒的第90个百分位延迟。假定终端节点配置为您的目标模型提供了足够的内存，全部模型都加载后的稳态调用延迟将与单模型终端节点的延迟类似。

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

为了在价格与性能之间进行权衡，咱们要使用本身应用程序的模型和表明性流量对多模型终端节点进行测试。Amazon SageMaker在CloudWatch中为多模型终端节点提供额外的指标，以便肯定终端节点的使用状况和缓存命中率，并对终端节点进行优化。指标以下：

• ModelLoadingWaitTime – 调用请求等待目标模型被下载或加载以执行推理的时间间隔。
• ModelUnloadingTime – 经过容器的 UnloadModel API 调用卸载模型所须要的时间间隔。
• ModelDownloadingTime – 从 S3 中下载模型所须要的时间间隔。
• ModelLoadingTime – 经过容器的 LoadModel API 调用加载模型所须要的时间间隔。
• ModelCacheHit – 发送至已加载模型的终端节点的 InvokeEndpoint请求数量。取平均统计值将显示模型已加载的请求的比率。
• LoadedModelCount – 已加载到终端节点的容器中的模型数量。每一个实例都会发出该指标。1分钟内的平均（Average）统计量将显示每一个实例已加载的模型平均数量，总（Sum）统计量显示在终端节点的全部实例中加载的模型总数量。由于咱们能够将一个模型加载到终端节点的多个容器中，此指标跟踪的模型不必定是惟一的。

咱们可使用 CloudWatch 图表帮助持续做出决策，选择出最佳的实例类型、实例计数和某个特定终端节点应托管的模型数量。例如，下面的图表显示加载的模型数量在不断增长，缓存命中率也在相应增长。

在本例中，缓存命中率的起始值为0，当时没有加载模型。随着加载的模型数量增长，缓存命中率最终达到100%。

将终端节点配置与使用案例匹配

为 Amazon SageMaker 终端节点选择适当的终端节点配置，尤为是实例类型和实例数量，这在很大程度上取决于特定使用案例要求。对于多模型终端节点也是如此。咱们能够在内存中保存的模型数量取决于终端节点配置（如实例类型和计数）、模型配置文件（如模型大小和模型延迟）及推理流量模式。咱们应该综合考虑上述因素来配置多模型终端节点并适当调整实例的大小，而且还应该为终端节点设置自动缩放。

Amazon SageMaker 多模型终端节点彻底支持自动缩放。调用速率用于触发自动缩放事件，该速率基于终端节点服务之完整模型集的聚合预测集。
有些情形下，咱们能够经过选择不能同时在内存中保存全部目标模型的实例类型来下降成本。Amazon SageMaker 将在内存用完时动态卸载模型，从而为新目标模型腾出空间。对于不常常请求的模型，动态加载能够节省成本，延迟尚可接受。对延迟敏感的情形，可能须要选择更大的实例类型或更多实例。对于特定使用案例，预先投入时间使用多模型终端节点进行测试和分析，将有助于优化成本，同时知足应用程序的性能需求。

结论

Amazon SageMaker 多模型终端节点可帮助咱们以尽量低的成本提供高性能机器学习解决方案。经过将一组相似的模型捆绑到单个终端节点后面，能够显著下降推理成本，咱们可使用单个共享服务容器提供服务。一样地，Amazon SageMaker 提供的托管 Spot 训练以帮助下降训练成本，并针对深度学习工做负载为 Amazon Elastic Inference 提供集成支持。最重要的是，它们将助力于 Amazon SageMaker 改进生产力，并有助于提升机器学习团队的影响力。