2026年FPGA工程师做边缘AI部署，为什么模型量化成INT8后精度掉得厉害，是校准集问题还是硬件截断位宽没对齐？

先说结论：你这情况大概率是校准集和硬件位宽两件事叠在一起了，别急着二选一。YOLOv5s 掉点、小目标全丢，这个现象本身就很有指向性——小目标在特征图上占的像素少，激活值分布本来就偏，一旦量化 scale 被大目标的激活值主导，小目标的响应很容易被压到量化台阶以下，直接归零。所以你用训练集随机抽 500 张，如果里面小目标样本占比本来就低，那校准出来的统计量天然就偏向大目标，这跟硬件截断是两回事，但会互相放大。

排查顺序我建议先软后硬，成本低。第一步，把校准集换成从验证集里按类别和小目标数量分层抽的样本，一般 200 到 500 张就够，重点看分布覆盖而不是数量。重跑量化看 mAP 有没有回升，回升明显就是校准集问题。第二步，如果还是掉，就上逐层比对：Vitis AI 一般能导出每层的量化前后输出，或者用浮点仿真和定点仿真对同一张图逐层跑，看从哪一层开始误差突然变大，通常问题层就是掉点的源头。

硬件侧要提醒一句：DSP48E2 本身是定点的，你 RTL 里的累加器位宽和移位对齐如果和量化脚本给的 scale 不一致，那属于实现 bug，不是精度调优问题。常见坑是累加器位宽不够导致中间结果溢出饱和，或者右移位数写错，这种错在仿真里就能看出来，不用等上板。所以先确认脚本产出的量化参数和 RTL 实际用的参数是一套，再谈精度。

你现在的量化流程是 Vitis AI 的 PTQ 还是 QAT？这个决定了后面排查路径完全不一样。

这个问题我想从因果链的角度捋一遍，因为很多人一上来就纠结「是校准集还是位宽」，其实这两个不是并列选项，而是先后顺序的问题。

量化的本质是用有限的整数台阶去近似连续的浮点分布。校准集的作用是估计每一层激活值的动态范围，也就是 min/max 或者更精细的直方图统计。如果校准集不能代表真实推理时的输入分布，那 scale 和 zero point 就是错的，后面硬件再完美对齐也没用。YOLOv5s 这种检测网络尤其敏感，因为它的输出不是单一分类，而是多尺度特征图上的回归加分类，小目标的响应幅度本来就小，一旦 scale 被大目标拉大，小目标的量化分辨率就不够了，表现出来就是小目标全丢。你用训练集随机抽 500 张，问题在于随机不等于有代表性，训练集里小目标样本可能本来就少，或者场景单一，统计出来的分布偏离验证集。

所以第一步一定是验证校准集。做法不复杂：从验证集里按目标尺寸分层抽样，保证小中大目标都有覆盖，重跑 PTQ，对比 mAP。如果回升明显，那校准集就是主因。

第二步才是硬件对齐。这里有个容易被忽略的点：量化脚本算出来的 scale 是浮点数，硬件里要用定点乘加加移位来实现，累加器位宽必须能容纳最坏情况下的累加和，否则会溢出饱和。DSP48E2 的乘法器本身位宽有限，累加通常在 LUT 或额外逻辑里做，如果位宽不够或者移位位数和 scale 不匹配，误差会系统性累积，而且这种误差往往不是均匀的，某些层会特别严重。

判断方法：用逐层比对工具，把浮点模型和定点模型在每一层的输出做差，看误差从哪一层开始爆炸。如果误差是均匀小幅增长，多半是量化本身的分辨率损失；如果某一层突然跳变，那要么是校准集在该层统计异常，要么是硬件实现有 bug。

工程上的取舍是：PTQ 调不动就上 QAT，QAT 能显著缓解小目标掉点，但训练成本高；硬件位宽对齐属于必须做对的基础工作，做不对后面全是白费。

你目前是只跑了 PTQ 还是已经试过 QAT？这个信息能帮判断该往哪个方向使劲。

先别急着把锅甩给 DSP48E2，Zynq 上的位宽截断问题通常不是第一嫌疑人。你描述的现象——整体掉点加小目标几乎全丢——非常像校准分布偏了，而不是硬件把数值算错了。原因很直白：小目标在特征图上激活值本来就小，如果校准集里大目标、背景样本占多数，那 scale 会被大动态范围拉大，小目标那点响应直接落进量化台阶的缝里，归零了。硬件位宽对齐不对齐，是在你已经有一个正确的 scale 之后才谈得上对齐的事。

给你一个成本很低的验证顺序。第一步，把校准集换成从验证集里分层抽的样本，按目标尺寸和类别都覆盖一下，数量两百到五百就够，重点看分布而不是看张数。这一步如果 mAP 明显回升，问题基本就锁定在校准集。第二步，如果还掉，再用 Vitis AI 的逐层比对功能，把每层量化前后的输出拉出来看，定位是哪一层开始崩的。一般掉得最狠的那层就是问题层，再回头查那层的 scale 和硬件移位是不是一致。

硬件侧确实有个常见坑：累加器位宽和移位方向如果和量化 scale 不匹配，会出现整体偏移或者饱和，但那种情况往往是大面积异常，而不是只丢小目标。所以先软后硬，别一上来就翻 RTL，容易白费功夫。顺带说一句，YOLOv5s 的检测头对量化本来就敏感，真到瓶颈了可以考虑对首尾层保留高精度，别硬扛全 INT8。你现在的校准集是从训练集随机抽的，验证集里小目标的占比大概是多少？

我先说一个容易被忽略的方向：你这个问题里藏着一个隐含假设，就是「量化掉点 = 量化算法出问题」。但在 Zynq 上跑 Vitis AI，掉点其实有相当一部分来自前后处理没有跟着量化一起对齐，尤其是 YOLO 这种带 anchor 解码、NMS、以及多尺度输出的网络。小目标几乎全丢，有时候不是 backbone 的量化误差，而是输出层那几个负责小尺度特征的 head 在量化后，sigmoid 和 exp 这类非线性函数的输入范围变了，导致置信度被压得很低，NMS 阶段直接被过滤掉。

所以排查顺序我建议这样：先确认校准集的分布，你随机抽 500 张训练集，如果小目标本来就稀疏，那统计出来的激活范围会被大目标和背景主导，scale 偏大，小目标的响应被量化台阶吃掉，这个和前面说的一致。但更值得做的一步是，把量化模型和浮点模型在输出端的原始张量（还没做解码的那种）逐通道对比一下，看是分类分支掉的还是回归分支掉的，这一步能帮你判断到底是量化本身还是解码环节。

至于 DSP48E2 的截断：一般来说 DPU 内部的乘加位宽是设计时固定的，Vitis AI 的量化流程会去匹配这个位宽，正常情况下不需要你手动去 RTL 里改移位。真正容易出问题的是你自己写的后处理模块，如果你在 PL 侧做 NMS 或者坐标缩放，用的定点位宽和量化模型输出的 scale 不一致，那掉点就发生在你手里而不是工具链里。这种情况我见过不少，表现就是浮点仿真一切正常，上板之后小框全没了。

低成本验证：先把后处理整个搬回 PS 用浮点做，只让 DPU 出原始输出，看 mAP 能不能回来。能回来，问题就在你的定点后处理；回不来，再往量化脚本和校准集上找。你现在后处理是在 PL 里定点做的还是 PS 里浮点做的？这个信息决定了下一步该往哪查。