简介：面向安全监控与火灾预警场景的YOLOv5烟雾检测工程包，适合具备一定深度学习基础、希望快速复现目标检测流程的开发者与学习者，重点解决烟雾数据标注、模型训练及部署验证问题。压缩包约360.52MB，共2000个文件，以jpg烟雾图像、txt标注文件、xml原始标注、yaml数据与模型配置、py训练推理脚本和pt已训练权重为主，同时附带md说明文档及Docker相关部署文件，目录按数据、代码与配置组织，便于检索和二次开发。已有2357人学习下载。包内提供的已训练模型与带标签数据集覆盖多种光照、角度和背景条件，可直接用于检测效果验证，也可作为迁移学习起点；配合训练脚本和配置文件，读者能够复现训练过程、调整参数并接入监控视频流或无人机巡检等应用，较快搭建烟雾预警原型。
1. 仓库监控里先看到烟而不是火，这套YOLOv5方案能省掉从零标注的功夫
工厂仓库的监控画面里，烟往往先于明火出现，但传统烟感探头要等烟飘到天花板、浓度攒够才报警，中间那几分钟正是处置窗口。视觉方案能在画面里直接把烟雾区域框出来，把报警往前挪。这份基于YOLOv5的烟雾检测资源，把训好的权重和配套数据集一起打包，拿到手不用从零标注、不用从零训练，先跑通推理看效果。它适合两类人：一类是想快速验证视觉烟雾检测可行性的开发者，一类是已经在做安防、工业监控，需要把烟雾识别接进现有业务流的团队。数据集和模型都在，意味着你可以先在本地把链路跑通，再决定换不换数据、调不调参数、怎么做部署。
2. 项目结构与技术栈：目录里每个文件夹对应哪一步
2.1 目录骨架与各模块职责
拿到一个目标检测项目，我习惯先看目录结构，因为它基本决定了后面每一步要动哪个文件。这类YOLOv5烟雾检测项目，骨架通常是下面这个样子，不同打包方式会有细微出入，但核心目录不会变：
smoke-detection/ ├── data/ │ ├── images/ │ │ ├── train/ # 训练图片 │ │ └── val/ # 验证图片 │ ├── labels/ │ │ ├── train/ # 训练标注（.txt，与图片同名） │ │ └── val/ # 验证标注 │ └── smoke.yaml # 数据集配置文件 ├── models/ │ └── yolov5s.yaml # 模型结构配置 ├── weights/ │ └── best.pt # 训好的权重 ├── detect.py # 推理入口 ├── train.py # 训练入口 ├── val.py # 验证入口 ├── export.py # 导出 ONNX/TensorRT 等格式 ├── requirements.txt # 依赖清单 └── utils/ # 数据加载、增强、指标等工具data/是数据的落点，images/和labels/必须保持同名对应，图片叫0001.jpg，标注就得叫0001.txt，差一个字符都读不到。models/放的是网络结构 YAML，weights/放的是训练产出的.pt权重，这两个不是一回事——前者描述「网络长什么样」，后者是「训练后参数是多少」。detect.py、train.py、val.py是三个最常用的脚本，分别对应推理、训练、验证。utils/里通常藏着数据增强、损失计算、NMS 后处理这些逻辑，二次开发时改得多的地方就在这里。
我一般会先打开requirements.txt和smoke.yaml各看一眼：前者决定环境能不能一次装好，后者决定类别数对不对。这两个文件是后面所有步骤的地基，先确认它们，比上来就敲命令稳得多。
2.2 选YOLOv5做烟雾检测的取舍
烟雾这个目标和行人、车辆不一样，它没有固定形状，边缘是弥散的，半透明，颜色偏灰白，跟背景对比度低，还特别容易跟云、雾、蒸汽、白色墙面混在一起。这些特性决定了检测器要能处理「边界模糊 + 多尺度 + 低对比度」的情况。YOLOv5 能被拿来做一个开箱即用的烟雾检测方案，原因有几个。
一是单阶段结构，推理速度快，放到实时视频流上不会成为瓶颈。烟雾检测很多时候是「持续看画面」的场景，FPS 掉下去体验就崩了。二是多尺度特征融合，P3/P4/P5 三个检测头分别管小、中、大目标，烟雾从刚起的一小团到铺满画面的大片，都能覆盖到。三是工程化程度高，train.py、val.py、detect.py、export.py一整套脚本齐了，从训练到导出一气呵成，不用自己拼流程。四是权重格式通用，.pt能直接转 ONNX、TensorRT，后面往边缘设备上挪也方便。
代价也要说清楚：YOLOv5 是基于 Anchor 的，烟雾这种形状不规则的类别，Anchor 的匹配不如对规则目标那么「贴」，所以训练时对数据增强和 Anchor 的调整要更小心；另外半透明目标本身信息量少，单帧检测的置信度容易抖，实际落地常常要加多帧确认。这些不是 YOLOv5 独有的毛病，换任何检测器都绕不开，只是用它起步最省事。
2.3 权重、配置、数据集三件套怎么对齐
这三样东西对不上，是新手跑不通最常见的原因。关系可以这么记：smoke.yaml里的nc（类别数）和names（类别名）必须跟权重训练时的设置一致；models/yolov5s.yaml里的nc也要跟数据一致；best.pt里已经存了训练时的类别信息，推理时如果传了--classes，索引要对得上。
# data/smoke.yaml path: ./data # 数据集根目录，相对路径按脚本运行位置算 train: images/train # 训练图片目录（相对 path） val: images/val # 验证图片目录（相对 path） nc: 1 # 类别数，只检测烟雾就是 1 names: ['smoke'] # 类别名，顺序要和标注里的 class id 对应path是个容易被忽略的参数，它决定了train和val的相对基准。很多人把train写成绝对路径，结果换台机器就挂；也有人path写错，脚本报「找不到图片」但其实图就在硬盘上。我一般统一用相对路径，并且从项目根目录执行命令，这样路径始终可预期。
nc和names的关系是：标注文件里每行第一个数字是类别索引，从 0 开始。如果只有烟雾一类，索引就是 0，names写['smoke']；如果数据集把「烟」和「火」分开标，那就是nc: 2、names: ['smoke', 'fire']。权重是在哪套配置上训出来的，推理和验证就得用哪套，混用会导致类别错位——检测框还在，但标签全错，这种问题不看输出根本发现不了。
3. 环境搭建与推理跑通：先让模型在本地框出第一团烟
3.1 依赖安装与版本对齐
目标检测项目的环境比普通 Python 项目敏感，PyTorch、CUDA、torchvision 三者版本要对上，否则要么装不上，要么跑起来报一堆底层错误。常见做法是先建独立环境，再按requirements.txt装：
# 建独立环境，避免和系统里其他 torch 版本打架 conda create -n smoke python=3.9 -y conda activate smoke # 先装和本机 CUDA 匹配的 torch，再去装其余依赖 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 # 装项目其余依赖 pip install -r requirements.txt第一条命令建环境，Python 3.9 是这类项目比较稳的选择，太新太旧都可能遇到轮子缺失。第二条命令装 PyTorch，cu118对应 CUDA 11.8，你得先nvidia-smi看本机驱动支持到哪个版本，再选对应的 wheel；没有 GPU 就把这行换成 CPU 版本。第三条把requirements.txt里其余依赖补齐。
装完做一次自检，确认 torch 能看到 GPU：
import torch print(torch.__version__) # 看版本 print(torch.cuda.is_available()) # True 表示 GPU 可用 print(torch.cuda.device_count()) # 显卡数量三行输出里，第二行是True才说明 GPU 环境通了。如果显示False，先别怀疑代码，九成是 torch 装成了 CPU 版，或者 CUDA 版本和驱动不匹配。这一步不确认清楚，后面训练会莫名其妙慢十倍，还查不出原因。
3.2 用随包权重跑单图、视频和摄像头
环境通了，先用随包权重跑推理，验证整条链路。推理入口是detect.py，最常用的几种 source 都能直接喂：
# 单张图片 python detect.py --weights weights/best.pt --source test.jpg --conf-thres 0.35 # 整个文件夹 python detect.py --weights weights/best.pt --source data/images/val --conf-thres 0.35 # 视频文件 python detect.py --weights weights/best.pt --source smoke.mp4 --conf-thres 0.35 # 摄像头（设备号 0） python detect.py --weights weights/best.pt --source 0 --conf-thres 0.35--weights指向权重文件，这是整个命令的核心；--source支持单图、目录、视频、摄像头、RTSP 流，实际项目里接监控流就是传 RTSP 地址；--conf-thres是置信度阈值，低于它的框会被丢掉。默认结果会写到runs/detect/exp目录下，图片或视频上直接画好框和类别，打开就能看。
如果想把检测结果存成结构化数据而不是只看图，加--save-txt：
# 除了画框图，还把检测框存成 txt，方便后续接业务逻辑 python detect.py --weights weights/best.pt --source smoke.mp4 \ --conf-thres 0.35 --save-txt --save-conf--save-txt会把每个检测框按 YOLO 格式写到labels/下，--save-conf额外把置信度也写进去。这两项在做报警逻辑时很有用——你需要的不是一张画了框的图，而是「第几帧、框在哪、置信度多少」这样的数据，拿去判断要不要触发报警。
3.3 推理结果解析与置信度调参
Python 里直接调模型也很常见，适合把检测嵌进自己的服务：
import torch # 从本地加载自定义权重，source='local' 避免联网拉取 model = torch.hub.load('./', 'custom', path='weights/best.pt', source='local') model.conf = 0.35 # 置信度阈值 model.iou = 0.45 # NMS 的 IoU 阈值 results = model('test.jpg') results.print() # 打印检测摘要 df = results.pandas().xyxy[0] # 转成 DataFrame，列含 xmin/ymin/xmax/ymax/confidence/class print(df)model.conf控制「多确定才算检测到」，调低会出更多框、误报变多，调高会漏掉一些不明显的烟雾。model.iou控制 NMS 合并重叠框的力度，烟雾经常连成一片，两个框重叠度高，iou太低会把同一团烟拆成好几个框，太高又会把相邻的两团烟合并掉。xyxy是像素坐标，confidence是置信度，class是类别索引。
调参这块有个实际经验：烟雾检测宁可多报也别漏报，所以conf可以比通用目标检测调低一些，比如 0.25～0.35 之间，再靠「连续多帧都检出」来压误报。单帧置信度 0.3 的框可能是噪声，但连续 5 帧都在同一位置出现，可信度就高得多。这个后处理逻辑得自己加，模型本身不管。
4. 数据集与训练：标注格式、配置文件和训练命令
4.1 YOLO标注格式与数据集目录
YOLO 的标注是纯文本，每张图对应一个同名.txt，每行一个目标，格式是：
<class_id> <x_center> <y_center> <width> <height>五个值用空格隔开，后四个都是归一化到 0～1 的相对值，不是像素。比如一张 640×480 的图，烟雾框左上角在 (100, 80)、宽 200、高 160，中心点就是 (200, 160)，归一化后x_center=200/640≈0.3125、y_center=160/480≈0.3333、width=200/640≈0.3125、height=160/480≈0.3333，写成：
0 0.3125 0.3333 0.3125 0.3333这里最容易踩的坑是拿像素坐标直接写进去，训练时框会全飘到画面外，loss 居高不下，但脚本不报错，只看日志根本发现不了。判断方法很简单：打开标注文件，五个数里后四个只要有一个大于 1，就说明没归一化。
数据集目录按images/train、images/val、labels/train、labels/val分好，训练和验证各走各的。随包数据集一般已经分好，但如果你自己加数据，记得图片和标注要成对放，漏一个标注文件，那张图就会被当成「无目标」负样本，训出来模型对烟雾更保守。
4.2 数据配置文件smoke.yaml怎么写
配置文件就是 2.3 节那段，核心是path、train、val、nc、names五项。前三个管「数据在哪」，后两个管「类别是什么」。如果数据集带测试集，还可以加一行test: images/test。
有个细节值得说：path用相对路径时，基准是执行train.py时的工作目录，不是smoke.yaml所在目录。所以要么从项目根目录执行命令，要么path直接写绝对路径。我一般把path写成相对于项目根的路径，然后在 README 里注明「请在项目根目录执行」，团队里就不会有人因为换目录跑而翻车。
4.3 训练命令与关键参数
数据配置好了就可以开训，最常用的一条命令：
python train.py \ --img 640 \ --batch 16 \ --epochs 100 \ --data data/smoke.yaml \ --weights yolov5s.pt \ --device 0--img 640是输入分辨率，烟雾目标如果普遍偏小，可以拉到 960 甚至 1280，代价是显存和速度。--batch 16是批大小，显存不够就往下调，8、4 都行，调到不 OOM 为止。--epochs 100是训练轮数，烟雾数据集通常不大，100 轮左右能看到收敛趋势。--data指向配置文件。--weights yolov5s.pt是从官方预训练权重开始微调，比从零训收敛快很多；如果要用随包的best.pt继续训，把这里换成weights/best.pt，但要注意类别数一致。--device 0指定第一块 GPU，多卡就写0,1。
想接着已有权重微调、而不是从头开始，还可以加--resume或者直接指权重路径。训练过程会实时打印每轮的 box loss、obj loss、cls loss 和 mAP，日志默认落在runs/train/exp下，曲线图、混淆矩阵、PR 曲线都在里面。
4.4 训练曲线和验证指标怎么看
训练完先别急着部署，打开runs/train/exp看几张图。results.png里 loss 曲线应该整体下行并逐渐平缓，如果验证 loss 早早开始上扬、训练 loss 还在降，就是过拟合，得加数据或加增强。confusion_matrix.png能看出烟雾和背景的混淆情况，烟雾被大量判成背景，说明召回不够，conf阈值或数据量要调。PR_curve.png看的是不同置信度下的 precision/recall 权衡。
验证单独跑一遍：
python val.py --weights runs/train/exp/weights/best.pt --data data/smoke.yaml --img 640输出的 mAP@0.5 是最常看的指标，但烟雾检测别只盯它。半透明目标框的边界本身就模糊，标注时不同人画的框大小能差一圈，mAP 对框的精确度很敏感，数值不高不代表模型没用。更该看的是「在实际视频上漏检多不多、误报多不多」，这得拿真实场景的视频跑一遍才知道。
5. 避坑与排查：烟雾检测里最容易翻车的几处
5.1 从现象倒推原因
现象一：推理时框全在画面左上角或者尺寸离谱。原因基本是标注没归一化，像素值直接写进了 txt。解决是把标注全部重写成 0～1 的相对值，写个小脚本遍历一遍labels/，发现任一坐标大于 1 就报出来，改完再训。
现象二：训练 loss 正常下降，但验证集 mAP 一直接近 0。先查smoke.yaml的nc和names跟标注里的 class id 对不对得上，再查train和val路径是不是指到了同一批图。还有一种隐蔽情况：图片和标注文件名大小写或后缀不一致（.jpg对.JPG），Linux 下区分大小写，Windows 下不区分，本地训得好、换机器就崩，血泪经验。
现象三：模型在测试图上检出率很高，接到真实监控流上几乎不报。多半是域偏移——训练图是网上找的清晰近景烟雾，监控画面是俯视、逆光、低分辨率、带压缩噪声的。解决办法是拿目标场景的截图补标一批数据做微调，哪怕只有几百张，效果也比在原数据集上堆量明显。烟雾检测这个领域，数据「像不像现场」比「多不多」更重要。
现象四：同一团烟被框成好几个重叠框。这是 NMS 的iou阈值设太低，或者烟雾本身连片导致框重叠。把--iou-thres从默认 0.45 往上调到 0.5～0.6 试试，还不行就在后处理里按框中心距离做一次合并。注意别调太高，否则相邻两团独立的烟会被合成一个。
现象五：显存明明够，训练却报 OOM。常见原因是--img调大了但--batch没跟着降，或者开了--multi-scale让输入尺寸在训练中浮动，峰值显存比固定尺寸高。先把 batch 减半确认能跑，再慢慢往上加，找到这块卡的临界值。
6. 二次开发：把烟雾检测接进自己的业务流
6.1 改造思路
想把这个项目用到自己业务里，改动通常分三层。第一层是数据层：换成本场景的数据，重新标一批，用随包权重做微调，这是性价比最高的一步。第二层是推理层：把detect.py里「读图→推理→画框→存图」的流程拆开，只保留推理和结果解析，接进自己的服务。第三层是后处理层：加多帧确认、区域过滤（比如只关心仓库某个 ROI）、报警去重，这些模型不管，得自己写。
导出成通用格式是接业务的前提：
# 导出 ONNX，方便在非 Python 环境或推理引擎里跑 python export.py --weights weights/best.pt --include onnx --img 640 # 有 TensorRT 环境就顺手导一份，边缘设备上更快 python export.py --weights weights/best.pt --include engine --img 640 --device 0--include指定目标格式，--img要和训练时一致，否则导出后精度会掉。导出的模型去掉了 Python 依赖，能塞进 C++ 服务或者边缘盒子里。
6.2 验证方法
改完之后别只看几张图就说成了。我的做法是准备一段带时间戳的真实场景视频，跑完整推理，统计三个数：检出帧占比、平均单帧耗时、误报次数（人工回看）。检出帧占比太低说明召回不够，耗时超标说明要换更小的模型或者上 TensorRT，误报多就回去调conf和后处理。这三个数比 mAP 更能说明「能不能上线」。
| 指标 | 含义 | 参考处理 |
|---|---|---|
| 检出帧占比 | 有烟的帧里被检出的比例 | 偏低就补数据或降 conf |
| 平均单帧耗时 | 端到端推理时间 | 超标换 yolov5n 或导 TensorRT |
| 误报次数 | 无烟帧被误报的数量 | 偏高加多帧确认或提 conf |
6.3 一个实用技巧
半透明目标最容易出的问题是「置信度抖动」——同一团烟这一帧 0.6、下一帧 0.2。我一般会在业务侧加一个滑动窗口：维护最近 N 帧的检测结果，按空间位置做简单聚类，同一个位置在窗口内出现超过 K 次才触发报警。N 取 5～10、K 取 3 左右，能压掉大部分单帧噪声，又不至于让报警延迟太久。这段逻辑跟模型无关，换任何检测器都能复用。
从那以后我每次接新的检测需求，都会先把「单帧指标」和「连续帧表现」分开测一遍，不再拿测试集上的 mAP 当唯一依据。模型在静态图上好看、在视频流里发飘的情况太多了，早测早发现。希望帮到你。
本文还有配套的精品资源，点击获取
