YOLOv6工业视觉检测优化与部署实战：从能检出到敢上线

工业视觉检测这个圈子有个挺有意思的现象实验室里 mAP 跑到 0.92 的模型搬到产线上一周就被人投诉到停线。原因不复杂——产线根本不看你那张 PR 曲线它只关心三件事节拍能不能跟上、误检能不能压住、连续跑三十天会不会莫名漂移。YOLOv6 工业视觉检测优化与部署实战这个题目讲的正是从能检出到敢上线这一段最脏最累的路。YOLOv6 作为一款面向工业落地设计的单阶段检测器靠着可重参数化主干、解耦检测头和多尺寸模型族在推理延迟和精度之间给了一个相对务实的平衡点特别适合节拍在几十到一百多毫秒、目标尺寸中等偏小的缺陷检测场景。这篇内容主要写给两类人一类是已经把 YOLO 系列跑通过、准备往产线推的算法工程师另一类是负责视觉系统集成的现场工程师需要知道模型交付后怎么接、怎么调、怎么保。我不会只讲架构更多是把数据、训练、导出、量化、流水线这几段里真实会咬人的地方拆开讲。1. 先搞清楚工业检测要什么需求拆解与模型选型逻辑1.1 产线真正卡脖子的指标跟论文里的完全不是一回事做学术评测的时候我们盯的是 mAP0.5:0.95多一个点能高兴半天。但产线验收单上写的往往是另一套东西单件检测时间不超过 120ms、过杀率低于 0.5%、漏检率低于 0.1%、连续运行 72 小时无异常退出、换型后 30 分钟内可完成重新标定。这几条里只有第一条跟模型算力直接相关剩下的几乎全是数据质量和工程稳定性问题。我印象很深的一次某产线做金属件表面划伤检测模型在测试集上 mAP 0.89信心满满上线结果第一天过杀率 6%。现场排查发现测试集是白天在恒温实验室采的产线是夜班、车间温度高、镜头前有油雾附着图像整体对比度掉了将近一档模型把正常的加工纹理当成了划伤。这件事之后我形成了一个习惯任何模型的评估集里必须包含至少 20% 的恶劣工况样本——不同班次、不同温湿度、镜头脏污程度不同的图。否则 mAP 就是个自欺欺人的数字。工业场景和通用场景的差异我习惯用一张表来对齐认知跟现场同事沟通时特别管用维度通用检测场景工业视觉检测首要指标mAP过杀率、漏检率、节拍类别数量几十到上千类通常 1 到 10 类但类内差异极大样本分布相对均衡极端不平衡缺陷样本可能只占千分之几目标尺寸差异大常集中在小目标区间8 到 64 像素数据获取成本低可爬取极高需要停产、布光、人工挑选对误检的容忍较高极低一次误判可能导致整批返工迭代周期以月计以周甚至以天计换型频繁看这张表就知道选模型不能只看 benchmark 排名得看它在这个约束集合里能不能活下来。1.2 YOLOv6 的架构取舍为什么正好卡在这个位置YOLOv6 的几处设计恰好踩在工业检测的痛点上值得单独说说。第一处是可重参数化主干。训练阶段用多分支结构类似 RepVGG 的思路提升表达能力推理阶段通过结构重参数化把多分支折叠成单路 3x3 卷积。这意味着你训练时享受多分支带来的精度红利部署时拿到的是纯单路的、对推理引擎极其友好的计算图。对工业部署来说这点很关键——单路卷积在 TensorRT 里的融合效率最高算子调度开销最小也不会出现某些分支算子不被支持而被迫回退的情况。第二处是解耦检测头。分类分支和回归分支分开各自走独立的卷积。工业缺陷往往长得像但位置差一点分类和回归的关注点本来就不一样解耦之后对小目标的定位精度提升明显。我在一个连接器针脚歪斜检测的项目里对比过同样的数据和解码方式解耦头比耦合头的定位误差中位数低了约 18%。第三处是多尺寸模型族。YOLOv6 提供了 N/T/S/M/L 几档参数量从两百万级到五千万级不等。这个梯度对工业选型太友好了边缘盒子跑 N 或 T工控机加中端卡跑 S 或 M只有极少数高精度场景才需要 L。我一般的做法是先用 S 跑通全流程拿到基线指标再往下降尺寸看能压到多小通常能省下 40% 左右的算力预算。第四处是量化友好。这一点在 2.x 之后体现得更明显配合重参数化结构INT8 量化的精度损失控制在 1 个点以内是常见结果。工业现场大量使用低功耗推理卡FP16 甚至 INT8 是刚需模型本身对量化友好等于省掉了一大块调优成本。1.3 什么情况下别硬上 YOLOv6该换思路这话我得说在前面因为踩过坑。有几种场景YOLOv6 不是最优解硬上只会浪费时间。目标小于 8 像素的极微小缺陷。比如某些芯片表面的微裂纹在原图里就几个像素。YOLOv6 最小下采样到 8 倍P3 特征图上目标只剩一两个格子召回率上不去。这种要么上切图推理把大图切块分别检测再合并要么直接换高分辨率输入加 P2 检测头要么干脆用传统图像处理配合频域分析。需要像素级轮廓而不是框的场景。缺陷面积占比、形状不规则度这类指标框给不出来得上分割模型。用检测框去估算面积误差能到 30% 以上客户不会认。样本少于 50 张的冷启动场景。缺陷样本实在太少监督学习训不动。这时候异常检测路线比如基于特征嵌入的方法往往比硬训检测器靠谱得多先跑起来积累数据等样本攒到几百张再切回检测。规则极其明确的缺陷。比如孔位偏移超过 0.2mm这种用卡尺算法或者模板匹配几毫秒就出结果又稳又可解释没必要上深度学习。我见过有团队为了一个规则明确的尺寸测量硬训了两个月模型最后精度还不如传统方法纯粹是路径依赖。提示选型阶段花两天做可行性验证比训两周模型再发现路线错了要划算得多。验证方法很简单——拿 100 张有代表性的图人工标注用小模型跑一遍看召回上限在哪。2. 数据与标注决定上限的那 80% 工作量2.1 打光决定天花板采集策略决定地板我一直跟团队说一句话模型的上限是光学系统给的不是网络结构给的。同一批缺陷环形光下拍出来对比度 30同轴光下可能只有 8后者你换什么网络都救不回来。采集阶段要盯死三件事。一是光源选型表面划伤用低角度暗场最敏感平面字符用同轴光最均匀透明件缺陷用背光最清晰。二是相机与镜头的匹配视场除以分辨率得到单像素物理尺寸这个值要小于最小缺陷尺寸的三分之一否则连看得见都做不到。三是样本的工况覆盖同一类缺陷要在不同批次、不同班次、不同设备状态下都采到。样本量的问题我给的经验值是主体类别正常件控制在缺陷类的 3 到 5 倍缺陷类每类至少 300 个实例稀有缺陷类实在凑不够就用过采样加针对性增强。某项目里有个边缘崩缺缺陷全月只出了 40 件我们通过调整光源角度人为复现了 200 多例这个做法在工业上很常见——不是造假是补足物理分布的覆盖。2.2 标注规范不写清楚后面全是返工标注这活儿看着简单实际上是最容易埋雷的地方。工业缺陷的边界经常是模糊的、渐变的十个人标出来的框能有十个样子。我的做法是先写一份标注细则把下面几个问题逐条定死框的粒度缺陷框是紧贴可见边界还是包含周围过渡区我的建议是紧贴可见边界过渡区留给模型自己学因为过渡区的界定主观性太强。重叠缺陷怎么处理两个缺陷挨着或者部分重叠是合并成一个大框还是各自独立标一般按是否会被同一道工序处理来判断同工序处理的合并。模糊样本的归属看不清但疑似缺陷的统一标为存疑类单独一档不参与正常训练留作后续复核。最小可标尺寸明确小于多少像素的不标避免标注员各自发挥。标完之后一定要做一致性校验。抽 10% 的图让第二个人盲标算一下同一目标两框的 IoU低于 0.85 的挑出来集体讨论对齐。这个动作看起来费时但能把后面训练阶段的标签噪声问题提前消掉一大半。2.3 增强要克制工业图像不能照搬通用套路从通用检测那套增强策略直接搬过来在工业场景大概率翻车。我列一下自己踩过的具体坑水平翻转慎用。很多缺陷是有方向性的比如划伤方向与走刀方向一致翻转之后方向反了模型学到的是错的先验。真要用先确认这一类缺陷是否存在方向语义。颜色抖动要收敛。通用场景里色调、饱和度乱抖没事工业场景里颜色本身就是判据——某类缺陷就是偏黄你把色调抖 30 度等于把判据抹掉了。我一般把色相抖动控制在 ±5 度以内饱和度和明度不超过 ±15%。Mosaic 要看场景。Mosaic 把四张图拼一起能提升小目标数量但会破坏上下文。工业场景里很多缺陷的判定依赖周边环境比如相对于螺纹的位置拼完之后上下文没了反而学坏。我的经验是纯外观类缺陷可以开位置相关类缺陷关掉或者降低概率。更该加的增强小角度旋转±10 度、亮度与对比度的轻微扰动、高斯噪声、轻微运动模糊、以及模拟镜头脏污的局部高斯模糊。后两个在工业上特别重要因为它们直接对应现场的漂移因素。下面是我常用的一套增强配置写在训练配置里大致长这样augment: hsv_h: 0.005 # 色相扰动极保守 hsv_s: 0.15 hsv_v: 0.2 degrees: 10.0 # 小角度旋转 translate: 0.05 scale: 0.15 shear: 0.0 perspective: 0.0 flipud: 0.0 fliplr: 0.0 # 方向敏感类缺陷必须置零 mosaic: 0.2 # 外观类可开到 0.5 以上 mixup: 0.0 blur_prob: 0.15 # 模拟失焦 noise_prob: 0.1 smudge_prob: 0.08 # 模拟镜头脏污后三项需要自己在数据管道里加官方默认配置里没有但现场效果提升很明显尤其是长时间运行后的稳定性。3. 训练与调优把默认配置推到可交付指标3.1 环境基线与第一版训练先说环境。我的习惯是固定版本别用 latest工业项目最怕的就是上周还能跑这周环境一升级全崩。基础组合大致是 Python 3.8 到 3.10、PyTorch 1.12 到 2.0、CUDA 11.6 到 11.8 之间选一套稳定的写进 requirements 锁死。训练起手式不要一上来就改结构先用官方配置和预训练权重跑一版基线看看数据本身的质量如何。命令大致是这样python tools/train.py \ --conf-file configs/yolov6s_finetune.py \ --data-path data/industrial.yaml \ --batch-size 16 \ --epochs 100 \ --device 0 \ --workers 8 \ --project runs/line_a --name baseline_v1数据配置文件写清楚路径和类别数train: /data/industrial/images/train val: /data/industrial/images/val nc: 4 names: [scratch, dent, stain, deform]基线跑完先别急着看 mAP先看两件事损失曲线是否平滑收敛、验证集上的查全率和查准率分别在什么水平。工业场景里查全率通常优先于查准率因为漏检的代价远大于过杀后处理阈值可以再调但召回丢了就找不回来了。超参方面微调阶段学习率比从头训要低一个数量级我一般用 0.01 配 cosine 衰减warmup 3 个 epoch。batch size 受显存限制能大则大8 到 32 之间都行配合梯度累积可以模拟更大的批。3.2 小目标与低对比度两个最常遇到的硬骨头工业缺陷八成以上是小目标。针对这个我按成本从低到高排了几种手段效果和代价对应如下手段实现成本召回提升速度代价适用判断提高输入分辨率低明显线性上升首选先试增加 P2 检测头中明显约 30%目标小于 16 像素时用切图推理中显著成倍大图小目标产线允许时用对比度预处理低中等可忽略图像偏灰时必做浅层特征增强高中等较小前几种都不够时再上提高分辨率是最先该试的。输入从 640 提到 960 或 1280小目标在特征图上的像素数成倍增加。但要注意分辨率提高会让推理时间线性增长得先把节拍预算算清楚。我的算法是单件允许时间减去采集、传输、后处理的固定开销剩下的才是推理预算再留 30% 余量。比如产线节拍 300ms固定开销 80ms推理预算 220ms留余量后实际可用 150ms 左右。增加 P2 检测头需要改网络结构把 stride4 的特征图接进 neck 和 head。代价是显存涨得快batch size 得降。改完之后小目标召回往往能提 5 到 10 个点但如果目标本身在 8 像素以下提升有限这种情况老老实实做切图。低对比度的问题预处理阶段我一般加一步 CLAHE限制对比度自适应直方图均衡clip limit 设 2.0 到 3.0网格 8x8。这个操作对灰度图效果最明显彩色图建议先转亮度通道处理再合并回去。要注意它也会放大噪声所以后面跟一步轻度高斯滤波比较稳妥。import cv2 def preprocess(img, clip2.5, grid(8, 8)): lab cv2.cvtColor(img, cv2.COLOR_BGR2LAB) l, a, b cv2.split(lab) clahe cv2.createCLAHE(clipLimitclip, tileGridSizegrid) l clahe.apply(l) out cv2.cvtColor(cv2.merge([l, a, b]), cv2.COLOR_LAB2BGR) return cv2.GaussianBlur(out, (3, 3), 0)3.3 标签分配与损失调整让模型关注该关注的样本YOLOv6 在 2.x 之后引入了基于任务对齐的标签分配策略和变焦损失这套机制对工业场景其实挺友好因为它会自动给分类置信高且定位准的样本更高权重正好对应既检出又框准的需求。但有两处需要针对工业数据改。第一处是正样本数量。默认的分配规则在小目标密集的场景下可能给的正样本偏少导致收敛慢。我的做法是适度放宽中心先验的半径让更多格子参与正样本候选实测在密集小目标场景下收敛速度能快 15% 左右。第二处是类别不平衡。缺陷类别之间数量差十倍很常见可以在损失里给稀有类加权或者干脆从采样层面解决——每个 batch 里强制包含稀有类样本。回归损失方面工业场景对定位精度的要求通常高于分类可以把回归损失的权重往上调一档。但别调太狠否则训练后期容易震荡。我一般从默认值往上加 20% 到 30%观察验证集上的定位误差中位数变化稳定就保持。还有一个容易被忽略的点置信度阈值的确定不能拍脑袋。训练完在验证集上把所有样本的置信度排序画出过杀率和漏检率随阈值变化的曲线找那个满足验收指标的交点。我见过有人直接设 0.5结果过杀率超标两倍其实阈值调到 0.72 就达标了白白多训了一轮模型。3.4 蒸馏与剪枝能不做就先不做模型压缩这块我的态度比较保守。蒸馏优先于剪枝量化优先于两者。自蒸馏的思路是拿一个大模型比如 M 或 L当老师小模型当学生用老师的软标签监督学生。在工业数据上效果不错尤其是缺陷类别边界模糊的时候软标签提供的类间关系信息很有价值。实现上注意一点老师模型必须是在同一份数据上训好的别拿通用预训练权重直接蒸馏分布差太远反而有害。剪枝我只在算力实在紧张时才用而且只做通道级剪枝剪枝率不超过 30%剪完必须重新微调至少 20 个 epoch。结构化剪枝对检测模型比较伤尤其伤小目标剪完召回掉三五个点是常事。相比之下量化感知训练配合 INT8 部署能拿到接近 4 倍的吞吐提升精度掉一个点以内性价比高太多。提示压缩之前先把 FP16 的上限摸清楚。很多项目 FP16 就够用了根本不需要折腾 INT8。别为了技术指标去上不必要的复杂度。4. 部署落地从训练脚本到产线进程4.1 ONNX 导出的那些坑我先替你踩一遍导出这一步看着最简单实际上问题最集中。核心原则是只导出到检测头输出为止后处理放在引擎外面。把解码和 NMS 写进计算图调阈值就得重新导出工程上极其难受。导出的关键点有这么几个opset 版本。别用太新的11 到 13 之间兼容性最好各家推理引擎支持都完善。动态维度。如果批大小或输入尺寸会变记得声明 dynamic axes如果固定不变就别开动态静态图优化空间更大。训练模式残留。导出前务必 eval()并确认重参数化已经完成融合否则导出的图里还带着多分支推理会慢一截。import torch model build_model(cfg).eval() ckpt torch.load(weights/best.pt, map_locationcpu) model.load_state_dict(ckpt[model]) dummy torch.randn(1, 3, 960, 960) torch.onnx.export( model, dummy, yolov6s_960.onnx, opset_version12, input_names[images], output_names[cls_score, bbox_pred], do_constant_foldingTrue, dynamic_axesNone )导出后一定要做数值对齐验证同一张图分别走 PyTorch 和 ONNX Runtime比较原始输出张量的最大绝对误差控制在 1e-4 量级才放心。我遇到过重参数化没做干净导致输出差 0.03 的情况肉眼看不出来但后面框的位置会系统性偏移两三个像素。4.2 TensorRT 构建FP16 是标配INT8 要谨慎TensorRT 构建这一步我一般先用 trtexec 快速验证一下延迟确认可行再写正式的 Python 构建脚本。trtexec --onnxyolov6s_960.onnx \ --saveEngineyolov6s_960_fp16.engine \ --fp16 \ --workspace4096 \ --minShapesimages:1x3x960x960 \ --optShapesimages:4x3x960x960 \ --maxShapesimages:8x3x960x960批大小的选择有讲究。产线如果要吞吐用批处理能显著提升 GPU 利用率但会引入排队延迟。我的经验是单件延迟敏感的用 batch1吞吐优先的用 batch4 到 8并且用多个 CUDA stream 做流水线重叠把预处理、推理、后处理三段并行起来。INT8 量化要过校准。校准集的选择直接决定精度我的标准是 500 到 1000 张必须覆盖所有类别、所有工况、所有光照条件不能只挑清晰的样本。校准算法方面熵校准entropy通常比最小最大校准minmax稳尤其是图像里存在高光或暗区的时候。量化之后一定要做逐层敏感度分析。TensorRT 提供逐层回退的功能哪一层量化后误差大就把哪一层退回 FP16。实操中通常是检测头前面那几层比较敏感退回之后整体精度就能拉回来。一个常见的误区是认为 INT8 一定比 FP16 快。实际上在小 batch 场景下INT8 的加速比可能只有 1.3 到 1.5 倍因为瓶颈已经转移到内存带宽和 kernel 启动开销上。真想要吞吐得配合批处理和流水线一起做。4.3 前后处理才是真正的性能黑洞模型推理只占整个链路的一部分前后处理经常吃掉一半以上的时间这一点很多人在优化时容易忽略。预处理主要做三件事letterbox 缩放、归一化、HWC 转 CHW。用 OpenCV 在 CPU 上做一张 960 的图要 8 到 15ms改成用 CUDA 写 kernel或者用 GPU 图像处理库能压到 1ms 以内。如果你用的是带 GPU 解码能力的采集卡可以直接把解码和缩放串在 GPU 上省掉一次主机内存往返。后处理的大头是 NMS。CPU 版的 NMS 在候选框上千的时候能跑到 20ms 以上是实打实的瓶颈。解决办法有三种一是用 GPU 版 NMSTensorRT 有对应的插件二是先做置信度过滤把候选框压到 200 以内再进 NMS三是用无 NMS 的替代方案比如基于距离的框合并或者 top-k 选择。我一般用第二种简单可靠效果也够。内存管理上别每次推理都重新分配显存。用 pinned memory 做主机到设备的异步拷贝预分配好输入输出缓冲区复用 CUDA stream这些细节加起来能省 5 到 10ms。在实际的产线进程里这几毫秒往往就是能不能卡进节拍的关键。4.4 一个可参考的产线部署结构下面这个结构是我在几个项目里反复用过的稳也容易维护。用三个线程加两个队列做流水线import queue, threading, time raw_q queue.Queue(maxsize8) res_q queue.Queue(maxsize8) def capture_worker(cam, stop): while not stop.is_set(): ok, frame cam.read() if ok: if raw_q.full(): raw_q.get() # 丢弃最旧帧防止延迟堆积 raw_q.put((time.time(), frame)) def infer_worker(engine, stop): while not stop.is_set(): ts, frame raw_q.get(timeout1) blob preprocess(frame) # GPU 预处理 outs engine.infer(blob) # 推理 dets postprocess(outs) # 解码 NMS res_q.put((ts, dets)) def result_worker(plc, stop): while not stop.is_set(): ts, dets res_q.get(timeout1) verdict decide(dets) # 阈值判定 plc.write(verdict) # 输出给 PLC采线程和推理线程之间要有丢帧策略这个必须做。产线偶尔卡一下如果队列无限堆积延迟会越滚越大最后输出的是几秒前的图那比不检测还危险。丢最旧帧保证实时性是工业视觉的标准做法。还有两件事必须加看门狗和超时保护。推理线程超过设定时间没出结果直接输出异常信号让产线停机或者走人工复检进程要有心跳主控发现心跳断了自动重启。这些机制平时用不上但真出事的时候能救命。5. 问题排查实录那些文档里不会写的情况5.1 训练侧的高频异常与定位思路训练阶段的问题相对好查因为有日志和指标可看。我整理了一张速查表基本覆盖了八成的现场提问现象高概率原因排查动作处理办法损失不降或剧烈震荡学习率过大、标签异常看损失曲线前 10 个 epoch学习率降一个数量级检查标注是否有越界框训练集 mAP 高、验证集低过拟合、分布不一致对比两边样本来源补数据、加增强、检查验证集是否混入训练图召回上不去、精度还行阈值过高、小目标漏检画 PR 曲线降阈值、加分辨率或 P2 头某一类几乎检不出该类样本过少、标注错统计各类实例数补样本、类别加权、检查标注正确性框位置系统性偏移预处理不一致检查训练和推理的归一化方式统一 letterbox 参数和 padding 值训练后期指标突然跌学习率衰减策略不当看 lr 曲线改用 cosine加早停表里最值得说的是框位置系统性偏移这一条。它不会让 mAP 掉太多但会让下游的尺寸测量全错。根因几乎都是预处理不一致——训练时用了一种 padding 方式推理时用了另一种或者归一化用的均值方差对不上。解决办法就是把预处理封装成一个函数训练和推理共用同一份代码不要各写各的。5.2 部署侧的问题往往藏在细节里部署阶段的问题更隐蔽因为很多时候程序不报错就是结果不对。我遇到过几个典型情况说出来供参考。引擎输出全零或全是背景。八成是输入的预处理错了常见的是通道顺序搞反BGR 当 RGB 送进去或者归一化漏了像素值还是 0 到 255 没除到 0 到 1。排查方法是拿同一张图分别跑 PyTorch 和引擎逐层比对中间输出一般到第二三层就能看出问题。同样的模型换台机器精度就掉。这个通常是量化相关——不同显卡对某些算子的实现有细微差异INT8 下会被放大。解决办法是统一硬件型号或者在交付前做一次跨机器的一致性验证。跑一段时间后延迟逐渐升高。内存或显存泄漏的典型表现。检查有没有在循环里重复创建 CUDA stream、TensorRT context 或者 OpenCV 的 Mat 对象。我见过在推理循环里每次都 new 一个执行上下文跑两个小时显存就满了。偶发性的框错位。这个最难受因为不可复现。常见的根因是多线程下共享了缓冲区没有加锁或者异步拷贝没有做同步就开始读结果。用 CUDA 的流同步或者显式加锁能解决但最好在设计阶段就把每个线程的数据隔离好。5.3 上线之后的持续运维才是真正的考验模型上线不是终点。产线的工况会漂移镜头会脏物料批次会换模型的表现一定会随时间缓慢下降。所以必须建一套线上监控和回流机制。监控方面我一般记录三类数据每天的检出率与过杀率趋势、置信度分布的均值与方差、以及推理延迟的分位数。检出率突然掉 5 个点、或者置信度均值整体下移往往预示着什么变了得赶紧去现场看。这三个指标实现起来都很简单但对早期发现问题极其有效。回流方面把线上判定的过杀样本和人工复检确认的漏检样本自动存下来每周做一次增量训练。增量训练时新旧数据按 1:3 混合别只用新数据否则会灾难性遗忘。换型的时候我的经验是预留一个快速标定流程新物料上线的头 200 件全部走人工复检同时把图像和结果都存下来用这批数据做一次小规模微调通常 20 个 epoch 就能把模型调整到可用状态。这个流程要提前固化下来写成操作手册现场工程师照着做就行不要每次都找算法团队。注意任何模型更新都要先灰度先在一个工位或者一个班次上跑指标稳定了再全量推。直接全量替换一旦出问题就是批量事故。6. 我在几个项目里攒下的实战心得写到这里分享几个不在文档里、但确实影响成败的细节。别迷信大模型。某次做塑料件外观检测客户一开始要求用 L 尺寸说精度越高越好。我坚持先跑 S最后 S 在优化后的数据上过杀率 0.3%、漏检率 0.05%完全达标推理时间只有 L 的三分之一客户也就没话说了。模型尺寸和数据质量的关系是乘法不是加法数据不行的时候换大模型纯属浪费算力。把预处理做成可配置的。不同产线、不同物料需要的预处理不一样如果写死在代码里每换一次都要改代码重新编译。我的做法是把 CLAHE 参数、letterbox 策略、归一化参数全部放到配置文件里现场工程师改配置就能调不用惊动开发。训练和部署用同一套后处理代码。这个前面提过但值得再强调一次。评估阶段算指标用的解码逻辑必须和部署时完全一致最好是同一个模块被两边引用。我见过评估用一套、部署用另一套评估 mAP 0.88上线实测差了一大截查了两天才发现 NMS 的 IoU 阈值不一样。给每条产线留一个性能基线文件。记录下标准测试图集在该配置下的延迟、精度、显存占用每次改动之后跑一遍对比。这个习惯能帮你快速定位是哪次改动拖慢了系统尤其在多人协作的项目里价值极大。现场调参带个可控光源。很多时候模型表现不好真不是模型的问题是光打得不到位。带个小光源去现场一边调角度一边看图像往往比回去改模型有效得多。这个经验是我被现场工程师拉着手调了三次光之后才彻底服气的。这套流程跑下来一个中等复杂度的工业检测项目从数据采集到稳定上线我一般需要六到十周其中模型训练只占两周剩下全是数据、集成和调优。这个时间分布本身就是个提醒把精力放在数据和工程上比反复调网络结构划算得多。后面如果要做扩展我会优先考虑两个方向一是把回流数据的管理做成半自动的流水线减少人工筛选成本二是把多工位的模型统一到一个服务里用模型热切换的方式支持快速换型避免每个工位单独维护一套环境。