针对上面的两项关键技术，我们还自研了相关框架与工具进行沉淀。包括基于Python的CPU与GPU进程自动隔离的推理服务框架，以及对推理模型进行转TensorRT优化的调试工具。
此外针对不同的推理服务性能瓶颈，我们还梳理了各种实战优化技巧，比如CPU与GPU分离，TensorRT开启半精度优化，同模型混合部署，GPU数据传输与推理并行等。
下面从理论，框架与工具，实战优化技巧三个方面介绍下推理服务性能优化的方法。
2、理论篇
2.1 CUDA架构
CUDA 是 NVIDIA 发明的一种并行计算平台和编程模型。它通过利用图形处理器 (GPU) 的处理能力，可大幅提升计算性能。
CUDA的架构中引入了主机端（host, cpu）和设备（device, gpu）的概念。CUDA的Kernel函数既可以运行在主机端，也可以运行在设备端。同时主机端与设备端之间可以进行数据拷贝。
CUDA Kernel函数：是数据并行处理函数（核函数)，在GPU上执行时，一个Kernel对应一个Grid，基于GPU逻辑架构分发成众多thread去并行执行。
CUDA Stream流：Cuda stream是指一堆异步的cuda操作，他们按照host代码调用的顺序执行在device上。
典型的CUDA代码执行流程：
a.将数据从Host端copy到Device端。
b.在Device上执行kernel。
c.将结果从Device段copy到Host端。
以上流程也是模型在GPU推理的过程。在执行的过程中还需要绑定CUDA Stream，以流的形式执行。
2.2 传统Python推理服务瓶颈
2.2.1 传统Python推理服务架构
由于Python在神经网络训练与推理领域提供了丰富的库支持，加上Python语言自身的便利性，所以推理服务大多用Python实现。CV算法的推理引擎大多采用Python flask框架或Kserve的框架直接实现。这种框架大致调用流程如下：
以上架构是传统推理服务的常用架构。这种架构的优势是代码写起来比较通俗易懂。但是在性能上有很大的弊端，所能承载的QPS比较低。我们用了几个CV模型去压测，极限QPS也一般不会超过4。
2.2.2 瓶颈分析
由于以上架构的CPU逻辑(图片的前处理，后处理)与GPU逻辑(模型推理)在同一个线程内，所以会存在如下性能瓶颈：
- 如果是单线程的模式，CPU逻辑与GPU逻辑相互等待，GPU Kernel函数调度不足，导致GPU使用率不高。无法充分提升QPS。这种情况下只能开启更多进程来提升QPS，但是更多进程会带来更多显存的开销。
- 如果开启多线程模式，经过实测，这种方式也不能带来QPS的提升。主要是因为Python的GIL锁的原因，由于Python GIL锁的存在，Python的多线程实际上是伪的多线程，并不是真正的并发执行，而是多个线程通过争抢GIL锁来执行，这种情况下GPU Kernel launch线程不能得到充分的调度。在Python推理服务中，开启多线程反而会导致GPU Kernel launch线程频繁被CPU的线程打断。由于GPU kernel lanch调度不足，这种方式也无法充分利用GPU使用率。
2.2.3 解决方案
针对以上问题，我们的解决方案是把CPU逻辑与GPU逻辑分离在两个不同的进程中。CPU进程主要负责图片的前处理与后处理，GPU逻辑则主要负责执行cuda kernel 函数，即模型推理。
另外由于我们线上有大量推理服务在运行，所以我们基于Python开发了一个CPU与GPU分离的统一框架。针对原有Flask或Kserve的服务，稍作修改即可使用我们的服务。具体请参考下面的CPU与GPU分离的统一推理框架相关介绍。
针对线上的某个推理服务，使用我们的框架进行了CPU与GPU进程分离，压测得出的数据如下，可见QPS大约提升了7倍左右。
推理服务框架类型 | QPS | 耗时 | GPU使用率 |
传统推理服务(多线程) | 4.5 | 1.05s | 2% |
自研框架(6CPU进程+1GPU进程) | 27.43 | 437ms | 12% |
2.3 TensorRT模型加速原理
TensorRT是由英伟达公司推出的一款用于高性能深度学习模型推理的软件开发工具包，可以把经过优化后的深度学习模型构建成推理引擎部署在实际的生产环境中。TensorRT提供基于硬件级别的推理引擎性能优化。
下图为业界最常用的TensorRT优化流程，也是当前模型优化的最佳实践，即pytorch或tensorflow等模型转成onnx格式，然后onnx格式转成TensorRT进行优化。
其中TensorRT所做的工作主要在两个时期，一个是网络构建期，另外一个是模型运行期。
a.网络构建期
i.模型解析与建立，加载onnx网络模型。
ii.计算图优化，包括横向算子融合，或纵向算子融合等。
iii.节点消除，去除无用的节点。
iv.多精度支持，支持FP32/FP16/int8等精度。
v.基于特定硬件的相关优化。
b.模型运行期
i.序列化，加载RensorRT模型文件。
提供运行时的环境，包括对象生命周期管理，内存显存管理等。
以下是我们基于 VisualTransformer模型进行的TensorRT优化前后的性能评测报告：
类别 | Pytorch | Onnx | TensorRT-fp32 | TensorRT-fp16 |
平均耗时 | 20ms | 15ms | 7ms | 3.5ms |
精度变化 | 精度不变 | 精度不变 | 精度不变 | 精度稍有损失，误差均值与方差在0.003内 |
3、框架与工具篇
这一篇章，主要介绍我们自己推出的框架与工具。其中框架为CPU与GPU分离的Python统一推理框架，工具则为Onnx转TensorRT的半自动化调试工具。相关框架与工具我们在线上大量推理服务推进使用中。
其中CPU与GPU分离的Python统一推理框架解决了普通Python推理服务无法自动隔离CPU与GPU的问题，用户只需要继承并实现框架提供的前处理，推理，后处理相关接口，底层逻辑即可自动把CPU与GPU进行进程级别隔离。
其中TensorRT半自动化调试工具，主要定位并解决模型转TensorRT的过程中遇到的各种精度丢失问题。底层基于TensorRT的相关接口与工具进行封装开发。简化TensorRT的优化参数。
3.1 CPU与GPU分离的统一推理框架
新架构设计方案如下：
方案设计的思路是GPU逻辑与CPU逻辑分离到两个进程，其中CPU进程主要负责CPU相关的业务逻辑，GPU进程主负责GPU相关推理逻辑。同时拉起一个Proxy进程做路由转发。
（1）Proxy进程
Proxy进程是系统门面，对外提供调用接口，主要负责路由分发与健康检查。当Proxy进程收到请求后，会轮询调用CPU进程，分发请求给CPU进程。
（2）CPU进程
CPU进程主要负责推理服务中的CPU相关逻辑，包括前处理与后处理。前处理一般为图片解码，图片转换。后处理一般为推理结果判定等逻辑。
CPU进程在前处理结束后，会调用GPU进程进行推理，然后继续进行后处理相关逻辑。CPU进程与GPU进程通过共享内存或网络进行通信。共享内存可以减少图片的网络传输。
（3）GPU进程
GPU进程主要负责运行GPU推理相关的逻辑，它启动的时候会加载很多模型到显存，然后收到CPU进程的推理请求后，直接触发kernel lanuch调用模型进行推理。
该方案对算法同学提供了一个Model类接口，算法同学不需要关心后面的调用逻辑，只需要填充其中的前处理，后处理的业务逻辑，既可快速上线模型服务，自动拉起这些进程。
该方案把CPU逻辑(图片解码，图片后处理等)与GPU逻辑(模型推理)分离到两个不同的进程中。可以解决Python GIL锁带来的GPU Kernel launch调度问题。
3.2 TensorRT调试工具
TensorRT虽然不是完全开源的，但是官方给出了一些接口与工具，基于这些接口与工具我们可以对模型优化流程进行分析与干预。基于TensorRT官方提供的接口与工具，我们自己研发了一套工具。用户可以使用我们的工具把模型转成TensorRT格式，如果在模型转换的过程中出现精度丢失等问题，也可以使用该工具进行问题定位与解决。
自研工具主要在两个阶段为用户提供帮助，一个阶段是问题定位，另一个阶段是模型转换。具体描述如下：
3.2.1 问题定位
问题定位阶段主要是为了解决模型转TensorRT开启FP16模式时出现的精度丢失问题。一般分类模型，对精度的要求不是极致的情况下，尽量开启FP16，FP16模式下，NVIDIA对于FP16有专门的Tensor Cores可以进行矩阵运算，相比FP32来说吞吐量提升一倍以上。
比如在转TensorRT时，开启FP16出现了精度丢失问题，自研工具在问题定位阶段的大致工作流程如下：
主要工作流程为：
（1）设定模型转换精度要求后，标记所有算子为输出，然后对比所有算子的输出精度。
（2）找到最早的不符合精度要求的算子，对该算子进行如下几种方式干预。
- 标记该算子为FP32。
- 标记其父类算子为FP32。
- 更改该算子的优化策略(具体参考TensorRT的tactic)
循环通过以上两个步骤，最终找到符合目标精度要求的模型参数。这些参数比如，需要额外开启FP32的那些算子等。然后相关参数会输出到配置文件中，如下：
配置项 | 解释 |
FP32_LAYERS_FOR_FP16 | 开启FP16模式下，哪些算子需要额外开启FP32。 |
TRT_EXCLUDE_TACTIC | TensorRT算子需要忽略的tactic策略。(tactic可参考TensorRT相关资料) |
atol | 相对误差 |
rtol | 绝对误差 |
check-error-stat | 误差的计算方法包括：mean, median, max |
3.2.2 模型转换
模型转换阶段则直接使用上面问题定位阶段得到的参数，调用TensorRT相关接口与工具进行转换。
此外，我们在模型转换阶段，针对TensorRT原有参数与API过于复杂的问题也做了一些封装，提供了更为简洁的接口，比如工具可以自动解析ONNX，判断模型的输入与输出shape，不需要用户再提供相关shape信息了。
4、优化技巧实战篇
在实际应用中，我们期望用户能够对一个推理模型开启CPU与GPU分离的同时，也开启TensorRT优化。这样往往可以得到QPS两次优化的叠加效果。比如我们针对线下某个分类模型进行优化，使用的是CPU与GPU分离，TensorRT优化，并开启FP16半精度，最终得到了10倍的QPS提升。
以下是我们在模型优化过程中的一些实战技巧，梳理一下，分享给大家。
（1）分类模型，CPU与GPU分离，TensorRT优化，并开启FP16，得到10倍QPS提升
某个线上基于Resnet的分类模型，对精度损失可以接受误差在0.001(误差定义：median,atol,rtol)范围内。因此我们对该推理服务进行了三项性能优化：
a.使用我们提供的GPU与CPU分离的统一框架进行改造。
b.对模型转ONNX后，转TensorRT。
c.开启FP16模式，并使用自研工具定位到中间出现精度损失的算子，把这些算子标记为FP32.
经过以上优化，最终得到了10倍QPS的提升(与原来Pytorch直接推理比较)，成本上得到比较大的缩减。
（2）检测模型，CPU与GPU分离，TensorRT模型优化，QPS提升4-5倍左右。
某个线上基于Yolo的检查模型，由于对精度要求比较高，所以没有办法开启FP16，我们直接在FP32的模式下进行了TensorRT优化，并使用统一框架进行GPU与CPU分离，最终得到QPS 4-5倍的提升。
（3）同模型重复部署，充分利用GPU算力资源
在实际的场景中，往往GPU的算力是充足的，而GPU显存是不够的。经过TensorRT优化后，模型运行时需要的显存大小一般会降低到原来的1/3到1/2。
为了充分利用GPU算力，框架进一步优化，支持可以把GPU进程在一个容器内复制多份，这种架构即保证了CPU可以提供充足的请求给GPU，也保证了GPU算力充分利用。优化后的架构如下图：
比如线上某个模型，经过TensorRT优化后，显存由原来的2.4G降低到只需要1.2G。为此我们申请了5G显存，配置GPU进程为复制4份，共需要4.8G显存。这样存充分利用5G显存，达到原来一个模型的4倍的算力，充分利用GPU的算力资源。
5、总结
采用以上两个推理模型的加速技巧，即CPU与GPU进程隔离，TensorRT模型加速。我们对线上的大量的GPU推理服务进行了优化，也节省了比较多的GPU服务器成本。
其中CPU与GPU进程隔离主要是针对Python推理服务的优化，因为在C++的推理服务中，不存在Python GIL锁，也就不存在Python Kernel launch线程的调度问题。目前业界开源的Python推理服务框架中，还没有提供类似的优化功能，所以我们后续有考虑把Python统一推理服务框架进行开源，希望能为社区做一点贡献。
此外TensorRT的模型优化，我们参考了大量NIVIDIA的官网文档，在上层做了封装，后续会进一步深入研究。
