做AI推理硬件选型这几年我背过的锅不算少。最常被问到的问题永远是“GPU还是NPU”仿佛整个推理世界就只有这两个选项。但在一个边缘视频检测项目里这两个答案都不合适GPU太吃功耗和成本NPU的算子支持又卡住了模型的脖子。折腾到最后我们选了很少被第一考虑的那个答案——FPGA。别急着觉得我在炒冷饭或者偏门。这篇文章不是理论比较是一个真实落地项目的完整复盘。我会说清楚为什么在这个项目里FPGA比GPU和NPU都合适也会把定点量化、数据通路、任务流水线这些实操步骤一项项展开最后把踩过的坑和排查思路也整理出来。如果你也在做边缘AI推理的选型或者手里正好有一个对功耗、成本和灵活性都有要求的视觉项目这篇内容应该能帮你省掉一小半试错时间。1. 项目缘起为什么GPU和NPU都不够用1.1 核心场景8路视频流的实时缺陷检测项目的背景其实很朴素某生产现场的质检环节要对8路工业相机视频流做实时检测识别传送带上产品的外观缺陷。模型选的是经典的轻量目标检测网络输入分辨率放在640x640单帧推理目标延迟控制在30毫秒以内。这听起来不算难GPU和NPU都能做到单帧30毫秒。但真正的约束在后面整个检测单元要装进一个半封闭的机壳里散热条件有限整机功耗预算只有35瓦同时因为产线会不定期换产品型号检测模型里的网络结构、锚点参数、甚至输入分辨率都需要跟着改。也就是说我需要一个“能变”的推理平台而不是一个被固定好的黑盒。我们先评估了GPU方案。单看推理性能一颗低功耗GPU确实能跑到8路并发、单帧30毫秒以内。但即便选低功耗型号整板功耗也在80瓦以上超出预算两倍多散热风扇、供电模块都得跟着加机壳尺寸直接失控。成本就更不用说了一颗工业级GPU的单价、交期和后续产能波动都是项目排期里的不稳定因素。NPU的情况刚好反过来。很多SoC里集成的NPU在功耗上非常漂亮几瓦就能跑到几百TOPS的理论算力而且专门的矩阵运算单元对卷积这类算子极其友好。但问题在于NPU的算子库是封闭的它“擅长”什么是由编译器提前定好的。我们想部署的模型用了不少非标准算子比如某个特殊的上采样方式编译器不认要么得重写网络结构要么得手工拆成基础算子去蹭。试了两个型号之后发现模型适配成本已经高到不如换个方案。1.2 选型困境的本质既要灵活又要功耗可控这个项目的需求本质是一个“既要又要”的问题既要有GPU那种“什么模型都能跑”的软件灵活性又要有NPU那种能效比优势还要在35瓦功耗墙内完成8路实时检测。当时我们内部开玩笑说这是一个“三角需求”传统硬件根本不可能同时满足。但也正是这个矛盾让我开始认真审视从来不在第一梯队考虑的那个选项FPGA。FPGA的硬件逻辑是可以用硬件描述语言或高层综合工具去“定制”的。换句话说它没有一个被固定死的指令集架构什么算子适合直接映射成硬件电路我们就把它做成一个专门的数据通路。网络结构变了重新编译烧写一下硬件跟着变。这正好命中“灵活性”这个需求而它的功耗模型又天然地贴近硬件本身没有指令解码、缓存管理这些通用计算的开销能效比和NPU同属一个量级。2. 第三个答案FPGA在AI推理里的特殊位置2.1 FPGA为什么能做到软硬兼顾很多人对FPGA的刻板印象是“用来做接口逻辑和信号处理的”跟AI推理八竿子打不着。但近几年的变化其实很大。FPGA厂商陆续推出了面向AI推理的工具链支持把常见的深度学习算子卷积、池化、归一化等编译成硬件加速单元同时保留了对非标准算子做自定义扩展的能力。这个“自定义扩展”恰恰是GPU和NPU都给不了的。拿我们遇到的特殊上采样算子来说。如果部署到NPU需要考虑怎么用其他算子凑出同样的效果这一步可能要好几天。但在FPGA上我们直接把这个算子的数据流逻辑用高层语言实现再映射成硬件模块等同于给推理引擎单独加了一个专用电路。整个适配过程两天完成而且硬件利用率非常高没有多余的数据搬运。从原理上看FPGA做推理时每个算子对应一段物理电路数据流过了这个电路就完成了计算。这没有指令取指、译码、乱序执行这些过程所以延迟模型非常确定。对这个产线场景来说确定性延迟和可控的功耗比单纯刷高帧率重要得多。2.2 与GPU/NPU的对比一张表说明白我在方案评审会上做了一张性能特征对照表基本把三个方向的区别讲清楚了。这里直接放出来可以当成选型参考维度GPUNPUFPGA软件生态成熟度高框架适配最快中算子库决定上限中低但工具链逐渐完善算子灵活性高几乎什么都能跑低非标算子很难搞高可以自定义硬件算子能效比同性能下功耗一般优秀优秀确定性与实时性一般受调度影响较好最好延迟可控开发/适配成本低中中高需要硬件思维生产成本中等规模高低中适用场景通用训练与批量推理稳定结构的端侧推理结构多变、功耗受限的嵌入式推理这张表里需要额外注意最后一行。FPGA的“适用场景”往往被低估但恰恰是我们这次选型的关键依据模型结构会变功耗上限固定部署环境又比较恶劣。这种情况下FPGA反而是成本最优解因为它一套硬件可以反复烧写适配不同模型不需要像NPU那样选定型号后再遇到模型升级就只能换芯片。2.3 一个重要前提先想清楚瓶颈在哪里选FPGA之前一定要想清楚一点你的项目瓶颈到底是算力不够、功耗太高、还是模型适配成本太大如果只是算力不够GPU是最省心的答案如果功耗敏感且模型结构非常稳定NPU是更轻的选择但如果模型结构会动而且你对单帧延迟有硬性约束FPGA才值得投入精力。我们之前有一个模拟项目X就是因为没做这个前置判断先上了NPU方案结果模型迭代两版之后算子不在库里前期的性能测试全部推倒重来。所以我在自己的团队里定了规矩选型评估第一天先列出未来一年内模型可能发生的变化点再去比硬件参数。这个习惯在这次FPGA选型里帮了大忙。3. 实操过程从算子分析到FPGA部署的完整链路3.1 第一步模型裁剪与算子清单分析部署到FPGA的第一个动作不是写代码而是把模型拆开看。我习惯用推理框架或者厂商工具先把网络结构导出来生成一个算子清单和每个算子的数据流依赖关系这是后面所有工作的基础。以我们用的目标检测模型为例网络里主要有这几类算子卷积包括标准卷积和深度可分离卷积、批归一化、激活函数ReLU、池化、上采样、以及最后的输出解码层包括边界框回归和分类。在FPGA上实现推理并不是把整个网络当成一个黑盒去跑而是把每个算子转成一个硬件加速模块再把模块按数据流顺序串联起来。这一步的关键动作是层融合也叫做算子融合。比如批归一化和激活函数在数学上是可以合并到前面卷积层里的合并之后不仅少了几次计算也减少了中间结果写入DDR再读出来的时间。我在实际项目里做了一次层融合之后整个网络的计算负载大概降了三成这个收益不花一分钱就是纯工程优化我非常推荐先做这一步。另外要特别关注深度可分离卷积这类算子。它在通用GPU上不一定比普通卷积快多少但在FPGA上如果能用硬件方式把深度卷积和逐点卷积拆成两条并行流水线吞吐量提升会非常明显。我们最终在FPGA实现里把这条通路单独优化了一轮效果比只做层融合又高了两成左右。3.2 第二步INT8定点量化与精度校准GPU和NPU的部署链路里量化通常是把浮点模型转成INT8或INT4格式FPGA也一样。但FPGA上做量化有一个特点你可以自主选择每个算子的定点位宽而不是被迫用统一精度。这意味着我可以为模型里的“关键层”保留多一点比特位而为不敏感的层削减位宽最终在精度和资源占用之间找到更细的平衡点。这一部分是整个部署流程中最容易被低估的环节。很多人以为量化就是把浮点参数乘以一个缩放因子存起来但实际操作时一个很小的量化策略差异就可能把mAP拉到不可用的水平。我们用的方法是先准备一个校准数据集这个数据集不需要很大几百张有代表性的图片就够了。把这些图片喂给浮点模型统计每个激活值的分布范围然后据此算出每一层的量化参数。重点是要看激活值里有没有特别大的离群点如果有直接用全局缩放会把大部分有效数值压得很低精度损失会特别明显必须针对离群的层做单独优化。初步量化之后的实测精度和浮点模型相比掉了约2个百分点这在缺陷检测里不太能接受。为了解决这个问题我们做了两件事第一把输出层之前的两个卷积层保留为更高精度定点格式第二对激活值分布特别不规律的层量化时不用对称量化改用非对称量化。这两项调整做完精度差距缩小到0.5个百分点以内缺陷漏检率回到了可接受范围计算资源只多花了不到一成。这里补充一个非常实用的经验不要只看总体的accuracy指标一定要单独观察单类别的检测准确率。我们的缺陷类型里有一种细小划痕它在量化前就偏低量化后直接掉了一半。单独看总指标根本发现不了这个问题只有按类别拆解之后才能精准定位。这个习惯后来也救过另一个项目的场建议你们也加上。3.3 第三步数据通路设计与DDR带宽估算模型层面的优化做完接下来是硬件工程的核心数据通路设计。FPGA上的算力其实经常不是瓶颈反而数据搬运也就是DDR带宽才是最容易卡住吞吐量的地方。我们做了一个很简单的计算。假设输入视频流是8路每路分辨率是1080p经过网络前处理裁剪成640x640从相机到FPGA侧的内存系统每一帧原始数据量并不大但推理过程中每个中间特征图都要写进DDR或者片上BRAM这个搬运量才是大头。最开始的实现里我们把上采样产生的中间特征图直接写到DDR然后下一层再读回来。结果测量带宽后发现整套流程的片外访存量非常高推理延迟一度超过40毫秒完全达不到目标。排查之后发现上采样产生的数据量虽然不大但写入和读出的突发长度太短DDR控制器的效率被拉得很低实际有效带宽只有理论值的一半左右。优化方法有两个方向。第一是尽可能把整个子网都放在片上RAM里完成不碰DDR。我们把模型里的前几层网络做了内存子块划分让一个帧的推理在一个连续的片上区域里完成这一步直接减掉了大量的带宽消耗。第二是针对必须搬到DDR的数据把多个小块的读写组合成一次大的突发传输让DDR控制器的每笔访问都能跑满。两个方向的优化叠加之后推理延迟从40毫秒降到了24毫秒左右明显超过目标。3.4 第四步N路并行与流水线设计单帧推理性能没问题之后还要解决8路视频流的并发问题。最简单的方案是每一路分配一个完整的推理引擎但这在FPGA上很不现实逻辑资源很快就不够用了。我们用的方案是“时分复用加流水线拼接”。具体来说8路视频流的数据按照固定的时间片轮转进入同一个推理引擎但推理引擎内部的每一层卷积、池化、上采样都被设计成独立流水线阶段。当第1路数据在跑第3层的时候第2路数据可以同时跑第2层第1路的前一帧结果也正在做后处理。这样单个时钟周期内硬件里的每一个阶段都在忙不会出现“一整块资源等待另一块资源”的空闲状态。这种流水线设计在FPGA上实现有一定门槛因为它要求每个算子模块都必须有独立的输入输出缓冲而且各阶段的处理时间要大致匹配。如果一个卷积层要跑10微秒上采样只要2微秒上采样模块就会有大量空等时间。我们通过调整每一路输入的间隔也就是流水线节拍先把各阶段延迟测出来再让调度器按最慢阶段做节拍对齐总算把8路总吞吐跑到了目标水平单帧延迟稳定在24到28毫秒之间。3.5 部署与上位机联调别忽略CPU端的配合FPGA推理引擎本身做完了整个系统还差最后一步与CPU端控制程序的数据交互。我们在方案里没有让FPGA单独完成全部解析逻辑而是把模型输出的中间结果通过底层接口直接搬回主控CPU用常规的目标解码逻辑做边界框后处理。这个设计是因为FPGA更适合规整而重复的计算而NMS这类动态逻辑在CPU上更成熟也更方便后续调整筛选阈值。实际联调时遇到一个不大不小的坑FPGA侧输出数据的排列原来是HWC格式而CPU端推理框架默认的是CHW格式两个格式不统一导致前几次后处理结果全乱。最后我们在FPGA端的输出逻辑里增加了一个数据重排模块格式对齐之后问题立刻消失。这个细节特别提醒大家注意很多联调问题根本不在算法而是数据结构约定没提前对齐。4. 常见问题与排查技巧实录4.1 问题一量化后精度大幅下降但找不到原因现象FPGA部署完成后同一张测试图浮点模型的置信度是0.82量化模型只有0.51差距太大无法上线。排查过程第一步先确认是不是量化校准集选得不好换了一个覆盖更多样本的校准集置信度提升到0.61仍然不够。第二步检查每个层的数据分布发现网络倒数第二层的激活值存在一个异常大的离群点远远偏离主体分布。全局缩放因子被这个离群点拉大导致有效数值全被压缩。第三步采用混合精度策略对这一层单独用更高位宽的定点表示置信度恢复到了0.75左右。最终结论量化精度问题90%都是激活值分布没有“照顾”好。不要迷信全局校准一定要敏感地处理离群点该区别对待就区别对待。4.2 问题二推理吞吐量上不去但FPGA逻辑资源还有大量余量现象单帧延迟已经达标但8路并发时总吞吐只有5路水平FPGA片上DSP和LUT的占用率却不高。排查过程最开始怀疑是调度器的问题但检查之后发现调度逻辑没有大问题。用硬件计数器分别统计卷积模块、上采样模块和DDR控制器的忙碌时间发现上采样模块的空闲率非常高数据总在等DDR返回。仔细看DDR访问模式发现输入数据块太小每次只读了一个很小的二维子块无法跑满DDR突发长度。最后通过在模块输入端增加一个预取缓冲把一个运算窗口所需的数据提前一次性搬入片上缓存DDR访问的颗粒度变大了带宽利用率显著上升。结论在FPGA性能优化里DDR带宽的利用率比算力更值得盯紧。只要DDR的突发访问没有跑到接近峰值都是物理设计层面的浪费不是资源不够。4.3 问题三整个工程编译一次要两个小时开发效率极低现象版本迭代频繁每次改一点点逻辑重新走一遍综合和布局布线就要接近两个小时多人协作时效率非常低。排查与处理第一件事不是优化编译速度而是把FPGA工程的构建流程做模块化拆分。我们按网络阶段分成多个IP核每个模块独立编译主工程只负责组装。修改某一模块时只重新综合该模块然后增量生成最终镜像单次迭代时间从两小时缩短到半小时。另外把版本清单纳入代码化管理每次编译前自动记录关键参数和版本号防止多人协作时把旧配置烧到新的硬件上。结论FPGA开发效率不能只看单次编译时间而是要在工程结构上做好隔离这个道理和大型软件工程里模块化设计完全一样。4.4 一些让人印象深刻的排错技巧这里的经验可能比较“土”但真的有用用FPGA片上的逻辑分析仪抓内部信号不要只靠打印日志。有一次推理结果偶尔错误跑CPU上根本看不出规律后来在调试接口里嵌入了一个计数器和状态快照抓到了因为某个使能信号时序差了一拍导致的偶发故障。对量化后的模型做一次“二次校准”。第一次量化后在FPGA上跑采集到的真实视频统计每一层的实际输出极值用这些真实数据重新算量化参数这么做可以把精度再挽回不少。在所有数据通路里加周期计数器不同模块的开始与结束事件各打一个唯一标志联调时可以快速定位是哪一段数据流阻塞了。这套打点技术排查起问题来非常高效强烈推荐。5. 最终成果与选型之外的个人体会最终这套FPGA方案的成果可以量化成三组数字整机功耗实测33瓦在35瓦预算内8路并发时单帧延迟平均26毫秒满足30毫秒以内的目标单位数量的检测精度和浮点模型相比差距控制在了1个百分点以内。更重要的一点是产线后来真的换了两次产品规格模型结构跟着改了两版我们只是重新做了量化和编译烧写没有动任何硬件。我自己的体会是做推理选型没有“永远正确”的答案只有“当前场景下最合适”的答案。单纯的算力对比只是面试题里的答案真实的工程决策永远要把功耗、成本、开发周期、模型演进风险全部放进来综合考量。如果你现在正在评估GPU和NPU并且觉得两边都差口气建议认真看一下FPGA这条路线它不一定是最终答案但大概率能拓展你对“硬件选型”这个问题的边界。最后分享一个小技巧无论最后选了哪个方案一定要在硬件定型之前先做一套“全流程模拟”测试把模型量化后的计算数据、中间特征图的数值范围、DDR带宽的仿真曲线全都提前跑一遍。我在这个项目里最大的一次调整从CHW改成HWC就是靠这个模拟提前发现的而不是等到硬件做好之后才面对返工的代价。这个习惯比任何单点的优化技巧都更值钱。