前一阵把 YOLOv8s 部署到地平线 J6m 上模型转换、板端推理这些环节走得都挺顺结果一到 INT8 量化就翻车mAP0.5 从浮点的 0.412 直接掉到 0.334将近 8 个点的差距这已经不是正常量化误差能解释的了。后来连续排查了好几天翻了不少工具链文档最后发现根子其实不在量化本身而在上游好几个“看起来影响不大”的环节。今天把这段踩坑记录整理出来希望能帮到正在 J6m 上做 YOLOv8 或者其他检测模型量化的朋友。这个内容适合谁看两类人最需要一类是刚接触地平线 J6m 部署正准备做 INT8 量化的可以先看完避坑另一类是已经遇到量化掉点、正在挠头找不到原因的可以参考我的排查思路按图索骥。文里不会贴太细的内部接口代码但每个排查步骤、每个经验结论都会讲清楚“为什么这么做”确保你能在项目里真正用上。1. 先把问题框定FP32基线、测试集和评估口径很多朋友遇到 INT8 掉点第一反应就是调整量化参数什么校准方法换一遍、校准集换一遍、scale 再校一遍折腾半天还是掉。我这次最大的教训是排查掉点问题第一步不是调量化而是把基线定住。所谓基线的意思就是你得先回答清楚一个问题这个模型现在到底“正常”应该跑出来多少精度如果 FP32 模型在 J6m 上本身就比训练时的精度低很多那 INT8 掉点很可能只是把迁移过程的问题放大了跟量化参数没太大关系。1.1 为什么需要一个干净的 FP32 基线我的习惯是建三组基线缺一不可PyTorch 原生 FP32 模型的评估结果用固定的测试集跑出来记为 A导出成 ONNX 后用 onnxruntime 在 PC 上跑同样的测试集记为 B地平线工具链仿真或者板端 FP32/混合精度模型的结果记为 C这三组结果要放在一起比A 和 B 之间的差异反映的是 PyTorch 到 ONNX 的导出损失B 和 C 之间的差异反映的是地平线工具链对模型结构重写、算子映射带来的损失C 和最终 INT8 的差异才真正是量化造成的损失。如果你的 A、B 之间就有 1% 以上的差距说明 ONNX 导出环节已经埋了雷这时候没必要往下走先把导出问题解决。如果 A、B 都正常C 明显偏低说明是工具链算子映射环节出了问题需要去查哪些算子被转换成了低效或者不支持的实现。只有 A、B、C 基本一致才可以放心地把矛头指向量化本身。1.2 预处理一致性最容易被忽视的暗坑这是我在这次排查里踩的最大的坑也极可能是你未来会遇到的问题。PyTorch 训练 YOLOv8 时ultralytics 框架默认的预处理是图像从 0-255 除以 255 变成 0-1然后按 ImageNet 的 mean/std 做归一化同时做 letterbox 到 640x640letterbox 的填充值默认是 114。这一套在 PyTorch 里跑得明明白白问题出在导出 ONNX、写校准脚本、部署预处理这几个环节非常容易有人写简化版。常见的不一致有这么几种通道顺序搞反训练时是 RGB校准脚本里 OpenCV 读进来就是 BGR没转回去忘了做 mean/std 归一化只做了除以 255letterbox 填充值写了 0 或者 128训练时是 114缩放方式不一致比如训练时按长边等比缩放部署时直接拉伸到 640x640目标比例变形这些差异在 FP32 模型上可能只掉零点几个点不明显但在 INT8 上因为量化本身就压缩了表示范围前端输入的微小偏差会被逐层放大最后体现在精度上就是好几个点的差距。所以排查时务必把训练、校准、部署三套预处理代码摆在一起逐行对。1.3 评估口径统一别让后处理吃掉精度另一个容易被忽略的“隐藏变量”是评估口径。训练的时候用 ultralytics 的 val.py 或者自定义的 mAP 脚本后处理参数是固定的NMS 的 IoU 阈值、置信度阈值、每个类别保留的框数量、计算 AP 时的 IoU 阈值这些参数有一套默认值。但到了板端验证时很多人会重新写一套后处理参数稍一改动mAP 就变了。我在排查过程中就发现自己后来写的一个板端验证脚本NMS 的 IoU 阈值用的是 0.6而训练时用的是 0.45就这么个差异mAP 就少了 1.5 个点左右。所以结论是比较浮点和 INT8 精度时后处理代码必须完全一样参数必须和训练时对齐。比较的是同一个后处理逻辑下浮点模型和量化模型输出的差异而不是把两套后处理逻辑的性能差异也算进去。1.4 逐类别拆解精度找到真正的掉点区域整体 mAP 是一个汇总指标它会把所有类别的表现平均在一起掩盖真实问题。这次我遇到的情况就是整体掉了近 8 个点如果只看这个数字会以为所有类别都在恶化。但拆到每个类别之后就发现人、车辆这类大目标其实掉得不多充其量一两个点真正惨的是红绿灯、锥桶这类小目标精度直接拦腰砍。为什么要做这一步因为不同类别、不同尺寸目标的掉点原因完全是两码事。大目标掉点通常指向全局性的问题比如预处理不一致、校准集分布整体偏移小目标掉点则往往指向局部细节比如某些浅层特征、特定尺度的检测头对量化更敏感或者校准集中该类别的样本太少。定位到具体类别排查方向就不会散。2. INT8量化链路梳理每个环节都可能埋雷基线打齐之后如果确认问题出在量化环节那就要把 J6m 上的 INT8 量化链路完整过一遍。这个过程其实不复杂但每个环节都有可能掉链子。2.1 J6m上YOLOv8s的部署链路概览地平线 J6m 的部署流程大方向是这样的训练好的模型先导出成 ONNX然后用地平线 OE 工具链做模型转换转换过程中会有一个 PTQ训练后量化环节工具链会跑一批校准数据统计各层激活值的分布算出合理的量化 scale最终生成 INT8 的 hbm 模型文件板端用推理运行时加载执行。整个链路里最容易出问题的地方不是最后的板端而是 ONNX 导出和校准这两个环节。因为工具链是“被动”接受 ONNX 的你给它的模型结构里有什么算子它就尽量去映射、去量化。模型结构本身如果在导出时就带病后续步骤再调也很难救回来。2.2 ONNX导出环节的几个注意点先说 ONNX 导出。我用的是 YOLOv8s 的 pytorch 权重ultralytics 官方就提供了导出接口一行命令就能出 ONNX很方便但也正因为方便很多人忽略了里面的细节opset 版本。地平线工具链对 ONNX opset 版本是有兼容范围的用太新的版本某些算子转换不了或者转换工具只能 fallback 到一个精度损失很大的实现。建议先确认工具链文档支持的 opset 范围在这个范围内选一个稳定的版本不要盲目追新。静态 shape 还是动态 shape。部署模型建议直接固定输入 shape 为静态比如 640x640。动态 shape 虽然灵活但工具链处理时往往要做 shape 推断推断不准确就会导致某些层计算错误。有时候导出 ONNX 默认是动态维度需要手动固定。导出后必须先验证。导出完用 onnxruntime 跑一遍拿浮点输出和 PyTorch 的输出逐层对比确认 max abs error 在极小范围。不要直接丢给地平线工具链否则后面出了什么问题都不知道是哪个环节导致的。DFL 解码部分是否导出到模型里。YOLOv8 的回归分支带一个 DFLDistribution Focal Loss解码结构这个结构里有 softmax、conv、matmul 等操作在量化时属于敏感区域。后面我详细讲这里先提一句导出时可以考虑把这部分后置到模型外面后面单独处理。2.3 校准集量化效果的第一决定因素校准集选了哪些图、选了多少张直接决定量化 scale 准不准。我踩过的坑是把训练集里随便抽了几百张当校准集结果训练集和实际部署场景的分布差太多了白天、夜晚、雨天各种场景分布不均量化出来的 scale 对测试集完全不对。校准集准备的经验建议数量500 张是底线我自己这次最终用了 1000 张效果明显比 500 张稳。太少的话激活值分布统计不够充分太多的话校准时间变长边际收益递减。分布覆盖部署场景下所有典型的光照、天气、目标尺度和类别。比如你的场景是自动驾驶路口那白天逆光、夜间灯光、雨天反光、远处小目标、近处大目标都得有。不要用增强过的图翻转、裁剪、拼接这些数据增强手段在校准场景下是帮倒忙因为量化要的是模型在真实推理分布上的激活统计不是训练分布。排除完全冗余的图连拍序列里前后帧高度相似的图挑一两张代表就行不要全塞进去避免某一种分布被过度代表。2.4 校准方法怎么选max、percentile、KL还是MSE地平线工具链里一般会提供几种量化校准方法每种方法本质上是不同的激活值统计策略。我常用的几个MAX直接取激活值的最大值作为量化边界。简单粗暴但对离群点极敏感。检测网络的特征图里经常会出现个别特别大的响应值比如某张图里一个超亮的光源一个 MAX 就把整个量化区间拉宽了其他正常区域的值被压缩到很少几个量化步长里精度自然崩。所以 YOLO 这类模型我一般不建议直接用 MAX。PERCENTILE取某个分位点的值作为量化边界把极端的尾部截断。比 MAX 稳很多适合激活值长尾分布的模型。分位点设多少需要试一般是 99.9% 到 99.999%太低了会截掉有效信息太高了跟 MAX 没区别。KL最小化量化前后分布之间的 KL 散度TensorRT 的默认做法被验证过很多模型上表现稳定我也经常用。MSE最小化量化前后数值的均方误差。理论上有道理但实际用起来有时候太“平滑”反而效果不如 KL 和 percentile部分模型上可以试。我的习惯是第一版先用 KL 或者 percentile看整体精度和逐类别精度。如果发现整体掉点但找不到明显问题再逐个换方法对比用数据说话。每种方法跑一次校准其实不需要太久多试几次不吃亏。2.5 量化粒度与预处理配置除了校准方法还有两个配置容易踩坑。第一个是权重量化粒度。per-tensor 是整个张量共用一个 scale实现简单但不同通道幅值差异大的时候误差大per-channel 是每个通道单独一个 scale精度更友好。J6m 工具链我印象里是支持 per-channel 的效果也更好。如果你的模型不是特别大建议优先考虑 per-channel。不过我实际用下来per-channel 对 YOLOv8s 这种通道数不算极端的模型提升幅度有限最终还是以实测为准。第二个是输入预处理节点。地平线工具链通常允许你配置一个输入预处理算子比如在模型里直接做归一化。这个配置必须和校准脚本的预处理一致校准脚本里喂给模型的如果是已经归一化到 0-1 的输入那模型内部的预处理节点就不要重复操作如果模型内部做了除以 255 的操作那校准数据就不能预先归一化。这个配置一端错了整个量化 scale 就是错的精度直接崩到底。3. 精度下降根因定位方法论基线正常、量化链路配置看着也没问题但 INT8 还是掉点多怎么办这时候不能继续盲调了需要一套系统化的定位方法。我的方法论核心是一句话让误差自己说话——逐层对比找到误差最先被放大的那一层。3.1 逐层输出对比让误差自己“说话”地平线工具链一般都带仿真或者输出统计的功能可以拿到量化模型中每一层的输入输出统计值。我们要做的就是先把浮点 ONNX 跑一遍保存每一层的输出 tensor再用工具链的量化仿真模式跑一遍同样的输入同样保存每一层的输出 tensor然后把两者逐层对比。对比指标我用的是余弦相似度和 NRMSE归一化均方根误差。余弦相似度对数值整体缩放不敏感能反映“形状”层面的差异NRMSE 对数值绝对差异敏感能反映“幅度”层面的差异。两个指标配合看基本能定位误差是从哪一层开始变大的。实操中你往往会看到这样的情况前几层相似度都在 0.99 以上某层之后突然掉到 0.85再往后一路走低。这个突变点就是量化误差被放大的源头。沿着这个点往前找看看是什么算子再看看这层的激活值分布有什么特点问题基本就清楚了。3.2 YOLOv8体系里的高频敏感算子在 YOLOv8 这个结构里经过这几轮排查我发现有几个位置是误差放大高发区DFL 解码里的 softmax。DFL 是 YOLOv8 回归分支的一个核心结构把 bbox 的每个坐标预测拆成 16 个 bin用 softmax 转为概率后求加权和。softmax 对输入数值的绝对大小和相对差异都很敏感一旦量化 scale 没有选准softmax 输出的概率分布就变形了导致回归框的位置偏移。这个在量化掉点里非常常见。检测头最后一层卷积的输出。这层输出直接决定类别得分和回归参数的原始值如果这层激活值分布跨度大或者有离群点量化误差会被 NMS 和后处理二次放大。有些场景下检测头分支的特征图里存在大量接近零的背景值量化很容易把这些背景区域处理得过于“干净”反而把原本微弱的目标信号也吃掉了。concat 和上采样的组合节点。YOLOv8 的 neck 部分有大量 concat把不同尺度的特征图拼接起来。如果拼接的特征尺度分布差异大一个 scale 很难同时 cover 两条分支误差就会在 concat 之后集中体现。定位到敏感算子之后修复手段就不是盲目调全局参数而是精准处理这几处。3.3 混合量化把关键层从INT8里摘出来当定位到个别敏感层后最直接有效的解决手段是混合量化也就是对少数关键层保留 FP16 甚至 FP32其他层继续走 INT8。地平线工具链支持算子级或者节点级的量化配置可以给指定的节点设置不量化。这里要慎重因为混合量化会牺牲部分性能所以必须遵循“先定位再回退只回退最少量”的原则。我这次的情况是DFL 部分的 softmax 回退成 FP16检测头最后一层卷积也回退成 FP16其余层全部保持 INT8。最终精度恢复到了浮点水平的 98% 以上板端推理帧率只降了不到 3%完全可以接受。如果你一开始直接用“整个模型回退到 FP16”来验证那当然也会恢复精度但这没有意义——性能损失太大还不如直接用 FP16 模型。混合量化的价值就在于用最小的性能代价换回大部分精度。3.4 从后处理视角反推精度问题逐层对比如果找不到明显异常问题可能不在量化模型本身而在后处理对量化输出的“放大作用”上。具体来说量化模型的输出置信度分布通常比浮点模型“平”一些原本 0.6、0.7 的置信度可能变成了 0.3、0.4。如果后处理置信度阈值是 0.25那就有一批检测框因为置信度被压到阈值以下而消失整体召回率下降mAP 自然就掉了。排查方法很朴素抓一张典型场景图分别跑浮点模型和 INT8 模型把后处理前的所有候选框和置信度打印出来并排对比。看看是置信度普遍变低还是回归框位置偏移还是 NMS 抑制逻辑出现了差异。我之前遇到过一种情况是 NMS 的阈值在量化后需要重新调节因为量化后置信度分布整体变化原来调好的阈值就不匹配了。这个因素不是模型的问题但最终也会体现在精度上属于排查盲区。4. 实测案例与排查速查表前面讲了方法论这部分把我实际遇到的几个案例拿出来拆解再把排查经验浓缩成速查表。三个案例分别对应三类典型原因预处理问题、校准集分布问题、敏感算子问题覆盖了绝大多数 YOLOv8s 在 J6m 上 INT8 掉点的场景。4.1 案例一预处理不一致整体掉点近10个点当时现象是 INT8 模型 mAP 从 0.781 掉到 0.682所有类别都掉没有任何类别幸免。因为掉得很“均匀”我第一反应是校准方法或者校准集的问题结果换了 KL、percentile 都差不多。后来静下心来打基线PyTorch 原生 FP32 评估 0.782导出 ONNX 用 onnxruntime 评估 0.781基本一致工具链仿真 FP32 评估 0.780也正常。问题就锁定在量化环节。再往下看校准脚本发现两个低级错误一个是图像通道顺序没从 BGR 转回 RGB另一个是 letterbox 填充值写成了 0而训练时是 114。改掉这两个预处理问题重新校准量化mAP 恢复到 0.769掉点从 9.9 个点缩小到 1.3 个点。这个案例说明INT8 本身放大了输入差异真正的问题出在输入链路。所以每次量化掉点预处理必须第一个排查。4.2 案例二校准集分布偏差特定类别精度崩掉另一个项目里整体 mAP 掉了 4 个点左右拆到逐类别后发现问题高度集中“锥桶”这一类从 0.63 掉到了 0.31其他类别基本正常。这个现象非常典型说明问题一定出在跟这一类目标相关的环节上。回看校准集500 张图片里锥桶样本最多只有 20 张而且大多数是远距离小目标特征很弱模型在量化时根本没有足够的锥桶样本去统计激活分布scale 就往其他高频类别偏了。重新构建校准集保证锥桶样本站到 10% 以上同时加入一些近距离、高清晰度的锥桶图片。重新量化后锥桶精度恢复到 0.61整体 mAP 也回来了。这个案例的教训是校准集不是你“模型训练集”的缩减版而应该是一个专门为量化统计设计的、类别和场景均衡的集合。尤其针对小目标、稀有类别一定要保证足够的占比。4.3 案例三检测头敏感层误差大混合量化解围第三个案例是最难定位的一类。整体掉点 6 个点逐层对比发现浅层和中层网络都正常但从某个检测头分支开始输出相似度从 0.99 骤降到 0.88误差从此一路放大。用工具链的统计工具查看后发现两个明确的误差放大点一个是 DFL 相关的一个 softmax 层另一个是最后输出类别得分的卷积层。针对这两个节点做混合量化回退成 FP16其他层保持 INT8。重新量化后mAP 掉点从 6 个点缩小到 1.5 个点以内板端推理帧率下降不到 3%。这个案例展示了定位敏感层再精准处理的有效性也说明混合量化是精度和性能之间的关键平衡杆。4.4 问题现象到排查项的自检速查表问题现象优先检查项目解决建议所有类别均匀掉点较多预处理链路RGB/BGR、归一化、letterbox填充值统一预处理重新校准特定类别掉点严重校准集中该类样本数量不足或分布不均补充该类真实样本重新构建校准集小目标大量漏检输入分辨率、NMS的topk数量、置信度阈值检查后处理参数考虑提高输入分辨率输出框位置明显偏移DFL解码部分是否被量化、后处理解码是否一致将DFL解码移出模型用浮点计算某一层输出相似度异常低该层算子类型、激活值分布特征定位敏感算子对该层开启混合量化量化前后置信度整体偏低校准方法选择、激活值量化范围尝试percentile或KL校准方法4.5 几个容易被忽略的经验技巧最后分享几个踩过几次坑之后总结出来的实操技巧这些细节常规文档里不会写但对排查掉点问题帮助很大。技巧一先跑小样本可视化对比。量化后不要直接跑整个测试集先挑 10 张左右有代表性的图把浮点模型和 INT8 模型的检测结果可视化并排对比。如果个别图差异明显能直接看出是哪类场景、哪类目标出问题比盲跑几千张测试集高效得多。技巧二确认预处理节点是否真的生效。地平线工具链里如果配置了输入预处理节点一定要确认转换后的模型里这个节点确实生效了。有个笨办法找个熟悉的小工具把输入一张全零图或者一张像素值已知的图跑一遍模型看第一层卷积的输入是不是你预期的预处理后的值。这个检查只花几分钟能避免很多“校准没问题、部署就掉点”的玄学问题。技巧三大分辨率对量化的容忍度更高。如果模型在 640x640 上掉点明显可以先在 960x960 或者更大分辨率下做量化评估因为信息冗余更多量化误差相对没那么致命。如果能通过加大分辨率找到问题源头再回头优化小分辨率下的量化策略定位效率会高很多。技巧四检测头输出尽量拆开观察。导出的 ONNX 如果分类分支和回归分支是拼接在一起的建议修改导出脚本把两个分支的输出拆成两路。这样在逐层对比时可以分别观察分类置信度和回归偏移的误差来源定位更精准排查方便很多。这次在 J6m 上部署 YOLOv8s 的过程让我最深的体会是INT8 掉点问题大部分人把锅甩给量化本身但实际排查下来多数问题出在量化之外。预处理的一致性、校准集的代表性和均衡性、评估口径的统一、后处理参数的匹配这些环节任何一个没对齐最后都会汇集成“量化掉点”这一个表象。所以我建议遇到问题先别急着调量化参数按本文的顺序把基线打好、链路捋清、逐层定位你会发现问题远比想象的简单。