1 大背景
随著CV演算法在销售业务情景中采用愈来愈多，给他们增添了捷伊考验，需要提高Python方法论推理服务项目的操控性以提高效率自然环境生产成本。有鉴于此他们深入细致去研究Python GPU方法论推理服务项目的工作基本原理，方法论推理数学模型强化的方式。最后透过三项关键性的控制技术: 1.Python的GPU与CPU民主化分立，2.采用TensorRT对数学模型展开快速，使圣戈当斯区绝大部分数学模型服务项目QPS提高5-10倍以内，大批节省了圣戈当斯区GPU方法论推理服务项目的生产成本。
特别针对下面的三项关键性控制技术，他们还暗鞘了有关架构与辅助工具展开结晶。包括如前所述Python的CPU与GPU民主化手动隔绝的方法论推理服务项目架构，以及对方法论推理数学模型展开转TensorRT强化的增容辅助工具。
除此之外特别针对不同的方法论推理服务项目操控性困局，他们还剖析了各种两栖作战强化基本功，比如说CPU与GPU分立，TensorRT迈入半精确度强化，同数学模型混和布署，GPU传输与方法论推理博戈达等。
下面从方式论，架构与辅助工具，两栖作战强化基本功四个方面如是说下方法论推理服务项目操控性强化的方法。
2 方式论篇
2.1 CUDA构架
CUDA 是 NVIDIA 发明者的一种虚拟化网络平台和程式设计数学模型。它透过借助绘图CPU (GPU) 的处置潜能，可急剧提高排序操控性。
CUDA的构架中导入了PS3端（host, cpu）和电子设备（device, gpu）的基本概念。CUDA的Kernel表达式既能运转在PS3端，也能运转在电子设备端。同时PS3端与电子设备端之间能展开统计数据复本。
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倍以内。
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数学模型文件。
ii.提供运转时的自然环境，包括对象生命周期管理，内存显存管理等。
以下是他们如前所述 VisualTransformer数学模型展开的TensorRT强化前后的操控性评测报告：
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的那些算子等。然后有关参数会输出到配置文件中，如下：
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的官网文档，在上层做了封装，后续会进一步深入细致研究。
