基于征程5芯片的Transformer量化部署实践与经验

3月28日，智东西公开课组织的「自动驾驶新青年讲座」第16讲顺利完结。在这一讲中，地平线工具链核心开发者杨志刚以《基于征程5芯片的Transformer量化部署实践与经验》为主题进行了直播讲解。

杨志刚首先介绍了Transformer发展趋势及在嵌入式智能芯片上部署的问题，之后重点讲解了以征程5为例的嵌入式智能芯片的算法开发流程，并对以SwinT为例的量化精度提升和部署性能优化做了详细解读，最后分析了如何在征程5上既快又好地部署Transformer模型。

本次讲座分为主讲和Q&A两个环节，以下则是主讲回顾：

大家好，我叫杨志刚，在地平线主要负责天工开物工具链的开发，比如征程2、征程3、征程5上的系列量化工具和算法工具的一些开发和验证工作。因此和我们公司内部的算法团队、编译器团队都有比较深入的接触。

今天我分享的主题是《基于征程5芯片的Transformer量化部署实践与经验》，然后也会从量化和部署两个方面分析如何让Swin-Transformer在征程5上跑得既快又好。

以下是本次讲座的主要内容，大概分为4个部分：

1、Transformer发展趋势及在嵌入式智能芯片上部署的问题

2、以征程5为例的嵌入式智能芯片的算法开发流程

3、以SwinT为例的量化精度提升和部署性能优化

4、如何在征程5上既快又好地部署Transformer模型

01

Transformer发展趋势

及在嵌入式智能芯片上部署的问题

第一部分是Transformer的发展趋势以及它在嵌入式智能芯片上的部署问题。最近，我估计大家都对Transformer势不可挡的趋势有所了解，它确实已经在NLP领域甚至在图像领域都起到了不可替代的作用。比如从2017年Transformer被提出来以后，因为它超强的序列建模和全局建模的能力，所以Transformer模型结构其实已经在整个智能模型结构里有着越来越重要的地位。

一方面，它引领了一个大模型的潮流（当然这个潮流主要是指NLP领域），比如最近比较火的BERT、GPT等这样以Transformer为基础的模型其实在NLP领域已经起到了一些根本性的变革，还有像GPT这种模型的参数量从亿级别到千亿级别，我们能看到 Transformer的容量还有模型发展的趋势都朝着越来越大的方向发展。当然越来越大的前提是我们可以通过更大的模型去获取更高的精度，所以这个量级基本上已经从亿级别到了千亿级别、万亿级别。

另外一方面，Transformer不仅在NLP领域引领了大模型的潮流，而且在图像领域也有着越来越重要的地位。我这里截的图（如图一所示）主要是它在Backbone也就是分类ImageNet上面的一个趋势图，可以看到随着它的计算量、参数量越来越大，它的正确率也会越来越高。

事实上它在常见的基础任务中（比如说常见的检测、分割、跟踪等这样的任务)制作刷榜的时候，可以看到前几名里基本上已经遍地都是Transformer的影子了。所以比如常见的以Swin-Transformer为例的encoder，以DETR为例的decoder，还有时序、BEV等这种用Transformer做特征融合的，不管在图像领域的哪一个阶段，我们都可以把Transformer的特性和CNN结合，甚至替代CNN的模型结构。无论是替代CNN还是和CNN结合，这两个发展方向都已经成为视觉领域的常用做法，所以整体上来说Transformer在现在的图像领域里已经是无法绕开的模型结构了。

其实我在标题里面新加了一句话“通向通用人工智能的一扇门”，当然这个话我不敢说，我也是在一些别的信息上看到的。现在基本上认为，在我们做特征提取的阶段中，Transformer是通用人工智能的一种组件，所以也被称为一扇门，不过这个不是我们今天要分享的重点。

Transformer确实在模型结构上起着越来越重要的作用，但是另一方面，它在嵌入式端部署的问题也会受到越来越多的重视。具体来说，Transformer越来越大和嵌入式智能芯片部署这两个方向的出发点是有区别的，比如说Transformer模型在发展上是越做越大、越做越宽，但是嵌入式智能芯片因为受到成本、功耗等方面的限制，导致它在算力、带宽等很多功能方面受限，这就导致当前的嵌入式智能芯片不管是部署稍微大一点的还是小一点的Transformer模型，都会有一些吃力。

这里我讲三个主要的例子。第一个因为嵌入式智能芯片受到成本和功耗的限制，所以它的算力、带宽、内存等方面都会受到一定的限制，这就直接导致像Transformer这样的大模型的部署会受到限制。因为如果用一个大模型去部署一个小算力的平台，就算不是Transformer哪怕只是普通的CNN，性能显而易见的可能会极差，更何况是Transformer这样的大模型在小算力平台上的部署很明显会有一些缺陷。

第二个特征是目前市面上比较流行的嵌入式智能芯片通常都会以低精度的方式来处理部署的模型。当然低精度之外也会少量的去支持一定精度的浮点，这个原因和算力、带宽受限是一样的，主要还是从成本、功耗等这方面的情况考虑的，所以这就直接导致了如果想要在嵌入式智能芯片上部署的话，那么这个模型可能要经过一些量化，但同时量化不能有一定的精度损失。否则如果精度损失比较大的话，这个部署就是没有意义的。

第三点是芯片的发展其实是滞后于算法的。关于这一点，在我们公司罗老师之前的分享当中（地平线罗恒博士：如何打造一颗好的自动驾驶AI芯片）有比较详细的描述，大家如果有兴趣可以去看一下。简单来说，就是芯片从设计到正式量产需要经过一个漫长的过程，这个过程可能是2-4年。因此现在市面上流行的嵌入式智能芯片基本上是源自于1-2年甚至更长时间之前的设计，而那时候设计的嵌入式智能芯片很大概率没有考虑Transformer的情况，因为那时候可能大部分市面上流行的还是以CNN为主的模型，所以这样就会造成现在大部分嵌入式智能芯片对CNN的部署非常友好，但是对Transformer的部署存在一定的gap。今天我们就要讨论这个gap到底来自哪里。

下面我们详细拆解一下刚刚讲到的问题：Transformer部署过程中会遇到哪些问题？

第一个是量化问题，其实Transformer的量化问题现在我们能在很多社区的论文或者一些博客当中看到。首先，它为什么要经过量化？我刚刚简单讲了一下，它是从成本、功耗等方面考虑的。如果用int8或者低比特的量化部署，它的好处是显而易见的，比如可以降低功耗、提高计算速度、减少内存和存储的占用。这里有个数据对比，Transformer部署的时候其实会有一些常见的问题，如果熟悉量化训练的同学应该比较清楚，Transformer模型当中有大量的非线性函数，比如说像GeLU、LayerNorm这样的东西。所以它激活值的输出和高斯分布会有比较大的差异，这就直接导致了很大一部分之前在CNN中最常用的对称量化的方法，可能会出现很明显的精度问题。

如果要解决Transformer的量化精度问题，社区有很多常见的经验。我这里举两个例子，比如用非对称量化等方法去处理分布不均衡或高斯分布差异较大的情况，还有一些情况可能会直接在硬件上使用浮点的SoftMax或LayerNorm，这种情况肯定是可以解决量化问题的，但实际上我们需要和硬件结合，而硬件上到底能不能支持浮点或者能不能支持非对称性量化是我们需要考虑的另一个问题。我们今天要讲的征程5的平台，它就是一个纯int8的嵌入式智能平台，如果要在一个纯int8的嵌入式智能平台上去部署一个浮点的SoftMax或者LayerNorm显然是不合理的。甚至有一些情况就算它是纯int8的，可能也不支持非对称量化，所以我们如果要解决Transformer量化不友好的问题，还需要结合硬件的特点来考虑。

Transformer模型部署的第二个问题是Transformer对算力的要求比较高。开始也讲到，Transformer是近年来最受关注的神经网络模型，而Transformer在机器视觉领域最重要也是最彻底的应用就是Swin Transformer，这个工作也得到了机器视觉领域最高的奖项，马尔奖。这里我们以Swin-Transformer为例。我们考虑Swin-Transformer这个最小的模型，它的计算量大概是4.5G左右。

说4.5G可能很多人没有直观概念，我做了两个简单的对比，这就约等于我们常用模型里的EffcientNetB4和ResNet50。说到ResNet50，很多人就有概念了，如果我们用ResNet50的水平去做部署的话，其实市面上很多算力稍微低一点的嵌入式智能芯片部署就会有点吃力了。如果有人知道地平线的历史，比如地平线的上一代芯片跑ResNet50是可以跑的，但它的效率不是很高，而且这还是CNN的部署效率，如果在Transformer上效率会进一步降低。这样考虑的话，整个SwinT部署的前提条件就是芯片的算力达到一定的要求。

除了刚才提到的SwinT的基础还有量化问题之外，还有一个比较重要的问题就是我们一直在讲的Transformer和CNN模型到底有哪些区别？为什么说我的芯片可以部署ResNet50，但是没法部署Transformer呢？其实这就是CNN模型和Transformer模型之间一个比较重要的区别。如果我们比较熟悉CNN模型，就会知道CNN基本上从头到尾只有一个卷积，或者有少量的非卷积算子，如RoiAlign。所以整个CNN模型实际上是以卷积和矩阵乘为主的。换句话说，这类算子的特征是以计算密集型算子为主。我们早期的智能芯片为什么并发能力强，因为智能芯片设计之初就是以这样的CNN模型为出发点的，它的重点是利用并发去解决计算密集型的问题。

但在Transformer里情况是不一样的，Transformer里除了我们刚刚说到的卷积和矩阵乘以外，还有大量像Elementwise、Reduce这样的访存密集型算子。访存密集型算子和计算密集型会有明显的区别，会要求我的访存带宽或者访存本身的存储容量比较高，同时不规则的数据搬运比较多，不像CNN中，一个4d-tensor可以从头到尾，而且我的4d-tensor的规则可能非常明显：W/H维度做下载样，C维度做特征变长，这种4d-tensor的特征对整个嵌入式智能平台是非常友好的。

但Transformer中不规则的数据搬运会明显多很多，比如像Swin-Transformer，我们做window partition和window reverse时会有很多Reshape和Transpose的操作，这种操作带来的问题是效率会进一步降低。事实上这个问题是整个Transformer或者说整个芯片行业都会遇到的一个问题，不仅是嵌入式智能芯片会有这样的问题，训练芯片也会有类似的问题。

我记得早几年前英伟达在测试上做过一个OPS的简单统计，这个细节就不说了，大体上的结论是纯粹计算型的算子，比如卷积和矩阵乘这样的算子在计算量上占比大概99.8%，但实际上它在英伟达芯片（就训练芯片上而言）的执行时间只有60%。换句话说，训练芯片本身有大量的占比很低的非计算型算子，但这些算子却花费了40%的时间。这个问题在Transformer部署嵌入式智能芯片时，会被很大程度的放大。常见的嵌入式智能芯片可能会有大量的时间浪费在访存算子和不规则数据搬运上面。

总结一下第一部分，就是嵌入式智能芯片由于受到成本、功耗等方面的限制，设计思路和实际上需要部署的Transformer模型之间有较大的区别。

02

以征程5为例的

嵌入式智能芯片的算法开发流程

第二部分重点讲一下嵌入式智能芯片的开发流程，这里虽然是以征程5为例，但实际上我们通过目前的调研或者就目前大部分嵌入式智能芯片总体上看，开发流程基本上是一致的，所以换句话说，大家要解决的问题基本上类似。

首先简单讲一下征程5的基本情况，这在之前的系列课里有比较充分的描述，是讲征程5是怎么设计出来的，然后针对智驾平台有怎样的创新或者怎样的用处，我就不多讲了，这里我主要讲这几个基本情况是如何符合Transformer部署的前提条件的。然后这个也和我们刚才说的常见的嵌入式智能芯片部署的缺陷对应上。

第一点是大算力计算平台，首先我们得有一个大算力计算平台作为前提，才有可能去部署Transformer系列模型。如果是小算力的话，刚刚也讲了，比如上一代征程3想部署Transformer可能就比较困难。

第二个重点是丰富的算子支持。我们在刚才Transformer的结构图中也能看到这点为什么比较重要，CNN模型的主体是以卷积为主，配合少量其他算子，如RoiAlign等。但Transformer中其实有很多很杂的算子，比如说像LayerNorm、SoftMax，还有Reshape、Transpose等，所以说智能芯片部署Swin-Transformer或者其他Transformer的前提条件除了大算力之外，还需要非常丰富的算子知识。

另外是最强的计算性能，我觉得在我们Transformer的部署中其实没有太多的参考价值，因为它是以CNN为基础的模型进行统计的，也就是以计算密集型的模型统计的，但Transformer的能力跟这个还是有比较明显的差距。

最后一点是超低功耗，这点也需要多讲，因为它本身也是征程5的亮点之一。地平线的征程5和天工开物工具链，其实已经积累了一套比较完善的软件工具，这套软件工具从用户训练的浮点模型开始，然后做量化、训练、编译、部署、优化等，最终部署到嵌入式端。以量化为例，基本上整个芯片工具链会提供PTQ的后量化和QAT的量化训练这两种量化方式。在优化编译阶段，可以提供Checker、Calibrator和分析、仿真等工具，最终可以保证用户的模型经过量化、优化后，能部署到嵌入式端。这里需要说一下早期的天工开物整个工具链的积累其实是基于CNN模型的，后面我也会讲为什么基于CNN模型积累下的整个芯片工具链在处理Transformer模型时，不管是量化还是优化部署方面都有一定缺陷。

下面是如何利用整个天工开物工具链帮助用户把浮点模型快速部署到嵌入式芯片上。这就是我一开始讲的，各家的芯片工具链、各家的嵌入式智能芯片的部署流程已经趋于相同了，整体上都是从算法迁移代价足够小的角度考虑，所以基本上已经是一个标准流程了。然后我们来看一下这个流程，从浮点训练开始，经过PTQ后量化的校准，如果后量化的精度满足要求我们就可以直接编译优化、最终部署；如果不满足要求可以反过来去做量化感知训练，量化感知训练的目的是使精度达到要求，并最终去做模型定义。那么如果我们要处理这种Transformer部署优化的流程，要处理的两个重点就是量化调优和编译优化，主要是利用量化公式去提升量化精度。第二个是在编译过程中，用手动或自动的方式去获取更好的部署性能。

天工开物工具链首次把Swin-Transformer部署在征程5上，其实没有遇到太多困难，当然这个前提我刚刚已经讲了，首先它有大算力，然后丰富的算子知识，这两点我们在征程5上的部署过程比较简单。这里简单讲一下支持哪些算子，其实了解Swin-Transformer的人应该都了解，比如说有Reshape、roll、LayerNorm、matmul等。这里为什么需要算子完全支持？我们一开始做这个事情的时候发现 ONNX opset上面没有完全支持roll，所以当时测Swin-Transformer在其他品牌上的结果时，还需要单独处理roll的情况。最近，我们发现opset上已经支持roll了，但另一个方面说明一些嵌入式智能芯片的平台不管是由于使用的工具还是最后部署的芯片的限制，想做到算子完全支持有一定的门槛。

【本文来自易车号作者车东西，版权归作者所有,任何形式转载请联系作者。内容仅代表作者观点，与易车无关】