概要

该文档主要介绍了地平线模型转换工具链中算子量化的内在逻辑，便于用户理解一些特殊场景的量化处理。

背景与问题

在用户使用地平线模型转换工具链时，偶尔会遇到如下问题：

模型成功转换成bin后，发现仍然有个别op运行在CPU上，但回头仔细对照地平线算子约束列表，明明该op是符合算子约束的，也就是理论上该算子应该成功运行在BPU上。为什么仍然是CPU计算呢？

此问题对较多用户都造成了一定的困扰，该文章即用来介绍模型转换工具链中内部的量化原理与背后的逻辑，并介绍几种解决解决方法。

一个op什么时候会运行在BPU上

对于模型转换工具链来说，一个op是否量化并运行在BPU上，取决于以下两点：

1. 该op是否符合BPU支持规格；

2. 该op在上下文能否找到合理的量化阈值；

op量化逻辑分类

主动量化类算子

量化逻辑特点

主动量化类算子指的是能量化尽可能量化的算子，此类算子有以下特点：

1. 往往算子本身是计算密集性算子，或者是BPU擅长的计算类型算子。

2. 研发通过大量实验，验证了该类型算子在大多数场景下量化的精度风险很小。

典型代表

• 计算密集型算子：conv/matmul/gemm/convtranspose等。

• 激活和数学类算子：mish/hardswish/sin/cos等。

• elementwise算子：mul/add等。

• 其它：argmax/reduce算子等

对于主动量化类算子，转换工具链会通过调整阈值校准位置等方法，尽可能的保证校准统计的阈值可以满足该算子的量化逻辑要求，进而保证其“尽可能的被量化并且运行在BPU上”。

被动量化类算子

被动量化类算子指的是该算子只有在其上下文的其它算子也比较“适合被量化在BPU”的情况下才会被动“跟随”量化的算子。更加简单但不严谨的说，就是当该算子前后都是主动量化算子的时候，该算子才会被动的也跟着量化。

量化逻辑特点

设计被动量化逻辑的主要原因是此类算子运行在BPU上精度和性能两个角度的考虑：

• 性能角度：

  1. 非计算密集型算子，相对而言，BPU没有那么“擅长”该类计算。

  2. 该算子所处的子结构整体不被BPU支持，避免出现单独量化该算子在BPU上运行了但整体运行效率却更低（引入了浮点quantize/dequantize的计算）。

• 精度角度：

  1. 相对而言，该类算子存在一定的量化精度风险。

  2. 由于BPU的特性，该类算子作为BPU最后输出节点时，为保证更高的精度该算子被放置在CPU上浮点计算（进而确保BPU的输出为定点32bit的高精度输出）。

典型代表

• 数据搬运和数据操作类算子：concat/slice/SpaceToDepth/gather/reshape/transpose等

• Pooling类算子：averagepool/maxpool/globalaveragepool/globalmaxpool

• resize算子：resize

由于被动量化逻辑不是很好理解，让我们举个栗子：

手动量化类算子

如何配置被动量化节点运行在BPU上？

模型转换工具链如此设计量化逻辑的背后原因是各种场景的最大公约数+精度与性能的平衡。但针对某个具体用户的具体场景，用户有更好的平衡精度和性能的考虑，为此，工具链提供几种方法进修改量化阈值逻辑，进而可以将默认运行在CPU上的被动量化or手动量化算子配置在BPU上运行。

• runonbpu功能：部分被动量化算子和手动量化算子，在转换后发现该算子运行在了CPU上并且该算子符合BPU算子约束时，可以通过声明runonbpu的方法将该算子配置在BPU上运行（被动量化算子只有部分支持runonbpu功能，后续工具链版本会逐步支持）。
• 插入unitconv算子：在原始训练框架构建并导出模型时，在被动量化算子前面/后面插入一个unitconv算子。因为conv算子是典型的主动量化算子并且不改变输入输出（不需要重新训练），在被动量化算子的前面or后面插入unitconv算子，可以保证该被动量化算子所在的前后上下文都有主动量化的conv算子，进而该被动量化算子会被动的跟随被量化（详细例子可以参考上文的conv+concat结构）。
  对unitconv算子的详细说明可见工具链社区文章，下面是一个典型unitconv在pytorch框架下的写法：

总结