在J6m上把YOLOv8s从FP32压到INT8第一次跑COCO验证集的时候mAP0.5:0.95直接从44.3掉到39.8整整少了4.5个点。这已经不是我第一次做量化部署了但看到这个数字还是有点懵因为前期用工具链自带的快速预览功能看似乎各方面都正常输出框数量也对得上结果精度一评估就露馅。翻了两天日志、改了好几版配置最终才把问题缩小到校准集分布和检测头DFL分支几个卷积层上。这个过程几乎包含了INT8量化部署最常见的坑所以抽时间整理出来给准备在Horizon平台上量化检测模型的朋友做个参照。如果你也遇到量化后掉点严重、小目标漏检、夜间场景拉胯的问题这篇文章应该能帮你省下至少一天的排查时间。1. 部署场景与量化掉点概况1.1 为什么非要用INT8这次项目用的是地平线J6m平台做前视摄像头感知检测任务覆盖行人、车辆、骑行者目标距离从十几米到七八十米都有。模型选YOLOv8s输入分辨率640x640COCO预训练权重基础上又用自己采集的数据微调过。选YOLOv8s的原因很简单它是目前检测精度和推理速度平衡得比较好的模型ONNX导出链路成熟部署生态也相对友好。真正的问题在J6m上芯片算力资源要同时跑多路感知任务如果模型全部以FP32精度运行卷积计算根本跑不满芯片的定点算子帧率上不去整体时延也会拖垮后面的融合模块。INT8量化对这类端侧部署几乎是必选项。芯片上有专门的定点计算单元INT8的吞吐量远高于FP32模拟计算模型体积也能缩小到原来的四分之一左右。代价就是数值精度损失但通常控制在1到2个点以内是能接受的超出这个范围就必须排查。1.2 量化后精度数据到底是多少先说基线。FP32模型在服务端用COCO验证集跑出来的结果是mAP0.5:0.9544.3mAP0.562.5。同样的模型转成J6m可部署格式后用FP32模式在板端推理精度基本没有损失mAP0.5:0.9544.1说明转换流程本身没把模型弄坏。INT8量化后问题就出来了模型形态mAP0.5:0.95mAP0.5J6m端单帧耗时YOLOv8s FP32服务器44.362.5不适用YOLOv8s FP32J6m44.162.3约26msYOLOv8s INT8J6m初始39.858.9约10.8ms逐类看的话行人这一类掉得最狠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做归一化。转换配置里对应的应该是mean0、scale0.003921568也就是1/255。但实际上转换配置里被写成了mean128、scale0.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检测头不太一样。它的回归分支输出的是DFLDistribution Focal Loss的分布向量一组离散概率分布后面还要做一个期望计算也就是把概率分布和预定义的投影向量做加权求和才能得到边界框的偏移量。这个分布向量在推理时很多值都接近0数值范围很宽分布也不均匀。量化时接近0的小数值可能会被直接量化成0概率分布的峰值位置也可能发生偏移最后计算期望时误差被积分放大。尤其是远距离小目标DFL分布往往没有一个明显的峰值各个值的权重都比较平均量化误差对最终框的位置影响就更大。这里可以用一个简单类比要求一组小数在计算加权平均时只保留一位小数平时误差看不出来但如果权重分布比较平均没有主导项舍入误差就会直接影响最终结果。DFL分支就是这个逻辑它对数值精度特别敏感。另外c2f模块里的concat操作在量化工具链实现中会把不同支路的特征在通道维度拼接起来这会导致激活值范围变大后续量化的尺度系数变大量化噪声也随之增加。如果模型结构可以在部署前做针对性调整比如对concat层之后的卷积做特殊处理也能减少精度损失。3.3 混精度配置只把敏感层留在高精度定位到嫌疑层之后解决方案就是混精度部署。把DFL分支的几个关键卷积层保留为FP32或者FP16运行其余层继续走INT8。地平线工具链支持在转换配置里对指定算子设置精度模式。我的做法是把DFL分支的卷积层全部设置为FP32c2f模块最后那个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端评估用的conf0.25、iou0.45板端如果用了conf0.3或者iou0.5评估指标当然对不上。建议评估阶段直接复用同一套Python后处理逻辑或者把后处理参数做成配置文件确保两端一致。4.2 芯片运行状态对测评结果的影响排查后期还遇到一个比较折腾的问题同样的模型早上测和下午测精度差了0.5个点。一开始以为是玄学后来发现是板子上的后台任务和频率调度影响了推理结果。具体表现是当板子上有其他高负载任务在跑时推理时延变大而且由于动态调度某些算子的执行顺序和并行度发生变化最终结果出现细微差异。这在量化模型上更明显因为INT8计算是定点运算理论上结果是确定的但如果算子被打散到不同计算单元浮点中间结果的累积顺序变了还是会带来微小误差。解决方式很简单评测阶段把CPU/BPU频率固定关掉不必要的后台服务保证每次跑模型的环境一致。因为用了嵌入式Linux系统我就把一些system service停掉同时在评测脚本里强制设置性能模式。这样做了之后多次评测的精度波动控制在了0.1个点以内。这块看起来不起眼但对规范化的模型验收流程很重要。如果评测环境不稳定后面定位问题的时候会被这些随机误差干扰浪费大量时间。5. 一套可复用的排查流程与最终结果5.1 从零开始的排查清单结合这次实战我整理了一套适合地平线J6m平台YOLO系列模型的量化精度排查流程按优先级排序检查预处理配置是否和训练代码完全一致重点看RGB顺序、归一化系数、resize方式。这一步如果有问题后面所有调整都无效。重新审视校准集按实际落地场景分类采样确保覆盖白天、夜间、雨雾、城市、高速等典型工况数量在500到1000张。尝试不同校准方法percentile、mse、entropy用同一套验证集快速评估选最优结果。如果掉点仍大于2个点做逐层余弦相似度对比定位量化敏感层。重点检查DFL分支、anchor-free回归头、concat之后的卷积层。对敏感层配置混精度每次只放开最可疑的一两个层增量评估精度和耗时。对齐板端后处理逻辑包括DFL积分、NMS阈值、分类阈值确保和PC端评估脚本完全一致。固定评测环境包括芯片频率、后台任务、温度条件多次重复评测取稳定值。每一步的耗时和收益可以参考下面这张表排查动作耗时预估本轮收益mAP0.5:0.95预处理对齐2小时无明显变化校准集重采样半天0.9校准方法调整3小时0.3逐层敏感度分析1天定位到关键层DFL分支混精度4小时2.4后处理对齐3小时0.5评测环境固定化2小时消除随机误差5.2 最终量化方案和精度对比最终落地的方案是600张场景均衡的校准集mse校准方法DFL分支卷积保留FP32c2f模块最后一个concat后的卷积保留FP16板端后处理和PC端完全一致评测环境固定。最终精度和性能数据模型形态mAP0.5:0.95mAP0.5J6m端单帧耗时YOLOv8s FP32J6m44.162.3约26msYOLOv8s INT8初始39.858.9约10.8msYOLOv8s INT8最终43.261.4约11.6ms从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. 常见问题速查表把这次排查过程中遇到的典型问题和对应的处理办法整理成速查表方便大家直接对照异常现象可能原因排查与解决夜间/弱光场景漏检严重校准集缺少夜间样本校准集按场景分类重新采样小目标检测框整体偏移DFL分支量化误差大DFL层混精度保留FP32框数量明显变多或变少后处理conf/iou与训练不一致统一conf、iou阈值和NMS逻辑转换日志出现算子回退个别算子不支持INT8查看工具链算子支持列表改写模型结构PC端模拟精度正常、板端掉点板端解码或NMS实现有差异固定输入逐层对比中间特征不同时间评测结果波动大芯片频率/后台任务变化评测时固定频率关闭后台服务校准集加了更多图但精度不变分布已经覆盖数量达到瓶颈调整校准算法或做敏感层分析量化后模型文件不降反增大量层被设置为高精度检查混精度配置范围减少高精度层数这个表格基本覆盖了YOLO系列模型在地平线平台上量化部署的高频问题。如果你遇到的情况不在表里优先从预处理和校准集这两个最容易出问题、又最容易忽略的环节查起。回头来看这次排查最有价值的不是最后的混精度配置而是建立了一套完整的量化精度排查方法论。INT8量化不是把模型扔进工具链就完事校准分布、预处理、算子敏感性、后处理每一环都可能偷偷吃掉一两个点。如果你的模型在J6m上掉点也很严重先别急着怀疑工具链或者芯片把上面这些环节逐个过一遍问题往往就出在最不起眼的地方。我现在拿到新模型第一步就是先做一次快速量化实验把模型结构里的量化敏感点找出来然后再决定是调校准还是改结构这个习惯帮我省了不少排障时间。