轮胎质检工位上灯光一打胎侧一道半毫米的细裂纹很容易就被观察人员疏漏。我早几年做某次产线质检改造项目时最初只上了目标检测模型框是能画出来了但缺陷的长宽、走向、有效面积全都算不准现场做判定的人根本不认这套东西。后来换成实例分割路线也就是基于yolov8-seg把每个轮胎损伤实例像素级标出来再配上一套Web前端展示页面实时渲染掩膜整套系统才从“演示玩具”变成真正能派上用场的东西。这篇文章就围绕一套轮胎损伤分割系统的源码、数据集和部署教程展开重点讲清楚 yolov8-seg-aux、yolov8-seg-C2f-Faster 这一批改进结构为什么适合轮胎场景也会把数据准备、训练调参、前后端联调这一整条链路拆开来讲。适合刚入门的实例分割读者也适合正在做工业质检原型验证、想快速跑通一套可用系统的工程师。1. 轮胎损伤分割为什么不能只画框1.1 从检测框到实例分割核心需求在哪很多人在工业缺陷检测里的第一反应都是“用目标检测框出来就行了”这个思路在粗筛阶段没问题但一旦到了需要判定返工还是报废的环节矩形框就变得很鸡肋。一块橡胶剥落也许是一个不规则的月牙形一条裂纹可能沿着胎侧蜿蜒十几厘米一个鼓包往往是局部隆起但边界模糊。矩形框只能框出一个大概范围无法告诉你这个缺陷的有效长度是多少、真实面积占比有多大、是否横跨了原本不该跨过的纹理区。而这些计算对轮胎这类安全件来说恰恰是刚需。实例分割输出的是一张逐像素的掩膜每个缺陷实例有独立的轮廓和面积在后端可以直接算出宽度、周长、中心位置和最小外接矩形用来做量化判定。也正因为这样YOLOv8-seg 这类“检测分割”一体的模型会比纯检测模型更贴合质检场景。1.2 轮胎损伤场景的常见类别与实际条件整套系统里最常见的损伤类别大概可以分成四类裂纹出现在胎侧或胎冠边缘细长条、方向性强有时只有几个像素宽。鼓包/气泡局部橡胶隆起或内部脱层轮廓相对圆润但边缘模糊。缺胶/橡胶剥落区域缺失形状不规则与正常橡胶面有清晰色差。划伤/割口因为外力造成的线状或V形伤口和裂纹的形态很接近但往往是单次事件。现场环境比实验室复杂得多光源会在轮胎弧面上形成高光表面还有粉尘、油污、胎毛和纹理干扰。油污的颜色和缺胶接近胎侧阴影和裂纹接近。现实中的数据和“干净图”差距很大这也是为什么这套系统最终要走到实例分割只有把像素边界严丝合缝地切出来后续的清洗和判定逻辑才有空间去处理这些干扰而不能再依赖一个粗糙的框。2. 复现前的数据盘点目录结构、标注类别与样本边界2.1 数据集该长什么样很多朋友拿到项目第一件事就是直接开始训练结果发现读不懂数据目录、验证集为空、标签文件格式对不上折腾一晚上还没开始。先花五分钟把数据集结构盘明白比跑训练更重要。按这套系统的惯例数据集会整理成 YOLO 系列常用的结构dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ ├── data.yaml └── classes.txtimages 放原图labels 放每个图像对应的标签文本文档。每个标签文档里一行代表一个实例格式是class_id 归一化中心x 归一化中心y 归一化宽 归一化高 多边形坐标...前五位和检测任务一样第六位开始就是掩膜多边形顶点的归一化坐标。YOLOv8-seg 的标签不是像素级 PNG 掩膜而是多边形点串这个细节经常被人忽略。训练时会根据图像尺寸自动把多边形重新渲染成掩膜来算损失所以标注点多、点少都行但点太稀疏会明显丢细节。2.2 标注时要划到的边界拿到原始数据集之后我建议大家重新检查一遍标注质量而不只是看数量。以下几类问题是轮胎场景里最容易出现的边缘划进背景标注时手抖把轮廓扩到了非缺陷区域训练时模型就会学着把正常沟槽也当成裂纹。类别混淆油污和缺胶在外观上非常接近标注标准一定要在团队里统一否则一个类别里混了两种形态模型精度很难提上去。漏标严重一套有几百张小裂纹图但标注不到一半的数据比几千张标注完整的数据更危险。模型会把漏标区域认为是“正常”后面一遇到裂纹就可能直接输出空白。关于分辨率我建议原始图像不要低于 640 像素宽。小裂纹往往只有 3-6 个像素的宽度如果原图本身压缩过头分割头再怎么上采样也很难把边界学出来。用 labelme 或 x-anylabeling 这类工具逐条勾轮廓导出 JSON 后再转成上面的 txt 格式是最常见的流程。3. 两个核心改进结构的原理与取舍aux辅助分割头、C2f-Faster标题里提到的yolov8-seg-aux和yolov8-seg-C2f-Faster是这套系统 50 改进点里我最推荐先看懂的两个结构。因为它们不是花架子一个解决“细裂纹学不到”一个解决“推理太慢”。3.1 aux辅助分割头细裂纹的梯度补偿标准 YOLOv8-seg 的分割头只在最后一段特征图上输出掩膜深层的输出语义抽象程度高但空间细节早就被下采样稀释了。胎侧裂纹通常很窄在网络里经过几次 2 倍下采样之后只剩下一丁点像素响应极易被分类分支当成背景。yolov8-seg-aux 的思路是额外增加一条辅助分割分支说白了就是在主干网络中间层提前接一个浅层的分割头让它参与训练阶段的损失计算。这个辅助分支的任务不是直接输出最终结果而是让监督信号能够绕过深层网络更早地回传到浅层特征层相当于给细纹路的梯度开了一条“近路”避免在层层堆叠中消失。这样一来浅层保留的边缘纹理信息能被更有效地利用对裂纹这种长宽比极端的小目标非常友好。要注意的是aux 分支一般只在训练阶段开启推理时会去掉。所以训练时显卡压力会略有上升但部署时不会平白增加计算量。3.2 C2f-FasterPConv怎么把计算量降下来另一个针对点是 C2f-Faster。YOLOv8 的 C2f 块用多个 Bottleneck 堆叠来增强特征表达效果好但参数量和计算量都不小。C2f-Faster 改成了基于部分卷积的模块设计。部分卷积的逻辑简单说就是不把所有通道都做卷积而是只抽出一部分通道做 3×3 卷积其余通道保持原样拼在一起再通过一个 1×1 卷积融合。这就把冗余计算砍掉了一块。对轮胎图像来说相邻像素有很多重复信息没必要让每个通道都做同一套卷积操作。这对部署非常实际。工业现场的服务器不一定是顶配显卡有些甚至要用 CPU 做近实时推理。换上 C2f-Faster 之后FPS 往往能高出不少而 mAP 的损失通常很小属于“花小代价换大提速”。3.3 50改进点里更值得关注的其他方向除了这两个结构这批改进点里还有一些值得按需挑选的方向。注意力机制类SE、CBAM、EMA、LSKA、ACmix 这几种主要用于让网络知道该把更强的响应放在缺陷区域。替换 C2f 的轻量化结构C2f-Ghost、C2f-DBB思路是在不损失太多特征的条件下减少冗余计算。损失函数类WIoU、SIoU 等边界框回归损失对遮挡、狭长目标的框回归会更稳健。但我不建议一上来就把所有改进点全叠上那样不仅训练不稳定排错也非常痛苦。我的习惯是“基线先行”跑通原始 YOLOv8-seg确认数据没问题再逐个加上 aux 和 C2f-Faster看每个变化对精度的贡献。4. 训练配置与调参让mAP50-95稳定过0.85的实用配方4.1 基础参数组这套系统自带的训练脚本会生成一份配置文件核心参数大概是这样的task: segment mode: train model: yolov8-seg-C2f-Faster.yaml data: data.yaml epochs: 300 batch: 16 imgsz: 640 optimizer: SGD lr0: 0.01 lrf: 0.01 momentum: 0.937 weight_decay: 0.0005 cache: True我把imgsz设成 640 而不是更大原因有三一是轮胎图像往往包含大量重复纹理拼到更高分辨率对全局理解帮助有限二是显存占用和训练时间都要考虑640 的性价比最高三是 640 切分的边缘已经能覆盖大部分毫米级裂纹再往大提会明显拖慢迭代速度。batch在单卡上通常设为 8 或 16。batch size 太小时 BN 层的统计量不稳定分割头更容易震荡太大则显存直接爆掉。先用 16 跑起来如果爆显存就降到 8同时把图像缓存关掉。4.2 数据增强的取舍YOLOv8-seg 默认会开 Mosaic、随机翻转、HSV 抖动等数据增强。轮胎场景里需要特别留意两点。第一Mosaic 对小目标不友好。四张图拼在一起后缺陷会被等比缩小裂纹这种本来就窄的目标可能直接缩到 1 个像素以下相当于训练样本里塞了一堆“看不清的缺陷”。我的做法是前 250 个 epoch 开启 Mosaic最后 50 个 epoch 关闭让模型在接近真实分布的数据上做最后精修。第二垂直翻转和 180 度旋转要谨慎。轮胎本身有花纹方向裂纹方向也往往有统计规律如果增强把方向完全打乱会让模型学到矛盾的方向特征。建议只保留水平翻转和轻微角度旋转。4.3 判断模型有没有学偏不要只看最终 mAP在训练过程中要多观察三个指标的趋势loss 曲线如果 seg loss 在 100 轮后还在反复跳先查标签格式有没有序号错位。类别 PR 曲线某些类别 AP 很低大概率是欠拟合而不是模型问题回去补这类样本。可视化掩膜每 20 轮抽几张验证集图把预测 mask 叠在原图上肉眼看边缘贴合不贴合。有时 mAP 数字很漂亮但 mask 整个长歪了就是训练时辅助头权重没调好的信号。在实做中我给一套大约 1200 张训练图、四分类的数据集跑了 300 轮mAP50 能稳定到 0.92 附近mAP50-95 在 0.85 左右。这个水平已经足够支撑产线做自动初筛人工只需要复核那些低置信度结果。5. Web前端展示分割结果mask从后端到浏览器的完整路径5.1 导出与后端推理训练完得到best.pt后第一步是导出 ONNX因为 Web 端不可能直接加载 PyTorch 模型来跑推理后端服务一般也不会为了一个百来兆的模型就常驻 GPU。python export.py --weights best.pt --include onnx --opset 12 --dynamic导出时开dynamic动态轴可以接收不同尺寸的输入图Web 端传图就不用强制 resize 成固定大小了。后端我用的是轻量 Web 框架监听/predict接口接收上传文件用 ONNX Runtime 做推理后返回四个字段类别、置信度、边界框、轮廓坐标。推理输出里那个分割 mask 是原始分辨率下的概率图不能直接原样返回给前端太大。更合理的做法是在后端用 OpenCV 的contours, _ cv2.findContours(mask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE)把掩膜的外轮廓抽成一系列稀疏坐标点再转成前端可用的浮点数组。一个 1000×1000 的 mask 整包返回可能有几兆抽成轮廓点后通常只有几十 KB传输渲染都轻快很多。5.2 前端绘制前端不需要引入重型的深度学习库一个 Canvas 就够了。拿到轮廓坐标后先按原图尺寸把 canvas 准备好然后把 mask 轮廓做填充fetch(/predict, { method: POST, body: formData }) .then(res res.json()) .then(data { data.masks.forEach(item { ctx.beginPath(); item.contour.forEach((point, idx) { if (idx 0) ctx.moveTo(point[0], point[1]); else ctx.lineTo(point[0], point[1]); }); ctx.closePath(); ctx.fillStyle rgba(255, 70, 70, 0.45); ctx.fill(); ctx.strokeStyle #ffff00; ctx.lineWidth 2; ctx.stroke(); }); });填充色用半透明红色边框用亮黄这样即使一张图上有多个实例重叠区域也不会完全盖住轮胎纹理检查员能同时看清缺陷和周围环境。5.3 数据传输与并发的小优化如果前端需要连续传多张图建议后端把已有图像尺寸、目标类别名映射一起传给前端可以减少一次前端请求。另一件容易被忽视的事是ONNX Runtime 的 session 要全局复用不能在每次请求里重新加载否则并发一上来就卡死。我一开始图省事把推理写在请求函数里结果并发测试直接超时改成启动时初始化全局 session 后单张推理从 300ms 降到 70ms 左右性能完全换了台机器。如果要把这套界面给车间用除了画 mask还得加原图缩放展示、单类别筛选开关、置信度阈值滑条。这些是现场操作员真正会用到的东西做质检系统的朋友千万别只盯着模型精度。6. 踩坑记录标签错位、mosaic过猛与显存爆掉6.1 标签错位的锅我遇到过一个特别误导的情况训练时 loss 一直不降所有验证图的 mask 都跑到图像左上角堆成一团。查了很久最后发现是某个脚本在把 labelme 的 JSON 转成 YOLO 分割标签时排序方式没有和图像名保持一一对应导致标签和图像错位了接近两百张。这种错误比模型本身的问题更难排查因为它们会伪装成“模型复现不出来”的假象。我的建议是训练前写一个几十行的校验脚本检查每个 label 文件的第一个 class_id 是否合法以及坐标是否全部在 0 到 1 之间。这类问题越早发现后面越省时间。6.2 mosaic过猛与裂纹消失另一个常遇到的坑是 Mosaic 开启到最后一轮。我在某次实验里发现验证集 mAP 在最后 30 轮不升反降tensorboard 里的增强图也显示小裂纹在拼接图里已经变成类似噪点的存在。问题就是 Mosaic 对小目标有明确的负面作用。后来参考项目脚本里留的自定义参数把 Mosaic 在最后 50 个 epoch 关闭改为只做轻微尺度变化和水平翻转效果立刻回升。这个参数在很多 YOLO 工程里都有预留但默认都是常开如果你觉得小目标效果不好先查这一条。6.3 显存爆掉与梯度检查点加了 aux 分割头之后训练时显存会比原始 YOLOv8-seg 多出一截这很正常因为多了一条分支和对应的误差回传。如果你的卡只有 8G 显存batch 8 都可能放不下可以考虑把cache关掉、降低输入尺寸或者换成显存重计算的梯度检查点方案。不过也要提醒不要在显存不够时立刻削减网络深度那样会牺牲对裂纹的感知能力。优先减 batch、减输入尺寸尽量保留特征提取的容量。6.4 测试集的测试逻辑最后一个建议是把训练、验证、测试三套数据彻底分开。我在某个复现过程里发现验证集 mAP 高得离谱是因为清洗数据时不小心把同一批图片同时放进了训练和验证集模型等于做了开卷考试。工业项目里大家精力都有限但数据划分的严谨性直接决定这套系统去现场试跑时的压测结果值得多花半小时检查。整套项目如果要落地成产线工具我最想强调的一点是改进结构和创新点都是锦上添花数据质量、前后端链路、标注规范和验证划分才是轮胎损伤分割系统真正能稳定跑多久的基础。把这一条链路梳理清楚这段代码就能从“实验室能跑”变成“工厂里能用”这也是我做这类项目最看重的一件事。 
长河君 · 2026/10/21 12:46:48 · 阅读 1.2k 基于YOLOv8-seg的轮胎损伤实例分割实战：从训练到Web部署
轮胎质检工位上灯光一打胎侧一道半毫米的细裂纹很容易就被观察人员疏漏。我早几年做某次产线质检改造项目时最初只上了目标检测模型框是能画出来了但缺陷的长宽、走向、有效面积全都算不准现场做判定的人根本不认这套东西。后来换成实例分割路线也就是基于yolov8-seg把每个轮胎损伤实例像素级标出来再配上一套Web前端展示页面实时渲染掩膜整套系统才从“演示玩具”变成真正能派上用场的东西。这篇文章就围绕一套轮胎损伤分割系统的源码、数据集和部署教程展开重点讲清楚 yolov8-seg-aux、yolov8-seg-C2f-Faster 这一批改进结构为什么适合轮胎场景也会把数据准备、训练调参、前后端联调这一整条链路拆开来讲。适合刚入门的实例分割读者也适合正在做工业质检原型验证、想快速跑通一套可用系统的工程师。1. 轮胎损伤分割为什么不能只画框1.1 从检测框到实例分割核心需求在哪很多人在工业缺陷检测里的第一反应都是“用目标检测框出来就行了”这个思路在粗筛阶段没问题但一旦到了需要判定返工还是报废的环节矩形框就变得很鸡肋。一块橡胶剥落也许是一个不规则的月牙形一条裂纹可能沿着胎侧蜿蜒十几厘米一个鼓包往往是局部隆起但边界模糊。矩形框只能框出一个大概范围无法告诉你这个缺陷的有效长度是多少、真实面积占比有多大、是否横跨了原本不该跨过的纹理区。而这些计算对轮胎这类安全件来说恰恰是刚需。实例分割输出的是一张逐像素的掩膜每个缺陷实例有独立的轮廓和面积在后端可以直接算出宽度、周长、中心位置和最小外接矩形用来做量化判定。也正因为这样YOLOv8-seg 这类“检测分割”一体的模型会比纯检测模型更贴合质检场景。1.2 轮胎损伤场景的常见类别与实际条件整套系统里最常见的损伤类别大概可以分成四类裂纹出现在胎侧或胎冠边缘细长条、方向性强有时只有几个像素宽。鼓包/气泡局部橡胶隆起或内部脱层轮廓相对圆润但边缘模糊。缺胶/橡胶剥落区域缺失形状不规则与正常橡胶面有清晰色差。划伤/割口因为外力造成的线状或V形伤口和裂纹的形态很接近但往往是单次事件。现场环境比实验室复杂得多光源会在轮胎弧面上形成高光表面还有粉尘、油污、胎毛和纹理干扰。油污的颜色和缺胶接近胎侧阴影和裂纹接近。现实中的数据和“干净图”差距很大这也是为什么这套系统最终要走到实例分割只有把像素边界严丝合缝地切出来后续的清洗和判定逻辑才有空间去处理这些干扰而不能再依赖一个粗糙的框。2. 复现前的数据盘点目录结构、标注类别与样本边界2.1 数据集该长什么样很多朋友拿到项目第一件事就是直接开始训练结果发现读不懂数据目录、验证集为空、标签文件格式对不上折腾一晚上还没开始。先花五分钟把数据集结构盘明白比跑训练更重要。按这套系统的惯例数据集会整理成 YOLO 系列常用的结构dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ ├── data.yaml └── classes.txtimages 放原图labels 放每个图像对应的标签文本文档。每个标签文档里一行代表一个实例格式是class_id 归一化中心x 归一化中心y 归一化宽 归一化高 多边形坐标...前五位和检测任务一样第六位开始就是掩膜多边形顶点的归一化坐标。YOLOv8-seg 的标签不是像素级 PNG 掩膜而是多边形点串这个细节经常被人忽略。训练时会根据图像尺寸自动把多边形重新渲染成掩膜来算损失所以标注点多、点少都行但点太稀疏会明显丢细节。2.2 标注时要划到的边界拿到原始数据集之后我建议大家重新检查一遍标注质量而不只是看数量。以下几类问题是轮胎场景里最容易出现的边缘划进背景标注时手抖把轮廓扩到了非缺陷区域训练时模型就会学着把正常沟槽也当成裂纹。类别混淆油污和缺胶在外观上非常接近标注标准一定要在团队里统一否则一个类别里混了两种形态模型精度很难提上去。漏标严重一套有几百张小裂纹图但标注不到一半的数据比几千张标注完整的数据更危险。模型会把漏标区域认为是“正常”后面一遇到裂纹就可能直接输出空白。关于分辨率我建议原始图像不要低于 640 像素宽。小裂纹往往只有 3-6 个像素的宽度如果原图本身压缩过头分割头再怎么上采样也很难把边界学出来。用 labelme 或 x-anylabeling 这类工具逐条勾轮廓导出 JSON 后再转成上面的 txt 格式是最常见的流程。3. 两个核心改进结构的原理与取舍aux辅助分割头、C2f-Faster标题里提到的yolov8-seg-aux和yolov8-seg-C2f-Faster是这套系统 50 改进点里我最推荐先看懂的两个结构。因为它们不是花架子一个解决“细裂纹学不到”一个解决“推理太慢”。3.1 aux辅助分割头细裂纹的梯度补偿标准 YOLOv8-seg 的分割头只在最后一段特征图上输出掩膜深层的输出语义抽象程度高但空间细节早就被下采样稀释了。胎侧裂纹通常很窄在网络里经过几次 2 倍下采样之后只剩下一丁点像素响应极易被分类分支当成背景。yolov8-seg-aux 的思路是额外增加一条辅助分割分支说白了就是在主干网络中间层提前接一个浅层的分割头让它参与训练阶段的损失计算。这个辅助分支的任务不是直接输出最终结果而是让监督信号能够绕过深层网络更早地回传到浅层特征层相当于给细纹路的梯度开了一条“近路”避免在层层堆叠中消失。这样一来浅层保留的边缘纹理信息能被更有效地利用对裂纹这种长宽比极端的小目标非常友好。要注意的是aux 分支一般只在训练阶段开启推理时会去掉。所以训练时显卡压力会略有上升但部署时不会平白增加计算量。3.2 C2f-FasterPConv怎么把计算量降下来另一个针对点是 C2f-Faster。YOLOv8 的 C2f 块用多个 Bottleneck 堆叠来增强特征表达效果好但参数量和计算量都不小。C2f-Faster 改成了基于部分卷积的模块设计。部分卷积的逻辑简单说就是不把所有通道都做卷积而是只抽出一部分通道做 3×3 卷积其余通道保持原样拼在一起再通过一个 1×1 卷积融合。这就把冗余计算砍掉了一块。对轮胎图像来说相邻像素有很多重复信息没必要让每个通道都做同一套卷积操作。这对部署非常实际。工业现场的服务器不一定是顶配显卡有些甚至要用 CPU 做近实时推理。换上 C2f-Faster 之后FPS 往往能高出不少而 mAP 的损失通常很小属于“花小代价换大提速”。3.3 50改进点里更值得关注的其他方向除了这两个结构这批改进点里还有一些值得按需挑选的方向。注意力机制类SE、CBAM、EMA、LSKA、ACmix 这几种主要用于让网络知道该把更强的响应放在缺陷区域。替换 C2f 的轻量化结构C2f-Ghost、C2f-DBB思路是在不损失太多特征的条件下减少冗余计算。损失函数类WIoU、SIoU 等边界框回归损失对遮挡、狭长目标的框回归会更稳健。但我不建议一上来就把所有改进点全叠上那样不仅训练不稳定排错也非常痛苦。我的习惯是“基线先行”跑通原始 YOLOv8-seg确认数据没问题再逐个加上 aux 和 C2f-Faster看每个变化对精度的贡献。4. 训练配置与调参让mAP50-95稳定过0.85的实用配方4.1 基础参数组这套系统自带的训练脚本会生成一份配置文件核心参数大概是这样的task: segment mode: train model: yolov8-seg-C2f-Faster.yaml data: data.yaml epochs: 300 batch: 16 imgsz: 640 optimizer: SGD lr0: 0.01 lrf: 0.01 momentum: 0.937 weight_decay: 0.0005 cache: True我把imgsz设成 640 而不是更大原因有三一是轮胎图像往往包含大量重复纹理拼到更高分辨率对全局理解帮助有限二是显存占用和训练时间都要考虑640 的性价比最高三是 640 切分的边缘已经能覆盖大部分毫米级裂纹再往大提会明显拖慢迭代速度。batch在单卡上通常设为 8 或 16。batch size 太小时 BN 层的统计量不稳定分割头更容易震荡太大则显存直接爆掉。先用 16 跑起来如果爆显存就降到 8同时把图像缓存关掉。4.2 数据增强的取舍YOLOv8-seg 默认会开 Mosaic、随机翻转、HSV 抖动等数据增强。轮胎场景里需要特别留意两点。第一Mosaic 对小目标不友好。四张图拼在一起后缺陷会被等比缩小裂纹这种本来就窄的目标可能直接缩到 1 个像素以下相当于训练样本里塞了一堆“看不清的缺陷”。我的做法是前 250 个 epoch 开启 Mosaic最后 50 个 epoch 关闭让模型在接近真实分布的数据上做最后精修。第二垂直翻转和 180 度旋转要谨慎。轮胎本身有花纹方向裂纹方向也往往有统计规律如果增强把方向完全打乱会让模型学到矛盾的方向特征。建议只保留水平翻转和轻微角度旋转。4.3 判断模型有没有学偏不要只看最终 mAP在训练过程中要多观察三个指标的趋势loss 曲线如果 seg loss 在 100 轮后还在反复跳先查标签格式有没有序号错位。类别 PR 曲线某些类别 AP 很低大概率是欠拟合而不是模型问题回去补这类样本。可视化掩膜每 20 轮抽几张验证集图把预测 mask 叠在原图上肉眼看边缘贴合不贴合。有时 mAP 数字很漂亮但 mask 整个长歪了就是训练时辅助头权重没调好的信号。在实做中我给一套大约 1200 张训练图、四分类的数据集跑了 300 轮mAP50 能稳定到 0.92 附近mAP50-95 在 0.85 左右。这个水平已经足够支撑产线做自动初筛人工只需要复核那些低置信度结果。5. Web前端展示分割结果mask从后端到浏览器的完整路径5.1 导出与后端推理训练完得到best.pt后第一步是导出 ONNX因为 Web 端不可能直接加载 PyTorch 模型来跑推理后端服务一般也不会为了一个百来兆的模型就常驻 GPU。python export.py --weights best.pt --include onnx --opset 12 --dynamic导出时开dynamic动态轴可以接收不同尺寸的输入图Web 端传图就不用强制 resize 成固定大小了。后端我用的是轻量 Web 框架监听/predict接口接收上传文件用 ONNX Runtime 做推理后返回四个字段类别、置信度、边界框、轮廓坐标。推理输出里那个分割 mask 是原始分辨率下的概率图不能直接原样返回给前端太大。更合理的做法是在后端用 OpenCV 的contours, _ cv2.findContours(mask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE)把掩膜的外轮廓抽成一系列稀疏坐标点再转成前端可用的浮点数组。一个 1000×1000 的 mask 整包返回可能有几兆抽成轮廓点后通常只有几十 KB传输渲染都轻快很多。5.2 前端绘制前端不需要引入重型的深度学习库一个 Canvas 就够了。拿到轮廓坐标后先按原图尺寸把 canvas 准备好然后把 mask 轮廓做填充fetch(/predict, { method: POST, body: formData }) .then(res res.json()) .then(data { data.masks.forEach(item { ctx.beginPath(); item.contour.forEach((point, idx) { if (idx 0) ctx.moveTo(point[0], point[1]); else ctx.lineTo(point[0], point[1]); }); ctx.closePath(); ctx.fillStyle rgba(255, 70, 70, 0.45); ctx.fill(); ctx.strokeStyle #ffff00; ctx.lineWidth 2; ctx.stroke(); }); });填充色用半透明红色边框用亮黄这样即使一张图上有多个实例重叠区域也不会完全盖住轮胎纹理检查员能同时看清缺陷和周围环境。5.3 数据传输与并发的小优化如果前端需要连续传多张图建议后端把已有图像尺寸、目标类别名映射一起传给前端可以减少一次前端请求。另一件容易被忽视的事是ONNX Runtime 的 session 要全局复用不能在每次请求里重新加载否则并发一上来就卡死。我一开始图省事把推理写在请求函数里结果并发测试直接超时改成启动时初始化全局 session 后单张推理从 300ms 降到 70ms 左右性能完全换了台机器。如果要把这套界面给车间用除了画 mask还得加原图缩放展示、单类别筛选开关、置信度阈值滑条。这些是现场操作员真正会用到的东西做质检系统的朋友千万别只盯着模型精度。6. 踩坑记录标签错位、mosaic过猛与显存爆掉6.1 标签错位的锅我遇到过一个特别误导的情况训练时 loss 一直不降所有验证图的 mask 都跑到图像左上角堆成一团。查了很久最后发现是某个脚本在把 labelme 的 JSON 转成 YOLO 分割标签时排序方式没有和图像名保持一一对应导致标签和图像错位了接近两百张。这种错误比模型本身的问题更难排查因为它们会伪装成“模型复现不出来”的假象。我的建议是训练前写一个几十行的校验脚本检查每个 label 文件的第一个 class_id 是否合法以及坐标是否全部在 0 到 1 之间。这类问题越早发现后面越省时间。6.2 mosaic过猛与裂纹消失另一个常遇到的坑是 Mosaic 开启到最后一轮。我在某次实验里发现验证集 mAP 在最后 30 轮不升反降tensorboard 里的增强图也显示小裂纹在拼接图里已经变成类似噪点的存在。问题就是 Mosaic 对小目标有明确的负面作用。后来参考项目脚本里留的自定义参数把 Mosaic 在最后 50 个 epoch 关闭改为只做轻微尺度变化和水平翻转效果立刻回升。这个参数在很多 YOLO 工程里都有预留但默认都是常开如果你觉得小目标效果不好先查这一条。6.3 显存爆掉与梯度检查点加了 aux 分割头之后训练时显存会比原始 YOLOv8-seg 多出一截这很正常因为多了一条分支和对应的误差回传。如果你的卡只有 8G 显存batch 8 都可能放不下可以考虑把cache关掉、降低输入尺寸或者换成显存重计算的梯度检查点方案。不过也要提醒不要在显存不够时立刻削减网络深度那样会牺牲对裂纹的感知能力。优先减 batch、减输入尺寸尽量保留特征提取的容量。6.4 测试集的测试逻辑最后一个建议是把训练、验证、测试三套数据彻底分开。我在某个复现过程里发现验证集 mAP 高得离谱是因为清洗数据时不小心把同一批图片同时放进了训练和验证集模型等于做了开卷考试。工业项目里大家精力都有限但数据划分的严谨性直接决定这套系统去现场试跑时的压测结果值得多花半小时检查。整套项目如果要落地成产线工具我最想强调的一点是改进结构和创新点都是锦上添花数据质量、前后端链路、标注规范和验证划分才是轮胎损伤分割系统真正能稳定跑多久的基础。把这一条链路梳理清楚这段代码就能从“实验室能跑”变成“工厂里能用”这也是我做这类项目最看重的一件事。