关于美团:美团视觉GPU推理服务部署架构优化实践

面对在线推理服务应用的 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 为例，网络的输出是图像浮点类型矩阵，尺寸大小固定为 224×224。因而二进制编码图片在送入网络前，须要做解码、缩放、裁切等预处理操作。

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 申请受权。