机器学习 (ML) 模型部署可能对当今的企业有非常苛刻的性能和延迟要求。 诸如欺诈检测和广告投放之类的用例是毫秒很重要并且对业务成功至关重要的示例。 需要满足严格的服务水平协议（SLA），一个典型的请求可能需要预处理、数据转换、模型选择逻辑、模型聚合和后处理等多个步骤。 在规模上，这通常意味着在保持低延迟的同时保持大量流量。 常见的设计模式包括串行推理管道、集成（分散-聚集）和业务逻辑工作流，从而将请求的整个工作流实现为有向无环图（DAG）。 但是，随着工作流程变得越来越复杂，这可能会导致整体响应时间增加，进而会对最终用户体验产生负面影响并危及业务目标。 Triton 可以解决这些用例，其中多个模型在管道中组成，它们之间连接输入和输出张量，帮助您解决这些工作负载。
当您评估与 ML 模型推理相关的目标时，可以考虑许多选项，但很少有像 亚马逊SageMaker Triton 推理服务器. 带有 Triton 推理服务器的 SageMaker 一直是许多客户的热门选择，因为它专为最大限度地提高吞吐量和硬件利用率而设计，具有超低（个位数毫秒）的推理延迟。 它拥有广泛支持的 ML 框架（包括 TensorFlow、PyTorch、ONNX、XGBoost 和 NVIDIA TensorRT）和基础设施后端，包括 NVIDIA GPU、CPU 和 AWS 推理. 此外，Triton 推理服务器与 SageMaker 集成，这是一种完全托管的端到端 ML 服务，为模型托管提供实时推理选项。
在这篇文章中，我们将介绍如何使用 Triton 推理服务器将欺诈检测集成工作负载部署到 SageMaker。
解决方案概述
任何项目都必须有一个需求列表和工作量估算，以便估算项目的总成本。 估算支持组织决策的投资回报率 (ROI) 非常重要。 将工作负载迁移到 Triton 时需要考虑的一些注意事项包括：
工作量估计是软件开发的关键，它的测量通常基于不完整、不确定和嘈杂的输入。 ML 工作负载也不例外。 多种因素将影响 ML 推理的架构，其中一些包括：
- 客户端延迟预算 – 它指定推理响应的客户端往返最大可接受等待时间，通常以百分位数表示。 对于需要接近数十毫秒的延迟预算的工作负载，网络传输可能会变得昂贵，因此在边缘使用模型会更合适。
- 数据有效载荷分布大小 – 有效载荷，通常称为 邮件正文, 是客户端传给模型的请求数据，也是模型传给客户端的响应数据。 有效载荷大小通常对延迟有重大影响，应予以考虑。
- 资料格式 – 这指定了如何将有效负载发送到 ML 模型。 格式可以是人类可读的，例如 JSON 和 CSV，但也有二进制格式，它们通常被压缩并且尺寸更小。 这是压缩开销和传输大小之间的权衡，这意味着在压缩或解压缩时会增加 CPU 周期和延迟，以节省通过网络传输的字节。 这篇文章展示了如何同时使用 JSON 和二进制格式。
- 所需的软件堆栈和组件 – 堆栈是一起运行以支持 ML 应用程序的组件的集合，包括操作系统、运行时和软件层。 Triton 带有内置的流行 ML 框架，称为 后端，如 ONNX、TensorFlow、FIL、OpenVINO、原生 Python 等。 您还可以创作一个 自定义后端 为您自己的本土组件。 这篇文章介绍了 XGBoost 模型和数据预处理，我们分别将其迁移到 NVIDIA 提供的 FIL 和 Python Triton 后端。
所有这些因素都应该在评估您的工作负载的性能方面发挥重要作用，但在这个用例中，我们专注于将您的 ML 模型迁移到使用 Triton Inference Server 托管在 SageMaker 中所需的工作。 具体来说，我们使用了一个由 XGBoost 模型组成的欺诈检测集成示例，该模型具有用 Python 编写的预处理逻辑。
NVIDIA Triton 推理服务器
Triton 推理服务器从头开始设计，使团队能够从基于 GPU 或 CPU 的基础设施上的任何框架部署、运行和扩展经过训练的 AI 模型。 此外，它已经过优化，可大规模提供高性能推理，具有动态批处理、并发运行、最佳模型配置、模型集成和支持流输入等功能。
下图显示了一个示例 NVIDIA Triton 集成管道。
工作负载应考虑 Triton 与 SageMaker 托管一起提供的功能，以最大限度地发挥所提供的优势。 例如，Triton 支持 HTTP 以及 编程接口，这允许在需要时进行灵活性和有效负载优化。 如前所述，Triton 支持多种开箱即用的流行框架，包括 TensorFlow、PyTorch、ONNX、XGBoost 和 NVIDIA TensorRT。 这些框架通过 Triton 后端得到支持，在极少数情况下后端不支持您的用例， Triton 允许您实现自己的并轻松集成.
下图显示了 NVIDIA Triton 架构的示例。
SageMaker 上的 NVIDIA Triton
SageMaker 托管 services 是一组 SageMaker 功能，旨在简化模型部署和服务。 它提供了多种选项来轻松部署、自动扩展、监控和优化针对不同用例量身定制的 ML 模型。 这意味着您可以针对所有类型的使用模式优化部署，从持久且始终可用的无服务器选项，到瞬态、长时间运行或批量推理需求。
SageMaker 托管保护伞下还有一组 SageMaker 推理深度学习容器 (DLC)，它们与相应的模型服务器软件一起预先打包，用于相应的受支持的 ML 框架。 这使您能够在没有模型服务器设置的情况下实现高推理性能，这通常是模型部署中最复杂的技术方面，通常不属于数据科学家的技能组合。 Triton 推理服务器现在是 可使用 在 SageMaker DLC 上。
这种广泛的选项、模块化和不同服务框架的易用性使 SageMaker 和 Triton 成为强大的匹配项。
NVIDIA FIL 后端支持
随着 Triton 22.05 版本发布, NVIDIA 现在支持由几个流行的 ML 框架训练的森林模型，包括 XGBoost、LightGBM、Scikit-learn 和 cuML。 当使用 Triton 的 FIL 后端时，您应该确保您提供的模型工件受支持。 例如，FIL 支持 model_type xgboost, xgboost_json, lightgbm或 treelite_checkpoint，分别表示提供的模型是 XGBoost 二进制格式、XGBoost JSON 格式、LightGBM 文本格式还是 Treelite 二进制格式。
这种后端支持对于我们在示例中使用至关重要，因为 FIL 支持 XGBoost 模型。 唯一需要检查的是确保我们部署的模型支持二进制或 JSON 格式。
除了确保您拥有正确的模型格式外，还应考虑其他因素。 Triton 的 FIL 后端为开发人员提供了可配置的选项，以调整他们的工作负载并优化模型运行性能。 配置 dynamic_batching 允许 Triton 保存客户端请求并在服务器端对它们进行批处理，以便有效地使用 FIL 的并行计算来推断整个批处理。 选项 max_queue_delay_microseconds 提供对 Triton 等待形成批次的时间的故障安全控制。 FIL自带Shapley解释器，可以通过配置激活 treeshap_output; 但是，您应该记住，Shapley 输出会因其输出大小而损害性能。 另一个重要方面是 storage_type 为了在内存占用和运行时之间进行权衡。 例如，将存储用作 SPARSE 可以减少内存消耗，而 DENSE 可以降低模型运行性能，但会以更高的内存使用量为代价。 确定每个选项的最佳选择取决于您的工作负载和延迟预算，因此我们建议您更深入地了解 FIL 后端常见问题 和 FIL 中可用的配置列表.
在 triton 上托管模型的步骤
让我们以欺诈检测用例为例，了解将工作负载迁移到 Triton 时应考虑的事项。
确定您的工作量
在这个用例中，我们有一个在零售客户结账过程中使用的欺诈检测模型。 推理管道使用具有预处理逻辑的 XGBoost 算法，其中包括预处理的数据准备。
确定当前和目标绩效指标以及可能适用的其他目标
您可能会发现您的端到端推理时间太长而无法接受。 对于相同数量的请求和相应的吞吐量，您的目标可能是从几十毫秒的延迟到个位数的延迟。 您确定大部分时间用于数据预处理和 XGBoost 模型。 网络和有效负载大小等其他因素在与端到端推理时间相关的开销中起着最小的作用。
向后工作以确定 Triton 是否可以根据您的要求托管您的工作负载
要确定 Triton 是否可以满足您的要求，您需要注意两个主要关注领域。 首先是确保 Triton 可以使用可接受的前端选项（例如 HTTP 或 C API）提供服务。
如前所述，确定 Triton 是否支持可以为您的工件提供服务的后端也很重要。 Triton 支持许多 后端 为支持 PyTorch 和 TensorFlow 等各种框架而量身定制的。 检查以确保您的模型受支持，并且您拥有 Triton 期望的正确模型格式。 为此，首先检查 Triton 后端支持的模型格式。 在许多情况下，这不需要对模型进行任何更改。 在其他情况下，您的模型可能需要转换为不同的格式。 根据源和目标格式，存在各种选项，例如将 Python pickle 文件使用 Treelite 的二进制检查点格式.
对于这个用例，我们确定 FIL 后端 无需更改即可支持 XGBoost 模型，并且我们可以使用 Python 后端 用于预处理。 借助 Triton 的集成功能，您可以通过避免托管实例之间昂贵的网络调用来进一步优化您的工作负载。
创建一个计划并估计使用 Triton 进行托管所需的工作量
让我们谈谈将模型移至 Triton 的计划。 每个 Triton 部署都需要以下内容：
- Triton 后端所需的模型工件
- 海卫一配置文件
- 具有适当结构的模型存储库文件夹
我们将在本文后面展示如何创建这些部署依赖项的示例。
运行计划并验证结果
在正确结构化的模型存储库中创建所需的文件和工件后，您需要调整部署并对其进行测试，以验证您现在是否达到了目标指标。
此时，您可以使用 SageMaker 推理推荐器 根据您的要求确定最适合您的端点实例类型。 此外，Triton 提供工具来进行构建优化以获得更好的性能。
SAP系统集成计划实施
现在让我们看一下实现细节。 为此，我们准备了两个笔记本，提供了一个可以预期的示例。 这 第一个笔记本 显示了给定 XGBoost 模型的训练以及用于训练和推理时间的预处理逻辑。 这 第二个笔记本 展示了我们如何准备在 Triton 上部署所需的工件。
第一个笔记本显示您的组织拥有的现有笔记本，该笔记本使用 急流 一套库和 RAPIDS Conda 内核。 此实例在 AWS 提供的 G4DN 实例类型上运行，该实例类型使用 NVIDIA T4 处理器进行 GPU 加速。
此示例中的预处理任务受益于 GPU 加速并大量使用 cuML 和 cuDF 库。 下面的代码就是一个例子，我们展示了使用 cuML 的分类标签编码。 我们还生成一个 label_encoders.pkl 我们可以使用该文件来序列化编码器并在推理期间使用它们进行预处理。
第一个笔记本通过训练我们的 XGBoost 模型并相应地保存工件来结束。
在这种情况下，训练代码已经存在，并且在训练时不需要对模型进行任何更改。 此外，虽然我们在训练期间使用 GPU 加速进行预处理，但我们计划在推理时使用 CPU 进行预处理。 我们稍后会在帖子中解释。
现在让我们转到第二个笔记本，并回忆一下成功部署 Triton 所需的内容。
首先，我们需要后端所需的模型工件。 我们需要为这个 ensemble 创建的文件包括：
- 预处理工件（
model.py,label_encoders.pkl) - XGBoost 模型工件 (
xgboost.json)
Triton 中的 Python 后端要求我们使用 Conda 环境作为依赖项。 在这种情况下，我们使用 Python 后端对原始数据进行预处理，然后再将其输入到在 FIL 后端运行的 XGBoost 模型中。 尽管我们最初使用 RAPIDS cuDF 和 cuML 库来进行数据预处理（如之前使用我们的 GPU 所引用的），但这里我们使用 Pandas 和 Scikit-learn 作为推理时间的预处理依赖项（使用我们的 CPU）。 我们这样做有三个原因：
- 展示如何为您的依赖项创建 Conda 环境以及如何将其打包到 预期格式 通过 Triton 的 Python 后端。
- 通过展示预处理模型在 CPU 上的 Python 后端运行，而 XGBoost 模型在 FIL 后端的 GPU 上运行，我们说明了 Triton 集成管道中的每个模型如何在不同的框架后端上运行，并在不同的硬件上以不同的方式运行配置。
- 它强调了 RAPIDS 库（cuDF、cuML）如何与它们的 CPU 对应物（Pandas、Scikit-learn）兼容。 这样，我们可以展示如何
LabelEncoders在 cuML 中创建的可以在 Scikit-learn 中使用，反之亦然。 请注意，如果您希望在推理期间预处理大量表格数据，您仍然可以使用 RAPIDS 对其进行 GPU 加速。
回想一下，我们创建了 label_encoders.pkl 第一个笔记本中的文件。 类别编码除了包含在我们的 model.py 文件进行预处理。
要创建 Triton Python 后端所需的 model.py 文件，我们遵循 后端要求的格式 并包含我们的 Python 逻辑来处理传入的张量并使用前面提到的标签编码器。 您可以查看 文件 用于预处理。
对于 XGBoost 模型，无需再做任何事情。 我们在第一个笔记本中训练了模型，Triton 的 FIL 后端不需要额外的 XGBoost 模型工作。
接下来，我们需要 Triton 配置文件。 Triton 合奏中的每个模型都需要一个 config.pbtxt 文件。 此外，我们还创建了一个 config.pbtxt 文件作为一个整体。 这些文件允许 Triton 了解有关集成的元数据以及我们期望的输入和输出等信息，并帮助定义与集成相关的 DAG。
最后，要在 Triton 上部署模型，我们需要模型存储库文件夹具有正确的文件夹结构。 Triton 对模型存储库布局有特定要求。 在顶级模型存储库目录中，每个模型都有自己的子目录，其中包含相应模型的信息。 Triton 中的每个模型目录必须至少有一个代表模型版本的数字子目录。 对于我们的用例，生成的结构应如下所示。
有了这三个先决条件后，我们创建一个压缩文件作为部署的打包并上传到 亚马逊简单存储服务 （亚马逊S3）。
现在，我们可以从我们在上一步中上传到 Amazon S3 的模型存储库创建 SageMaker 模型。
在这一步中，我们还提供了额外的环境变量 SAGEMAKER_TRITON_DEFAULT_MODEL_NAME，它指定要由 Triton 加载的模型的名称。 此键的值应与上传到 Amazon S3 的模型包中的文件夹名称匹配。 在单个模型的情况下，此变量是可选的。 对于集成模型，必须为 Triton 指定此密钥才能在 SageMaker 中启动。
此外，您可以设置 SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT 和 SAGEMAKER_TRITON_THREAD_COUNT 用于优化线程数。 这两个配置值都有助于调整 CPU 上运行的线程数，因此您可以通过为具有更多内核的 CPU 增加这些值来获得更好的利用率。 在大多数情况下，默认值通常效果很好，但可能值得尝试一下，看看是否可以为您的工作负载获得更高的效率。
使用前面的模型，我们创建了一个端点配置，我们可以在其中指定端点中我们想要的实例的类型和数量。
最后，我们使用前面的端点配置创建一个新的 SageMaker 端点并等待部署完成。 状态变为 InService 部署成功后。
而已！ 您的端点现在已准备好进行测试和验证。 此时，您可能希望使用各种工具来帮助优化您的实例类型和配置，以获得最佳性能。 下图提供了一个示例，说明了通过在 Triton 上为 XGBoost 模型使用 FIL 后端可以获得的收益。
总结
在这篇文章中，我们将引导您使用 Triton 推理服务器将 XGBoost 集成工作负载部署到 SageMaker。 将工作负载转移到 SageMaker 上的 Triton 可以带来有益的投资回报。 与采用任何技术一样，审查流程和计划是关键，我们详细介绍了一个五步流程，以指导您完成迁移工作负载时应考虑的事项。 此外，我们深入研究了在 SageMaker 上的 Triton 上部署使用 Python 预处理和 XGBoost 模型的集成所需的步骤。
SageMaker 提供的工具可以消除 ML 生命周期每个阶段的繁重工作，从而促进全面优化模型部署所需的快速实验和探索。 SageMaker 对 Triton 推理服务器的托管支持可实现低延迟、高每秒事务 (TPS) 工作负载。
您可以在以下位置找到用于此示例的笔记本 GitHub上.
关于作者
詹姆斯公园 是 Amazon Web Services 的解决方案架构师。 他与 Amazon.com 合作，在 AWS 上设计、构建和部署技术解决方案，并且对 AI 和机器学习特别感兴趣。 在业余时间，他喜欢寻找新的文化、新的体验并紧跟最新的技术趋势。
刘家宏 是 NVIDIA 云服务提供商团队的解决方案架构师。 他帮助客户采用机器学习和人工智能解决方案，利用 NVIDIA 加速计算来解决他们的训练和推理挑战。 闲暇时间，他喜欢折纸、DIY项目和打篮球。
克什蒂兹·古普塔 是 NVIDIA 的解决方案架构师。 他喜欢向云客户介绍 NVIDIA 必须提供的 GPU AI 技术，并帮助他们加速机器学习和深度学习应用程序。 工作之余，他喜欢跑步、远足和观赏野生动物。
布鲁诺·阿吉亚尔·德梅洛 是 Amazon.com 的一名软件开发工程师，他帮助科学团队构建、部署和发布 ML 工作负载。 他对 ML 建模/设计阶段必须考虑和衡量的仪器和可控方面感兴趣，因为模型执行性能与模型质量性能同样重要，特别是在延迟受限的用例中。 在业余时间，他喜欢葡萄酒、棋盘游戏和烹饪。
伊柳斯·特里亚纳 是 NVIDIA 的开发者关系经理。 他将 Amazon 和 AWS 产品负责人、开发人员和科学家与 NVIDIA 技术专家和产品负责人联系起来，以加速 Amazon ML/DL 工作负载、EC2 产品和 AWS AI 服务。 此外，Eliuth 还是一位热情的山地车手、滑雪者和扑克玩家。
