VCAP如何利用GPU优化端侧推理

原创 vivo AI Lab vivo人工智能技术

JEEK

容易脸红的编程大神

深度学习端侧推理在这两年是一个比较引人注目的话题，如何利用终端有限的资源实现高性能推断成为主流研究方向。由于行业内仍有大量模型以浮点方式部署，再加上卷积神经网络的大规模流行，因此如何发挥GPU的并行加速能力显得至关重要。

本文主要介绍vivo自研计算加速平台VCAP中采用的一些GPU加速思想。

1 为何能用GPU加速

大部分深度学习的算子适用于GPU的SIMT(Single Instruction Multiple Thread)体系结构(即多个线程执行相同指令)。例如Convolution，Batchnorm，ReLU等算子，都是简单且大量的重复性计算，因此很适合发挥出GPU并行计算的优势。

2 API选择

众所周知，在GPU上可以采用许多图形API进行开发，例如OpenCL、OpenGLES、Vulkan等等，那么如何进行选择，选择的依据又是什么呢？这里就要提到一个比较重要的概念——平台厂商对于各API的优化力度。例如在高通的Adreno系列GPU上，我们就采用OpenCL进行开发，因为高通对OpenCL实现了许多扩展，并且Adreno的硬件针对OpenCL有专属的优化，例如对Image对象的读取就有L1Cache进行加速(如下图所示)，因此将Weights和Feature Map保存在Image对象上能显著提升性能。所以在Adreno上适合采用OpenCL进行开发。而在其他GPU上情况就有所不同，例如在Mali上，Image对象的读写性能甚至比普通的Buffer读写还要慢很多。因此在开发前要调研平台厂商对各API的支持情况再做选择。

图片来自 Qualcomm® Snapdragon™ Mobile Platform OpenCL General Programming and Optimization

3 优化方法

初始化优化——单次数据拷贝

初始化耗时对于某些应用场景来说至关重要，例如相机场景识别，该功能在打开相机后会自动启动，将识别结果显示在预览界面，若初始化过慢则会导致用户在打开相机后许久才收到识别结果反馈，这会带来相当糟糕的体验。因此VCAP通过优化GPU内存拷贝时间，显著地降低了初始化耗时。

以MobilenetV1为例，该模型有将近60个网络层，其中的Convolution、Batchnorm层都带有Weights数据，若逐层拷贝到GPU上则会严重影响初始化性能。因为GPU和CPU之间的数据拷贝代价相当之高，即使几个字节的拷贝，耗时也是毫秒级。因此，在解析模型时，VCAP会在CPU端申请一块地址连续的大内存来存放所有网络层的Weights，然后将其整块的拷贝到GPU上，由此带来的初始化性能提升相当显著，我们测试了逐层拷贝(优化前)和单次拷贝(优化后)两种方式的初始化时间，如下图所示。

内存优化——内存复用、低精度计算

低精度计算

VCAP采用了低精度计算，将所有的Weights和Feature Map采用16bit浮点来保存，对比32bit浮点，内存占用减小了一倍，并且能节省带宽。另外，我们对16bit和32bit的精度进行了测试，结果证明16bit浮点几乎没有带来精度损失。

内存复用

VCAP还采用内存复用技术来进一步减少Feature Map内存，为何要引入这个概念？我们对模型进行了分析，发现大部分模型存在着大量相同尺寸的Feature Map，若对这些Feature Map单独申请内存，则会产生浪费。因此我们设计了一个内存分配器来统一管理所有Feature Map的内存分配，内存分配器在分配内存时会顺便给该内存标上引用计数，该内存每使用一次，引用计数就会减1，当引用计数为0时，该内存就可以被内存分配器回收，并分配给其他相同尺寸的Feature Map。VCAP运用该技术将MobilenetV1的内存占用减少了40%左右。

其实经过仔细推敲就会发现，相同尺寸的内存复用并不是最佳的策略，其实完全可以将大尺寸的内存复用给小尺寸的Feature Map(但是复用内存的长宽需均大于Feature Map，因为Image(2D)对象是严格的二维寻址)，这样内存的复用率会进一步上升，看起来是十分美好的事，但需要注意一个细节：在内存复用时需要同时记录Feature Map真实尺寸和分配内存的实际尺寸，在做异构调度时(例如将GPU运算结果拷贝到CPU上继续运算)，需要额外检查这两个尺寸是否一致，然后按照Feature Map的真实尺寸将Image对象数据写入Buffer，最后再拷贝回CPU，否则拷贝结果就有可能出错。如下图所示，在将Image对象的数据写入Buffer时，若没有经过尺寸检查，错误的将8x8的Image全部写入Buffer，那么最后拷贝得到的16个数据就会对应8x8内存块的前两行，这就会导致CPU端的数据出错，从而导致连锁反应，最终输出错误的计算结果。规避这个问题的方法也很简单，只需要在将Image数据写入Buffer时，只写入4x4的部分即可，VCAP将在后续版本引入这个策略，进一步降低内存占用。

推断速度优化——内存布局、算子融合

内存布局

持续关注端侧推理的同学可能知道，NC/4HW4内存布局已经成为了“香饽饽”，所谓的NC/4HW4就是将数据以4个通道对齐的方式重新排列。为什么这种布局如此受推崇呢？了解图形编程的同学应该清楚，GPU能一次读取4个float数据，并且使用一条指令就能完成float4矢量的运算，因此该内存布局天生就适合GPU并行计算。

以Convolution为例，将输入数据转换为NC/4HW4布局后，每次运算时都会读取4通道的输入数据和4通道的Weights数据，这样经过一次运算就能直接得到4通道的输出结果。另外需要注意的是，若遇到通道不是4的整数
倍的情况，只需要将数据补0对齐到4通道即可。

那是不是NC/4HW4布局就完美无缺了呢？当然不是，对某些算子而言，该布局反而增大了算子编写难度。例如进行concat运算时，若恰好需要将两块Feature Map的通道进行拼接，而Feature Map的通道恰好不是4的倍数，那在计算时就需要对读取出来的float4矢量进行检查，再进行拼接。因此NC/4HW4布局下的concat算子实现存在着许多的分支。

算子融合

算子的融合主要包括两部分，对于原始算子进行融合以及在端侧推理过程中对算子进行进一步的融合。

目前TensorFlow作为主流训练框架，有灵活性高，扩展性强等优点，但同时也带来一个问题，那就是过细的算子粒度严重限制了终端推断的性能。以谷歌官方开源的MobileNetSSD模型为例，其NMS（non maximum suppression）运算的实现包含了652个节点，若每个节点逐个运算则会发生数百次内存读写，这显然是不划算的，因此VCAP将这652个节点转换为融合为一个NMS层，
这样只需几次读写即可完成计算。

在推断过程中，一些特定的算子可以再度进行融合，进一步的减少内存读写次数，最经典的就是Convolution+Batchnorm+ReLU组合，将这三个算子融合可以避免在Batchnorm层和ReLU层再进行内存的读取。

4 总结

本文从初始化、内存布局、算子融合等方面介绍了在GPU上实现端侧推理加速的一些思想，其实部分原理也可以用于CPU上。目前VCAP仍在持续的开发迭代，后续会支持Vulkan运行时，进一步提升MTK和Exynos平台的推断性能。最后附上VCAP目前的GPU性能数据。

回顾上篇：

Kube-batch在AI计算平台的应用

继续滑动看下一个