如何为多租户 SaaS 用例扩展机器学习推理

这篇文章是与 Zendesk 的高级机器学习工程师 Sowmya Manusani 共同撰写的

Zendesk 是一家 SaaS 公司，以简单性为基础，为所有人构建支持、销售和客户参与软件。 它使全球超过 170,000 家公司高效地为数亿客户提供服务，从而蓬勃发展。 Zendcaesk 的机器学习团队负责增强客户体验团队以实现最佳状态。 通过结合数据和人员的力量，Zendesk 提供智能产品，通过自动化手动工作来提高客户的工作效率。

Zendesk 自 2015 年以来一直在构建 ML 产品，包括 回答机器人, 满意度预测, 内容提示, 建议的宏， 还有很多。 在过去的几年里，随着深度学习的发展，尤其是 NLP 的发展，他们看到了很多机会来自动化工作流程并帮助代理通过 Zendesk 解决方案来支持他们的客户。 Zendesk 目前使用 TensorFlow 和 PyTorch 来构建深度学习模型。

Zendesk 等客户已经在 Amazon Web Services (AWS) 上建立了成功的大规模软件即服务 (SaaS) 业务。 成功的 SaaS 商业模式的一个关键驱动因素是在应用程序和基础架构中应用多租户的能力。 这可以提高成本和运营效率，因为应用程序只需构建一次，但可以多次使用，并且可以共享基础架构。 我们看到许多客户在 AWS 上在堆栈的所有层（从计算、存储、数据库到网络）构建安全、经济高效的多租户系统，现在我们看到客户需要将其应用到机器学习（ML ）。

在模型重用和超个性化之间做出艰难的权衡

SaaS 业务的多租户通常意味着单个应用程序在多个用户（SaaS 客户）之间重复使用。 这创造了成本效益并降低了运营开销。 然而，机器学习模型有时需要高度个性化（超个性化）才能做出准确的预测。 这意味着如果模型具有特异性，“构建一次，多次使用”的 SaaS 范式就不能总是应用于 ML。 以客户支持平台的用例为例。 用户在支持票中包含的语言会有所不同，具体取决于是拼车问题（“骑行时间过长”）还是服装购买问题（“洗后变色”）。 在此用例中，提高预测最佳补救措施的准确性可能需要在特定于业务领域或垂直行业的数据集上训练自然语言处理 (NLP) 模型。 Zendesk 在尝试在其解决方案中利用 ML 时就面临着这一挑战。 他们需要创建数千个高度定制的 ML 模型，每个模型都是为特定客户量身定制的。 为了以经济高效的方式解决部署数千个模型的挑战，Zendesk 求助于 Amazon SageMaker。

在这篇文章中，我们将展示如何使用 亚马逊SageMaker，一个完全托管的机器学习服务，用于构建多租户 ML 推理能力。 我们还分享了一个真实世界的示例，说明 Zendesk 如何通过在其 ML 模型中支持超个性化与使用 SageMaker 多模型端点的基础设施的经济高效共享使用之间部署一种快乐的媒介，成功地实现了相同的结果（ MME）。

SageMaker 多模型端点

SageMaker 多模型端点使您能够在可能包含一个或多个实例的单个推理端点后面部署多个模型。 每个实例都旨在加载和服务多个模型，直至其内存和 CPU 容量。 借助这种架构，SaaS 业务可以打破托管多个模型的线性增长成本，并实现与应用程序堆栈中其他地方应用的多租户模型一致的基础架构重用。

下图说明了 SageMaker 多模型终端节点的架构。

SageMaker 多模型终端节点从 亚马逊简单存储服务 (Amazon S3) 调用时，而不是在首次创建终端节点时下载所有模型。 因此，对模型的初始调用可能会看到比后续推理更高的推理延迟，后者以低延迟完成。 如果模型在调用时已经加载到容器上，则跳过下载步骤，模型以低延迟返回推理。 例如，假设您有一个每天只使用几次的模型。 它会按需自动加载，而经常访问的模型则保留在内存中并以始终如一的低延迟调用。

让我们仔细看看 Zendesk 如何使用 SageMaker MME 通过其 Suggested Macros ML 功能实现经济高效的超大规模 ML 部署。

为什么 Zendesk 构建超个性化模型

Zendesk 的客户分布在全球不同的垂直行业，具有不同的支持票语义。 因此，为了最好地为客户服务，他们通常必须构建个性化模型，这些模型在客户特定的支持工单数据上进行训练，以正确识别意图、宏等。

2021 年 XNUMX 月，他们发布了一项新的 NLP ML 功能 Suggested Macros，该功能根据数千个客户特定的模型预测来推荐宏（预定义的操作）。 Zendesk 的 ML 团队构建了一个基于 TensorFlow 的 NLP 分类器模型，该模型根据之前的票证内容和每个客户的宏的历史进行训练。 在这些模型可用的情况下，每当座席查看工单时建议进行宏观预测（如下面的屏幕截图所示），这有助于座席快速为客户服务。 由于宏是针对客户的，Zendesk 需要针对客户的模型来提供准确的预测。

在 Zendesk 建议的宏的引擎盖下

建议的宏模型是基于 NLP 的神经网络，大小约为 7-15 MB。 主要挑战是通过具有成本效益、可靠和可扩展的解决方案将数千个这些模型投入生产。

每个模型都有不同的流量模式，每秒最少两个请求，峰值每秒数百个请求，当模型在内存中可用时，每天提供数百万个预测，模型延迟约为 100 毫秒。 SageMaker 终端节点部署在多个 AWS 区域中，每个终端节点每分钟可处理数千个请求。

与为每个客户部署单个模型端点相比，SageMaker 能够在单个端点上托管多个模型，从而帮助 Zendesk 减少了部署开销并创建了具有成本效益的解决方案。 这里的权衡是对每个模型管理的控制较少； 然而，这是 Zendesk 与 AWS 合作改进多模型端点的领域。

SageMaker 多模型功能之一是模型的延迟加载，即模型在第一次调用时加载到内存中。 这是为了优化内存利用率； 但是，它会在第一次加载时导致响应时间尖峰，这可以看作是冷启动问题。 对于 Suggested Macros 来说，这是一个挑战； 然而，Zendesk 通过在 SageMaker 端点配置之上实施预加载功能来克服这个问题，以便在服务生产流量之前将模型加载到内存中。 其次，MME 会从内存中卸载不常用的模型，因此为了在所有模型上实现一致的低延迟并避免“嘈杂的邻居”影响其他不太活跃的模型，Zendesk 正在与 AWS 合作添加新功能，稍后将讨论，以启用更明确的每个模型管理。 此外，作为临时解决方案，Zendesk 调整了 MME 机群的规模，以尽量减少过多的模型卸载。 有了这个，Zendesk 能够以低延迟（大约 100 毫秒）为所有客户提供预测服务，并且与专用端点相比，仍然可以节省 90% 的成本。

在合适大小的 MME 上，Zendesk 在负载测试期间观察到，在 MME 之后拥有更多数量的较小实例（偏向于水平扩展）比拥有更少的较大内存实例（垂直扩展）是更好的选择。 Zendesk 观察到，在单个大内存实例上打包太多模型（在他们的案例中超过 500 个 TensorFlow 模型）效果不佳，因为内存不是实例上可能成为瓶颈的唯一资源。 更具体地说，他们观察到 TensorFlow 为每个模型生成了多个线程（3 x 总实例 vCPU），因此在单个实例上加载超过 500 个模型会导致内核级别的限制被打破，从而超出了可以在实例上生成的最大线程数。 当 Zendesk 在 MME 后面的某些实例上遇到限制（作为一种安全机制）时，使用更少、更大的实例会出现另一个问题，因为每秒唯一模型调用率超过了 多模型服务器 (MMS) 在单个实例上可以安全地处理，而不会中断实例。 这是通过使用更多和更小的实例解决的另一个问题。

从可观察性的角度来看，这是任何生产应用程序的关键组成部分， 亚马逊CloudWatch 调用、CPU、内存利用率等指标和多模型特定指标（如内存中加载的模型、模型加载时间、模型加载等待时间和模型缓存命中）提供了丰富的信息。 具体来说，模型延迟的分解有助于 Zendesk 了解冷启动问题及其影响。

MME 自动缩放的底层

在每个多模型端点后面，都有模型托管实例，如下图所示。 这些实例根据模型的流量模式在内存中加载和驱逐多个模型。

SageMaker 继续将模型的推理请求路由到已加载模型的实例，以便从缓存的模型副本中提供请求（请参见下图，该图显示了第一个预测请求的请求路径与缓存的预测请求小路）。 但是，如果模型接收到许多调用请求，并且多模型端点有其他实例，SageMaker 会将一些请求路由到另一个实例以适应增加的情况。 要利用 SageMaker 中的自动模型缩放，请确保您拥有 实例自动缩放设置 提供额外的实例容量。 使用自定义参数或每分钟调用次数（推荐）设置您的终端节点级扩展策略，以向终端节点队列添加更多实例。

最适合 MME 的用例

SageMaker 多模型端点非常适合托管大量类似模型，您可以通过共享服务容器提供这些模型，而无需同时访问所有模型。 MME 最适合大小和调用延迟相似的模型。 模型大小的一些变化是可以接受的； 例如，Zendesk 的模型范围从 10 到 50 Mb，运行良好，但 10、50 或 100 倍的大小变化不合适。 较大的模型可能会导致较小模型的更多加载和卸载以容纳足够的内存空间，这可能会导致端点延迟增加。 较大模型的性能特征差异也可能不均匀地消耗 CPU 等资源，这可能会影响实例上的其他模型。

MME 还设计用于共同托管使用相同 ML 框架的模型，因为它们使用共享容器来加载多个模型。 因此，如果您的模型队列中混合了 ML 框架（例如 PyTorch 和 TensorFlow），则 SageMaker 专用端点或多容器托管是更好的选择。 最后，MME 适用于可以容忍偶尔的冷启动延迟损失的应用程序，因为可以卸载不经常使用的模型以支持频繁调用的模型。 如果您有不常访问的模型的长尾，多模型端点可以有效地服务于此流量并显着节省成本。

总结

在本文中，您了解了 SaaS 和多租户如何与 ML 相关，以及 SageMaker 多模型端点如何为 ML 推理实现多租户和成本效益。 您了解了 Zendesk 的每个客户 ML 模型的多租户用例，以及他们如何在 SageMaker MME 中托管数千个 ML 模型以实现其建议的宏功能，并与专用端点相比节省了 90% 的推理成本。 超个性化用例可能需要数以千计的 ML 模型，而 MME 是这种用例的一种经济高效的选择。 我们将继续在 MME 中进行增强，使您能够以低延迟托管模型，并对每个个性化模型进行更精细的控制。 要开始使用 MME，请参阅 在一个端点后面的一个容器中托管多个模型.

---

作者简介

赛杰弗里 是 AWS 的高级解决方案架构师。 他与从中型组织到大型企业、从金融服务到 ISV 的一系列公司合作，帮助他们在云中构建和运营安全、弹性、可扩展和高性能的应用程序。

索米亚·马努萨尼 是 Zendesk 的高级机器学习工程师。 她致力于生产化基于 NLP 的机器学习功能，专注于为成千上万的 Zendesk Enterprise 客户提高代理生产力。 她在为数千个个性化模型构建自动化训练管道并使用安全、弹性、可扩展和高性能的应用程序为它们提供服务方面拥有丰富的经验。 在空闲时间，她喜欢解决难题并尝试绘画。

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

迪普蒂·拉加 是 Amazon SageMaker 团队的软件开发工程师。 她目前的工作重点是构建功能以有效地托管机器学习模型。 在业余时间，她喜欢旅行、远足和种植植物。

• 硬币聪明。 欧洲最好的比特币和加密货币交易所。
• 柏拉图区块链。 Web3 元宇宙智能。 知识放大。 自由登入。
• 加密鹰。 山寨币雷达。 免费试用。
• 资料来源：https://aws.amazon.com/blogs/machine-learning/how-to-scale-machine-learning-inference-for-multi-tenant-saas-use-cases/