Darknet版YOLOv3火焰烟雾检测：小样本训练与部署实战

简介：面向火焰与烟雾检测场景的Darknet版YOLOv3资源包，适合计算机视觉开发者、安防消防领域研究人员及有目标检测课程需求的学生使用，适用于消防预警、安防监控等需要识别火情和烟雾的场合。它基于Darknet框架搭建，解决了从零训练YOLOv3模型周期长、数据难获取的问题，可直接利用训练好的权重进行检测，或基于配套数据继续训练、调参。压缩包内共1457个文件，包含weights权重、cfg与data及names配置文件，另有约500张jpg火焰烟雾图片，标注类别为fire和smoke，并配套txt、xml两种格式标签，以及Python脚本和训练map/loss曲线图等，整体约222.15MB，目录结构便于按检测、训练和评估模块查阅。目前已有527人学习下载，读者可获得可直接运行的模型权重、完整配置、双格式标注数据集和评估曲线，既能快速验证检测效果，也能用于二次训练与效果对比。该资源对有快速落地或课题实验需求的用户较为实用。

1. Darknet版YOLOv3火焰和烟雾检测：500数据集够用，权重是现成的

厂区监控里冒出一缕烟，系统要比人眼更快喊出来；森林防火杆上的边缘盒子，不允许把视频传回云端做判断。这类场景下，Darknet版YOLOv3火焰和烟雾检测一直是工业应急视觉里的经济方案：训练好的权重拿去就能推理，500张标注数据就能做出一个可用的专用模型。这套组合最值钱的地方在于框架轻、离线可跑、全程可控，不依赖任何在线服务。文章围绕三样东西展开——权重、数据集、Darknet框架，把从编译、推理到训练的所有关键步骤和最容易翻车的位置讲清楚。适合想离线部署、硬件条件一般、又需要在几天内跑通烟火检测原型的工程师，也适合刚接触目标检测、想用一套完整项目入门的团队。

2. 为什么是Darknet+YOLOv3：火焰烟雾检测的选型逻辑与原理边界

2.1 火焰和烟雾检测为什么是目标检测里的硬骨头

火焰和烟雾与常见物体最大的区别是“没有固定形状”。火焰的轮廓随时间抖动，烟更是半透明、边缘和背景融在一起。传统做法常用颜色阈值加背景减除，比如用HSV里红色和黄色的范围圈火焰，用灰度纹理变化找烟。这类方法在固定镜头下偶尔能用，一旦遇到光照变化、镜头抖动、白烟在白色天空下出现等情况，误报率直接失控。

YOLOv3这类深度学习检测器避免了手工特征，它把整个画面划分成网格，直接回归目标框和类别。但火焰和烟雾的目标尺度跨度非常大：近处一堆篝火可能占据半个画面，远处一个小火苗只有十几个像素。通用检测模型对小目标本就敏感度不足，这也是烟火检测项目里很多人跑通demo后却在实际场景漏检的根源。明白这个难点，后面调整数据和分辨率时才不会瞎试。

2.2 YOLOv3的三个检测尺度和Darknet的落地优势

Darknet版YOLOv3在输入416x416时，会在13x13、26x26、52x52三个尺度上分别做预测，每个网格配3个锚框，一共产生10647个候选框，再通过置信度筛选和NMS去重。三个尺度意味着它天生对目标大小跨度有更强的容忍度，适合火焰和烟雾这种“有时大如墨块、有时小如星点”的对象。

Darknet是YOLOv3的原生框架，用纯C编写，编译产物就一个可执行文件和配套权重。这一点对部署非常重要：现场服务器或边缘盒子往往没有Python环境，也不方便装大型依赖，而Darknet只要把Makefile改好、make完，拷贝到目标机器就能跑。相比YOLOv8和OpenCV DNN，Darknet既支持训练也支持推理，权重格式统一，做迁移学习不用来回转换格式。现在不少人习惯用YOLOv8的接口方式去套Darknet，结果发现命令完全不同，这是后续操作里最容易踩的第一道坎。

2.3 权重、cfg、names三件套的配套关系

训练好的权重文件只是网络参数，它本身不包含网络结构和类别名称。Darknet推理时至少需要三个文件配合：weights存参数，cfg存网络层结构，names存类别名。names由一个data文件引用，data文件同时指定训练集、验证集路径。三者如果版本不一致，最典型的结果是加载权重时直接段错误，或者预测类别错乱。常见做法是这三件套放在同一工作目录，用相对路径引用，避免部署时路径失效。

很多人只下载了weights，拿别的项目cfg来试，那模型根本跑不起来。判断三件套是否匹配，最简单的标准是看cfg里三个yolo层的classes数目是否等于names里的行数，以及每个yolo层前一层卷积的filters是否等于(classes+5)*3。火焰和烟雾检测如果是两类，这个值就是21。

2.4 500数据集的性质与迁移学习底线

500张图在工业打标里属于小样本，但它足以支撑一个专用场景的烟火检测，前提是数据构成对路。我一般会看三件事：正负样本比例是否失衡、小目标火焰有没有独立标注、烟的颜色和背景是否覆盖了目标使用环境。如果500张里有400张是近景火焰，那模型到了远景监控里几乎必然漏检。

这个规模下不能从零训练，标准做法是用Darknet官方预训练权重darknet53.conv.74做迁移学习。darknet53.conv.74在ImageNet上完成了特征提取层的预训练，复用它可以大幅缩短收敛时间，也让500张数据发挥出接近数千张从零训练的效果。训练时不是只冻结前几层，而是整个网络一起微调，但初始学习率要压得比从零训练更低。

3. 用训练好的权重做推理：从编译Darknet到跑通视频的最小命令

3.1 编译Darknet：GPU版和CPU版怎么选

拿到源码后先改Makefile再编译，这是Darknet和很多现代框架不一样的地方。不装CUDA的机器可以直接编译CPU版，做单张图片检测没有问题；但视频流和摄像头推理强烈建议用GPU版。安装好CUDA和cuDNN后，把Makefile里对应开关打开：

cd darknet sed -i 's/GPU=0/GPU=1/' Makefile sed -i 's/CUDNN=0/CUDNN=1/' Makefile sed -i 's/OPENCV=0/OPENCV=1/' Makefile make -j4

第一行把GPU编译开关打开，第二行启用cuDNN加速，第三行开启OpenCV支持。OpenCV这一项很多人会忽略，不开的话图片推理能跑，但读取视频和摄像头会很麻烦，输出画面也不方便。Makefile里的LIBSO=1如果也打开，会额外生成libdarknet.so动态库，后续做二次开发时用得上，不影响命令行推理。

编译完成后，先跑一句简单的版本输出确认可执行文件正常。常见的失败是CUDA路径不对，开头会报“nvcc not found”，这时候检查编译环境，后面第5章会专门说。

3.2 单张图片检测：命令、阈值参数与输出说明

图片用detector test子命令，传入data文件、cfg、weights和待检测图片：

./darknet detector test cfg/obj.data cfg/yolov3-fire.cfg weights/yolov3-fire.weights data/test.jpg -thresh 0.25

-thresh控制置信度阈值，默认是0.24。调低到0.1能捞回一些微弱目标，但误报也会明显变多；调高到0.5适合背景干净、只需要强信号的场景。火焰和烟雾的语义天然模糊，我一般先按0.25跑一遍看效果，再决定是否微调。命令执行完毕后，检测结果会写到当前目录的predictions.jpg，终端里同时打印每个框的类别、置信度和坐标。注意这个命令是单帧处理，不依赖视频解码，CPU机器也能快速看到结果。

3.3 视频与摄像头检测：实时性和跳帧策略

视频和摄像头统一用detector demo子命令，参数和test基本一致：

./darknet detector demo cfg/obj.data cfg/yolov3-fire.cfg weights/yolov3-fire.weights data/test.mp4 -out_filename result.avi

-out_filename用于把检测结果写成本地视频；不加参数时直接弹窗口实时预览。摄像头场景把最后一个文件路径换成-c 0，表示读取编号0的摄像头设备。注意demo子命令处理的是连续帧，模型第一次加载和预热需要一点时间，头几帧没有输出是正常现象。

Darknet的推理是逐帧串行的，没有内置跟踪和跳帧机制。现场实时性不够时，常见做法是每3帧检测一次，中间两帧沿用上一帧的框位置，只要火焰移动不剧烈，视觉上完全能接受。更简单的方式是用-resize参数把输入分辨率压到416或320，检测速度会明显提升，代价是小目标召回率下降，适合烟雾大范围出现而小火苗不重要的场景。

3.4 运行时日志怎么读：显存、FPS和框坐标

检测过程中终端会滚动输出当前帧的FPS、处理耗时，以及每个框的坐标。FPS指的是模型推理部分的速度，不包含窗口渲染和视频编码。GPU上运行416分辨率的小模型，几十帧每秒很常见；CPU上跑到5帧每秒已经算不错，不要被这个数字误导。显存占用则在程序启动时打印，通常不是固定值，会随输入分辨率变化。4G显存的卡跑416x416足够，换成608x608就有爆显存风险。框坐标格式是x, y, w, h，对应的分别是左上角横坐标、左上角纵坐标、框宽、框高，理解这个格式后接业务逻辑做告警过滤就方便了。

4. 用500数据集训练自己的火焰烟雾模型：标注、划分与cfg参数

4.1 VOC标注转Darknet格式：从labelImg到txt的转换脚本

标注工具推荐labelImg，导出的是Pascal VOC格式的XML文件。Darknet训练需要的是每张图片对应一个同名txt，每行格式为：类别编号 中心点x 中心点y 框宽 框高，全部按图片宽高归一化。

from pathlib import Path import xml.etree.ElementTree as ET CLASSES = ["fire", "smoke"] def voc_to_darknet(xml_path, out_path): root = ET.parse(xml_path).getroot() size = root.find("size") img_w = int(size.find("width").text) img_h = int(size.find("height").text) lines = [] for obj in root.findall("object"): name = obj.find("name").text if name not in CLASSES: continue box = obj.find("bndbox") xmin = float(box.find("xmin").text) ymin = float(box.find("ymin").text) xmax = float(box.find("xmax").text) ymax = float(box.find("ymax").text) x_center = (xmin + xmax) / 2.0 / img_w y_center = (ymin + ymax) / 2.0 / img_h w = (xmax - xmin) / img_w h = (ymax - ymin) / img_h lines.append(f"{CLASSES.index(name)} {x_center:.6f} {y_center:.6f} {w:.6f} {h:.6f}") Path(out_path).write_text("\n".join(lines), encoding="utf-8") for xml_file in Path("annotations").glob("*.xml"): voc_to_darknet(xml_file, "labels/" + xml_file.stem + ".txt")

脚本逻辑很直接：遍历annotations目录下的XML，解析每张图片的宽高和每个目标框的坐标，换算成归一化中心点格式后写入同名txt。参数需要注意两点：CLASSES的排列顺序决定了类别编号，必须与后面names文件保持一致；图片尺寸一定要从XML读取，不要用文件名猜尺寸，否则宽高比错误会让所有框偏移。烟雾标注的经验是框住肉眼可见的烟区整体，宁大勿小，边界不必扣到每一个弥散的像素，否则人工标注工作量大，模型还不一定学到更多。

4.2 数据划分与obj.data的写法

500张图的常见划分是训练400、验证50、测试50。验证集用来观察mAP和loss，测试集最后做一次干净评估。划分时必须图片和标签同步移动，最稳妥的方式是先生成路径列表文件：

import random from pathlib import Path images = list(Path("images").glob("*.jpg")) random.seed(42) random.shuffle(images) total = len(images) train, valid = images[: int(total * 0.8)], images[int(total * 0.8):] for split_name, split_imgs in [("train", train), ("valid", valid)]: with open(f"{split_name}.txt", "w", encoding="utf-8") as f: for img in split_imgs: f.write(str(img.resolve()) + "\n")

random.seed(42)固定随机种子，保证每次运行划分结果一致，也方便复现训练。train.txt和valid.txt里写的是图片绝对路径，Darknet训练时会自动去找同名txt标签。这里有一个容易忽略的坑：如果某张图没有任何目标，也要在labels目录下生成一个空txt文件，否则训练加载数据时会异常中断。500张数据里负样本最好保留80到100张，让模型见过“没有火也没有烟”的画面，否则推理时会把反光汽车、橙色路灯这样的东西也当成火焰。

接着创建obj.data和names文件。obj.data是Darknet训练和推理的总入口，内容如下：

classes=2 train=data/train.txt valid=data/valid.txt names=data/fire.names backup=backup/

names文件里写入两行，顺序与转换脚本的CLASSES一致：第一行fire，第二行smoke。backup目录用于保存训练过程中间权重，要提前创建好，否则训练结束时写文件会报错。

4.3 修改cfg文件：classes、filters和anchors

从YOLOv3官方cfg复制一份来改，核心改动项很少，但每处都要改对。

filters的计算规则是(classes + 5) * 3，两类目标就是21。这个改动最容易被漏掉，只改classes不改filters，加载权重时网络参数数量不匹配，直接报错或段错误。改完三个yolo层及其前一层卷积后，再检查一遍，Darknet不会自动帮你校验这些值。

锚框方面，COCO预训练用的锚框尺寸对火焰烟雾并不合适。常见做法是用calc_anchors重算：

./darknet detector calc_anchors data/obj.data -num_of_clusters 9 -width 416 -height 416

命令会读入所有训练标注，聚类出9个锚框尺寸，输出一组数字。把这9个数按从小到大排列，前3个填到52x52尺度对应的yolo层，中间3个填到26x26，最后3个填到13x13。注意calc_anchors输出的排列顺序不一定是cfg需要的分组顺序，粘贴时逐行核对。若训练场景以远处小火苗为主，甚至可以只聚类6个锚框，让模型的锚框容量更集中，小目标召回通常会有改善。

4.4 训练命令、中断恢复与损失监控

训练命令如下：

./darknet detector train data/obj.data cfg/yolov3-fire.cfg darknet53.conv.74 -map

darknet53.conv.74是Darknet官方提供的预训练特征提取权重，参数只有网络前74层的卷积部分，专用于迁移学习。加-map后会在训练过程中间用valid.txt评估mAP，输出到终端，这是判断模型是否真正在变好的核心指标，不要省。训练日志里每100轮打印一次当前loss和avg_loss，一个正常的小样本训练过程是：前几百轮loss快速下降，之后缓慢波动，同时mAP逐步爬升。如果loss在几千轮后还在几十上下震荡，往往是学习率或数据划分出了问题，而不是模型不够复杂。

网络断了或中途想停，不要从头再来。backup目录下会持续保存训练状态，用权重文件继续训练即可：

./darknet detector train data/obj.data cfg/yolov3-fire.cfg backup/yolov3-fire_last.weights

_last.weights保存最近的训练状态，_best.weights保存目前mAP最高的版本。恢复训练时用一个就行，推荐用_best，避免把模型从过拟合状态继续往回拉。

4.5 500数据集的训练预期：轮数、显存与收敛判断

500张数据配合迁移学习，训练轮数一般不用太多。batch为64时，6000轮左右是一个比较稳的参考值，显存占用在4G卡上能跑动，因为subdivisions已经把梯度累计拆成小块。显存只有2G时，把subdivisions从16调到32或者64，训练效果基本不变，只是速度变慢。

收敛判断不要只看loss，更可靠的是观察valid mAP的走势。常见做法是训练到一半时把学习率降一档，比如初始0.001，在steps设置的位置降到0.0001，这一步对稳定mAP很关键。如果3000轮时mAP已经不再上升，可以直接提前结束，不必跑满全部轮数。500张能支撑的精度上限就在那里，追求更高的指标靠的是数据扩容，而不是让模型在有限数据上反复过拟合。

5. 训练和部署中的5个高频坑：现象、原因与解决

5.1 编译时找不到CUDA环境

现象：执行make后终端报“nvcc: not found”，或者编译过程中卡在找不到cuda_runtime.h头文件。

原因：CUDA工具包装完了，但环境变量没有配置，编译器不知道去哪里找nvcc和CUDA头文件。

解决：先确认CUDA的安装路径，再把路径暴露到环境变量：

export PATH=/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH

执行完这两句后重新make。如果你安装的CUDA不在/usr/local/cuda，而是带了版本号的目录，比如/usr/local/cuda-12.1，就把路径替换为实际位置，并确认Makefile里的NVCC路径和它一致。另一种情况是机器上有多个CUDA版本，Makefile写死了一个不存在的路径，改成实际存在的那个即可。

5.2 推理时段错误：权重和cfg不匹配

现象：加载权重后程序直接崩溃，终端提示segmentation fault，往往没有任何其他错误信息。Docker容器里跑这类问题尤其常见。

原因：cfg里的网络结构和训练权重时的设置不一致。最常见的两个点是目标类别数不一致，以及width或height被改过。Darknet加载权重时按层逐层拷贝参数，结构对不上就访问越界，直接崩。

解决：检查cfg里三处yolo层的classes是否都是2，检查它们前一层的filters是否为21，再确认width和height没有在训练后被随意改动。如果权重文件来自他人，最好先把原始配套的cfg和weights一起跑通，确认没问题后再动参数。这类崩溃很难靠日志排查，先用原版组合做交叉验证是最快的定位方式。

提示：权重文件拷贝不完整也会导致段错误，检查文件大小是否和来源一致，不要只看后缀名。

5.3 训练loss不降反升

现象：训练到第1000轮，avg_loss比第200轮还高，mAP一直是0，或者反复震荡。

原因：第一个常见原因是学习率过大，loss在最优解附近来回弹跳收不进去。第二个是obj.data或names配置出错，类别编号和实际标注对不上，等于让模型在错误监督信号下学习。第三个是正负样本严重失衡，负样本太多，模型快速滑向“永远预测背景”的局部最优。

解决：学习率从0.001起步，burn_in保持默认1000不要乱动。检查names文件是否正好两行，顺序是否和转换脚本的CLASSES列表一致。打开训练用的train.txt，随机抽查几个图片和标签对，确认标注没有张冠李戴。给没有目标的图片补上空标签，避免训练中断。做过这三步后，loss通常会在下一轮训练里回到下降通道。

5.4 小目标漏检严重

现象：近距离火焰能框得很准，换到远距离监控视角，小火苗完全没有预测框；把-thresh调到0.05后，误报又占领了屏幕。

原因：500张数据里小目标样本占比太少，模型几乎没有见过“十几个像素的火焰”长什么样。另一个原因是416分辨率下，过小的目标在特征图上只剩几个像素，信息在卷积过程中被稀释掉了。锚框尺寸不匹配也会让模型对这类目标表示能力不足。

解决：用calc_anchors重新聚类，替换cfg里的默认锚框。如果小目标确实重要，直接把训练分辨率从416提到608，并在数据里补充远距离火焰的标注。补充标注时不要因为目标小就忽略它，十几个像素也算一个有效样本。不要指望靠调低推理阈值来救场，那只是把判断标准放宽，本质上是在赌概率，误报率会不可控。

5.5 部署时FPS虚高，画面却卡顿

现象：终端显示FPS有30以上，但实际预览画面像在放幻灯片，一卡一卡，完全不像能实时处理的样子。

原因：Darknet统计的FPS是纯推理耗时，不包含窗口渲染和视频编码。OpenCV的预览窗口在高分辨率下渲染本身就吃性能，写视频时编码器配置不当也会拖累整体帧率。

解决：用-out_filename输出结果时，在编码参数上选择MJPG格式，速度通常比默认格式快很多。实时预览场景把显示窗口缩小，避免大分辨率缩放造成额外开销。业务上如果检测不需要每一帧都精确，就采用跳帧策略，每3帧推理一次，中间帧沿用上一帧的检测结果，画面流畅度会有明显改善。遇到实在跑不动的部署环境，优先考虑升级GPU，而不是继续压分辨率，压到320以下小目标就彻底丢了。

6. 怎么验证模型真的能用：mAP计算与实景测试的取舍

6.1 用valid命令单独评估最终权重

训练时的-map结果有参考价值，但最终权重单独跑一次验证更干净：

./darknet detector valid data/obj.data cfg/yolov3-fire.cfg backup/yolov3-fire_best.weights

命令会逐张跑完valid.txt里的图片，在results目录下生成每个类别的检测结果文件，每行记录置信度和框坐标。配合目标检测评估脚本计算mAP，能得到比训练日志更明确的质量结论。跑valid时用的阈值和实际部署阈值最好保持一致，这样算出的mAP才有落地参考意义。火焰和烟雾两类分开看，不要只看总mAP——烟雾这一类经常因为边界标注的主观性，mAP低于火焰，单独观察便于定位模型短板。

6.2 实景测试比mAP更能暴露边界

mAP高只说明在测试集上表现好，不代表现场能用。500张数据训练出的模型，对场景和光照非常敏感。我习惯在训练结束后挑3至5段完全没有出现在训练集里的视频做回归测试：白天强光、傍晚逆光、室内暗光、白烟和黑烟各覆盖一段。这些场景才是真实部署环境。

实景测试时把检测日志落盘，方便回放排查：

./darknet detector demo data/obj.data cfg/yolov3-fire.cfg backup/yolov3-fire_best.weights data/field.mp4 2>&1 | tee detection.log

2>&1把报错信息也合流到日志文件里，之后用脚本提取每一帧的框和置信度，和实际画面逐段对照。这里最值得保留的是每次训练产生的last和best权重，不要删，回归测试发现问题时可以随时换回旧版本，慢慢比较是哪一个训练阶段丢失了对某个场景的召回。我吃过亏的是只盯着mAP就急于上线，结果到了阴天场景漏了几次小火苗，后来养成了每次迭代都留全套权重的习惯。验证模型不是一项一次性工作，换场景、换摄像头、换季节之后都得重新过一遍。希望帮到你。

本文还有配套的精品资源，点击获取