FPGA做边缘AI推理，MobileNet和YOLOv5s在LUT和DSP资源受限的开发板上该怎么选模型？

先说结论：EG4S20这个量级，MobileNetV1/V2的完整版都未必舒服，YOLOv5s基本可以直接放弃，除非你接受极小输入分辨率加大量裁剪。原因不在参数量，而在访存和算子形状。深度可分离卷积参数量是小，但它是逐通道卷积加1×1卷积两步，逐通道卷积的输入通道数等于输出通道数，在FPGA上意味着你要么做很多个小规模的并行MAC阵列，DSP利用率极低，要么把通道串行化，那样延迟又上去了。29个DSP48，按INT8算一个DSP顶多拆成两三个乘法器，理论峰值也就百来个MAC每周期，这个算力跑YOLOv5s哪怕是320×320输入都很勉强。

所以路径上我建议这样排：第一步先把目标定清楚，你是要检测还是只要分类。如果只是分类，MobileNetV1的0.25或0.5宽度版本，输入128×128或160×160，INT8量化后裁剪到只保留前若干层，这是能落地的。第二步量化，优先用PTQ而不是QAT，因为QAT在FPGA工具链里支持往往不完整，安路的量化工具链成熟度一般，先跑通再说。INT8对MobileNet这类网络，分类精度掉1到3个点很常见，逐通道卷积那层对量化特别敏感，通常要把第一个和最后一个卷积层保留成INT16或者做per-channel量化。

如果一定要检测，退而求其次用Tiny YOLO或者自己剪一个backbone，把YOLOv5s的neck和head砍掉，只保留浅层特征加一个轻量head，输入压到160×160以内。别指望精度，能跑起来、帧率能看就算成功。

还有个容易被忽略的点：这块板子的片上BRAM和外部存储带宽。深度可分离卷积虽然计算少，但中间特征图反复读写，带宽吃紧时DSP反而在等数据。做之前先算一下每层特征图大小和总访存量，比算MAC数更能预测能不能跑。

你现在的目标是分类还是检测，输入分辨率大概想定多少？这两个定了，模型选择范围会窄很多。

我按工程取舍的角度说一条主线：先看你的板子到底卡在哪，是算力还是带宽还是片上存储。EG4S20的20K LUT其实不算特别小，但29个DSP是真紧，这决定了你的瓶颈大概率是乘加吞吐，而不是逻辑资源。

那么选模型的判断维度就三个，按优先级排：第一，算子的DSP友好度。标准卷积虽然MAC多，但形状规整，容易映射成规则的MAC阵列，DSP利用率高。深度可分离卷积MAC少，但逐通道卷积的通道并行度低，DSP会大量闲置。所以在DSP极少的板子上，一个MAC总量中等但形状规整的模型，可能比MAC更少但形状零碎的模型跑得更快。

第二，量化误差的传播路径。MobileNet的逐通道卷积后面接BN和ReLU，PTQ下这一层误差会累积，通常需要per-channel量化或者把这层提到INT16。YOLOv5s的检测头有sigmoid和坐标回归，量化后框的偏移更明显，对小目标尤其不友好。

第三，你的验收标准是什么。如果只是课堂演示或者毕设，跑通一个裁剪版MobileNet做分类完全够。如果是要真实检测任务，建议换思路，用传统CV做候选区域，再用一个小CNN做分类，FPGA上这种混合方案往往比端到端检测网络更现实。

落地步骤：先拿PYNQ或者PC端仿真验证量化精度，确认INT8掉点可接受，再上板。别一上来就写RTL。你手上有没有已经跑通的量化工具链，还是准备从零搭？

先说个容易被忽略的点：你真正要选的不是「MobileNet 还是 YOLOv5s」，而是「分类任务还是检测任务」。这两条路的资源需求根本不在一个量级上，把它们放一起比参数量其实是个陷阱。

如果是分类，MobileNetV1 的 0.25 或 0.5 宽度版是能落地的，输入压到 96×96 或 128×128。原因很直白：分类网络最后只有一个全局池化加一层全连接，整条流水线的并行度可以做得比较规整，你不需要为了输出坐标去做一堆后处理。EG4S20 的 20K LUT 装一个 0.25 宽度的前端加几层 1×1 卷积是有希望的，29 个 DSP 主要用在 1×1 上，逐通道卷积那部分甚至可以用 LUT 拼乘法器顶一顶。

如果是检测，YOLOv5s 直接放弃吧。不是因为参数量，而是它的检测头、上采样、concat、以及 NMS 后处理，这些在 FPGA 上要么占大量 LUT 做地址生成和缓存，要么得丢给软核跑，软核一跑实时性就没了。你就算把 backbone 塞进去，head 也会把你卡死。

那深度可分离卷积到底怎么处理？我的建议是：不要把逐通道卷积当成「省算力」的层，而要把它当成「省权重存储」的层。在 DSP 极少的板子上，逐通道卷积的并行度低，DSP 会大量闲置，所以更实际的做法是把逐通道卷积用 LUT 实现成小的乘法累加单元，把宝贵的 29 个 DSP 全部留给 1×1 卷积和全连接。这是资源分配上的取舍，不是模型层面的取舍。

量化方面，INT8 对 MobileNet 这类网络，PTQ 掉点通常比较明显，尤其逐通道卷积后面的 BN 和 ReLU 会把误差放大。常见做法是对逐通道卷积层做 per-channel 量化，或者干脆把这层保留成 INT16。分类任务上，INT8 per-channel 一般能保住原始浮点精度的 95% 以上，但检测任务我建议你别指望 PTQ，直接上 QAT，否则 mAP 掉得你怀疑人生。

最后给个最小可行路径：先拿 MobileNetV1 0.25 宽度、96×96 输入，在 PC 上做 INT8 PTQ 看掉点，掉点可接受再上板；上板先只跑前几层验证数据通路，别一上来就全网络综合。你现在的工具链是安路的 TD 还是第三方综合？这个决定了后面量化脚本怎么写。

先说一个容易被忽略的点：EG4S20这种板子，真正决定你能不能跑起来的往往不是LUT和DSP的总数，而是DSP的排布方式和你打算让它们每周期干几次活。29个DSP48，如果按INT8拆成两个8位乘法，理论上限也就58个MAC每周期，这是硬天花板，任何模型选择都要先过这道数学关。

把这道关算清楚再谈模型。假设你目标30fps，那就是每帧只有约30万个MAC周期的预算（按50MHz算）。MobileNetV1的0.25宽度、128×128输入，乘加量大概在2000万到3000万次量级，即使只算一次乘加等于一个周期，也远超预算，所以现实里你必须接受低帧率，或者把输入再降到96×96甚至64×64。YOLOv5s不管怎么裁，光主干加检测头的MAC量就是MobileNet的十倍以上，29个DSP基本没戏，除非你把它当研究项目而不是产品。

所以取舍的主线其实只有一条：你是要「能跑起来看到结果」，还是要「跑得够快能实用」。前者选MobileNetV1的0.25或0.35宽度版本，输入压到96×96，做INT8，先跑通。后者这个板子本身就不合适，应该换带更多DSP的器件，而不是在模型上继续抠。

量化方面，深度可分离卷积的逐通道卷积是最容易掉精度的地方，原因是每个通道只有一组权重，量化尺度一旦偏了没有别的通道帮它平均。常见做法是对逐通道卷积层用per-channel量化，BN融合进卷积后再量化，激活用per-tensor。这样INT8通常能把分类精度损失控制在1到2个百分点以内，但前提是你的校准集要覆盖真实输入分布，别拿几十张图随便凑。如果掉得厉害，把逐通道卷积那一层单独提到INT16，DSP消耗翻倍但精度能救回来不少。

还有一个实操建议：别一上来就写RTL。先用安路的工具链或者找个开源的NPU软核，把MobileNet的某个版本走一遍综合，看真实资源报告。综合报告会告诉你DSP到底够不够、BRAM会不会爆，这比纸上算MAC靠谱得多。

你现在的输入分辨率和目标帧率大概定在什么范围？这个直接决定模型还能不能裁。