美团视觉GPU推理服务部署架构完善实践
发布时间：2023-02-14 14:25:14 所属栏目：服务器 来源：互联网
导读：以图像检测+分类服务为例，优化后的服务压测性能指标GPU利用率由40%提升至100%，QPS也提升超过3倍。本文将会重点介绍推理服务部署架构优化的工程实践，希望对大家能有所帮助或启发。 0. 导读 通过实验分析发现，造成视觉推理服务GPU利用率低下的一个重要原因
|
以“图像检测+分类”服务为例，优化后的服务压测性能指标GPU利用率由40%提升至100%，QPS也提升超过3倍。本文将会重点介绍推理服务部署架构优化的工程实践，希望对大家能有所帮助或启发。 0. 导读 通过实验分析发现，造成视觉推理服务GPU利用率低下的一个重要原因是模型结构问题：模型中预处理或者后处理部分CPU运算速度慢，导致推理主干网络无法充分发挥GPU运算性能。基于此，视觉研发团队通过模型结构拆分和微服务化，提出一种通用高效的部署架构，解决这种常见的性能瓶颈问题。 目前，该解决方案已经在多个核心服务上成功应用。以“图像检测+分类”服务为例，优化后的服务压测性能指标GPU利用率由40%提升至100%，QPS提升超过3倍。本文将会重点介绍推理服务部署架构优化的工程实践，希望对从事相关工作的同学们有所帮助或启发。 1. 背景 随着越来越多的AI应用进入生产应用阶段，推理服务所需要的GPU资源也在迅速增加。调研数据表明，国内AI相关行业推理服务的资源使用量占比已经超过55%，且比例未来还会持续升高。但很多公司面临的实际问题是，线上推理服务GPU利用率普遍较低，还具备很大的提升空间。 而造成服务GPU利用率低的重要原因之一是：推理服务本身存在性能瓶颈，在极限压力情况下也无法充分利用GPU资源。在这种背景下，“优化推理服务性能、提高GPU资源使用效率、降低资源使用成本”具有非常重要的意义。本文主要介绍如何通过架构部署优化，在保证准确率、推理时延等指标的前提下，提升推理服务的性能和GPU利用率。 2. 视觉模型服务的特点与挑战 近年来，深度学习方法在计算机视觉任务上取得显著进展，已经成为主流方法。视觉模型在结构上具有一些特殊性，如果使用现有推理框架部署，服务在性能和GPU利用率方面可能无法满足要求。 2.1 模型优化工具与部署框架 深度学习模型部署前通常会使用优化工具进行优化，常见的优化工具包括TensorRT、TF-TRT、TVM和OpenVINO等。这些工具通过算子融合、动态显存分配和精度校准等方法提高模型运行速度。模型部署是生产应用的最后一环，它将深度学习模型推理过程封装成服务，内部实现模型加载、模型版本管理、批处理以及服务接口封装等功能，对外提供RPC/HTTP接口。业界主流的部署框架有以下几种： TensorFlow Serving：TensorFlow Serving（简称TF-Serving）是Google发布用于机器学习模型部署的高性能开源框架，内部集成了TF-TRT优化工具，但是对非TensorFlow格式的模型支持不够友好。 Torch Serve：TorchServe是AWS和Facebook联合推出的Pytorch模型部署推理框架，具有部署简单、高性能、轻量化等优点。 Triton：Triton是Nvidia发布的高性能推理服务框架，支持TensorFlow、TensorRT、PyTorch和ONNX等多种框架模型，适用于多模型联合推理场景。 在实际部署中，无论选择哪种框架，需要同时考虑模型格式、优化工具、框架功能特点等多种因素。 2.3 视觉推理服务面临的问题与挑战 由于视觉模型存在的上述特点，导致模型在部署和优化上存在2个问题： 模型优化不彻底：TensorRT、TF-TRT等工具主要针对主干网络优化，但忽略了预处理部分，因此整个模型优化并不充分或者无法优化。例如分类模型中ResNet-50所有网络层都可以被优化，但预处理中的图像解码（通常是CPU运算）操作"tf.image.decode"会被TF-TRT忽略跳过。 多模型部署困难：视觉服务经常存在组合串接多个模型实现功能的情况。例如在文字识别服务中，先通过检测模型定位文字位置，然后裁切文字所在位置的局部图片，最后送入识别模型得到文字识别结果。服务中多个模型可能采用不同训练框架，TF-Serving或Troch Serve推理框架只支持单一模型格式，无法满足部署需求。Triton支持多种模型格式，模型之间的组合逻辑可以通过自定义模块（Backend）和集成调度（Ensemble）方式搭建，但实现起来较为复杂，并且整体性能可能存在问题。 这两点常见的模型部署问题，导致视觉推理服务存在性能瓶颈、GPU利用率低，即便Triton这种高性能部署框架也难以解决。 通用部署框架重点关注的是“通信方式、批处理、多实例”等服务托管方面的性能问题，但如果模型本身中间某个部分（如图像预处理或后处理）存在瓶颈，优化工具也无法优化，就会出现“木桶效应”，导致整个推理过程性能变差。因此，如何优化推理服务中的模型性能瓶颈，仍然是一件重要且具有挑战性的工作。 3. GPU服务优化实践 分类和检测是两种最基础的视觉模型，常应用在图像审核、图像标签分类和人脸检测等场景。下面以两个典型服务为案例，单个分类模型和“分类+检测”多模型组合的使用情况，来介绍具体性能的优化过程。 3.1 图像分类模型服务优化 美团每天有千万量级的图片需要审核过滤有风险内容，人工审核成本太高，需要借助图像分类技术实现机器自动审核。常用的分类模型结构如图1，其中预处理部分主要包括“解码、缩放、裁切”等操作，主干网络是ResNet-50。预处理部分接收图像二进制流，生成主干网络需要的矩阵数据Nx3x224x224（分别代表图片数量、通道数、图像高度和图像宽度 ），主干网络预测输出图片分类结果。 模型经过TF-TRT优化后的实际结构如下图2所示，主干网络ResNet被优化为一个Engine，但预处理部分的算子不支持优化，所以整个预处理部分仍然保持原始状态。 3.1.1 性能瓶颈 模型经过TF-TRT优化后使用TF-Serving框架部署，服务压测GPU利用率只有42%，QPS与Nvidia官方公布的数据差距较大。排除TF-TRT和Tensorflow框架等可能影响的因素，最终聚焦在预处理部分。Nvidia进行性能测试的模型没有预处理，直接输入Nx3x224x224矩阵数据。但这里的线上服务包含了预处理部分，压测指标CPU利用率偏高。查看模型中各个算子的运行设备，发现模型预处理大部分是CPU运算，主干网路是GPU运算（具体细节参见图1）。 如下图3所示，通过NVIDIA Nsight System（nsys）工具查看模型运行时的CPU/GPU执行情况，可以发现GPU运行有明显间隔，需要等待CPU数据准备完成并拷贝到GPU上，才能执行主干网络推理运算，CPU处理速度慢导致GPU处于饥饿状态。结合服务压测的CPU/GPU利用率数据可以看出：预处理部分CPU消耗高、处理速度慢，是推理服务的性能瓶颈。 3.1.2 优化方法 增加CPU：增加机器CPU数量是最简单的做法，但是受限于服务器硬件配置，1个GPU通常只配置8个CPU。所以增加CPU的方法只能用于性能测试数据对比，无法实际应用部署。 分离预处理：另外一种思路是将模型预处理部分和主干网络拆分，预处理部分单独部署到CPU机器上，主干网络部署到GPU机器上。这种做法让CPU预处理服务可以水平无限扩容，满足GPU处理数据供给，充分利用GPU性能。更重要的是将CPU和GPU运算进行解耦，减少了CPU-GPU数据交换等待时间，理论上比增加CPU数量效率更高。唯一需要考虑的是服务间的通信效率和时间，裁切后图像大小为224x224x3，采用无符号整型类型数据大小是143KB，传输时间和带宽在1万QPS以下没有问题。 3.1.3 优化结果 如下图5所示，我们利用NVIDIA Nsight System，对比上述几种方法优化后的模型运行情况。增加CPU和前置预处理的方法都可以缩短CPU预处理时间，减少GPU数据等待时间，提升GPU利用率。但相较而言，分离预处理的方法优化更加彻底，CPU到GPU的数据拷贝时间最短，GPU利用最为充分。 图5 优化方法nsys性能诊断对比图 各种方法优化后的线上服务压测性能结果见下图6（其中前置预处理和分离预处理中的CPU预处理服务额外使用16个CPU），机器配置的CPU型号是Intel(R) Xeon(R) Gold 5218 CPU@2.30GHz、GPU型号是Tesla T4。从压测结果可以看出： 图6 优化结果性能对比 1. 服务CPU增加到32核，QPS和GPU利用率（通过nvidia-smi命令获取的GPU-Util指标）提升超过1倍，GPU利用率提升至88%； 2.. 分离预处理方法优化后QPS提升2.7倍，GPU利用率达到98%接近满载状态。 增加CPU并不能完全解决服务性能瓶颈问题，虽然GPU利用率达到88%，但是CPU-GPU数据传输时间占比较大，QPS提升有限。前置预处理方法也没有完全解决预处理性能瓶颈问题，优化并不彻底。相较而言，分离预处理方法充分发挥了GPU运算性能，在QPS和GPU利用率指标上都取得了更好的优化效果。 3.2 图像“检测+分类”模型服务优化 在一些复杂任务场景下（如人脸检测识别、图像文字识别等），通常是检测、分割、分类等多个模型组合实现功能。本节介绍的模型便是由“检测+分类”串接而成，模型结构如下图7所示，主要包括以下几个部分： 图7 原始模型结构示意图 预处理：主要包括图像解码、缩放、填充等操作，输出Nx3x512x512图像矩阵，大部分算子运行在CPU设备上。 检测模型：检测网络结构是YOLOv5，算子运行设备为GPU。 （编辑：甘南站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
