简介这是一份面向火焰烟雾检测应用开发者的YOLOv8模型与配套数据集资源。模型基于PyTorch框架训练完成可直接用于推理和二次开发数据集包含标注好的火焰fire与烟雾smoke样本标签为txt格式方便训练、验证和微调适合安防监控、早期火情预警等场景也适合有一定目标检测基础的学习者作为实战参考。压缩包共2000个文件约339.34MB其中1984个txt为各类标签文件13个md为说明文档2个pdf可提供检测结果参考另有1个yaml配置文件用于描述模型与数据格式。目前已有1370人学习浏览配套的检测结果与数据集说明可在作者博客查看便于对照效果。整包结构清晰下载后可按README目录快速上手从数据准备到模型调用形成完整闭环能显著缩短火焰烟雾检测项目的落地周期。1. 拿到YOLOv8火焰烟雾检测模型和数据集后先想清楚怎么验证再动手火焰烟雾检测这几年已经从实验室走向了工厂车间、森林防火、储能电站等真实场景。市面上能拿到的YOLOv8训练好的火焰烟雾检测模型权重以及配套的标注数据集其实不少但绝大多数人拿到手的第一步就是急着跑推理看到几个框就以为大功告成。实际踩过坑的人都知道火焰烟雾检测和行人检测、车辆检测完全不一样烟雾形态多变、火焰边缘模糊、光照条件剧烈波动模型在训练集上表现不错换到现场监控画面往往会翻车。下面会从模型和数据集的结构讲起给出最小可复现的推理和微调流程再把落地过程中最容易出问题的几个点逐一拆开讲清楚适合刚拿到权重和数据集、准备往项目里集成的开发者。2. 火焰烟雾检测的模型选型与数据集构成YOLOv8为什么是稳妥起点2.1 火焰烟雾检测与普通目标检测的差异先说一个最常见的认知误区有人直接把通用目标检测的权重拿来识别火焰结果漏检率高得离谱。原因在于火焰烟雾在视觉特征上和普通物体有本质区别。普通物体有稳定的边缘、纹理和内部结构而火焰是半透明的边缘在持续抖动烟雾更特殊它是半透明的弥散体边界模糊到人眼都很难画出一个准确的框。检测模型依赖边界框回归来学习位置这两类目标的框本身就不稳定模型学起来自然比车辆行人这类规则目标困难。说深一层火焰烟雾的检测线索往往是多模态的。颜色火焰的橙红色、烟雾的灰白色、纹理火焰的跳动纹理、上下文火焰周围往往有烟雾都在起作用但没有一个单独特征能构建出强判别力。这导致火焰烟雾检测对数据多样性的要求比通用检测更高——同一火焰在不同背景、光照、距离下的视觉差异非常大如果训练集场景单一模型泛化性就会很差。这也是为什么说直接用COCO预训练权重做零样本识别是行不通的。COCO的80个类别里没有火焰和烟雾模型的特征提取层虽然通用但检测头对这两类的响应很弱。用训练好的火焰烟雾模型权重本质上是把网络的检测能力重新校准了一遍让模型学会用火焰和烟雾特有的线索做决策而不是用一个通用物体检测器去猜测。2.2 YOLOv8在火焰烟雾场景的结构与损失函数特点选择YOLOv8而不是YOLOv5或更早的版本有几个结构层面的具体理由。第一是Anchor-Free设计。YOLOv5需要预先聚类生成锚框YOLOv8直接预测目标中心点和宽高少了聚类这一环节。这对火焰烟雾这类尺寸跨度极大的目标更友好——火焰可以小到几十个像素也可以大到占满半屏固定锚框集合很难覆盖这种极端跨度。第二是C2f模块替换了C3模块。C2f在特征提取路径中增加了更多的梯度分支梯度流更丰富浅层特征和深层特征的融合更充分。这对小目标火焰的召回有实际帮助因为小目标主要依赖浅层高分辨率特征图上的响应。第三是解耦检测头把分类和回归分支拆开各自用独立的卷积通道处理训练时梯度互不干扰收敛更稳定。损失函数方面YOLOv8分类分支用BCE损失回归分支用CIoU损失。CIoU在IoU基础上额外考虑了中心点距离和宽高比对于火焰这种宽高比不固定、框边界模糊的目标回归精度比普通IoU损失更稳。以下是一个典型的火焰烟雾数据集类别定义YOLOv8训练时直接读这个yml配置# dataset.yaml 火焰烟雾检测的类别定义 names: 0: fire 1: smoke这里把类别定义为fire和smoke两类是实践中验证过的最稳妥做法。有团队把类别细分成火焰、火光、浓烟、薄烟等多个类别结果类别之间特征重叠严重误检率反而上升。火焰和烟雾在视觉上经常同时出现模型把这两类作为两个独立类别去学各自的特征边界反而更清晰业务侧也只需要知道该区域是否有火情。常见的数据集规模并不大在几千张到几万张的水平浮动YOLOv8在这种中等规模数据上的拟合能力和收敛速度都很合适。2.3 数据集标注格式与目录结构拿到手的数据集最常见的组织方式是YOLO格式的txt标注配合images和labels两个目录。每个txt文件名与对应图片名一致一行代表一个目标框。标注文件里的格式为类别ID、归一化中心点x、归一化中心点y、归一化宽、归一化高。以下是一个标准目录结构dataset/ ├── images/ │ ├── train/ │ │ ├── fire_001.jpg │ │ └── smoke_014.jpg │ └── val/ ├── labels/ │ ├── train/ │ │ ├── fire_001.txt │ │ └── smoke_014.txt │ └── val/ └── dataset.yaml标注文件内容示例一行代表一个检测框0 0.53125 0.4921875 0.30625 0.51875 1 0.70234375 0.384375 0.1765625 0.3625这两行的字段含义用一张表列出来更直观字段第1行示例含义类别ID00代表fire1代表smoke中心点x0.53125目标框中心点在图像宽度的53.125%处中心点y0.4921875目标框中心点在图像高度的49.22%处框宽0.30625目标框宽度为图像宽度的30.625%框高0.51875目标框高度为图像高度的51.875%这里要特别强调YOLO格式存的是归一化坐标取值范围是0到1而不是像素坐标。这一点很多人会搞混。后续如果要把标注转成VOC的XML格式或者COCO的JSON格式需要先做反归一化乘以图片宽高还原像素坐标否则会在转换时直接爆框。数据划分建议按8:1:1做训练验证测试划分但要注意火焰烟雾数据常常来自连续视频帧同一个监控点位的连续帧如果在划分时随机散布到训练集和验证集验证分数会虚高。正确做法是先按视频片段或场景分组再整体划分。3. 用训练好的火焰烟雾模型跑通推理最小命令与三个必调参数3.1 环境配置与权重加载拿到YOLOv8火焰烟雾检测模型的权重文件后缀通常是.pt这是PyTorch的序列化格式。首先要确认这个权重是由哪个版本的ultralytics库训练出来的因为模型文件本身记录了结构信息如果用不兼容的库版本加载大概率会报错。环境安装一条命令就能完成pip install ultralytics装完后不要直接跑业务代码先做一个最小加载测试确认权重和库版本匹配from ultralytics import YOLO # 加载训练好的火焰烟雾检测权重 model YOLO(fire_smoke_best.pt) # 打印模型结构确认加载成功 print(model.model)这里有一个经验如果加载时报错提示权重键名不匹配或者出现size mismatch的报错大概率不是权重文件损坏而是库版本不一致。我遇到过一次这种情况当时花了大半天时间怀疑权重文件的问题最后发现是环境里的ultralytics版本被升级了。处理办法很直接把ultralytics固定到训练时的大版本可以避免这类兼容性问题。提示如果你的ultralytics版本过新加载旧权重时出现size mismatch优先降级库版本而不是修改权重文件。3.2 单图推理代码与参数说明模型加载成功后对单张图片做推理是整个落地流程的起点。以下代码是完整的单图推理流程包含了火焰烟雾场景下最值得关注的几个参数from ultralytics import YOLO model YOLO(fire_smoke_best.pt) # 单张图片检测 results model.predict( sourcetest_fire.jpg, # 输入图片路径 conf0.25, # 置信度阈值,低于此值的框被过滤 iou0.45, # NMS的IoU阈值 imgsz640, # 推理输入尺寸 saveTrue, # 保存标注后的图片 save_txtTrue, # 导出检测结果的txt标注 show_confTrue # 在框上显示置信度 )这里三个参数在火焰烟雾场景里最值得反复调。conf控制置信度阈值默认0.25但火焰烟雾场景经常要改误检多就往高了调漏检多就往低了调后面避坑章节会具体展开。iou控制NMS合并策略火焰和烟雾的目标经常紧挨着iou设置太高会把两个不同目标的框合并成一个一般保持在0.45到0.5之间比较稳。imgsz这个参数同样不能忽视。它必须与训练时的输入尺寸保持一致。如果训练时是640推理时改成1280模型看到的特征尺度变了小目标火焰的检测结果不会变好反而可能变差。这是因为模型在固定输入尺寸下学到的特征尺度是特定的盲目放大输入只能增加计算量并不会按比例提升精度。3.3 视频流推理与业务侧帧间投票真实项目里很少只检测单张图片更多的是接摄像头视频流。视频推理需要注意的点比单图多一个量级先看标准代码from ultralytics import YOLO model YOLO(fire_smoke_best.pt) # 视频流推理,streamTrue按帧返回结果 results model.predict( sourcecamera_feed.mp4, # 也可以是摄像头RTSP地址 conf0.30, iou0.45, imgsz640, streamTrue, # 生成器方式逐帧输出,避免内存爆炸 devicecuda # GPU加速,无显卡改为cpu ) # 帧间投票统计:连续N帧检测到fire才告警 frame_count 0 for result in results: boxes result.boxes fire_count sum(1 for c in boxes.cls if int(c) 0) if fire_count 0: frame_count 1 if frame_count 5: print(触发火焰告警) frame_count 0 else: frame_count 0streamTrue这个参数在视频推理中非常关键。如果不设置YOLO会尝试把整个视频读入内存再统一推理长视频会直接打爆内存。改用生成器方式逐帧处理内存占用可以保持恒定。device参数指定计算设备有独立显卡且装好CUDA就用cuda没有就只能用cpu但要注意CPU推理的速度会慢很多640分辨率的帧在桌面级CPU上大概每帧150到300毫秒只能算勉强可用。如果接入的是RTSP摄像头流还有一个容易忽略的点视频解码是CPU密集操作当摄像头路数增加时CPU会先于GPU成为瓶颈。常见做法是先用FFmpeg或OpenCV把RTSP流解码成帧再送入推理队列解码和推理用两个独立线程跑避免互相阻塞。这个架构层面的调整对路数多的项目比单纯调参更有效。还有一个业务层面的细节值得单独强调。单帧的误检率在视频场景下会被放大——模型偶尔在一帧中把水雾识别成烟雾如果每一帧都触发告警系统就废了。常见的做法就是上面代码里的帧间投票连续N帧都检测到火焰才触发告警N一般取3到5。这个逻辑应该放在业务代码里而不是模型推理里保持模型的纯净性方便后续独立升级模型或修改业务规则。4. 数据集拆分与二次微调从现成权重到自己的部署版本4.1 标签质量自检与坐标还原脚本拿到数据集后第一个步骤不应该是直接开始训练而是检查标注质量。火焰烟雾数据集的标注质量参差不齐常见问题包括标注框过大把背景包进去了、小目标火焰漏标、类别标反。一个快速的自检方法是把标注框画回图片上看一遍。以下是坐标还原和绘制的脚本import cv2 def draw_yolo_labels(image_path, label_path): img cv2.imread(image_path) h, w img.shape[:2] with open(label_path, r) as f: for line in f.readlines(): cls, x, y, bw, bh map(float, line.strip().split()) # 归一化坐标还原为像素坐标 x1 int((x - bw / 2) * w) y1 int((y - bh / 2) * h) x2 int((x bw / 2) * w) y2 int((y bh / 2) * h) color (0, 0, 255) if int(cls) 0 else (128, 128, 128) cv2.rectangle(img, (x1, y1), (x2, y2), color, 2) return img # 抽查样本,人工确认标注框是否贴合目标 img draw_yolo_labels( dataset/images/train/fire_001.jpg, dataset/labels/train/fire_001.txt ) cv2.imwrite(check_label.jpg, img)这段脚本的坐标转换逻辑是框左上角的像素x坐标等于中心点x减去宽度的一半再乘以图像宽度。如果画出来的框明显偏移或者框住了大片无关区域说明这条标注的质量有问题。这种有问题的样本如果直接参与训练模型会在学习时引入噪声表现出的症状是训练loss降得很快但验证集精度上不去。标签自检通过后才做数据划分。我建议的做法是先把样本按来源场景分组比如同一个视频片段、同一个监控点位的画面归为一组再把整组按比例划入训练集或验证集。这样能确保验证集里的场景是模型训练时没有见过的得分才有参考价值。随机划分虽然操作更简单但会高估模型的真实泛化能力这一点在火焰烟雾场景中尤其明显因为同一场景的连续帧之间高度相似。4.2 微调训练的YAML配置与超参数用现成的训练好的火焰烟雾模型继续微调比从零开始训练的成本低得多收敛也快。关键是要写对训练配置和超参数。以下是一条完整的微调训练命令yolo detect train \ datadataset.yaml \ modelfire_smoke_best.pt \ epochs50 \ imgsz640 \ batch16 \ lr00.001 \ optimizerauto \ patience10 \ projectfinetune_run \ namefire_smoke_v2核心参数的含义和设置理由用表格列出来参数设置值理由modelfire_smoke_best.pt在已有权重上继续训练复用已学特征epochs50中等数据规模下50轮足以收敛lr00.001微调场景比从零训练低一个数量级batch168GB显存的上限显存不足降到8patience10连续10轮验证集不提升则提前停止imgsz640与训练时输入尺寸保持一致这里面的参数选择有明确的逻辑。model参数传的是已有权重文件YOLOv8会在这个权重的基础上继续训练而不是从COCO预训练权重重新开始这相当于站在已有特征的基础上调整。epochs取50是一个平衡点火焰烟雾数据集普遍规模不大50轮足够模型充分学习继续增加轮数容易过拟合。patience10是防止过拟合的保险丝验证集指标连续10轮没有提升就自动停止。lr0取0.001这个细节值得多说一句。从零训练一个新模型学习率0.01是常见起点但微调场景下学习率必须调低因为已有权重里的特征提取层已经学习到了有效的视觉特征学习率太高会把这些特征破坏掉训练初期会出现loss剧烈震荡。如果发现训练开始阶段loss不降反升第一个要查的就是学习率是不是太高。4.3 训练日志解读与权重选择训练结束后在project/name这个输出目录下会生成weights子目录里面有best.pt和last.pt两个权重文件。best.pt是验证集上综合指标最好的权重通常直接用它做部署。但有一个例外需要留意如果验证集的场景分布与你的实际应用场景差异很大best.pt在验证集上的高指标可能不能完全代表真实场景的表现。我一般的做法是训练结束后不急着把best.pt部署出去而是先用自己的测试视频在best.pt和last.pt上各跑一遍对比实际画面中的检测效果。测试视频里应该包含真实场景的正样本和负样本。某些情况下last.pt在实际场景中的表现反而比best.pt更稳因为验证集上的指标波动不能完全反映场景层面的视觉差异。训练过程中还要关注过拟合信号。观察训练日志里的loss曲线如果训练loss持续下降而验证loss开始回升说明模型开始过拟合训练集。这时候有两个选择一是从历史权重中找出验证loss最低的那个轮次二是调整训练策略比如降低epochs或增强数据增强。很多人在训练完成后直接拿last.pt去部署除非你能确认训练轮次远未达到过拟合点否则这并不稳妥。5. 火焰烟雾模型落地避坑5个高频问题与排查记录这一章是我实际使用中踩过坑的集合每条都按现象、原因、解决三步说清楚。5.1 误检严重白云、水雾、蒸汽被识别为烟雾现象模型在室内火焰测试集上表现很好部署到户外后白云和水雾被大量识别为烟雾误报率高到没办法正常使用。原因烟雾本身的视觉特征就是半透明、边缘模糊、颜色偏白灰。在户外光照条件下白云和水雾在二维图像上和烟雾高度相似。训练数据如果以室内场景为主缺乏带负样本的户外数据模型就学不会区分这些易混淆物体。解决收集只包含白云、水雾、蒸汽但没有火焰和烟雾的负样本图片加入训练集重新微调。负样本的标注文件为空文件代表图中没有任何目标。这一步对户外场景效果立竿见影实测能把误检率降低一半以上。再补一个业务层的辅助手段真实烟雾有运动和扩散特性而静止的云和水雾在连续帧中几乎不动利用帧间运动一致性做二次过滤可以再压掉一部分误检。5.2 小目标火焰漏检现象远处的初期火苗、画面角落的小火种模型完全输不出检测框或者置信度低到被默认阈值过滤掉。原因火焰烟雾数据集中小目标占比天然偏低。标注人员在标注时倾向于优先框选大而明显的火焰画面里的小火焰容易被遗漏导致训练数据中该类样本不足。YOLOv8对中等和大尺寸目标的检测能力已经很好但数据分布不均衡时小目标问题依然突出。解决第一检查训练集里小目标的占比偏低时通过复制粘贴增强或重采样扩增这类样本。第二推理时把imgsz从640提高到960甚至1280小目标的特征在更大的输入分辨率下更容易被激活前提是显存和时间预算允许。第三降低conf阈值到0.15配合帧间投票使用用时间维度上的连续确认来换单帧精度。5.3 夜间与强光照场景检测波动大现象白天检测正常到了夜间或逆光强光环境火焰检测的置信度波动很大忽高忽低甚至出现漏检。原因火焰烟雾的视觉特征和光照条件密切相关。白天阳光下的火焰颜色和夜间的火光在色温、亮度和对比度上都有明显差异训练数据如果以白天样本为主模型对夜间火焰的响应就不稳定。更极端的情况是监控摄像头开启红外夜视模式画面变成灰度图颜色特征直接失效依赖火焰橙红色先验的模型可能完全失去工作能力。解决针对部署场景做数据适配。如果现场以夜间监控为主就在训练数据中加入红外夜视模式的火焰烟雾样本单独微调出一版夜间权重。如果白天夜间都要支持准备两套权重按时间段切换这是实践中验证过最稳妥的办法虽然听起来不够智能但可靠度最高。5.4 视频流推理掉帧严重现象GPU推理单张图片时速度可以接受但接视频流后帧率直线下降CPU版本卡顿到没法实际使用。原因视频流是连续帧处理每一帧完整推理的计算量很大。很多人忽略了帧率采样问题——每一帧都跑推理而且推理分辨率经常设得很高导致算力被白白消耗。解决第一个手段是抽帧推理每2到3帧跑一次检测中间帧沿用最近一次检测结果。火焰烟雾属于缓变目标每秒抽5到10帧足够用这个操作能直接拉高视频处理吞吐。第二个手段是缩小推理尺寸在精度可接受前提下把imgsz降到480计算量几乎减半。第三个手段是模型加速把PyTorch权重导出为ONNX再转成TensorRT引擎部署推理延迟可以降低一个数量级这部分在下一章展开。5.5 类别不均衡导致偏向性输出现象训练集里火焰标注远多于烟雾训练出来的模型对烟雾的召回率明显偏低纯烟雾场景经常完全没有检测框。原因数据分布不均衡。训练过程中模型迭代火焰样本的频次远高于烟雾样本烟雾的特征学习不充分这是一个数据问题而不是模型结构问题。解决最直接的方案是过采样烟雾样本让两类目标的数量大致平衡。我更倾向于在数据层面解决而不是在损失函数里加类别权重因为数据层面的平衡效果更可预期。另外一个被验证过的思路是把fire和smoke合并成单个fire_smoke类别重新训练对很多业务场景来说只需要知道这个区域有没有火情不需要区分是火焰还是烟雾合并后类别特征更集中检测稳定性反而更好。6. 火焰烟雾模型上线前的两个习惯ONNX加速与置信度校准模型在目标场景下能稳定工作之后剩余的两个优化方向最值得投入一是通过ONNX和TensorRT把推理速度提上去二是通过置信度校准把误报控制住。先看加速。把PyTorch权重导出为ONNX格式的命令很简单yolo export modelfire_smoke_best.pt formatonnx imgsz640导出之后可以由ONNX Runtime接入TensorRT后端生成高度优化的推理引擎。这一步通常能把推理延迟降到PyTorch动态图推理的四分之一甚至更低对视频流整体帧率提升非常显著。导出时还有一个细节如果部署环境固定就使用固定输入尺寸导出让引擎在静态形状下做最大优化只有在需要多分辨率输入的边缘场景下才打开动态轴选项但那样引擎会牺牲一部分推理速度。再谈置信度校准这是我个人认为很多人会忽略但收益很高的步骤。训练时的置信度分布和真实场景并不一定匹配。方法很简单准备一段没有火焰烟雾的日常监控视频跑一遍推理统计模型在无火情画面中输出的最高置信度。这个值就是误检基线比如模型在正常画面里偶尔输出0.3左右的虚警分数那么conf阈值应该设置在0.45以上留出安全余量。这个操作只需要一个推理脚本和一段视频就能完成不需要重新训练但对系统稳定性的提升立竿见影。这两个习惯加上前面提过的回归测试集形成一个固定的上线检查动作每次模型更新后先在回归测试集上对比检测率和误报率再跑一版置信度校准最后决定是否部署。我从一开始也踩过只顾着调参、不看负样本表现的坑后来养成的习惯是模型更新前固定跑一遍回归和基线校准靠这个习惯在一次模型更新中提前发现了置信度偏移问题避免了一次上线事故。希望帮到你。本文还有配套的精品资源点击获取