使用 Amazon SageMaker 上的 NVIDIA Triton 推理服务器实现模型服务的超大规模性能

机器学习 (ML) 应用程序部署复杂，并且通常需要多个 ML 模型来服务单个推理请求。 一个典型的请求可能跨越多个模型，包括预处理、数据转换、模型选择逻辑、模型聚合和后处理等步骤。 这导致了串行推理管道、集成（分散聚集）和业务逻辑工作流等常见设计模式的演变，从而将请求的整个工作流实现为有向无环图（DAG）。 但是，随着工作流程变得越来越复杂，这会导致这些应用程序的整体响应时间或延迟增加，进而影响整体用户体验。 此外，如果这些组件托管在不同的实例上，这些实例之间的额外网络延迟会增加整体延迟。 考虑一个流行的 ML 用例示例，用于客户支持中的虚拟助理。 一个典型的请求可能必须经过几个步骤，包括语音识别、自然语言处理 (NLP)、对话状态跟踪、对话策略、文本生成，最后是文本到语音。 此外，为了使用户交互更加个性化，您还可以使用最先进的基于 Transformer 的 NLP 模型，例如不同版本的 BERT, BART及 GPT. 最终结果是这些模型集合的响应时间长且客户体验差。

在不影响整体吞吐量的情况下降低响应时间的一种常见模式是将这些模型与嵌入其中的轻量级业务逻辑一起托管在同一个实例上。 这些模型可以进一步封装在同一实例上的单个或多个容器中，以便为正在运行的进程提供隔离并保持低延迟。 此外，总体延迟还取决于推理应用程序逻辑、模型优化、底层基础设施（包括计算、存储和网络）以及接受推理请求的底层 Web 服务器。 NVIDIA Triton 推理服务器 是一款开源推理服务软件，具有最大限度地提高吞吐量和硬件利用率以及超低（个位数毫秒）推理延迟的功能。 它广泛支持 ML 框架（包括 TensorFlow、PyTorch、ONNX、XGBoost 和 NVIDIA TensorRT）和基础设施后端，包括 GPU、CPU 和 AWS 推理. 此外，Triton 推理服务器与 亚马逊SageMaker，一个完全托管的端到端 ML 服务，提供实时推理选项，包括 单 和 多型号 托管。 这些推理选项包括在同一容器中托管多个模型 单端点, 和托管 具有多个容器的多个模型 在单个端点后面。

2021 年 XNUMX 月，我们宣布 Triton 推理服务器在 SageMaker 上的集成. AWS 与 NVIDIA 密切合作，使您能够两全其美，并更轻松地在 AWS 上使用 Triton 进行模型部署。

在这篇文章中，我们将探讨使用 SageMaker 上的 Triton 推理服务器在 GPU 上大规模部署 Transformer 模型的最佳实践。 首先，我们首先概述 SageMaker 中有关延迟的关键概念，并概述性能调优指南。 接下来，我们将概述 Triton 及其功能以及在 SageMaker 上部署的示例代码。 最后，我们使用 SageMaker 推理推荐器 并总结 Hugging Face 提供的流行变压器模型负载测试的见解和结论。

您可以查看 笔记本 我们曾经使用以下代码自行部署模型并执行负载测试 GitHub上.

SageMaker 上模型服务的性能调优和优化

性能调优和优化是一个经验过程，通常涉及多次迭代。 要调整的参数数量是组合的，并且配置参数值的集合不是彼此独立的。 各种因素会影响最佳参数调整，包括有效负载大小、类型和推理请求流图中 ML 模型的数量、存储类型、计算实例类型、网络基础设施、应用程序代码、推理服务软件运行时和配置等。

如果您使用 SageMaker 部署 ML 模型，则必须选择具有最佳性价比的计算实例，这是一个复杂且反复的过程，可能需要数周的试验。 首先，您需要根据模型的资源需求和输入数据的大小，从 70 多个选项中选择正确的 ML 实例类型。 接下来，您需要针对所选实例类型优化模型。 最后，您需要配置和管理基础架构以运行负载测试并调整云配置以获得最佳性能和成本。 所有这些都会延迟模型部署和上市时间。 此外，您需要评估延迟、吞吐量和成本之间的权衡，以选择最佳部署配置。 SageMaker 推理推荐器 自动选择正确的计算实例类型、实例计数、容器参数和模型优化以进行推理，以最大限度地提高吞吐量、减少延迟并最大限度地降低成本。

SageMaker 中的实时推理和延迟

SageMaker 实时推理 非常适合具有实时、交互式、低延迟要求的推理工作负载。 有四个最常用的指标可用于监控 SageMaker 推理端点的推理请求延迟

• 容器延迟 – 发送请求、从模型容器中获取响应以及在容器中完成推理所需的时间。 该指标在 Amazon CloudWatch 中作为 调用指标 由 SageMaker 发布。
• 模型延迟 – 所有 SageMaker 容器在一个 推理管道. 该指标在 Amazon CloudWatch 中作为 调用指标 由 SageMaker 发布。
• 开销延迟 – 从 SageMaker 收到请求到它向客户端返回响应的时间减去模型延迟。 该指标在 Amazon CloudWatch 中作为 调用指标 由 SageMaker 发布。
• 端到端延迟 – 从客户端发送推理请求到收到响应的时间测量。 客户可以将此作为自定义指标发布在 Amazon CloudWatch 中。

下图说明了这些组件。

容器延迟取决于几个因素； 以下是最重要的：

• 用于与推理服务器通信的底层协议 (HTTP(s)/gRPC)
• 与创建新 TLS 连接相关的开销
• 请求/响应负载的反序列化时间
• 底层推理服务器提供的请求队列和批处理功能
• 底层推理服务器提供的请求调度能力
• 推理服务器的基础运行时性能
• 调用模型预测函数之前的预处理和后处理库的性能
• 底层 ML 框架后端性能
• 特定于模型和特定于硬件的优化

在这篇文章中，我们主要关注优化容器延迟以及整体吞吐量和成本。 具体来说，我们探索了在 SageMaker 容器内运行的 Triton 推理服务器的性能调整。

用例概述

在生产环境中部署和扩展 NLP 模型可能非常具有挑战性。 NLP 模型通常规模很大，包含数百万个模型参数。 需要优化模型配置来满足生产级 NLP 应用程序的严格性能和可扩展性要求。

在这篇文章中，我们使用基于 Triton 推理服务器容器的 SageMaker 实时端点对 NLP 用例进行基准测试，并为我们的 ML 用例推荐性能调整优化。 我们使用一个大型的、预训练的基于 Transformer 的 Hugging Face BERT 大号无壳 模型，它有大约 336 亿个模型参数。 用于二进制分类模型的输入句子被填充并截断为最大输入序列长度为 512 个标记。 推理负载测试模拟每秒 500 次调用（每分钟最多 30,000 次调用）和 ModelLatency 小于 0.5 秒（500 毫秒）。

下表总结了我们的基准测试配置。

NVIDIA Triton 推理服务器

Triton Inference Server 专门设计用于在生产中实现可扩展、快速和轻松的模型部署。 Triton 支持各种主要的 AI 框架，包括 TensorFlow、TensorRT、PyTorch、XGBoost 和 ONNX。 借助 Python 和 C++ 自定义后端，您还可以针对更多自定义用例实施推理工作负载。

最重要的是，Triton 提供了一个简单的基于配置的设置来托管您的模型，它提供了一组丰富的性能优化功能，您只需很少的编码工作即可使用。

Triton 通过使用不同的优化技术（并发模型运行和动态批处理是最常用的）最大化硬件利用率来提高推理性能。 从动态批量大小和并发模型实例数量的各种组合中找到最佳模型配置是使用 Triton 在低成本服务中实现实时推理的关键。

动态批处理

当使用多个独立请求调用服务器时，许多从业者倾向于按顺序运行推理。 尽管设置起来更容易，但利用 GPU 的计算能力通常不是最佳做法。 为了解决这个问题，Triton 提供了内置的优化 动态批处理 在服务器端将这些独立的推理请求组合起来，动态形成更大的批次，以提高吞吐量。 下图说明了 Triton 运行时架构。

在上述架构中，所有请求首先到达动态批处理器，然后进入实际的模型调度器队列等待推理。 您可以使用 首选批次大小 模型配置中的设置。 （请注意，形成的批量大小需要小于 最大批量大小 该型号支持。）您还可以配置 最大队列延迟微秒 根据您的延迟要求指定批处理器中等待其他请求加入批处理的最大延迟时间。

以下代码片段显示了如何使用模型配置文件添加此功能，以设置动态批处理，首选批处理大小为 16 以进行实际推理。 使用当前设置，当满足首选批处理大小 16 或自第一个请求到达动态批处理器后经过 100 微秒的延迟时间时，立即调用模型实例。

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

同时运行模型

Triton 中提供的另一个重要优化是在不增加延迟开销的情况下最大限度地提高硬件利用率是 并发模型执行，它允许多个模型或同一模型的多个副本并行运行。 此功能使 Triton 能够同时处理多个推理请求，从而通过利用硬件上原本空闲的计算能力来增加推理吞吐量。

下图展示了如何只需更改几行代码即可轻松配置不同的模型部署策略。 例如，配置A（左）显示可以广播两个模型实例的相同配置 bert-large-uncased 到所有可用的 GPU。 相比之下，配置 B（中）仅显示了 GPU 0 的不同配置，而没有更改其他 GPU 上的策略。 您还可以在单​​个 GPU 上部署不同模型的实例，如配置 C（右）所示。

在配置 C 中，计算实例可以处理 DistilGPT-2 模型的两个并发请求和七个并发请求 bert-large-uncased 模型并行。 通过这些优化，可以更好地将硬件资源用于服务流程，从而提高吞吐量并为您的工作负载提供更好的成本效益。

张量RT

英伟达 TensorRT 是用于高性能深度学习推理的 SDK，可与 Triton 无缝协作。 TensorRT 支持所有主要的深度学习框架，包括一个推理优化器和运行时，可提供低延迟和高吞吐量，通过强大的优化运行大量数据的推理。

TensorRT 通过释放不必要的内存并有效地重用它来优化图形以最小化内存占用。 此外，TensorRT 编译融合了模型图中的稀疏操作以形成更大的内核，以避免多个小内核启动的开销。 内核自动调整通过在目标 GPU 上选择最佳算法来帮助您充分利用硬件。 CUDA 流使模型能够并行运行，以最大限度地提高 GPU 利用率以获得最佳性能。 最后但同样重要的是，量化技术可以充分利用 Tensor 核的混合精度加速在 FP32、TF32、FP16 和 INT8 中运行模型，以实现最佳推理性能。

SageMaker 托管上的 Triton

SageMaker 托管 services 是一组 SageMaker 功能，旨在简化模型部署和服务。 它提供了多种选项来轻松部署、自动扩展、监控和优化针对不同用例量身定制的 ML 模型。 这意味着您可以针对所有类型的使用模式优化部署，从持久且始终可用的无服务器选项，到瞬态、长时间运行或批量推理需求。

SageMaker 托管保护伞下还有一组 SageMaker 推理深度学习容器 (DLC)，它们与相应的受支持 ML 框架的适当模型服务器软件一起预先打包。 这使您能够在没有模型服务器设置的情况下实现高推理性能，这通常是模型部署中最复杂的技术方面，通常不属于数据科学家的技能组合。 Triton 推理服务器现在是 可使用 关于 SageMaker 深度学习容器 (DLC).

这种广泛的选项、模块化和不同服务框架的易用性使 SageMaker 和 Triton 成为强大的匹配项。

SageMaker Inference Recommender 用于基准测试结果

我们使用 SageMaker Inference Recommender 来运行我们的实验。 SageMaker Inference Recommender 提供两种类型的作业：默认和高级，如下图所示。

默认作业仅使用模型和示例负载提供有关实例类型的建议以进行基准测试。 除了实例推荐之外，该服务还提供提高性能的运行时参数。 默认作业的建议旨在缩小实例搜索范围。 在某些情况下，它可能是实例系列，而在其他情况下，它可能是特定的实例类型。 然后将默认作业的结果输入高级作业。

高级作业提供更多控制以进一步微调性能。 这些控件模拟真实环境和生产要求。 在这些控制中是流量模式，它旨在为基准测试设置请求模式。 您可以使用交通模式的多个阶段来设置坡道或稳定交通。 例如，一个 初始用户数 1， 生成率 1，和 持续时间InSeconds 600 可能会导致 10 分钟的斜坡流量，开始时有 1 个并发用户，最后有 10 个并发用户。 此外，在控件上， 最大调用次数 和 模型延迟阈值 设置生产阈值，因此当超过其中一个阈值时，基准测试停止。

最后， 推荐指标 包括吞吐量、最大吞吐量时的延迟和每次推理的成本，因此很容易比较它们。

我们使用 SageMaker Inference Recommender 的高级作业类型来运行我们的实验，以获得对流量模式的额外控制，并微调服务容器的配置。

实验设置

我们使用 SageMaker Inference Recommender 的自定义负载测试功能对我们用例中概述的 NLP 配置文件进行基准测试。 我们首先定义以下与 NLP 模型和 ML 任务相关的先决条件。 SageMaker Inference Recommender 使用此信息从 Amazon Elastic Container注册 (Amazon ECR) 并使用 SageMaker 模型注册表注册模型。

SageMaker Inference Recommender 中的流量模式配置允许我们为自定义负载测试定义不同的阶段。 负载测试从两个初始用户开始，每分钟产生两个新用户，总持续时间为 25 分钟（1500 秒），如以下代码所示：

"TrafficPattern": { "TrafficType": "PHASES", "Phases": [ { "InitialNumberOfUsers": 2, "SpawnRate": 2, "DurationInSeconds": 1500 }, ],
}

我们尝试在两种不同的状态下对同一模型进行负载测试。 基于 PyTorch 的实验使用标准的、未更改的 PyTorch 模型。 对于基于 TensorRT 的实验，我们预先将 PyTorch 模型转换为 TensorRT 引擎。

我们在这两个模型上应用了不同的性能优化特征组合，总结在下表中。

测试结果和观察

我们对同一 g4dn 系列中的三种实例类型进行了负载测试：ml.g4dn.xlarge、ml.g4dn.2xlarge 和 ml.g4dn.12xlarge。 所有 g4dn 实例类型都可以访问 NVIDIA T4 Tensor Core GPU 和第二代 Intel Cascade Lake 处理器。 选择实例类型背后的逻辑是既要有一个只有一个 GPU 可用的实例，又要有一个可以访问多个 GPU 的实例——在 ml.g2dn.4xlarge 的情况下是四个。 此外，我们想测试仅使用一个可用 GPU 增加实例上的 vCPU 容量是否会提高性价比。

让我们首先回顾一下单个优化的加速。 下图显示，与 ml.g50dn.xlarge 实例上 PyTorch 中的原生延迟相比，TensorRT 优化可将模型延迟降低 4%。 这种延迟减少在 ml.g4dn.12xlarge 的多 GPU 实例上增长了三倍以上。 同时，30% 的吞吐量提升在两个实例上是一致的，从而在应用 TensorRT 优化后具有更好的成本效益。

通过动态批处理，我们可以在 ml.g2dn.xlarge、ml.g4dn.4xlarge 和 ml.g2dn.4xlarge 的所有实验实例上使用相同的硬件架构将吞吐量提高近 12 倍，而不会显着增加延迟。

类似地，并发模型执行使我们能够通过最大化 ml.g3dn.xlarge 实例上的 GPU 利用率以及 ml.g4dn.4xlarge 实例和 ml 的多 GPU 实例上大约 2 倍的改进来获得大约 4-2 倍的吞吐量提高。 g4dn.12xlarge.. 这种吞吐量增加没有任何延迟开销。

更好的是，我们可以整合所有这些优化，通过充分利用硬件资源来提供最佳性能。 下表和图表总结了我们在实验中获得的结果。

[1] 上表中的初始实例数是建议的实例数，可与自动扩展策略一起使用，以维持工作负载的吞吐量和延迟要求。

[2] 上表中的每小时成本是根据实例类型的初始实例数和价格计算得出的。

结果主要验证了不同性能优化功能的预期影响：

• TensorRT 编译对所有实例类型具有最可靠的影响。 与 TensorRT 引擎对默认 PyTorch BERT 的性能相比，每个实例每分钟的事务数增加了 30-35%，成本持续降低了约 25%（pt-base）。 TensorRT 引擎的性能提升与其他经过测试的性能调整功能相结合并加以利用。
• 在每个 GPU（实例组）上加载两个模型几乎使所有测量指标增加了一倍。 每个实例每分钟的调用量增加了大约 80-90%，成本降低了 50%，几乎就像我们使用两个 GPU 一样。 实际上， 亚马逊CloudWatch 我们在 g4dn.2xlarge 上的实验指标（例如）证实，当我们配置一个包含两个模型的实例组时，CPU 和 GPU 利用率都翻了一番。

进一步的性能和成本优化技巧

这篇文章中提供的基准测试只是触及了可以与 Triton 一起使用以提高推理性能的可能特性和技术的表面。 这些范围从数据预处理技术（例如将二进制有效负载发送到模型服务器或具有更大批量的有效负载）到本机 Triton 功能，如下所示：

• 模型热身，它通过在收到第一个推理请求之前完全初始化模型来防止初始、缓慢的推理请求。
• 响应缓存，它缓存重复的请求。
• 模型合奏，这使您能够创建一个或多个模型的管道以及这些模型之间的输入和输出张量的连接。 这开启了在每个请求的处理流程中添加预处理和后处理步骤，甚至使用其他模型进行推理的可能性。

我们希望在未来的帖子中测试和基准测试这些技术和功能，敬请期待！

结论

在这篇文章中，我们探讨了一些参数，您可以使用这些参数来最大限度地提高 SageMaker 实时端点的性能，以便使用 Triton 推理服务器为 PyTorch BERT 模型提供服务。 我们使用 SageMaker Inference Recommender 执行基准测试以微调这些参数。 这些参数本质上与基于 TensorRT 的模型优化有关，与未优化的版本相比，响应时间提高了近 50%。 此外，同时运行模型并使用 Triton 的动态批处理导致吞吐量增加了近 70%。 微调这些参数也导致推理成本的整体降低。

得出正确值的最佳方法是通过实验。 但是，要开始构建有关性能调整和优化的经验知识，您可以观察不同 Triton 相关参数的组合及其对 ML 模型和 SageMaker ML 实例的性能的影响。

SageMaker 提供的工具可以消除 ML 生命周期每个阶段的繁重工作，从而促进全面优化模型部署所需的快速实验和探索。

您可以在以下位置找到用于负载测试和部署的笔记本 GitHub上. 您可以更新 Triton 配置和 SageMaker Inference Recommender 设置以最适合您的使用案例，从而实现经济高效且性能最佳的推理工作负载。

作者简介

维克拉姆·埃兰戈 是位于美国弗吉尼亚州的 Amazon Web Services 的 AI/ML 专家解决方案架构师。 Vikram 以设计和思想领导力帮助金融和保险行业客户大规模构建和部署机器学习应用程序。 他目前专注于整个企业的自然语言处理、负责任的 AI、推理优化和扩展 ML。 在业余时间，他喜欢和家人一起旅行、远足、烹饪和露营。

若昂·莫拉 是 Amazon Web Services 的 AI/ML 专家解决方案架构师。 他主要专注于 NLP 用例和帮助客户优化深度学习模型训练和部署。 他还是低代码 ML 解决方案和 ML 专用硬件的积极支持者。

莫汉甘地 是 AWS 的高级软件工程师。 在过去的 9 年中，他一直在 AWS 工作，并参与了各种 AWS 服务，例如 EMR、EFA 和 RDS on Outposts。 目前，他专注于改进 SageMaker 推理体验。 业余时间，他喜欢远足和跑马拉松。

达瓦尔·帕特尔 是 AWS 的首席机器学习架构师。 他曾与从大型企业到中型初创公司的组织合作，解决与分布式计算和人工智能相关的问题。 他专注于深度学习，包括 NLP 和计算机视觉领域。 他帮助客户在 SageMaker 上实现高性能模型推理。

桑托什·巴瓦尼（Santosh Bhavani） 是Amazon SageMaker Elastic Inference团队的高级技术产品经理。 他致力于帮助SageMaker客户加速模型推断和部署。 业余时间，他喜欢旅行，打网球和喝很多普'茶。

刘家宏 是 NVIDIA 云服务提供商团队的解决方案架构师。 他帮助客户采用机器学习和人工智能解决方案，利用 NVIDIA 加速计算来解决他们的训练和推理挑战。 闲暇时间，他喜欢折纸、DIY项目和打篮球。

• 硬币聪明。 欧洲最好的比特币和加密货币交易所。
• 柏拉图区块链。 Web3 元宇宙智能。 知识放大。 自由登入。
• 加密鹰。 山寨币雷达。 免费试用。
• 来源：https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/