棉纺场景烟雾火焰检测实战：基于YOLOv26的工业视觉落地全流程

1. 这个项目到底在解决什么问题

1.1 棉纺与仓储场景的特殊性

棉花这个东西，看起来人畜无害，但它天然就是火灾的“完美燃料”。原棉的燃点不算高，而棉纤维蓬松、比表面积大，一旦出现阴燃，可以在堆垛内部无声无息地烧上几个小时，等你肉眼看到冒烟，往往已经烧进去很深了。更麻烦的是，棉纺车间里的飞花、棉尘悬浮在空气中，一遇到火星就是爆燃。我接手这个项目时，需求来源是某纺织工业园区的原料仓库和车间通道，甲方就一句话：“在烟雾刚刚冒头、火焰还没成势的时候，把报警信号发出去。”要命的是，这类目标恰恰是视觉检测里最难的那一档。

车间里有大面积采光天窗，自然光和灯光会在一天之内剧烈变化；地面棉絮会随风飘动，天花板上挂着飞花；设备运转会产生蒸汽和油雾；仓库里还有叉车尾气、加湿喷雾。这些全是视觉干扰项。加上仓库夜间几乎全黑，只有应急灯，摄像头能拍到的画面对比度极低。所以做棉质场景的烟雾火焰检测，本质上不是“模型能不能识别”的问题，而是“模型在这么多干扰下能不能稳定识别”的问题。我一开始也觉得，火焰检测嘛，老早就有成熟方案了，结果真上手才发现，把工业场景的灰尘、光照、气流全算进去之后，这事儿的难度完全不亚于做自动驾驶感知。

1.2 传统方案为什么不够用

先说传感器方案。传统感烟探测器靠离子或光电原理，对阴燃烟雾响应不算差，但棉纺车间的飞花和粉尘本身就挂在天花板上，探测器非常容易误报。我在现场见过一个车间，感烟探头被棉絮糊住之后直接失效，检修工人说平均一个月得清理一次，否则就狂报警。感温探测器更不靠谱，等它触发的时候，堆垛内部的火已经烧透了。这类方案维护成本高、响应滞后，在棉纺场景里只能算兜底，不能算主力。

再说视觉方案，这几年大家常用的还是传统图像处理：背景建模、帧差法、颜色阈值分割。火焰的HSV特征、烟雾的纹理特征，确实能抓到一部分，但阈值法最大的问题是鲁棒性差。车间灯光一变、镜头沾灰、纱窗透进来的光斑移动，都会造成大面积的误分割。后来有人用HOG+SVM或者浅层CNN，效果有提升，但特征表达力在复杂背景下还是撑不住。我的实际感受是，传统视觉方案更像“实验室能用、现场崩盘”，一到真实车间里，误报率能把值班人逼疯。

所以这个项目从一开始就明确了技术路线：用深度目标检测模型做端到端检测，直接输出“烟”和“火”两个类别的边界框，配合检测之后的一系列后处理规则，形成完整的报警判定链路。我在选型的时候对比了上一代主流模型和新的YOLOv26，最终锁定在YOLOv26上。原因后面会详细拆，这里先给结论：它在这类小目标、强干扰场景下的召回率有明显优势，而且部署生态非常完善，从训练到TensorRT导出一条龙，特别适合工业落地项目。

2. 数据才是这个项目的命门

2.1 数据来源与标注规范

很多做视觉项目的人上来就调参，结果模型怎么调都不收敛，其实问题九成出在数据上。烟雾和火焰这个方向尤其如此，因为目标和背景的边界天然模糊，标注质量直接决定模型上限。我这次的数据来源分四块：

1. 现场摄像头实际录像。我在布料仓库、清花车间、梳棉车间装了十几路摄像头，录了大约三个月的素材，覆盖白天、夜间、晴天、阴天、灯全开、灯半开各种工况。
2. 从公开火灾烟雾数据集里筛选出来的部分样本，作为场景补充。
3. 早期试错阶段积累的误报样本，这些样本非常有价值，后面单独说。
4. 合成数据，用3D粒子渲染出烟雾和火焰，叠加在实景背景图上，解决早期样本不足的问题。

标注规范是决定模型上限的东西，我把最容易出错的地方先写在前面。

首先是类别的定义。烟和火在视觉上有很强的耦合：有火必有烟，有烟未必有火。我们按“是否能独立触发告警”来定义边界：框内能看到明显火焰主体的标为“火”；只有烟雾、没有明火主体的标为“烟”；两者在同一区域且相互重叠时，分开标两个框，允许IoU重叠。这样设计的意图是让模型把“烟”和“火”学成两种独立信号，避免它把“有火”当成“有烟”的充分条件。将来做报警策略时，单独出烟也能触发预警，但权重可以低于出火。

其次是边界框的粒度。烟雾是弥散性的，边缘模糊，标注员如果按肉眼感知的“全部烟雾范围”去拉框，框会非常大且包含大量背景。我们定的规则是：框尽量贴合烟雾浓度最高的核心区域，宁可小一点、准一点，也不要拉一大片。原因很简单，训练用的是IoU损失，框太大直接稀释了回归损失，模型会被迫去学“这个框应该包含多少背景”这种没意义的信息。

还有一组细节容易被忽略：夜间样本一定要单独管理。夜间画面整体很暗，火焰作为自发光体特征显著，烟雾在夜间几乎没有可见特征，只能靠红外反射或者周围背景变化来判断。如果训练集里日夜混杂且夜间样本少，模型会学出“暗等于火”这种坏先验，一到夜间就疯狂误报。我把日夜样本分开统计，在夜间样本不足时单独做了一轮采集，才把这个问题压住。

2.2 数据增强与类别不平衡的拉锯战

原始素材标注完，统计下来火类框大约1.8万个，烟类框大约1.2万个，纯背景负样本4000张。乍一看类别不算失衡，但细看就有问题：火类里大火焰占了七成，初期小火焰和阴燃火焰特别少；烟类里白烟多、灰烟少，烟雾淡薄的早期样本只占两成。这种“看似均衡、实则难度分布失衡”的情况，比简单的数量不平衡更隐蔽。

我对付类别不平衡的习惯分两步。第一步不是加数据，而是先做难度分布分析：把已标注样本按框面积分桶，统计每个桶的样本量。结果小目标（面积小于32乘32像素）在火类里只占12%，这显然不行。于是我从几十个小时的原始录像里专门去抽“刚冒烟”“小火苗”的片段，很多是画面角落里只有几十个像素的小点，人眼不仔细看都发现不了。这一步比任何数据增强都管用，因为真实分布就是这样，模型得先见过这些样本，才能学会在现实里认出它们。

第二步才是增强。我的增强管线分“感知增强”和“几何增强”两层。感知层面做随机亮度扰动、HSV色相小幅偏移、高斯噪声和运动模糊。这里有一个关键点：烟雾火焰的颜色分布是强先验，不能乱调。色相偏移如果太大，火焰会变成绿色，模型会学到错误的颜色映射关系。所以我限定色相偏移在正负5度以内，亮度扰动范围设得比较大，用来模拟白天、黑夜、灯光切换带来的光照变化。

几何层面做随机缩放、平移、旋转和翻转。翻转在烟雾火焰任务上是安全的，烟雾纹理和火焰形态没有左右对称性概念。不过要注意，翻转配置一旦定了就不要中途改，否则前后训练阶段的数据分布不一致，模型会震荡。

我还做了一个场景级别的增强：把不同时间段的光照背景和烟雾火焰前景做随机合成。简单说，用一个图像合成脚本把火焰或烟雾的实例抠出来，随机贴到另一张背景图上，再做羽化和色调匹配。合成样本大约占训练集的20%，实测下来对夜间小火的召回提升非常明显。这个做法的逻辑是：模型光见“烟在白天车间”和“火在夜间仓库”还不够，它得学会把“烟”和“火”从背景中解耦出来，跨场景迁移才稳。

3. YOLOv26的结构改动与选型理由

3.1 从YOLOv8到YOLOv26，主干网络走了哪几步

先交代一句：YOLOv26这个版本号在不同渠道叫法可能不太统一，我按我自己使用的这个版本来讲，重要的是理解这一代模型的结构思路。我拿到的预训练权重是在大规模通用数据集上训练的，这帮我省了很多前期成本，从零训练一个检测器的时间和显存开销，在工业项目里根本划不来。

主干部分，YOLOv26把之前的C2f结构进一步改造成了带可变形卷积感知的变体。可变形卷积这个机制，常规卷积的采样点是固定的3乘3网格，而可变形卷积会给每个采样点学习一个偏移量，相当于让卷积自己决定“该往哪个位置看”。烟雾是弥散的、边缘不规则的，火焰是闪烁跳动的，固定网格对这类目标的表达能力天然不足，可变形卷积在原理上正好对症。代价是显存占用和推理速度，所以我只在深层特征提取阶段使用，浅层保持普通卷积，兼顾精度和速度。

主干里还嵌入了轻量注意力机制。这类注意力把通道注意力分成两支，在空间尺度上做加权。烟雾和火焰经常在画面里占比很小，注意力机制的核心价值，就是帮模型把特征重心从大面积背景挪到小目标上。我在消融实验里对比过：去掉这层注意力之后，小目标AP掉了大约3个点，但推理速度只提升了不到1毫秒。这笔账非常划算，工业现场不缺那1毫秒，缺的是对早期小火苗的敏感度。

3.2 Neck与Head的针对性优化

Neck部分延续了特征金字塔的融合思路，但YOLOv26把融合路径做了加权处理。原来的特征金字塔结构做特征融合时基本是简单相加，而加权融合会让网络自动学习不同层级特征的贡献权重。具体到我们的场景，烟雾目标往往在低层特征上信号更强，因为它的纹理是弥散的、低频的；火焰的高频边缘信息则在高层更明显。加权的意义就是让模型自己决定“该信哪一层”，而不是一刀切地平均。

Head部分，YOLOv26采用了动态标签分配策略。老版本模型大多用静态IoU阈值给检测框分配标签，动态分配会把预测质量也纳入匹配过程，类似任务对齐的做法。这个改动在小目标多的场景里作用尤其明显：小目标的先验框和真实框的IoU天然偏低，静态阈值很容易把本该参与训练的小目标误判成负样本，导致模型对它们视而不见。

多尺度检测头的设计也值得一提。三个检测头分别对应大、中、小目标，小目标头在高分辨率特征图上做预测。后面针对棉纤场景我又做了一次自定义：把小目标头的下采样倍数从8降到4，直接用更高分辨率的特征图来检测小火焰和早期烟雾。代价是计算量上升，但换来的是最核心指标——小目标召回率的明显提升。这个改动属于典型的“为业务定制结构”，通用模型不会替你考虑到。

3.3 为什么最终锁定YOLOv26

我做模型选型对比的习惯是：固定同一份数据、同一个batch size、同样的训练轮次，只看相对差距，不看绝对分数。对比结果大致如下，模型均为同输入尺寸640乘640，同一台设备上测试：

客观说，这些绝对数值只有相对意义，但趋势很明确：YOLOv26在几乎不掉速度的前提下，把最痛的小目标指标拉高了近5个点，这和它主干里的可变形卷积、注意力机制以及动态标签分配是直接相关的。

除了精度，部署生态是我重点考虑的第二维度。工业项目不是交个模型就完事，要能在现场边缘盒子或工控机上跑起来。YOLOv26官方遍历提供了完整的ONNX导出、TensorRT转换脚本和量化工具，API接口和前几代基本一致，我之前写的推理代码可以直接迁移。这个零迁移成本，对我的项目周期来说和精度一样重要。很多模型精度很高，但导出部署时各种算子不支持，改到怀疑人生，这种亏我不想再吃第二次。

我还有一个选型心得：别光看论文里的COCO指标。COCO数据集以日常物体为主，小目标占比有限，烟雾火焰这种弥散目标在COCO里的表现很难外推到工业现场。有条件的话，一定要自己拿标注好的业务数据跑一轮对比，这才是唯一可信的选型依据。

4. 训练全流程与参数调优实录

4.1 环境配置与训练超参数

训练机器是两张24G显存的卡，PyTorch版本2.1以上，CUDA版本和驱动匹配即可。除了硬件，我在训练前固定做三件准备工作。

第一件，一致性哈希划分数据集。按录制时间段而不是按文件名随机划分，防止同一场景的连续帧同时出现在训练集和验证集里。我之前吃过这个亏：随机划分导致验证集和训练集里有大量高度相似的相邻帧，指标虚高到离谱，现场一跑就现原形。按时间段划分后，验证集的评估结果才真正贴合现场的“没见过”场景。

第二件，统计并核对数据集的边界框宽高比分布。烟雾框宽高比接近1，火焰框竖长比略多一点，整体集中在0.8到1.5之间，所以anchor数量保持默认即可。输入尺寸我用了640，没有盲目开1280，因为边缘设备的算力摆在那里，模型再准，部署跑不动就是白搭。

第三件，设置模型快照策略。每个epoch结束保存一次权重，保存条件同时看验证集loss和mAP，两者都变好才覆盖最优快照，防止后期过拟合把最优解覆盖掉。这个习惯帮我避免过多次“训了300轮，最后要用第220轮的权重”这种尴尬。

训练超参数我贴一份可以直接抄的配置：

# 训练配置示例 batch: 32 epochs: 300 imgsz: 640 optimizer: SGD lr0: 0.01 lrf: 0.01 momentum: 0.937 weight_decay: 0.0005 warmup_epochs: 3 warmup_momentum: 0.8 mosaic: 1.0 mixup: 0.0

这里有两个容易踩的坑。第一个是SGD和AdamW的选择。很多教程默认AdamW，但在中小规模数据集的目标检测任务上，SGD配合理的warmup往往泛化更好。我实测SGD最终的mAP比AdamW高约2个点，而且SGD后期更稳，不容易在验证集上瞎震荡。第二个坑是mosaic增强。烟雾火焰这类弥散目标经过mosaic裁剪后很容易碎，模型会学到“残片”而不是完整目标。我这版最终把mosaic概率降到0.5，mixup直接关掉，小目标AP反而回来了一个点。这类增强手段是为通用目标设计的，对强纹理、小目标任务需要重新评估。

4.2 loss曲线与指标变化复盘

训练过程中最重要的不是看最终mAP，而是看loss三条线（box、cls、dfl）的下降趋势。我复盘这次训练的几个关键节点：

前20个epoch，loss从初始值快速下降，box loss和cls loss同步减小，没有明显震荡。第60到100个epoch，cls loss下降变缓，box loss还有一点波动，此时验证集的mAP在缓慢爬升，说明模型在学习边界框的精细调整。这时候最忌讳的就是因为loss不动而乱调学习率，会前功尽弃。第150个epoch之后，验证mAP增长趋平，我开始重点盯过拟合迹象——训练loss还在降、验证loss开始回升。早停机制在240个epoch左右触发，最终就停在那里。

最终验证集表现：火类mAP50-95约61分，烟类约55分，综合约58分。坦白说这个数字不算惊艳，但把它换成业务指标就非常能说明问题。在真实现场回放视频上，从烟雾出现到首帧检出平均耗时控制在0.5秒以内，火焰检出几乎都是第一帧就命中。检出延迟对消防报警来说是生命线，这个指标比我多刷好几个点的mAP都重要。指标是给人看的，业务是给自己和甲方扛的。

我做了一组消融实验，验证关键改动各自的贡献，结果列出来供参考：

消融实验的价值不在于证明某个模块“多牛”，而在于让你知道哪些改动是真正在起作用。后面做量化和剪枝的时候，我会优先保住这些关键模块的精度，其他不那么敏感的部分可以大胆压缩。

5. 推理提速与边缘部署实战

5.1 剪枝、量化和导出

模型训练完只是第一步，工业现场真正考人的是部署。棉纺仓库里不会放服务器，现场基本都是边缘盒子或者很老的工控机。我这次的目标设备是一块算力约8TOPS的边缘计算卡，必须把推理压到实时才行。

第一步做结构化剪枝。我按BN层的gamma值排序，把贡献小的通道剪掉，再做逐层敏感度分析，确定每层合适的剪枝比例。目标是把参数量压到原来的40%左右。剪枝后精度大概掉了2个点，然后我用原训练集做了20轮微调，精度基本回到95%以上。这里要提醒：剪枝比例不是统一的，不同层敏感度差异极大，千万别图省事给所有层设一样的比例。有一层我当时多剪了10%的通道，那一层的输出特征就明显退化，精度直接往下掉。

第二步做量化。量化这里有个坑：烟雾火焰模型的激活值分布和常规目标不一样，暗背景下很多通道的激活值接近0，如果直接做训练后量化，精度掉得很厉害。我实测PTQ量化后mAP掉了4到5个点，后来改用量化感知训练，把精度损失压缩到1.5个点以内。所以如果你的部署链路允许，强烈建议直接上QAT，别在PTQ上浪费时间。很多教程告诉你PTQ又快又方便，但那些教程很少提到它在极端分布任务上的惨痛表现。

第三步导出。统一走ONNX再转TensorRT的路线。这里要仔细核对动态输入维度和每层精度设置，特别是用到可变形卷积的层，在TensorRT转换时容易出兼容问题。我最后把含有可变形卷积的层单独保留FP16精度，其余层用INT8，速度和精度的平衡点在这里最合适。转换过程中会遇到各种算子不支持的报错，别急着换模型，多数情况可以通过升级TensorRT版本来解决，或者把出问题的层拆成普通卷积替换掉。

5.2 边缘设备上的实测数据

部署完成后我在目标设备上跑了一组基准测试：输入640乘640，FP16精度下，单帧推理耗时稳定在22毫秒左右，大约45帧每秒。换成INT8量化后，耗时降到16毫秒。现场我采用的是每秒抽2帧检测的策略，算力余量非常充足，甚至可以同时跑两路视频流。

这里我想强调一个工程习惯：做软硬件一体验证，不要在开发机上测完就上线。边缘设备的散热、降频、内存带宽都跟开发机差一个量级。我在现场实测时发现，连续运行半小时后边缘盒子因为温度升高而自动降频，推理耗时从22毫秒慢慢涨到35毫秒。后来加了散热片、限制了共享内存占用，才把耗时压回25毫秒以内。如果没有这一步验证，预警延迟会随时间逐渐恶化，在消防场景中这个隐患是致命的。

部署架构上也做了一点设计：检测线程和报警线程分离。检测线程只负责推理，把结果写进环形队列；报警线程消费队列，做连续帧确认和告警去抖。连续3帧都检出且置信度超过阈值才触发报警，避免单帧误检导致误报。现场实测下来，这个去抖策略把误报率降低了大约70%，同时没有明显增加漏报概率。时序去抖的好处是零成本，不需要任何额外算力，只需要在软件逻辑上多写几行代码。

6. 现场误检与漏检的排查手册

6.1 典型的误检场景与对策

部署到现场以后，误检是每天都要面对的事情。我整理了三个最典型的场景，每个都是实测踩出来的，给你当排查手册用。

场景一：车间喷雾加湿系统的水雾。棉纺车间为了防静电和保湿，会装高压喷雾，水雾在灯光下和烟雾在视觉上非常像。对策分两步：第一，把喷雾区域附近的摄像头安装位置调高，避开喷雾覆盖区；第二，在检测后处理里加一条区域规则，对固定喷雾区域附近的检测结果做延迟告警，需要连续更多帧确认才触发。这个方案比单纯调模型参数更可靠，因为成像干扰来自物理层面，模型再强也绕不开光学上的相似性。

场景二：叉车尾气和柴油机排烟。仓库里叉车进出频繁，排气管冷启动时会喷出一团白烟，持续时间约1到2秒。这个靠时序去抖就能解决，但要注意一个细节：打火瞬间的烟形和早期火灾烟雾在纹理上几乎没有区别，去抖窗口不能设太大，我最后定在3帧，既滤掉了叉车短时烟，又不耽误火灾告警。如果你设成5帧以上，真火灾的报警延迟就不好看了。

场景三：灯光频闪和镜头眩光。夜间仓库的应急灯频闪，或者摄像头正对门口、阳光直射产生的眩光，会形成高亮区域，火焰检测头偶尔会把这类区域当成火焰。我的处理思路是在后处理里加一个“置信度阈值随时间动态调整”的策略：白天亮度高时提高火焰阈值，夜间亮度低时降低阈值。同时利用火焰的闪烁特征做时域校验，真实火焰的亮度波动频率和灯光频闪固定频率有明显差异，用轻量级频谱统计就能区分大部分光源干扰。

我把这几个场景整理成一个速查表，方便你在现场快速对照：

6.2 漏检问题与样本反馈闭环

漏检比误检更严重，因为误检最多是烦人，漏检是安全事故。我遇到的两类漏检，一类是远处小火焰，一类是超淡烟雾。

远处小火焰的漏检，本质是小目标特征不足。我除了把检测头下采样倍数降到4，还在后处理上做了多尺度推理，部署时同时跑640和960两个输入尺寸，对小目标的召回率提升明显，代价是算力翻倍。后来发现算力吃紧，我就改成“自适应分辨率”：白天光线好时跑640，夜间光线差时跑960，因为夜间小火焰的可见度本身更低，更需要高分辨率输入。动态切换的逻辑很简单，按画面的平均亮度值做判断，一行代码的事。

超淡烟雾的漏检则更考验数据闭环。我在现场发现，有一个位置的烟雾是浅灰色，和背景融合度极高，模型几乎完全检测不到。排查半天才找到原因：那个摄像头对着白色墙面，逆光条件下烟雾对比度极低。这类问题单纯靠模型很难解决，只能靠现场工程调整。我把该摄像头的曝光参数改成低曝光高增益，让烟雾灰度和墙面的差异稍微拉大一点，同时把这一路视频加入了“人工复核名单”。检测模型只是第一道防线，系统还允许值班人员在客户端上手动确认画面区域并手动报警。工业项目的安全感，从来不是靠单一模型扛起来的。

最后说一个我现在固定养成的习惯：把每一次误检和漏检都截图存档，不打标签、不分类，直接丢回数据集。然后每隔两周做一次增量训练，把新样本融进原始训练集重新训一遍。这个“现场反馈-样本回流-增量训练”的闭环，才是系统长期稳定运行的根本保障。模型不是训完就完事的，它是和现场共同演化的。原始训练集再精心设计，也不可能覆盖现场未来半年内所有可能的光照、灰尘、季节性场景变化，只有让数据持续回流，模型才能跟得上现场的变化。

如果要我给出一句最直接的落地建议，那就是：从项目第一天就开始记录误报和漏报截图，别等上线之后再补课。我在这个习惯上吃过亏，前期偷懒了几周，后面补数据、重训练、调后处理的成本，比当时每天花十分钟截几张图要高得多。这个项目做完，我最深的体会是，视觉检测系统落地，精度和速度只是入场券，真正决定成败的，是你能不能把现场的人、现场的光线、现场的灰尘都算进系统设计里。数据回流机制、时序去抖策略、分辨率自适应，这些看起来不起眼的小工程，每一个都比“把mAP再刷两个点”更能救火。这条经验，我是用真金白银的代价换来的。