Veriff 如何使用 Amazon SageMaker 多模型终端节点将部署时间缩短 80% | 亚马逊网络服务

Veriff 是创新增长驱动型组织的身份验证平台合作伙伴，其中包括金融服务、金融科技、加密货币、游戏、移动和在线市场领域的先驱。 他们提供先进的技术，将人工智能驱动的自动化与人类反馈、深刻的见解和专业知识相结合。

Veriff 提供了经过验证的基础架构，使客户能够在客户旅程中的所有相关时刻信任用户的身份和个人属性。 Veriff 受到 Bolt、Deel、Monese、Starship、Super Awesome、Trustpilot 和 Wise 等客户的信赖。

作为人工智能驱动的解决方案，Veriff 需要以经济高效的方式创建和运行数十个机器学习 (ML) 模型。 这些模型包括从轻量级的基于树的模型到深度学习计算机视觉模型，这些模型需要在 GPU 上运行以实现低延迟并改善用户体验。 Veriff 目前还在其产品中添加更多产品，旨在为其客户提供超个性化的解决方案。 为不同的客户提供不同的模型增加了对可扩展模型服务解决方案的需求。

在这篇文章中，我们将向您展示 Veriff 如何使用以下方法标准化其模型部署工作流程 亚马逊SageMaker，降低成本和开发时间。

基础设施和发展挑战

Veriff 的后端架构基于微服务模式，服务运行在 AWS 基础设施托管的不同 Kubernetes 集群上。 这种方法最初用于所有公司服务，包括运行昂贵的计算机视觉 ML 模型的微服务。

其中一些模型需要部署在 GPU 实例上。 意识到 GPU 支持的实例类型的成本相对较高，Veriff 开发了 定制解决方案 在 Kubernetes 上，在不同服务副本之间共享给定 GPU 的资源。 单个 GPU 通常具有足够的 VRAM，可以在内存中保存多个 Veriff 计算机视觉模型。

尽管该解决方案确实降低了 GPU 成本，但它也存在这样的限制：数据科学家需要事先表明他们的模型需要多少 GPU 内存。 此外，DevOps 还需要手动配置 GPU 实例来响应需求模式。 这导致了运营开销和实例的过度配置，从而导致成本状况不佳。

除了 GPU 配置之外，此设置还要求数据科学家为每个模型构建 REST API 包装器，以便为其他公司服务提供通用接口以供使用，并封装模型数据的预处理和后处理。 这些 API 需要生产级代码，这给数据科学家生产模型带来了挑战。

Veriff 的数据科学平台团队正在寻找这种方法的替代方法。 主要目标是通过提供更简单的部署管道来支持公司的数据科学家更好地从研究到生产的过渡。 第二个目标是降低配置 GPU 实例的运营成本。

解决方案概述

Veriff 需要一个新的解决方案来解决两个问题：

• 允许轻松围绕 ML 模型构建 REST API 包装器
• 允许以最佳方式管理预配置的 GPU 实例容量（如果可能的话）自动管理

最终，ML 平台团队一致决定使用 Sagemaker 多模型端点 （MME）。 这一决定是由于 MME 对 NVIDIA 的支持而做出的 Triton 推理服务器 （一个以 ML 为中心的服务器，可以轻松地将模型包装为 REST API；Veriff 也已经在尝试 Triton），以及通过简单的自动缩放策略本地管理 GPU 实例的自动缩放的能力。

Veriff 创建了两台 MME，一台用于登台，一台用于生产。 这种方法允许他们在暂存环境中运行测试步骤，而不影响生产模型。

SageMaker MME

SageMaker 是一项完全托管的服务，可为开发人员和数据科学家提供快速构建、训练和部署 ML 模型的能力。 SageMaker MME 提供可扩展且经济高效的解决方案，用于部署大量模型以进行实时推理。 MME 使用共享服务容器和一组资源，这些资源可以使用 GPU 等加速实例来托管您的所有模型。 与使用单一模型端点相比，这通过最大化端点利用率来降低托管成本。 它还减少了部署开销，因为 SageMaker 管理在内存中加载和卸载模型并根据端点的流量模式扩展它们。 此外，所有 SageMaker 实时端点都受益于管理和监控模型的内置功能，例如包括 阴影变体, 自动缩放, 和本机集成 亚马逊CloudWatch （有关更多信息，请参阅 多模型终端节点部署的 CloudWatch 指标).

定制 Triton 合奏模型

Veriff 决定使用 Triton 推理服务器有几个原因，主要是：

• 它允许数据科学家通过以标准目录格式排列模型工件文件来从模型构建 REST API（无代码解决方案）
• 它与所有主要人工智能框架（PyTorch、Tensorflow、XGBoost 等）兼容
• 它提供特定于 ML 的低级和服务器优化，例如 动态批处理 请求数

使用 Triton 可以让数据科学家轻松部署模型，因为他们只需要构建格式化的模型存储库，而不需要编写代码来构建 REST API（Triton 还支持 Python模型 如果需要自定义推理逻辑）。 这减少了模型部署时间，让数据科学家有更多时间专注于构建模型而不是部署模型。

Triton 的另一个重要功能是它允许您构建 模型合奏，它们是链接在一起的模型组。 这些集成可以像单个 Triton 模型一样运行。 Veriff 目前利用此功能使用 Python 模型（如前所述）为每个 ML 模型部署预处理和后处理逻辑，确保在生产中使用模型时输入数据或模型输出不存在不匹配。

以下是此工作负载的典型 Triton 模型存储库：

model.py 文件包含预处理和后处理代码。 训练后的模型权重在 screen_detection_inferencer 目录，型号版本下 1 （本例中模型采用 ONNX 格式，但也可以是 TensorFlow、PyTorch 格式或其他格式）。 集成模型定义位于 screen_detection_pipeline 目录，其中步骤之间的输入和输出映射到配置文件中。

运行 Python 模型所需的其他依赖项在 requirements.txt 文件，需要进行conda打包来搭建Conda环境（python_env.tar.gz). 有关更多信息，请参阅 管理 Python 运行时和库。 此外，Python 步骤的配置文件需要指向 python_env.tar.gz 使用 EXECUTION_ENV_PATH 指令。

然后需要使用 TAR 压缩模型文件夹并重命名 model_version.txt。 最后，得到的结果是 <model_name>_<model_version>.tar.gz 文件被复制到 亚马逊简单存储服务 (Amazon S3) 存储桶连接到 MME，允许 SageMaker 检测模型并提供服务。

模型版本控制和持续部署

正如上一节所表明的，构建 Triton 模型存储库非常简单。 但是，如果手动运行，则运行部署它所需的所有步骤非常繁琐且容易出错。 为了克服这个问题，Veriff 构建了一个单一存储库，其中包含要部署到 MME 的所有模型，数据科学家在其中以类似 Gitflow 的方法进行协作。 该 monorepo 具有以下特点：

• 它的管理使用 裤子.
• 使用 Pants 应用 Black 和 MyPy 等代码质量工具。
• 为每个模型定义了单元测试，用于检查模型输出是否是给定模型输入的预期输出。
• 模型权重与模型存储库一起存储。 这些权重可以是大型二进制文件，因此 DVC 用于以版本化方式将它们与 Git 同步。

该 monorepo 与持续集成 (CI) 工具集成。 对于存储库或新模型的每次新推送，都会运行以下步骤：

1. 通过代码质量检查。
2. 下载模型权重。
3. 构建Conda环境。
4. 使用 Conda 环境启动 Triton 服务器并使用它来处理单元测试中定义的请求。
5. 构建最终模型 TAR 文件（<model_name>_<model_version>.tar.gz).

这些步骤可确保模型具有部署所需的质量，因此每次推送到存储库分支时，生成的 TAR 文件都会被复制（在另一个 CI 步骤中）到暂存 S3 存储桶。 在主分支中完成推送后，模型文件将复制到生产 S3 存储桶。 下图描述了这个 CI/CD 系统。

成本和部署速度优势

使用 MME 允许 Veriff 使用 monorepo 方法将模型部署到生产环境。 综上所述，Veriff的新模型部署工作流程包括以下步骤：

1. 使用新模型或模型版本在 monorepo 中创建分支。
2. 在开发机器中定义并运行单元测试。
3. 当模型准备好在临时环境中进行测试时推送分支。
4. 当模型准备好在生产中使用时，将分支合并到主分支中。

有了这个新的解决方案，在 Veriff 部署模型就成为开发过程中一个简单的部分。 新车型开发时间从10天缩短到平均2天。

SageMaker 的托管基础​​设施配置和自动扩展功能为 Veriff 带来了额外的好处。 他们使用了 每个实例的调用数 CloudWatch 指标可根据流量模式进行扩展，从而在不牺牲可靠性的情况下节省成本。 为了定义指标的阈值，他们在登台端点上执行负载测试，以找到延迟和成本之间的最佳权衡。

在向 MME 部署七个生产模型并分析支出后，Veriff 报告称，与最初基于 Kubernetes 的解决方案相比，GPU 模型服务的成本降低了 75%。 运营成本也降低了，因为手动配置实例的负担从公司的 DevOps 工程师身上减轻了。

结论

在这篇文章中，我们回顾了 Veriff 选择 Sagemaker MME 而不是 Kubernetes 上的自我管理模型部署的原因。 SageMaker 承担了无差别的繁重工作，使 Veriff 能够减少模型开发时间、提高工程效率并大幅降低实时推理成本，同时保持关键业务运营所需的性能。 最后，我们展示了 Veriff 简单而有效的模型部署 CI/CD 管道和模型版本控制机制，可以作为软件开发最佳实践与 SageMaker MME 相结合的参考实现。 您可以在以下位置找到有关使用 SageMaker MME 托管多个模型的代码示例 GitHub上.

---

作者简介

里卡德·博拉斯 是 Veriff 的高级机器学习人员，负责领导公司的 MLOps 工作。 他通过在公司构建数据科学平台，并将多个开源解决方案与 AWS 服务相结合，帮助数据科学家构建更快、更好的 AI/ML 产品。

若昂·莫拉 是位于西班牙的 AWS 的 AI/ML 专家解决方案架构师。 他帮助客户进行深度学习模型大规模训练和推理优化，以及更广泛地在 AWS 上构建大规模 ML 平台。

米格尔·费雷拉（Miguel Ferreira） 在位于芬兰赫尔辛基的 AWS 担任高级解决方案架构师。 AI/ML 一直是他一生的兴趣，他已帮助多个客户将 Amazon SageMaker 集成到他们的 ML 工作流程中。

• SEO 支持的内容和 PR 分发。 今天得到放大。
• PlatoData.Network 垂直生成人工智能。 赋予自己力量。 访问这里。
• 柏拉图爱流。 Web3 智能。 知识放大。 访问这里。
• 柏拉图ESG。 碳， 清洁科技, 能源， 环境， 太阳能， 废物管理。 访问这里。
• 柏拉图健康。 生物技术和临床试验情报。 访问这里。
• Sumber: https://aws.amazon.com/blogs/machine-learning/how-veriff-decreased-deployment-time-by-80-using-amazon-sagemaker-multi-model-endpoints/