乐趣区

关于人工智能:给每个用户创建一个独有-ML-模型这是一种怎样的体验

jiezi

依据业务需要创立一种或几种 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 改良生产力，并有助于进步机器学习团队的影响力。

退出移动版