接手第一个工业AI项目时我以为最难的是算法精度。过去做互联网AI项目数据在服务器上躺着模型训完直接上GPU跑上线也就是发个版本的事。真正踏进工厂做边缘部署才发现训练出90%准确率的模型只是万里长征第一步——从训练环境到车间工控机中间隔着的不是一条命令而是一整套工程化鸿沟。这篇内容不聊算法怎么调参就聊我从零部署一套工业视觉检测系统时踩过的那些坑希望能给准备入局的朋友省下几个月的弯路。1. 需求评估阶段的“我以为我知道要做什么”1.1 客户说的“简单”往往是最贵的坑项目启动会上客户指着产线说“就做个外观缺陷检测产品种类不多环境也不复杂”。等我带着设备进场才发现所谓“不多”是七种颜色、三种材质、两种包装版本加五种不同朝向所谓“不复杂”是车间里粉尘、油雾、震动、忽明忽暗的灯光一个不少。这是工业AI项目第一坑需求描述和生产现场的差距永远是评估阶段低估最严重的地方。我的建议是需求阶段不要坐在会议室里听PPT直接去产线上站一个小时。看什么看实际来料波动有多大看节拍要求是多少看过往的不良品样本长什么样看操作工目前靠什么判断缺陷。当时我们拿着相机测试样图回办公室设计算法却忘了问一句“来料角度是否固定”结果算法在实验室测试集上99%准确率到了现场因为来料倾斜角超过15度直接崩到90%以下。1.2 算力评估不能只看“论文里的FLOPs”选边缘计算盒子的时候我第一版评估方案把模型参数量和FLOPs算得很漂亮按理论推算用一款Teraflops级的设备就够了。但理论算力是理想峰值真实的端到端推理延迟包括图像预处理比如缩放、归一化、色彩空间转换、模型前向推理、后处理比如NMS、阈值筛选、坐标还原、加上相机触发和通信的往返时间。实测下来预处理后处理占了整体延迟的30%以上。算力评估正确的做法是倒推先看产线节拍比如每分钟检测60件意味着从触发到输出结果不能超过1秒再在这个1秒里给预处理、通信各留出200ms给推理留600ms然后在目标设备上跑真实模型做基准测试留出40%以上的余量因为后续还要加功能、还要应付更难的样本。我见过太多项目在选型时抠算力成本结果上线半年后模型一升级设备直接跑不动只能全部返工换硬件。2. 数据侧的真实代价采集、清洗、打标没有捷径2.1 工业数据的分布和公开数据集完全是两码事做视觉检测的AI工程师通常都很熟悉公开数据集类别均衡、背景干净、标注规范。到了工业现场数据的特点是极度不均衡——好品占了98%缺陷品每一种都稀稀拉拉而且缺陷形态五花八门一个“划伤”就能分出货真价实的深划痕、细微纹理、反光造成的伪影、还有真的脏污点。训练时你会遇到一个尴尬局面模型在一千张好品上加一百张划伤样本很快就学会了“只要没划伤就是好品”精确率虚高但遇到没见过的缺陷类型就完全瞎了。我的建议是前两周不要急着上模型先积累数据。把过往三个月的返修记录、巡检图片、甚至操作工手机拍的疑似缺陷照片全部翻出来和现场采集的正样本混合在一起做初步分类。每个类别的样本哪怕只有三五十张也远比只有“看起来很标准的样本”强。数据清洗上要特别小心一种坑数据泄露。工业相机拍摄时有固定的视野和光源但你可能在不同时间段采集环境光变了或者某批次产品表面工艺变了导致特征分布漂移。如果训练集合测试集采集时间不重叠模型可能学的是“早上拍的都判正常”上线就是事故。2.2 打标不是“找个人画框”那么简单很多团队把打标外包给标注公司结果拿回来的标注质量惨不忍睹。工业缺陷标注的特殊性在于标的不只是“位置和类别”还要区分真实缺陷和纹理背景。比如铸件表面的斑点和金属本身的纹理差异在灰度和光照变化下非常接近外包标注员经常出现前后标准不一致。我前后踩过两次打标的坑总结出的解决方案是写一本不超过三页的标注规范手册里面放上每一种缺陷的典型图、难例图、边界案例“这种算不算缺陷”然后让标注员先标50张我们用脚本统计标注框与图像边缘的关系、框稳定性发现离谱的立即打回。最后所有数据过三遍自动清洗脚本剔除异常坐标、人工抽查10%的图、算法工程师最后终审一遍困难样本。2.3 数据增强不是万能的要贴合现场做边缘部署很多朋友习惯做随机翻转、随机裁剪、色彩抖动来扩充数据。这在通用目标检测里有效但在工业场景里要小心工业相机的机位固定产品朝向固定光源方向基本不变。你用随机旋转90度增强出来的数据在现场根本不可能出现反而可能让模型学到错误的姿态容忍度降低在真实分布上的表现。我自己的经验是增强策略要“模拟真实现场的光照变化和轻微震动模糊”比如增加小角度旋转正负5度以内、轻微缩放、增加噪声、模拟镜头灰尘造成的暗角而不是大尺度翻转。另外工业现场特有的变化其实应该通过硬件去约束——把光源、遮光罩、固定工装做好远比让模型去适应各种乱七八糟的光照靠谱得多这一点到后面现场部署部分还会展开。3. 训练与部署之间的鸿沟剪枝、量化、格式转换3.1 PyTorch模型跑不到边缘盒子上每一个算子都是一道关卡很多人第一次做边缘部署时的流程是PyTorch训练→导出ONNX→转TensorRT/OpenVINO/RKNN→上设备推理。看上去简单实际每一步都在掉点。先说ONNX导出。PyTorch模型里只要用了自定义算子比如某些检测头里的特殊实现导出时要么报错要么给你悄悄替换成一个错误实现。我当时用的检测模型里有一个基于DCN可变形卷积的算子导出ONNX后推理结果在几个样本上和PyTorch结果差了0.3%排查了一整天才发现算子没有被正确支持。我的经验是从模型设计阶段就要考虑部署约束。如果明确目标环境是边缘设备尽量别用过于花哨的自定义层或者预留一个等价的部署版本代码路径。另外一个常见问题是版本对齐——训练环境的PyTorch版本、ONNX opset版本、推理引擎版本这三者必须严格匹配一个不对转换出来的模型在推理引擎上就可能报出不存在的shape错误。3.2 量化的坑你以为你量化的是模型其实你量化的是灾难边缘设备通常需要INT8量化来提升推理速度、降低内存占用。第一次量化之后我的模型精度从96%掉到了88%这在质检场景里直接意味着大量误判完全不可用。后来排查发现问题出在校准数据集上。TensorRT/RKNN等工具做INT8量化时需要一组校准图片统计每个激活层的数值范围。我用的是训练集里随机选的500张图但训练集里好品占绝大多数导致激活值分布统计出来严重偏向正常样本的分布对缺陷样本的细小特征几乎采用不了合理的量化尺度。正确的做法是校准集必须覆盖每一类缺陷样本和边界样本让量化统计阶段就能“看到”最需要保留的特征。我重新构建了一套平衡校准集每种类别都放进去包括难例量化后的精度恢复到94.5%左右。另外一个更隐蔽的坑是逐层量化敏感性不一致——某些层对量化极度敏感一旦转INT8精度骤降。现在主流的推理引擎已经支持敏感层回退FP16我建议无论用哪个框架都认真跑一下逐层敏感度分析把对量化敏感的那几层保留到浮点精度效果非常显著。3.3 别忽略预处理的一致性这是很多教程里不写、但是现场最容易出问题的点。训练阶段图片读进来是BGR还是RGB归一化用的是mean/std还是直接除以255缩放用双线性还是最近邻边缘推理部署时这些都要和训练阶段严格一致差一个像素值、差一个通道顺序都会导致精度明显下降。更麻烦的是不同推理引擎对图像布局还有自己的要求比如有些NPU要求NHWC格式有些要求输入尺寸必须对齐到16的倍数。我的建议是把预处理逻辑写成一份精确的配置文档训练和部署各维护一套镜像版本用一个测试脚本对同一张图在训练框架和推理引擎上分别跑对比输出张量的差异允许的误差原则上不超过1e-4。4. 边缘硬件选型算力不是唯一标准4.1 “能跑模型”和“跑得久”是两码事第一轮硬件选型我基本只看了算力TOPS和内存大小。实际拿到设备在产线上长期运行后发现散热和稳定性才是边缘硬件的分水岭。工业现场夏天车间温度40度是常态边缘盒子内置风扇一旦积灰堵塞设备就会过热降频推理延迟从70ms飙到300ms产线直接报警。后来我们采购的设备都要求无风扇被动散热加上宽温设计运行环境尽量做好防尘通风这一条目前看来比任何一项性能指标都重要。另外还要关注内存带宽。很多边缘AI芯片标称算力很高但内存带宽不足跑起大一点的模型时瓶颈根本不在算力而在数据搬运。我后来对比了两款标称算力几乎一样的设备实际跑YOLO系列模型内存带宽高的那一款端到端延迟更低30%这就是真实差距。4.2 算子支持矩阵买之前先画一张表不同边缘推理芯片对网络算子的支持差别极大。有的芯片对卷积和全连接优化得飞起但遇到近年流行的注意力机制、上采样方式就踩坑。所以选型时必须做一件事把模型的每一类算子列出来挨个对照芯片的算子支持表。比如我用的模型里有一个上采样是近邻插值拼接的结构在芯片A上支持得很好在芯片B上就报“Unsupported layer”。选型阶段还要给模型升级留余量。当时我们只跑一个单模型后来客户要求加一个OCR识别模块这就涉及到芯片是否支持文字检测相关的算子以及内存是否还够。所以在硬件选型时宁可留宽裕一点比如算力比当前需求高1.5倍、内存比当前需求高一倍这笔投资很快就能在后续迭代中赚回来。4.3 网络通信的坑不要低估车间网络的“惨烈”你的边缘设备和服务器在同一个局域网看似简单实则是另一个隐藏坑源。车间网络经常有大量广播包、电压不稳、交换机老化还有跨VLAN隔离问题。我们第一次部署时设备离线检测结果需要上传服务器结果经常出现上传超时、断线重传整体延迟大得离谱。方案上我建议业务数据走在本地云端只做汇总关键控制指令走独立信道。如果必须实时上传可以先在边缘设备上做本地缓存网络恢复后批量补传。总之永远不要把网络链路当成可靠基础要在软件层面做好断网容错。5. 跑通Demo只是开始现场部署中的物理劫难5.1 光源是灵魂硬件不配合一切白搭一个让我印象深刻的坑是实验室模拟光源效果极好到现场一装发现相机对着的是产线上振动的工件——图像每一帧边缘都在抖检测精度直接大幅下降。工业视觉AI项目光源和机械固定的重要性绝不亚于算法。拍照时如果产品位置、角度、姿态不稳定你再牛的模型也扛不住。后来我们给工件加了V型定位槽把相机曝光时间缩短以减少运动模糊再用一个漫射光源消除金属表面的反光热点检测准确率才恢复到实验室水平。建议所有准备做工业视觉的朋友预算和时间分配上不要只盯着模型和算力光源、镜头、支架、遮光罩占到整个系统成本的四分之一甚至三分之一都毫不夸张。5.2 Docker部署的执念与现实我习惯用Docker打包推理服务在服务器上一切优雅。到了现场工控机有两个问题立刻冒出来一是很多工厂环境没有外网没法直接拉取镜像必须提前在联网环境导出镜像tar包再上传而且基础镜像最好精简二是工控机的资源本来就有限Docker日志如果一直增长会把磁盘塞满容器崩溃恢复也是个问题。我的部署经验是在工控机上把Docker容器设为开机自启同时给容器加上--restartalways策略。还要注意容器时间漂移问题容器内默认的时间可能和宿主机不同步日志里时间错乱排查问题会让你怀疑人生。建议在docker compose里设置TZAsia/Shanghai并挂载宿主机的/etc/localtime。此外日志一定要做轮转比如设置max-size10m防止个别工控机重启后磁盘满爆。5.3 相机触发和节拍对齐毫秒级延迟都会造成灾难工业产线对时间极其敏感。我们一开始用轮询方式让边缘设备主动取图结果每次间隔一抖就漏检或者重复检测。后来改成硬件硬触发——相机接收到传感器的信号才拍照边缘盒子被动接收图像进行检测再将结果通过IO或协议回传。这种方式虽然部署复杂一点但实测下来稳定性好太多。在延迟分配上还需要仔细核算相机曝光和传输时间、预处理耗时、模型推理耗时、结果输出耗时每一项都要在节拍限制内完成。我当时做了个简单的延迟拆解表优化后从“端到端850ms”降到“380ms”没有改一行模型代码纯粹是调整了图像预处理策略和传输方式。6. 上线之后才算真正开始运维与模型迭代6.1 监控不只是看“服务有没有挂”模型部署上线只是起点更重要的在于持续的监控和迭代。很多团队把精力放在开发忽略了部署后的监控告警和模型效果评估。我的做法是给边缘设备都加上指标采集推理延迟、GPU/NPU使用率、内存占用、CPU占用、设备温度、检测通过率、各类缺陷的检出比例。这些指标汇总到一套轻量级监控面板上设置告警规则——比如设备连续10分钟温度超过75度或某类缺陷的检出率低于历史基线的85%时自动通知。上线后第一个坑是模型漂移。生产过程中产品工艺可能调整原材料批次更换光源衰减这些都会让真实数据分布慢慢偏离训练集。我习惯每周跑一次回测用过去一周新采样并且有标签的样本重新评测模型如果准确率相对基线下降超过2%就触发重新训练流程。6.2 远程模型更新的3个版本和一套回滚预案工业现场的模型更新远比互联网产品麻烦。你不可能直接拉流式更新因为现场操作工不会等你下载完模型再开机。我的建议是准备三个版本当前稳定版、候选版、开发版。先在实验室用现场回传的新样本验一遍候选版再灰度到一台设备上试运行一天确认没问题后才全量更新。每次更新必须保留上一个版本的备份一键回滚脚本是保命的底线。另外还有一个看似小事但很重要的点版本信息要刻进模型和日志里。有次客户说“新模型不好用了”我们查了三天发现是因为某台设备上的模型文件被误覆盖了连版本号都没记录下来根本没法追溯。后来我强制每个模型文件名带日期和git commit号提示层在日志里输出模型版本这类问题再没出现过。6.3 和现场人员打交道的那些“非技术坑”最后说一个所有教程都不会教你的现场操作工和班组长才是系统日常运行的最终用户。系统误检一次他们就会倾向于关掉自动拦截退回人工目检告警太多他们就会习惯性忽略。所以系统设计时界面要尽量简洁只显示“OK/NG”和必要的缺陷位置信息不要给一堆置信度、IOU之类的参数。误报误检的比例控制在可接受范围内并且现场管理员能一键反馈“误报”样本回到你的标注库形成闭环。我见过很多团队技术很强但项目烂尾多半是栽在这一环——他们以为自己交付的是“模型”其实客户要的是一个能融进产线节奏、不让现场人员烦心的工具。从需求评估到硬件选型、模型压缩、现场部署再到上线运维每一个环节我都踩过不止一个坑而且回过头看很多坑其实是可以靠前期规划避开的。最深的体会是工业AI边缘部署本质上是系统工程算法只是其中一小块真正的硬功夫在于对现场的敬畏、对硬件和网络的细致把握以及对数据闭环和运维体系的提前规划。如果你刚开始接触这类项目希望这篇内容能帮你在规划阶段就避开我当年走过的弯路。