导读：
11月22日，新一期《地平线你好，开发者工具链技术专场》在智慧猩猩企业直播中圆满落幕。 本次专题会议由地平线工具链量化训练工具研发负责人曲淑倩主讲，主题为：“地平线量化训练工具的设计和精度调整经验”。
本文是主要讲座的文字记录。 如果您有现场回放和问答的需求，可以点击这里阅读原文去**。
曲淑谦：大家好，我是地平线深度习平台的曲书谦，主要负责地平线工具链的量化训练工具。 今天，我们将讨论“地平线量化训练工具的设计和精度调整经验”这一主题。 今天我将从以下几个角度进行解释：1定量训练技术导论 2定量训练工具的挑战3在地平线量化工具的设计和精确调整方面的经验4未来的探索方向。
定量训练技术简介
众所周知，整数计算在芯片或设备端部署中肯定比浮点计算快得多。 这里有一个简单的传说。 
例如，从图中可以看出，8b 添加和同一层实际上相差几个数量级。 因此，从功耗和面积的角度来看，整数计算实际上更适合设备端部署。 我们的 Journey 系列芯片支持 INT8 或 INT16 计算，从 Journey 2、Journey 3、Journey 5 到最近推出的 Journey 6。 我们的工具是将浮点模型部署到我们的芯片上。
定量训练工具的挑战
众所周知，智能驾驶场景中存在一些量化问题：
1、智能驾驶场景中的传感器种类和数量很多，如摄像头、雷达等，不同类型数据的数据范围差异较大。 以这张图片为例，大家都明白它是int（0-255）;雷达有很多位置信息，甚至速度信息，所以它的数值范围非常大，这对量化来说是一个很大的挑战。 今天我也看到一些同学的提问，比如输入层能不能用更低的位量化目前，这其实是相当困难的。 2、智能驾驶场景模型会越来越复杂，尤其是现在大家都在追求端到端的模式。 从感知到监管的端到端过程非常漫长，每个阶段的模型结构都存在差距，因此量化的挑战会越来越大。 在我们公司，我们在做端到端模型的时候，遇到了很多问题，在量化方面也遇到了很多问题。 3.FP32的数值精度为2 对于INT8来说，只有1 256个数字，也就是256个数字，因此不友好量化的现象时有发生。 传统上，每个人都认为这是正常的，所以很容易量化。 但事实并非如此，特别是因为某些 Transformer 模型对量化不是很友好。 与浮点精度相比，量化训练可以进一步减少量化部署精度的损失。 我稍微介绍一下定量训练的基础知识，也许现在大部分的同学都比较清楚，但是有些同学会不熟悉。 量化是从浮点到定点的映射过程，这里的公式是均匀的零点非对称量化。 我们目前的量化训练工具主要是对称量化，零点为0。 去量化是反向的过程。 以 conv 为例，从输入到输出，比如 int 和 weight，都是浮点型的。 如果是一个量化过程，它真正的计算过程就变成了前两个有量化节点，两个输入是 int8，输出是 int32。 所以 conv 是 int8 的计算。 说到量化训练，量化训练就是一个先量化后去量化的过程，是一个伪量化节点。 这个节点在量化训练过程中更为重要，相当于在浮点训练过程中模拟部署在设备侧的量化过程。 它的输出也是一个浮点数，可以认为是量化去量化后的浮点数，这与之前的浮点数不同。
地平线量化工具设计与设计
精密调优经验
接下来，我们将重点介绍Horizon当前的量化策略。 1. 基于现有浮点模型进行微调，无需用户重新训练。 当然，有好事也有坏事要做，这是社区中最常见的方式：训练浮点模型并进行微调。 它的成本相对较低，目前感知在浮点的1 10以下。 这其中也会有一些问题，在智能驾驶场景的量产过程中，浮点模型本身不断微调，然后加入QAT微调，理论上可能会有一些问题，但是我们还没有遇到过。 另一方面，我们也可以允许用户基于量化模型，也就是刚才的假量化模型，直接从0开始做量化训练。 这适用于我们公司的一些场景模型，对于模型迭代来说可能会更稳定一些。 2、梯度计算也是业界比较常用的方法，就是STE。 因为量化函数是阶梯，所以没有导数。 因此，业界常用的方法是透传，直接传输输出的量化梯度。 唯一的区别是两端是饱和的还是不饱和的，以及该位置是否应该透明。 3、规模更新策略以统计为主，min、max一般不直接使用。 例如，移动 **er**ge 的一种方法是根据当前批次和前一批次的一些数据进行统计。 还有一种基于习的方法。 规模本身也是习，也可以用梯度的方式来做，比如LSQ。 支持这种水平策略，并且还支持一种基于实际数据范围设置固定比例的方法。 这种方法可能看起来不那么崇高，但它可以在很多场景中使用。 对于某些数值范围，例如 qat 或 calibration，某些数据可能无法覆盖某些实际数值范围，因此此时需要根据实际数值范围计算一个固定的刻度，除以 int8 除以浮点数的最小值和最大值，例如刚才提到的 -128 和 127 的最小值和最大值。 4.还支持浮点模型FP16&FP32的部署。 征程 5 采用异构方式，部分在 CPU 上计算，将直接支持征程 6。 自去年下半年以来，我们一直在探索一种方法：校准 + QAT。 在早期，我们没有使用这种方法来做QAT定量训练计划。 你可能会认为QAT已经很稳定了，随便做一下，准确性就会上来。 其实不然，尤其是在Transformer模型出现之后，我们发现了很多定量问题，有时候直接插上QAT是无法解决问题的。 所以我们的策略是先进行校准，然后进行QAT。 这种方法的优点是，在某些情况下，精度更高 *** 在直接 QAT 上不会上升，并且可以通过这种方式完成。 目前，我们大约有1个3个，甚至更多的参考模型不需要QAT直接满足精度，根据场景，大概是多一点分类和分割模型。 当使用校准刻度作为QAT的基础时，可以减少QAT中的步数，并且可以更快地达到精度目标，因此整体量化成本会更低。 其实我们的用户相当关心QAT或者整个解决方案会带来多少成本，除了人力成本，还有机器成本，比如我花了一周时间训练一个模型，如果QAT再花几天时间，可能就不能接受了。 所以这个策略可以更快地达到最终部署的准确性，这在以前可能需要一天，但现在可以在半天内完成。 鉴于刚才的好处，我们的校准策略也在逐步完善，我们支持行业内比较常用的策略，包括kl、percentile、mse、max、adaround等。 最近，还支持自动搜索混合校准策略，以便为每一层选择最佳校准策略。 其实这也是来自客户的需求，他们不想在每个阶段都匹配策略，这样会花费大量的人力二是用户在使用时不知道该选择哪一个，因为在某些情况下很难知道哪一个最好。 所以我们有了自动搜索策略，当然，自动搜索会消耗更多的机器资源，相当于用资源换取一些人力，对大家会更友好。 下面列出了一些 CNN 模型准确性的主要参数。 
由此，比如分类和分割模型，我们可以通过直接做标定来实现。 以下模型需要执行 QAT。 让我们谈谈我们在变压器量化方面所做的一些工作。 在我们探索变形金刚的早期，它给我们带来了很多麻烦。 过去，我们会接触到很多CNN模型，因为当时的Transformer方案在面向真实场景的时候还不是很成熟。 但是目前大家都在做一些集成，比如智能驾驶场景，会用到一些变形金刚注意力方案，但其实之前不会，所以大家一开始就尝试了很多东西。 目前，我们针对这些复杂的算子，如layernorm、softmax、gridsample等，提供了更加人性化的精度方案，但这里不能完全认为gridsample。 用户可以直接调整社区的运营商，无需感知。 我们将它转移到 QAT 的模型中，该模型主要是 INT8 和 INT16 的混合，并使用 INT16 来解决一些精度问题，这样可以降低 Transformer 模型的量化难度。 在这些运营商中，例如 gelu，我们并不认为它有太大问题。 对于一些常见的注意力结构，例如 multiscaledeformableattention，它提供了精度和部署性能优化。 我可能已经选择了一些模型，您可以看到一些用于各种场景的模型，例如分类、检测和车道标记。 
该区域模型的最终精度看起来还可以。 目前，从QAT的角度来看，我们可以解决Transformer的量化问题，不仅是INT8，还有INT16。 刚才讲了部分量化训练策略，会多做一点工作，如何选择pytorch量化训练接口这也是一个令人头疼的问题。 如果我想尝试 PyTorch 量化工具，我该怎么办？社区可能已经提供了一些解决方案，但社区界面将始终是原型和测试版，并且在非常早期的阶段会持续很长时间。 量化训练问题本质上是在合适的位置插入一个伪量化节点，可能会有一些节点替换问题，但关键问题是插入一个伪量化节点。 同时，训练特征应保持不变，插入后无法获得图，但使用量化的体验与原来的浮点体验不同。 这张图是 2022 年底到 2023 年初的状态，有很多方法可以用 PyTorch 捕获图。 
实际上有很多捕获方法，从脚本到跟踪，再到FX，Dynamo，并且在不同的级别上有不同的解决方案。 我们更关心的是获得全貌，有时没有它就很难做某事。 那么我们应该选择什么样的解决方案呢？一个是没有图表的 EAGER 或 FX 或 Dynamo。 对于发电机，上一段刚刚发布的 21 Dynamo 导出程序。 这些方案都不是完美的，每个方案都有自己的局限性，会给算法同学带来一些不太友好的东西，你不可能一下子全部得到。 就像我们早期使用的那个，比如MXNet或者TF，我们直接定义图的节点。 在这一点上，框架级别操作起来很简单，但可能对用户不友好。 Horizon 现在支持“急切模式”和“FX 模式”。 
在急切模式的整体方案中没有图表。 当用户实际做QAT时，他的体验和做浮点是一样的，可以做单步调试。 但是，由于没有图，用户在做算子融合时需要手动操作，例如，融合conv、bn、relu算子后，量化更友好，部署也会更友好。 这些是偏差优化的操作。 在急切模式下，需要手动替换一些运算符，例如加法、减法、乘法和除法。 在浮点阶段，我们可以随意调用这些算子，但在 QAT 上就不同了，如果要添加量化，就意味着在其中插入一些量化节点。 量化节点是我们刚才看到的尺度、零点等。 它们是要转换为火炬模型的状态参数。 用模块替换函数需要用户手动替换它，因此此解决方案的问题可能在于其友好性。 但是在配置了 qconfig 并准备后，还是可以的。 FX Mode 没有那么麻烦，因为它有一个图表，我们可以在其中做一些我们想要的工作。 但是 fx 模式存在一些语法问题。 这种方法使用代理而不是真实张量，如果有非真实张量做符号跟踪，符号跟踪和python语法之间会存在一些兼容性问题。 总的来说，这是我们目前的方法。 我们也在努力帮助用户提高定量接口的适用性。 相信在这两个版本的基础上，会做出一些更友好的版本。 例如，基于 Torch 21. 导出方法跟踪 fx-graph。 接下来是与硬件相关的优化。 
1.当前的QAT仍然绑定到硬件上，并没有完全与硬件分离。 因此，其目标更接近于硬件的模拟量化，可以进一步降低从QAT模型到量化模型的损耗。 直观地说，如果你使用的是浮点，那么你可能没有这个问题。 但如果在部署时也修复了，仍然会出现这些问题。 毕竟前面是模拟的量化，后面是真正的定点，所以精度会有一些差距。 正如你刚才看到的，我们目前的量化相对QAT相对较小。 2、在保证精度的同时，尽量量化多个算子，充分发挥硬件的潜力。 我在前面的ppt中也说过，int计算还是比较经济的。 3、为一些特殊场景提供硬件高效算子。 这些运算符在我们的硬件上进行了优化，并嵌入到工具中，以便用户可以按需使用它们。 4.支持量化模型。 基于GPU和x86**的高性能，我们今年还优化了几个版本。 5. 支持稀疏性训练 （2：4）。 （2：4） 稀疏可能是公认的硬件友好稀疏策略，硬件实现成本相对较低，精度损失还可以。 我在这里没有精确度的案例。 稀疏性训练+量化的整个过程比之前的精度损失低了2%左右，这是我们目前一些实验的结论。 它自己的流程是基于浮点模型的，浮点模型进来后，先是稀疏化，然后量化，再部署。 我谈到了我们在许多场景中量化复杂模型训练的经验。 我们内部有一些复杂的模型，我认为它会变得越来越复杂，至少现在不会，我们已经有一些经验：首先是某些场景模型的输入，比如雷达数据。 对于雷达来说，不同信道的数字范围会比较不同，不适合量化。 因此，我们建议用户先做归一化，然后在网络中量化，量化损失会比较小。 第二种是视觉转换器，比如bevformer，它有很多参考点和位置相关的信息例如，gridsample的网格计算也与位置有关，无论是相对位置还是其他位置，因为量化灵敏度相对较高，并且需要更高的精度。 我们建议使用 int16 量化，或基于真实数据范围的固定比例。 我刚才提到过，你为什么要做这种工作？事实上，有时为了进行量化，这项工作是必要的。 我们看到，在实验场景中，QAT 在数据集上多次运行，但当每个人都在真实场景上制作模型时，它是按照步骤计算的，而不是 EPOCH。 在 STEP 中，我可以在 QAT 上运行 1000 个步骤，所以我不知道我可以运行多少数据。 当你按照某个标准选择数据时，你可能无法非常合理地选择它，所以这种情况很可能需要设置一个固定的刻度，我们也可以让用户稍后设置一些浮点。 三是检测等模型，例如网络输出与算法指标关系较大，我们建议设置高精度输出，或者默认设置高精度。 这是一张来自其他地方的照片。 
例如，您学习到的 scale、min 和 max 都是基于统计数据获得的，并且会删除一些异常值。 但有些点是相当重要的，比如刚才提到的点的位置，如果你在没有大脑的情况下做饱和，那就有问题了。 这就是我们在调整复杂模型方面的经验。 目前，我们很多内部和非公司量产客户都在使用这套工具，以下是丰富的精密调校工具。 这里我列举了很多工具，包括一些模型结构检查工具、故障排除共享OP、算子融合、量化配置等。 
共享 OP 对于浮点用户来说通常并不常见。 特别是在 PyTorch 中，例如某些检测标头，某个 CONV 可能需要多次传递，但共享 OP 不一定对量化友好。 共享 OP 的问题在于，它本来是按张量尺度，但共享后相当于多张量尺度，一个尺度管理多个张量。 除非每次多个分支的数值范围分布差异很小，否则没有问题;一旦出现一些差异，准确性就会出现问题。 因此，我们不建议大家在QAT阶段使用共享OP，当然也有一些工具可以检查。 以下是一些提供相似性和统计数据的工具，可帮助您找到定量敏感性。 还有一些工具支持分步调试。 单步调试和浮点的体验是一样的，就像PyTorch最大的优势是python程序一样，大家都是同一个python程序，不会变成别的什么。 最后一个是支持部署一致的对齐工具。 调试是有代价的，而且不是免费的。 至少我们没有一个特别好的指标可以处理所有情况。 因此，有必要通过多个指标共同分析哪些地方可能带来数量问题。 我们也在内部继续探索，如何做得更好例如，他们会尽量让大家发现不好的案例，如果直接运行这些工具，有时可能就反映不出来了。 但也许在找到一个糟糕的案例后没关系。 这与调试相同，我们正在尝试使用类似的策略进行改进，我们将在未来继续改进它。 这是当前精度调优的流程图，我就不赘述了。
在浮点、校准、QAT 和量化阶段可能存在一些量化问题。 比如校准，我不希望校准达到1%以下的损耗，很多时候是达不到的，这时候需要调整QAT，网络结构、校准策略或者定量配置都可能有问题。 将qat转换为量化模型的问题在于精度可能会下降，而且问题有很多种，我给大家举一个典型的例子：一个非线性激活，比如exp，看起来很奇怪，我们在量化的时候会把它变成一个查找表，因为查找表在硬件上是最好的， 而且计算速度也非常快。但是这个时候，如何找到你的表，如何设置表间隔都是问题。 我们内部会自动找到这些东西，但是已经有 1 2 个案例了，我们发现的表间隔不是很合理，所以我们这个时候需要微调。
推荐新一期《地平线你好，开发者工具链技术专场：12月6日，地平线模型转换与量化工具负责人何道元将做《地平线模型转换与量化部署后培训》讲座。
未来的探索方向。
最后，我们将探讨我们未来探索的方向。
我们将继续探索复杂场景模型的量化部署，因为目前的模型确实越来越复杂。 数据量化部署、量化调优、精准调优的流程也要不断完善。 之前ppt中出现过一些模型，这些模型确实需要大量的时间来调试。 如果你是一个完全不了解量化算法的人，你可能无法完全进行量化。 某些情况的量化并不友好，可能是因为输入和输出的物理含义是绑定的。 作为一个制作定量工具的人，有时你可能无法感知这些物理意义。 所以每个人都必须相互理解。 做量化的学生必须了解一些算法，做算法的学生必须了解一些量化。 就目前而言，我们认为这是不可避免的，只是你了解多少的问题。 我们也在不断改进，希望大家能尽可能少地理解，一手或几手就能做到。 提高算法迭代效率。 毕竟大家都在抓时间、赶量产，大家都花了很长时间调整浮点模型的精度，也不想花那么长时间做量化。 我们也希望让这个过程更加完善，这样可以提高迭代的效率。 探索低位混合量化。 可能不仅仅是更低的位，包括 int8、int16、fp16 甚至更低。 由于硬件将支持多种数据类型，因此在什么情况下这些数据类型最适合硬件性能？对于QAT来说，确实有很大的探索空间。 QAT 对量化问题的容忍度更高一些，因此它更有可能获得更准确部署的模型。 探索大型LLM模型的定量部署。 大型模型的问题可能在于它们无法进行完整的微调并再次执行所有数据，这可能是每个人都无法接受的。 目前大家只是在跑一点数据，和刚才提到的复杂模型类似，大家都在跑步，不是纪元。 如果运行步骤较少，而有些运行步骤较多，则精度会有所不同。 这些是我们想要探索的一些后续任务。 这就是我今天要说的，谢谢。