亚马逊SageMaker 多模型端点 (MME) 使您能够经济高效地在单个端点中部署和托管多个模型，然后水平扩展端点以实现扩展。 如下图所示，这是在机器学习 (ML) 基础架构中实现模型多租户的有效技术。 我们已经看到软件即服务 (SaaS) 企业使用此功能在其 ML 模型中应用超个性化，同时实现更低的成本。
有关 MME 工作原理的高级概述，请查看 AWS 峰会视频 将 ML 扩展到新的水平：在 SageMaker 上托管数千个模型. 要了解有关 MME 支持的超个性化、多租户用例的更多信息，请参阅 如何为多租户 SaaS 用例扩展机器学习推理.
在本文的其余部分，我们将深入探讨 SageMaker MME 的技术架构，并分享优化多模型端点的最佳实践。
最适合 MME 的用例
SageMaker 多模型端点非常适合托管大量模型，您可以通过共享服务容器提供这些模型，并且您无需同时访问所有模型。 根据端点实例内存的大小，有时可能会从内存中卸载模型以支持加载新模型以最大限度地有效利用内存，因此您的应用程序需要能够容忍卸载模型上偶尔出现的延迟峰值。
MME 还设计用于共同托管使用相同 ML 框架的模型，因为它们使用共享容器来加载多个模型。 因此，如果您的模型队列中混合了 ML 框架（例如 PyTorch 和 TensorFlow），则 SageMaker 专用端点或多容器托管是更好的选择。
最后，MME 适用于可以容忍偶尔的冷启动延迟损失的应用程序，因为模型在第一次调用时加载，并且可以从内存中卸载不经常使用的模型以支持加载新模型。 因此，如果您混合了经常访问和不经常访问的模型，则多模型端点可以以更少的资源和更高的成本节省有效地服务于这种流量。
我们还看到了一些场景，其中客户部署了一个具有足够总内存容量的 MME 集群来适应他们的所有模型，从而完全避免了模型卸载，但由于共享推理基础设施仍然实现了成本节约。
模型服务容器
当您使用 SageMaker 推理工具包或与 MME 兼容的预构建 SageMaker 模型服务容器时，您的容器具有 多模型服务器 （JVM 进程）正在运行。 将多模型服务器 (MMS) 合并到模型服务容器中的最简单方法是使用 SageMaker 模型服务容器 与 MME 兼容（寻找 Job Type=inference 和 CPU/GPU=CPU 的那些）。 MMS 是一个开源的、易于使用的工具，用于为深度学习模型提供服务。 它提供了一个带有 Web 服务器的 REST API，用于在单个主机上服务和管理多个模型。 但是，使用彩信不是强制性的； 您可以实现自己的模型服务器，只要它实现 MME需要的API.
当用作 MME 平台的一部分时，所有对 MMS 或您自己的模型服务器的预测、加载和卸载 API 调用都通过 MME 数据平面控制器进行引导。 来自数据平面控制器的 API 调用仅通过本地主机进行，以防止来自实例外部的未经授权的访问。 MMS 的主要优势之一是它支持用于加载、卸载和调用模型的标准化接口，并兼容各种深度学习框架。
彩信高级配置
如果您选择使用 MMS 进行模型服务，请考虑以下高级配置来优化您的 MME 实例的可扩展性和吞吐量。
增加每个模型的推理并行度
MMS 根据每个模型的值创建一个或多个 Python 工作进程 每个模型的默认工人数 配置参数。 这些 Python 工作者通过运行您提供的任何预处理、预测和后处理功能来处理每个单独的推理请求。 有关详细信息，请参阅 自定义服务处理程序 GitHub仓库。
拥有多个模型工作者会增加给定模型可以提供的预测的并行性。 但是，当大量模型托管在具有大量 CPU 的实例上时，您应该对 MME 执行负载测试以找到 default_workers_per_model 以防止任何内存或 CPU 资源耗尽。
针对流量高峰的设计
端点实例中的每个 MMS 进程都有一个请求队列，可以使用 作业队列大小 参数（默认为 100）。 这决定了当所有工作进程都忙时 MMS 将排队的请求数。 在您确定每个模型的最佳工作人员数量后，使用此参数微调终端节点实例的响应能力。
在每个模型的最佳工人比率中，默认值 100 对于大多数情况应该足够了。 但是，对于到端点的请求流量异常激增的情况，如果您希望端点快速失败以将控制传递给应用程序，则可以减小队列大小，或者如果您希望端点吸收峰值，则可以增加队列大小.
最大化每个实例的内存资源
当每个模型使用多个工作进程时，默认情况下每个工作进程都会加载自己的模型副本。 这会减少其他模型的可用实例内存。 您可以通过设置配置参数在工作进程之间共享单个模型来优化内存利用率 预加载模型=真. 在这里，您在降低推理并行性（由于单个模型实例）与更高的内存效率之间进行权衡。 对于模型延迟较低但每个推理请求的预处理和后处理（由工作进程完成）较重的用例，此设置以及多个工作进程可能是一个不错的选择。
设置彩信高级配置的值
MMS 使用 config.properties 文件来存储配置。 MMS 使用以下顺序来定位此 config.properties 文件：
- 如果
MMS_CONFIG_FILE设置环境变量，彩信从环境变量加载配置。 - 如果
--mms-config参数传递给彩信，它从参数加载配置。 - 如果有的话
config.properties在用户启动彩信的当前文件夹中，它会加载config.properties当前工作目录中的文件。
如果以上都没有指定，MMS 会使用默认值加载内置配置。
以下是使用显式配置文件启动 MMS 的命令行示例：
监控端点性能的关键指标
可以帮助您优化 MME 的关键指标通常与 CPU 和内存利用率以及推理延迟有关。 实例级指标由 MMS 发出，而延迟指标来自 MME。 在本节中，我们将讨论可用于了解和优化 MME 的典型指标。
端点实例级指标（MMS 指标）
来自 MMS 指标列表、CPUUtilization 和 MemoryUtilization 可以帮助您评估您的实例或 MME 集群的大小是否合适。 如果这两个指标的百分比都在 50-80% 之间，那么您的 MME 大小合适。
通常，低 CPUUtilization 和高 MemoryUtilization 表示过度配置的 MME 集群，因为它表示不经常调用的模型没有被卸载。 这可能是因为为 MME 配置的端点实例数量高于最佳数量，因此对于不经常访问的模型保留在内存中的聚合内存高于最佳数量。 相反，这些指标的利用率接近 100% 意味着您的集群配置不足，因此您需要调整集群 Auto Scaling 策略。
平台级指标（MME 指标）
来自 MME 指标的完整列表，可以帮助您了解推理请求延迟的关键指标是 ModelCacheHit。 此指标显示模型已加载到内存中的调用请求的平均比率。 如果此比率较低，则表明您的 MME 集群配置不足，因为 MME 集群中的聚合内存容量可能不足以容纳唯一模型调用的数量，从而导致模型经常从内存中卸载。
现场经验教训和优化 MME 的策略
我们从一些客户对 MME 的一些大规模使用中看到了以下建议。
使用较小实例进行水平扩展优于使用较大实例进行垂直扩展
在较少的端点实例上运行高每秒请求数 (RPS) 时，您可能会遇到模型调用限制。 每秒的调用次数（实例上可能同时发生的加载和卸载）存在内部限制，因此拥有更多数量的较小实例总是更好。 运行更多数量的较小实例意味着端点的这些限制的总聚合容量更高。
使用较小的实例进行水平扩展的另一个好处是，在运行具有更高并行度的 MMS 以及内存中更多模型（如本文前面所述）时，您可以降低耗尽实例 CPU 和内存资源的风险。
避免颠簸是共同的责任
颠簸 在 MME 中，模型经常从内存中卸载并由于内存不足而重新加载，无论是在单个实例中还是在集群中的聚合中。
从使用的角度来看，您应该调整各个端点实例的大小并调整 MME 集群的总体大小，以确保每个实例以及集群的总容量都足够用于您的用例。 MME 平台的路由器队列也将最大限度地提高缓存命中率。
不要激进地在更少、更大的内存实例上打包太多模型
内存不是实例上唯一需要注意的资源。 CPU 等其他资源可能是一个限制因素，如以下负载测试结果所示。 在其他一些情况下，我们还观察到其他内核资源（例如进程 ID）在实例上耗尽，这是由于加载的模型过多以及底层 ML 框架（例如 TensorFlow）为每个模型生成的线程是可用线程的倍数vCPU。
以下性能测试演示了影响模型延迟的 CPU 约束示例。 在此测试中，与具有四个较小实例的端点相比，具有大实例的单实例端点虽然具有足够的内存以将所有四个模型保存在内存中，但在负载下产生的模型延迟相对较差。
单实例端点模型延迟
单实例端点 CPU 和内存利用率
四实例端点模型延迟
四个实例端点 CPU 和内存利用率
为了同时实现性能和成本效益，使用更多的较小实例来调整 MME 集群的大小，这些实例总体上可以为您提供最佳内存和 CPU 容量，同时在成本相对较低但更大的内存实例的情况下相对平价。
优化 MME 的心智模型
在调整 MME 大小时，您应该始终考虑四个关键指标：
- 模型的数量和大小
- 在给定时间调用的唯一模型的数量
- 实例类型和大小
- 端点后面的实例数
从前两点开始，因为它们通知第三点和第四点。 例如，如果端点后面没有足够的实例来满足您拥有的唯一模型的数量或大小，那么端点的聚合内存将会很低，并且您会看到较低的缓存命中率并在端点级别出现抖动，因为 MME将频繁地在内存中加载和卸载模型。
同样，如果对唯一模型的调用高于端点后面所有实例的总内存，您将看到较低的缓存命中。 如果实例的大小（尤其是内存容量）太小，也会发生这种情况。
使用非常大的内存实例进行垂直扩展也可能导致问题，因为尽管模型可能适合内存，但其他资源（如 CPU 和内核进程以及线程限制）可能会耗尽。 在预生产中进行负载测试水平扩展，以获得 MME 的最佳实例数量和大小。
总结
在这篇文章中，您对 MME 平台有了更深入的了解。 您了解了 MME 适合哪些技术用例，并查看了 MME 平台的架构。 您对 MME 架构中每个组件的角色以及您可以直接影响其性能的组件有了更深入的了解。 最后，您更深入地了解了可以调整以针对您的用例优化 MME 的配置参数，以及您应该监控以保持最佳性能的指标。
要开始使用 MME，请查看 使用 XGBoost 的 Amazon SageMaker 多模型终端节点 和 在一个端点后面的一个容器中托管多个模型.
关于作者
赛杰弗里 是 AWS 的首席解决方案架构师。 他与来自中型组织、大型企业、金融服务和 ISV 的一系列公司合作，帮助他们在云中构建和运营具有成本效益和可扩展的 AI/ML 应用程序。
索拉布·特里坎德 是 Amazon SageMaker Inference 的高级产品经理。 他热衷于与客户合作，并以机器学习民主化的目标为动力。 他专注于与部署复杂的 ML 应用程序、多租户 ML 模型、成本优化以及使深度学习模型的部署更易于访问相关的核心挑战。 在业余时间，Saurabh 喜欢徒步旅行、学习创新技术、关注 TechCrunch 以及与家人共度时光。
