面对在线推理服务应用的GPU资源一直减少、GPU利用率广泛较低的挑战，美团视觉研发团队决定通过模型构造拆分和微服务化进行优化，他们提出一种通用高效的部署架构，来解决这种常见的性能瓶颈问题。以“图像检测+分类”服务为例，优化后的服务压测性能指标GPU利用率由40%晋升至100%，QPS也晋升超过3倍。本文将会重点介绍推理服务部署架构优化的工程实际，心愿对大家能有所帮忙或启发。

0. 导读

美团视觉面向本地生存服务，在泛滥场景上落地利用了文字辨认、图像品质评估、视频了解等视觉AI技术。此前，在线推理服务应用的GPU资源一直减少，但服务GPU利用率广泛较低，节约大量计算资源，减少了视觉AI利用老本，这是美团也是很多企业亟需解决的问题。

美团视觉智能部通过试验剖析发现，造成视觉推理服务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.2 视觉模型特点

与传统办法不同， 深度学习是一种端到端的办法，不须要独自设计特征提取、分类器等模块，用单个模型取代传统办法多模块工作。深度学习模型在分类、检测、宰割、辨认等视觉工作上呈现出微小劣势，做到了传统办法无奈达到的精度。罕用的视觉分类模型（如ResNet、GoogleNet等）和检测模型（如YOLO、R-FCN等）具备如下特点：

  • 网络层数多（适宜用GPU运算）：以ResNet-50为例，网络蕴含49个卷积层和1个全连贯层，参数量高达2千5百万，计算量达到38亿FLOPs（浮点运算数）。模型推理蕴含大量矩阵计算，适宜用GPU并行减速。
  • 输出图像尺寸固定（须要预处理）：同样以ResNet-50为例，网络的输出是图像浮点类型矩阵，尺寸大小固定为224x224。因而二进制编码图片在送入网络前，须要做解码、缩放、裁切等预处理操作。

2.3 视觉推理服务面临的问题与挑战

因为视觉模型存在的上述特点，导致模型在部署和优化上存在2个问题：

  1. 模型优化不彻底：TensorRT、TF-TRT等工具次要针对骨干网络优化，但疏忽了预处理局部，因而整个模型优化并不充沛或者无奈优化。例如分类模型中ResNet-50所有网络层都能够被优化，但预处理中的图像解码（通常是CPU运算）操作"tf.image.decode"会被TF-TRT疏忽跳过。
  2. 多模型部署艰难：视觉服务常常存在组合串接多个模型实现性能的状况。例如在文字辨认服务中，先通过检测模型定位文字地位，而后裁切文字所在位置的部分图片，最初送入辨认模型失去文字辨认后果。服务中多个模型可能采纳不同训练框架，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 优化办法

如下图4所示，针对预处理CPU耗费过高影响推理服务性能的问题，提出几种优化办法：

  1. 减少CPU：减少机器CPU数量是最简略的做法，然而受限于服务器硬件配置，1个GPU通常只配置8个CPU。所以减少CPU的办法只能用于性能测试数据比照，无奈理论利用部署。
  2. 前置预处理：大尺寸图片的解码、缩放操作CPU耗费较高，相较而言小尺寸图片的处理速度会快很多。因而思考对输出图片提前进行预处理，将预处理后的小图再送入服务。通过验证Tensorflow中缩放、裁切操作具备叠加不变性，即屡次操作和单次操作对最终后果没有影响。预处理后的小图像通过编码后，再送入原始分类服务。须要留神的是图像编码必须抉择无损编码（如PNG），否则会导致解码数据不统一，引起预测误差。前置预处理形式的长处是不须要批改原始模型服务，可操作性高、预测后果没有误差。毛病是须要反复预处理，导致整体流程时延减少、CPU资源节约。
  3. 拆散预处理：另外一种思路是将模型预处理局部和骨干网络拆分，预处理局部独自部署到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利用最为充沛。

各种办法优化后的线上服务压测性能后果见下图6（其中前置预处理和拆散预处理中的CPU预处理服务额定应用16个CPU），机器配置的CPU型号是Intel(R) Xeon(R) Gold 5218 CPU@2.30GHz、GPU型号是Tesla T4。从压测后果能够看出：

  1. 服务CPU减少到32核，QPS和GPU利用率（通过nvidia-smi命令获取的GPU-Util指标）晋升超过1倍，GPU利用率晋升至88%；
  2. 前置预处理办法优化后服务QPS晋升超过1倍，略优于减少CPU的办法，但从GPU利用率角度看仍有较大优化空间；
  3. 拆散预处理办法优化后QPS晋升2.7倍，GPU利用率达到98%靠近满载状态。

减少CPU并不能齐全解决服务性能瓶颈问题，尽管GPU利用率达到88%，然而CPU-GPU数据传输工夫占比拟大，QPS晋升无限。前置预处理办法也没有齐全解决预处理性能瓶颈问题，优化并不彻底。相较而言，拆散预处理办法充分发挥了GPU运算性能，在QPS和GPU利用率指标上都获得了更好的优化成果。

3.2 图像“检测+分类”模型服务优化

在一些简单工作场景下（如人脸检测辨认、图像文字辨认等），通常是检测、宰割、分类等多个模型组合实现性能。本节介绍的模型便是由“检测+分类”串接而成，模型构造如下图7所示，次要包含以下几个局部：

  • 预处理：次要包含图像解码、缩放、填充等操作，输入Nx3x512x512图像矩阵，大部分算子运行在CPU设施上。
  • 检测模型：检测网络结构是YOLOv6，算子运行设施为GPU。
  • 检测后处理：应用NMS（非极大值克制）算法去除反复或误检指标框，失去无效检测框，而后裁切指标区域子图并缩放，输入Nx3x224x224图像矩阵，检测后处理大部分算子运行在CPU设施上。
  • 分类模型：分类网络结构是ResNet-50，算子运行设施为GPU。

其中检测和分类两个子模型是独自训练的，推理时合并成单个模型，部署框架采纳TF-Serving，优化工具采纳TF-TRT。

3.2.1 性能瓶颈

模型中预处理和检测后处理大部分是CPU运算，检测和分类模型骨干网络是GPU运算，单次推理过程中须要进行屡次CPU-GPU之间数据交换。同样地，CPU运算速度慢会导致GPU利用率低，推理服务存在性能瓶颈。

理论线上服务压测GPU利用率68%，QPS也存在较大优化空间。服务配置为1GPU+8CPU（机器CPU型号是Intel(R) Xeon(R) Gold 5218 CPU@2.30GHz，GPU型号是Tesla T4）。

3.2.2 优化办法

依然采纳模型拆分的思路，将CPU和GPU运算局部独自部署微服务。如下图8所示，咱们将原始模型拆分为4个局部，预处理和检测后处理部署成CPU微服务（可依据流量大小动静扩容），检测模型和分类模型部署成GPU微服务（同一张GPU卡上）。为了放弃调用形式简略，下层采纳调度服务串接各个微服务，提供对立调用接口，对上游屏蔽调用差别。拆分后的检测模型和分类模型通过TensorRT优化后采纳Triton部署。

3.2.3 优化后果

如下图9所示，除了原始服务和微服务拆分，另外还比照了减少CPU和Triton Ensemble两种形式的性能测试后果。Triton Ensmeble形式将所有子模型（包含预处理和后处理）部署在一个机器上，实现多模型流水线调度。比照能够看出：

  • 原始服务CPU减少到32核，GPU利用率晋升到90%，但QPS晋升只有36%；
  • Triton Ensemble形式与原始TF-Serving服务相比性能差距不大；
  • 模型拆分微服务形式优化后QPS晋升3.6倍，GPU利用率达到100%满载状态。

减少CPU的办法对服务GPU利用率晋升较大、QPS晋升不显著，起因在于CPU预处理和后处理工夫缩短，但CPU-GPU数据传输工夫在整个推理过程中依然占比拟大，GPU运算工夫较少。

将模型拆分应用Triton Ensmeble形式部署实现多模型调度流水线，效率并不比模型拆分前高。因为多模型流水线是在同一台机器上，CPU和GPU相互影响的问题并没有解决，GPU解决效率受CPU制约。模型拆分微服务部署形式在服务层面实现了调用流水线，CPU预处理和后处理微服务能够依据流量动静减少资源，满足GPU模型微服务吞吐需要，实现了GPU/CPU处了解耦，防止了CPU解决成为瓶颈。

总而言之，拆分微服务的形式充分发挥了GPU运算性能，在QPS和GPU利用率指标上都获得了更好的成果。

4. 通用高效的推理服务部署架构

除了上述两个具备代表性的推理服务优化案例，视觉其它很多服务也采纳了这种优化形式。这种优化形式具备一个核心思想：在CPU运算是瓶颈的推理服务中，将模型的CPU和GPU运算局部拆分，独自部署成CPU/GPU微服务。

依据这种思维，咱们提出一种通用高效的推理服务部署架构。如下图10所示，底层应用通用的部署框架（TF-Serving/Triton等），将模型中CPU运算局部如预处理、后处理拆分独自部署成CPU微服务，骨干网络模型部署成GPU服务，下层调度服务串联模型微服务实现整体性能逻辑。

这里须要解释一个重要问题，为什么这种部署架构是高效的？

首先在宏观层面，模型拆分部署成微服务，通过调度服务实现了子模型流水线解决。拆分的子模型CPU微服务能够依据流量和解决能力动静扩容，防止模型预处理或后处理CPU运算能力有余成为性能瓶颈，满足了GPU模型微服务的吞吐需要。

其次在宏观层面，如果模型蕴含多个CPU/GPU运算局部，那么GPU运算之间会存在距离。如下图11所示，单次推理过程中两次GPU运算之间须要期待CPU后处理局部实现，CPU预处理也会影响GPU运算。模型拆分后，预处理和后处理局部独立部署成CPU服务，GPU服务中推理过程仅蕴含两个子模型运算局部，并且子模型间运算互相独立无数据关联，CPU-GPU数据传输局部能够与GPU运算过程并行，实践上GPU能够达到100%运行效率。

另外，在时延方面，拆分微服务的部署形式减少了RPC通信和数据拷贝工夫开销，但从实际来看这部分工夫占比很小，对端到端的提早没有显著影响。例如对于下面3.1节中的分类模型，优化前服务的均匀耗时是42ms，优化后微服务模式（RPC通信协议为Thrift）的服务整体均匀耗时是45ms。对于大部分视觉服务利用场景而言，这种级别的提早减少通常并不敏感。

5. 总结与瞻望

本文以两个典型的视觉推理服务为案例，介绍了针对模型存在性能瓶颈、GPU利用率不高的问题进行的优化实际，优化后服务推理性能晋升3倍左右，GPU利用率靠近100%。依据优化实际，本文提出了一种通用高效的推理服务部署架构，这种架构并不局限于视觉模型服务，其它畛域的GPU服务也可参考利用。

当然，这种优化计划也存在一些有余，比方优化过程中模型如何拆分比拟依赖人工教训或者试验测试，没有实现优化流程的自动化与标准化。后续咱们打算建设模型性能剖析工具，主动诊断模型瓶颈问题，反对主动拆分优化全流程。

6. 作者

| 张旭、赵铮、岸青、林园、志良、楚怡等，来自根底研发平台视觉智能部。
| 晓鹏、駃飞、松山、书豪、王新等，来自根底研发平台数据迷信与平台部。

浏览美团技术团队更多技术文章合集

前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试

| 在公众号菜单栏对话框回复【2022年货】、【2021年货】、【2020年货】、【2019年货】、【2018年货】、【2017年货】等关键词，可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至tech@meituan.com申请受权。