企业官网建设流程全解析

在J6m上把YOLOv8s从FP32压到INT8，第一次跑COCO验证集的时候，mAP0.5:0.95直接从44.3掉到39.8，整整少了4.5个点。这已经不是我第一次做量化部署了，但看到这个数字还是有点懵，因为前期用工具链自带的快速预览功能看，似乎各方面都正常，输出框数量也对得上，结果精度一评估就露馅。翻了两天日志、改了好几版配置，最终才把问题缩小到校准集分布和检测头DFL分支几个卷积层上。

这个过程几乎包含了INT8量化部署最常见的坑，所以抽时间整理出来，给准备在Horizon平台上量化检测模型的朋友做个参照。如果你也遇到量化后掉点严重、小目标漏检、夜间场景拉胯的问题，这篇文章应该能帮你省下至少一天的排查时间。

1. 部署场景与量化掉点概况

1.1 为什么非要用INT8

这次项目用的是地平线J6m平台，做前视摄像头感知，检测任务覆盖行人、车辆、骑行者，目标距离从十几米到七八十米都有。模型选YOLOv8s，输入分辨率640x640，COCO预训练权重基础上又用自己采集的数据微调过。

选YOLOv8s的原因很简单，它是目前检测精度和推理速度平衡得比较好的模型，ONNX导出链路成熟，部署生态也相对友好。真正的问题在J6m上，芯片算力资源要同时跑多路感知任务，如果模型全部以FP32精度运行，卷积计算根本跑不满芯片的定点算子，帧率上不去，整体时延也会拖垮后面的融合模块。

INT8量化对这类端侧部署几乎是必选项。芯片上有专门的定点计算单元，INT8的吞吐量远高于FP32模拟计算，模型体积也能缩小到原来的四分之一左右。代价就是数值精度损失，但通常控制在1到2个点以内是能接受的，超出这个范围就必须排查。

1.2 量化后精度数据到底是多少

先说基线。FP32模型在服务端用COCO验证集跑出来的结果是mAP0.5:0.95=44.3，mAP0.5=62.5。同样的模型转成J6m可部署格式后，用FP32模式在板端推理，精度基本没有损失，mAP0.5:0.95=44.1，说明转换流程本身没把模型弄坏。

INT8量化后，问题就出来了：

逐类看的话，行人这一类掉得最狠，mAP0.5从60.2掉到54.7，远距离小目标漏检明显增多，夜间、逆光场景下检测框抖动也很严重。这个结果已经影响到项目验收指标，必须着手排查。

2. 排查的第一步：校准流程和预处理是否拉胯

2.1 校准集的选择直接决定INT8的基线

INT8量化的核心是统计每一层激活值的分布范围，然后决定量化scale和zero point。统计用的数据集就是校准集，它必须尽可能代表模型实际运行时的数据分布。这个原则理论上都懂，但实际落地时很容易偷懒。

我第一次量化时，从训练集里随机抽了500张图做校准。这些图大部分是白天、晴天、城市快速路的场景，场景单一，分布窄。而项目实车运行是全天候的，夜间、雨天、逆光、乡下小路这些场景都有。问题在于，夜间图像的像素值分布和白天差异非常大，量化scale是按校准集的分布算出来的，夜间帧进入模型时，激活值大量落在量化区间的边缘，量化误差被成倍放大。

我重新按场景类别做了采样，白天城市、夜间城市、雨天、高速、乡村道路、隧道各取大概100张，凑了600张校准图。重新生成模型后，mAP0.5:0.95提升了0.9个点左右。这个改动几乎不花任何成本，就是花点时间去挑图。

校准集数量方面，地平线工具链的建议是500到1000张，实际跑下来600张已经足够。再往上加，精度变化基本在0.1个点以内，纯粹增加校准时间。关键是覆盖度，不是数量。

2.2 预处理参数的一致性检查

排查量化掉点问题，第一步永远是检查预处理是否对齐。这个步骤听起来很简单，但踩坑概率极高，而且一旦错，后面所有工作都白做。

我这次就差点被这里坑了。训练代码里YOLOv8用的标准预处理是RGB输入、letterbox到640x640、像素值除以255做归一化。转换配置里对应的应该是mean=0、scale=0.003921568（也就是1/255）。但实际上，转换配置里被写成了mean=128、scale=0.0078125，这组参数一看就是从某个分类模型配置里复制过来的，忘记改了。

结果就是输入图像经过第一层卷积之前，数值分布整体偏移，第一个tensor量化后误差就比较大，后面的误差不断累积。这种问题在FP32模型上影响有限，量化后会被放大到不可接受的程度。

建议写一个自动化检查脚本，把同一张图在PyTorch模型里跑一遍，再在板端推理相同输入，对比两边的输出特征图或者最终检测框。如果差异从一开始就很明显，优先怀疑预处理。检查时重点看RGB顺序、归一化系数、缩放方式三个点。

2.3 校准参数和迭代次数怎么调

地平线工具链支持多种校准方法，常见的有percentile、mse、entropy这几种。它们统计激活值分布的策略不同，对最终量化效果也有影响。我这次用默认的percentile 99.99%跑了一版，换到mse方法之后，mAP0.5:0.95又有大约0.3个点的提升。

经验是，检测模型一般优先试mse，它在减小均方误差方面比较稳。entropy方法对分布比较极端的层可能有优势，但全局效果不一定好。实际项目中可以把校准方法做成可配置的参数，一次性生成几个版本，用同一套验证集快速评估，选最优的，不用过度纠结理论。

校准迭代次数不用太大。用600张校准图，跑10个迭代基本就收敛了，跑20个迭代精度几乎不变，只是耗时增加。有人以为迭代越多越好，其实校准分布统计的是整体分布区间，不是拟合精度，迭代太多反而可能被个别离群样本带偏。

3. 定位量化敏感层：从整模型到逐层对比

3.1 用转换工具看各层量化误差

预处理和校准集修正之后，量化精度有明显提升，但还差着2个点左右，距离验收标准有距离。接下来需要搞清楚究竟是哪些层在量化过程中损失最大。

地平线工具链在模型转换时本身会输出日志和量化报告，可以查看每一层是否成功量化成INT8、是否出现算子回退。但这类报告通常只给到算子级别，不会直接告诉你“哪个层导致掉了多少mAP”。

我的做法是写脚本做逐层余弦相似度对比：在PC端用工具链导出的量化模型跑一组验证图片，记录每一层的激活值输出；再用FP32模型跑同样的图片，记录对应层的输出。计算每一层的余弦相似度，相似度低于0.95的基本就是嫌疑层。

统计结果很有指向性。主干网络大部分层的余弦相似度都在0.99以上，说明基础特征提取没被量化破坏太多。真正问题集中在两个地方：一是c2f模块里最后一次concat之后的卷积，二是检测头DFL分支的多个卷积层，其中几个层的余弦相似度只有0.87到0.9，低得离谱。

3.2 为什么YOLOv8的DFL头对INT8特别敏感

YOLOv8的检测头和传统的anchor-based检测头不太一样。它的回归分支输出的是DFL（Distribution Focal Loss）的分布向量，一组离散概率分布，后面还要做一个期望计算，也就是把概率分布和预定义的投影向量做加权求和，才能得到边界框的偏移量。

这个分布向量在推理时很多值都接近0，数值范围很宽，分布也不均匀。量化时，接近0的小数值可能会被直接量化成0，概率分布的峰值位置也可能发生偏移，最后计算期望时，误差被积分放大。尤其是远距离小目标，DFL分布往往没有一个明显的峰值，各个值的权重都比较平均，量化误差对最终框的位置影响就更大。

这里可以用一个简单类比：要求一组小数在计算加权平均时只保留一位小数，平时误差看不出来，但如果权重分布比较平均，没有主导项，舍入误差就会直接影响最终结果。DFL分支就是这个逻辑，它对数值精度特别敏感。

另外，c2f模块里的concat操作在量化工具链实现中，会把不同支路的特征在通道维度拼接起来，这会导致激活值范围变大，后续量化的尺度系数变大，量化噪声也随之增加。如果模型结构可以在部署前做针对性调整，比如对concat层之后的卷积做特殊处理，也能减少精度损失。

3.3 混精度配置：只把敏感层留在高精度

定位到嫌疑层之后，解决方案就是混精度部署。把DFL分支的几个关键卷积层保留为FP32或者FP16运行，其余层继续走INT8。

地平线工具链支持在转换配置里对指定算子设置精度模式。我的做法是把DFL分支的卷积层全部设置为FP32，c2f模块最后那个concat后的卷积设置为FP16。这里要注意，如果保留高精度的层太多，INT8的性能优势就没了。建议每次只放开最可疑的一两个层，重新生成模型、重新评估精度和耗时，用增量方式找到性价比最高的配置。

实测结果：把DFL分支的几个卷积保留为FP32后，mAP0.5:0.95从40.7恢复到43.1，精度损失被压到1个点左右。同时，单帧推理时间从10.8ms涨到11.6ms，完全在可接受范围内。这个成本对精度收益来说非常划算。

4. 板端推理细节：后处理和推理环境也是掉点元凶

4.1 解码和NMS的实现必须和训练完全一致

在校准集和量化配置都调整到位后，我又遇到一个诡异的问题：量化模型在PC端用工具链模拟评估精度正常，但上板之后，检测结果比PC端还要差一截。同一张测试图，PC端能检测出目标，板端偶尔漏检或者框偏移。

排查到最后发现是后处理解码不一致。YOLOv8的DFL回归分支需要把概率分布做期望积分才能得到box偏移量。PC端验证脚本用的是完整积分逻辑，而板端代码里为了省计算量，把这个期望计算简化成了取最大值，也就是直接用概率最大的那个位置作为偏移量。

这两个方案在小目标、远距离目标上的差距很明显。DFL分布没有明显峰值时，取最大值会丢掉大量信息，框的位置偏移自然就大。这个问题和量化无关，但在INT8模型上，由于前面已经有量化误差，后处理再把误差放大，整体效果就雪上加霜。

排查这个问题的有效方法是固定输入图片，导出模型的中间特征，在PC端和板端逐层对比。从第一个不一致的地方开始往下追。如果中间特征完全一致，只是最终输出框不同，那问题基本出在解码和NMS代码上。

另外，NMS参数也容易不一致。PC端评估用的conf=0.25、iou=0.45，板端如果用了conf=0.3或者iou=0.5，评估指标当然对不上。建议评估阶段直接复用同一套Python后处理逻辑，或者把后处理参数做成配置文件，确保两端一致。

4.2 芯片运行状态对测评结果的影响

排查后期还遇到一个比较折腾的问题：同样的模型，早上测和下午测，精度差了0.5个点。一开始以为是玄学，后来发现是板子上的后台任务和频率调度影响了推理结果。

具体表现是，当板子上有其他高负载任务在跑时，推理时延变大，而且由于动态调度，某些算子的执行顺序和并行度发生变化，最终结果出现细微差异。这在量化模型上更明显，因为INT8计算是定点运算，理论上结果是确定的，但如果算子被打散到不同计算单元，浮点中间结果的累积顺序变了，还是会带来微小误差。

解决方式很简单，评测阶段把CPU/BPU频率固定，关掉不必要的后台服务，保证每次跑模型的环境一致。因为用了嵌入式Linux系统，我就把一些system service停掉，同时在评测脚本里强制设置性能模式。这样做了之后，多次评测的精度波动控制在了0.1个点以内。

这块看起来不起眼，但对规范化的模型验收流程很重要。如果评测环境不稳定，后面定位问题的时候会被这些随机误差干扰，浪费大量时间。

5. 一套可复用的排查流程与最终结果

5.1 从零开始的排查清单

结合这次实战，我整理了一套适合地平线J6m平台YOLO系列模型的量化精度排查流程，按优先级排序：

1. 检查预处理配置是否和训练代码完全一致，重点看RGB顺序、归一化系数、resize方式。这一步如果有问题，后面所有调整都无效。
2. 重新审视校准集，按实际落地场景分类采样，确保覆盖白天、夜间、雨雾、城市、高速等典型工况，数量在500到1000张。
3. 尝试不同校准方法（percentile、mse、entropy），用同一套验证集快速评估，选最优结果。
4. 如果掉点仍大于2个点，做逐层余弦相似度对比，定位量化敏感层。重点检查DFL分支、anchor-free回归头、concat之后的卷积层。
5. 对敏感层配置混精度，每次只放开最可疑的一两个层，增量评估精度和耗时。
6. 对齐板端后处理逻辑，包括DFL积分、NMS阈值、分类阈值，确保和PC端评估脚本完全一致。
7. 固定评测环境，包括芯片频率、后台任务、温度条件，多次重复评测取稳定值。

每一步的耗时和收益可以参考下面这张表：

5.2 最终量化方案和精度对比

最终落地的方案是：600张场景均衡的校准集，mse校准方法，DFL分支卷积保留FP32，c2f模块最后一个concat后的卷积保留FP16，板端后处理和PC端完全一致，评测环境固定。

最终精度和性能数据：

从FP32到最终INT8方案，mAP0.5:0.95损失0.9个点，mAP0.5损失0.9个点，单帧推理时间从26ms降到11.6ms，速度提升接近一倍多，精度损失控制在1个点以内，对项目验收来说是完全可以接受的。

5.3 聊一下QAT什么时候值得做

如果你按上面的流程走完，精度损失还是超过3个点，那就要考虑QAT（量化感知训练）了。YOLOv8的结构本身对量化不算友好，尤其是DFL回归头和anchor-free分支，后训练量化能保住精度说明模型运气好，保不住也没什么可惊讶的。

QAT的思路是在训练阶段就模拟量化过程，让模型权重主动适应量化的噪声。地平线工具链也有对应的QAT方案，但训练成本不低，需要准备专用的训练代码、调超参、重新训练，整个流程下来可能要一两周时间。

我的建议是，项目排期允许并且精度指标很严格时再上QAT。常规项目先按第5.1节的流程走一遍，通常都能解决问题。我自己这次就没有走到QAT那一步。

6. 常见问题速查表

把这次排查过程中遇到的典型问题和对应的处理办法整理成速查表，方便大家直接对照：

这个表格基本覆盖了YOLO系列模型在地平线平台上量化部署的高频问题。如果你遇到的情况不在表里，优先从预处理和校准集这两个最容易出问题、又最容易忽略的环节查起。

回头来看，这次排查最有价值的不是最后的混精度配置，而是建立了一套完整的量化精度排查方法论。INT8量化不是把模型扔进工具链就完事，校准分布、预处理、算子敏感性、后处理，每一环都可能偷偷吃掉一两个点。如果你的模型在J6m上掉点也很严重，先别急着怀疑工具链或者芯片，把上面这些环节逐个过一遍，问题往往就出在最不起眼的地方。我现在拿到新模型，第一步就是先做一次快速量化实验，把模型结构里的量化敏感点找出来，然后再决定是调校准还是改结构，这个习惯帮我省了不少排障时间。