简介：一套面向YOLO火焰目标检测学习与实战的数据集及预训练模型包，适合计算机视觉初学者、安全监控与火灾预警相关开发者。资源包含519张已标注火焰图片及配套txt、xml标注文件，共1559个文件，压缩包57.26MB，另附tflite和h5两种格式的测试模型，便于直接加载验证或迁移训练。标注信息涵盖边界框坐标与类别标签，既可用于训练YOLO系列模型，也可用于练习数据预处理、训练调参和模型评估。已有2520人学习下载，内容组织清晰，上手门槛较低。通过这套资源，读者可以完整走通火焰检测从数据准备、模型训练到测试部署的流程，理解YOLO在特定场景下的应用方法，并为后续引入YOLOv4、YOLOv5或数据增强等优化手段打下基础。
1. 火焰目标检测，最怕的不是算法而是数据集
做yolo火焰目标检测的人，十有八九是先下载一个预训练模型跑通demo，再把权重换到自己的视频流里，结果发现白天还行、晚上全瞎，或者把路灯、车灯、橙色衣服全当成火。真正让你翻车的往往不是yolo本身的网络结构，而是你手里的数据集和测试模型这两块短板。火焰目标检测和通用检测最大的差别在于：火焰没有稳定的形状和纹理，同一团火在不同光照、不同风向下看起来是两样东西，而公开数据集又少得可怜。这篇文章就是按我实际做项目的路径来写：从原始图像收集、标注格式转换、模型选型、训练参数，到最后的测试脚本和那些说不清的坑，一步步给你一条能复现、能变通的路线。
2. 自建火焰数据集：从取材、标注到清洗
2.1 火焰图像采集的三个常见来源与取舍
火焰场景不像行人检测那样有成规模的开源数据集，常见做法是自己攒一个。我一般把来源分成三类：一是网上爬现场照片，包括消防训练、森林火灾新闻图、工业厂区火炬；二是从监控视频或直播流截帧；三是自己拍或合成。第三类听起来最靠谱，但实际覆盖不了远距离小目标，因为火焰一旦放远就只剩几个像素，标注工都看不清边界。综合下来，现场照片加视频截帧是性价比最高的，公开的燃气管道、油罐区图像集也能做补充。
采集时要注意一个常被忽略的参数：图像原始分辨率。很多手机摄影图和监控截图一个大一个小，进yolo前会被双线性插值统一缩放，小图里的火焰区域只有十几像素，标注出来也是废框。整理素材阶段就把分辨率低于640x640、且火焰区域占画面比例不足2%的图剔除，能省掉后面大量无效训练时间。
2.2 标注格式转换：从VOC到YOLO的一步到位脚本
标注用什么工具其实都行，LabelImg和X-AnyLabeling我都用过，最后导出格式会不一样。LabelImg默认存VOC的xml，X-AnyLabeling导出json。而yolo系列训练的标签格式是每张图一个txt文件，每一行是class x_center y_center width height，这四个值全部归一化到0~1之间。转换这一步最容易被坑的是宽高的归一化基准。有人直接把xml里像素级的宽高除以图像原始宽高，这没问题，但如果你用标注工具打点的时候是相对坐标，再混上绝对坐标的xml，出来的框就跑偏了。
我习惯用下面这个Python脚本做一次批处理转换，输入的xml目录结构是标注工具默认的Annotations和JPEGImages两个文件夹，输出成yolo要求的images和labels并存结构：
import os import xml.etree.ElementTree as ET from pathlib import Path def convert_voc_to_yolo(xml_dir: str, img_dir: str, out_dir: str, classes: list): xml_dir, img_dir, out_dir = Path(xml_dir), Path(img_dir), Path(out_dir) (out_dir / 'images').mkdir(parents=True, exist_ok=True) (out_dir / 'labels').mkdir(parents=True, exist_ok=True) for xml_file in xml_dir.glob('*.xml'): tree = ET.parse(xml_file) root = tree.getroot() img_name = root.findtext('filename') width = int(root.findtext('size/width')) height = int(root.findtext('size/height')) # 拿到原始图像路径，做一次尺寸兜底校验 src_img = img_dir / img_name if not src_img.exists(): print(f"[警告] 图片不存在: {img_name}") continue label_lines = [] for obj in root.findall('object'): name = obj.findtext('name') if name not in classes: print(f"[注意] 跳过未定义类别: {name}") continue cls_id = classes.index(name) bndbox = obj.find('bndbox') xmin = float(bndbox.findtext('xmin')) ymin = float(bndbox.findtext('ymin')) xmax = float(bndbox.findtext('xmax')) ymax = float(bndbox.findtext('ymax')) # 过滤掉过小和越界的框，避免训练时loss异常 if xmax - xmin < 3 or ymax - ymin < 3: continue x_center = ((xmin + xmax) / 2) / width y_center = ((ymin + ymax) / 2) / height box_w = (xmax - xmin) / width box_h = (ymax - ymin) / height label_lines.append(f"{cls_id} {x_center:.6f} {y_center:.6f} {box_w:.6f} {box_h:.6f}") if label_lines: shutil.copy(src_img, out_dir / 'images' / img_name) label_path = out_dir / 'labels' / (xml_file.stem + '.txt') label_path.write_text('\n'.join(label_lines) + '\n') if __name__ == '__main__': classes = ['fire'] convert_voc_to_yolo('Annotations', 'JPEGImages', 'fire_dataset', classes)这段脚本做了三件普通转换脚本不做的事：第一，检查xml对应的原始图像是否存在，防止标注文件残留导致训练时加载失败；第二，把小于3个像素的框丢掉，这种小框在归一化之后宽高趋近于0，会让损失函数剧烈浮动；第三，类别不在预设列表里的直接跳过，而不是把其他杂类一起带进火焰模型。运行后看一眼labels目录下txt文件的行数和坐标数值范围，正常情况所有坐标都应该在0到1之间，如果有负数或者大于1的值，说明xml里的目标框本身越界，要及时回源修正。
2.3 数据集规模与目录组织的底线要求
火焰数据集做多大合适取决于你的应用场景，如果只检测大面积明火，1500张左右就能出一个能用的模型；如果要检测早期火苗和烟一起出现的小目标，建议至少3000到5000张。我踩过的血泪经验是：同场景的图像不要占比超过20%，否则模型对背景的过拟合会非常严重，换一个厂区灯光的摄像头直接失效。
组织目录时按yolo项目常见的两步法：最外层放fire_dataset，里面分images和labels两个目录，各自再按train和val分一次，这样不用修改太多训练脚本的路径参数。很多人在这个环节图省事，把所有图片放一个大目录里，靠train_test_split函数临时切分，结果训练过一阵子重新跑实验时发现切分结果变了，半路翻车还难排查。
3. 选模型还是选框架：YOLO系列怎么挑
3.1 从v5到v8到v11，火焰检测该看哪几个能力
标题只写了yolo，没有版本，这其实还原了真实处境——你手里有GPU或者只有CPU，你希望模型能在监控盒子上跑，还是能在云端慢慢分析。选版本之前先把约束条件列清楚。我的建议是直接面向推理设备选：如果你最终要部署到Jetson或者工控机这类算力受限设备，YOLOv5s或YOLOv8s是稳妥起点；如果你有独立显卡，且希望省掉魔改注意力机制的麻烦，YOLOv8和YOLO11是更省心的选择。
对比维度上，火焰检测的特殊性体现在三处：第一，火焰是半透明物体，边缘和背景混在一起，模型主干能不能提取到高频边缘特征很重要，这一点上v8的C2f结构比v5的C3结构表现更稳；第二，远距离小目标占比高，需要在训练时打开多尺度参数；第三，火焰可能在画面的任意位置，不像行人总有固定的长宽比，所以SPPF和PANet这类多尺度融合模块比锚框尺寸预设更影响精度。下表是我在相同数据集上做过的简单对比，具体数字会随数据集变化，参考价值在于理解差异来源：
| 模型 | 参数量 | 火焰小目标召回率表现 | 推理速度（640x640，T4） | 适用场景 |
|---|---|---|---|---|
| YOLOv5s | 约7.2M | 一般 | 较高 | 内存极小的边缘设备 |
| YOLOv8s | 约11.2M | 较好 | 中等 | 通用监控项目，推荐 |
| YOLO11s | 约9.4M | 较好 | 中等偏上 | 新项目，考虑长期维护 |
3.2 预训练模型怎么接进自己的数据集
无论选哪个版本，都不建议从零训练权重。yolo官方仓库里提供的预训练模型是基于ImageNet和COCO的，对通用特征有很好的提炼，火焰虽然是新类别，但早期的边缘、纹理、颜色特征是可以迁移的。有一段时间我用v8训练火焰，头几轮loss下降很慢，排查下来是预训练权重没加载对，加载了v5格式的权重文件，结构名对不上才导致训练状态异常。
使用预训练权重的常见做法是先跑一遍官方推理脚本确认权重路径没问题，再把权重路径填进训练配置。以YOLOv8为例，一行命令就能启动训练，但前提是你要准备一个fire.yaml来告诉训练脚本数据在哪：
# fire.yaml path: ./fire_dataset train: images/train val: images/val nc: 1 names: ['fire']然后执行：
yolo train model=yolov8s.pt data=fire.yaml epochs=120 imgsz=640 batch=16model=yolov8s.pt这行参数同时做了两件事：如果当前目录有这个权重文件，它会被当作预训练权重；如果不存在，ultralytics会尝试从官方源拉取。data指向的yaml文件里path字段是相对当前工作目录的，很多人在这个字段上踩坑，写成绝对路径或者带项目名的路径，一旦换了机器跑训练就找不到数据。更稳妥的写法是训练脚本和数据集保持同一级目录，path直接填./fire_dataset。
3.3 损失函数与置信度之间的微妙关系
火焰检测在损失函数这一层没有特殊的魔法，yolo系列默认的CIoU和分类交叉熵就能用，真正需要盯的是损失曲线里的Box Loss和Cls Loss。火焰因目标颜色和背景高度接近，分类分支的loss下降往往比通用目标慢，这是正常现象。有一种玄学观点认为换Focal Loss或变体就能提升火焰精度，我试过几次，收益不稳定还增加了调参时间。
值得调整的反而是NMS阶段的置信度阈值。火焰检测在低置信度时会有很多疑似框，尤其是烟雾边缘颜色接近火焰时。训练阶段不用管这个阈值，测试模型时才需要根据你的场景权衡误报和漏报。很多开源火焰模型在demo视频里效果惊人，一上真实画面就不行，原因就在测试阶段的score阈值被作者压得很低来追求高召回，换到你的业务场景，误报几十次根本没法用。
4. 训练配置与损失曲线：三个必调参数
4.1 imgsz和batch的选择：火焰小目标的地基
训练图像的尺寸直接决定火焰小目标在特征图上的像素占比。用默认640的输入尺寸适合大多数场景，但如果你是做园区杆塔这类远距离监控，火焰在画面里经常只有十几个像素，建议把imgsz提到960或1280。代价是显存占用成倍上涨，8G显存跑1280基本不现实，常规操作是保持640输入，然后期望多尺度训练帮忙兜底。
batch大小要根据显存和图像尺寸联动调整。显存不够时优先减batch而不是减imgsz，因为火焰目标对分辨率更敏感。我一般在12G显存上用640输入配batch16，如果是1080ti这种11G卡，batch降到8能稳一点。训练过程中如果出现loss直接变NaN，第一反应就是batch太大导致梯度爆炸，先把batch对半砍再试。
4.2 epochs、早停和学习率衰减的配合
epochs也不是越大越好。火焰数据集如果标注质量参差，训练过拟合后会开始记忆标注噪声，表现为验证集mAP先升后降。一个比较实用的做法是设置patience=20开启早停，模型验证指标20轮不再上升就自动停止，然后把best.pt和last.pt都留着，便于回退到最优权重。
学习率方面，yolo默认的lr0=0.01在通用目标上表现正常，但在火焰这类小目标数据集上，我习惯把lr0调低到0.005，同时把lrf（最终学习率因子）保持默认。原因是火焰数据集规模通常不大，动辄上千轮时过大的初始学习率会让前几十轮震荡，后面的衰减段又会显得过长，调低初始学习率可以让训练曲线更平滑，验证集的表现也更稳定。
4.3 数据增强参数：火焰场景的开与关
yolo训练默认开启的增强参数在火焰检测上不能全盘照搬。hsv_h、hsv_s、hsv_v这三个色调增强参数要尤其小心，火焰和烟雾的特征高度依赖颜色分布，把色相增强开大了会让橙色火焰被改成紫色，模型等于在学一个不存在的假样例。我一般把hsv_h改成0.015，hsv_s和hsv_v保持在0.5以下，既能增强光照鲁棒性，又不会过度破坏火焰颜色特征。
翻转和旋转增强另说。火焰没有明确的语义方向性，上下翻转不开，左右翻转可以开，特别是你采集的现场照片里火焰在画面左右两侧的分布不均衡时。旋转增强建议只开小的角度，比如degrees=10，过大的旋转会让火焰框出现大量背景填充，弱化前景特征。
4.4 训练日志里需要盯的几个指标，以及BN崩溃
训练过程中不是光看loss就行。每一轮结束后的验证输出里，Precision、Recall和mAP50三者要一起看。如果mAP50在涨但Recall一直偏低，说明火焰区域被大量漏检，常见原因是小目标占多数；如果Precision偏低，说明误检多，多半是训练数据里背景样本和火样本混淆。还有一个在yolo训练里让人头皮发麻的问题：BN崩溃，现象是loss在某一轮突然变成NaN，之后所有指标全乱。
BN崩溃在火焰数据集中发生的概率不低，原因通常是数据中存在极端尺寸的框或异常像素值。我遇到的案例是一张夜间消防训练照片里，火焰占了画面80%，归一化后的gt框宽高接近1.0，经过几次下采样后在深层特征图上完全失配，最终导致BN统计量爆炸。解决办法是把这批极端长宽比的样本先筛掉，或者在hyp配置里把batch_norm_momentum从默认的0.1调低到0.03，给BN的统计量更新加个缓冲，能明显降低崩溃概率。
5. 测试模型的排查清单：5个常见翻车点
5.1 总体翻车：测试图能出框，但一换视频就漏
现象：跑官方测试脚本时单张图片效果很好，火焰框很稳定，但换成一段监控视频后，火焰偶尔出框、偶尔不出，帧与帧之间框的位置跳动很大。
原因：单张图片的测试结果取决于这张图的静态特征，而视频里的火焰是动态的，颜色、形状、大小每帧都在变。另一个隐形原因是测试脚本对输入做了letterbox处理，视频帧分辨率如果与测试尺寸不一致，火焰区域被缩放后特征会变化。
解决：测视频时先确认输入帧是否经过同样的letterbox逻辑。我一般会在测试代码里打印预处理前后的图像尺寸，确保视频推理和训练时的预处理一致。另外把测试视频切成若干段，选白天、黄昏、夜间各一段分别测，不要只挑火焰最旺盛的那几十秒验证。
5.2 误检爆炸：橙色物体全被识别成火
现象：模型对火焰的召回率不错，但画面里穿橙色工服的人、夕阳下的红色墙面、甚至黄颜色的路牌都会被标成火框。
原因：训练集中的负样本（没有火焰的背景图）数量不足，或者负样本里的颜色分布和火焰高度接近，模型学到的不是火焰的结构特征，而是橙色色块的统计规律。
解决：给数据集中补充两类负样本，一类是完全没有火焰的普通场景帧，另一类是包含橙色、红色物体的干扰帧。标注时不要把这类图像直接删掉，而是保留空标注文件，让模型在训练时看到“这个颜色不是火”的反例。一般空标注图占比达到总数的10%以上，误检率就会有明显下降。
5.3 小目标全漏：远处火苗一个都框不出来
现象：近距离的火焰测试成绩很好，但远距离监控里一个像素点大小的火苗完全漏检，mAP50看着还行，实际业务不可用。
原因：训练集里小目标占比太低。yolo训练时默认的anchor和特征图对小目标的响应是有上限的，目标在640分辨率下只有10x10像素，到了下采样32倍后的特征图上只剩不到1个像素点，召回率自然会跌到谷底。
解决：先把测试结果按目标尺寸分组统计，看清漏检目标的具体像素范围。然后做两个调整：一是训练时打开mosaic=1.0并配合copy_paste增强，让小目标在拼图中多次出现；二是推理时用imgsz=960或1280重新跑一遍，小目标召回率会明显上升，代价是推理耗时增加。如果两者叠加还不够，就要考虑使用P2层输出的yolo变体配置，但这属于模型结构改动，需要额外实验验证。
5.4 测试模型文件混乱：best.pt换到工程里性能下降
现象：训练目录下的best.pt在训练时验证集mAP很高，但把它放到部署环境里跑真实场景，精度大打折扣。
原因：大概率是训练数据增强在验证时关闭了，而部署环境用的代码又打开了增强，或者是测试脚本和部署脚本的预处理参数不一致。另一个常见问题是混淆了best.pt和last.pt，early stopping之后best.pt是验证集最优权重，但如果你中途改了数据集切分，best.pt对应的反而是旧数据集上的结果。
解决：把测试模型的流程固定成一个脚本，强制指定预处理尺寸、归一化方式、NMS阈值，并且测试时从模型目录重新加载一次权重，确认md5一致再进入部署阶段。我还会把训练时用的数据集划分文件保存下来，避免重新训练时验证集变化导致权重对比不可信。
5.5 混淆矩阵总合不唯一：先查数据标签再看矩阵
现象：打印验证集的混淆矩阵时发现每一行的数值总和对不上，表格看起来乱，怀疑模型出了问题。
原因：yolo的混淆矩阵生成过程中，normalize参数会把每一行归一化到0到1，如果你看的是归一化后的矩阵，各行各列总和自然不唯一，这不是bug。另一个情况是数据集中存在错误标注或者贴近边界的目标框，预测框与真实框的匹配失败，导致部分样本在矩阵里被记错位置。
解决：检查是不是看了归一化矩阵，若是就去掉normalize=True再看原始计数。如果原始计数依然混乱，把验证集里class_id和图像路径打印出来，用标注工具回看一遍边界框位置，很多混淆矩阵异常其实是标注的问题，不用折腾模型。
6. 推理阶段的精度与速度平衡技巧
模型训练完进入测试推理阶段，有两个容易被忽略的小参数会显著影响最终体验：conf_thres和iou_thres。实测同一个权重文件，conf从0.25降到0.1，火焰召回率上升但误报数量翻倍；iou从0.45提到0.6，重叠框变少但相连的多团火可能被并成一个框。火焰检测里多团火在画面中连接在一起是常态，建议iou保持0.45到0.5之间，conf根据现场误报容忍度来调，宁可先高后低，逐步下探。
使用YOLOv8的推理API时，输出格式也要注意，火焰检测往往需要的是目标框中心坐标，而很多人拿到的results[0].boxes.xyxy是四个角坐标，多一步转换：
from ultralytics import YOLO model = YOLO("runs/detect/train_fire/weights/best.pt") results = model("test_frame.jpg", conf=0.35, iou=0.45, imgsz=640) for r in results: boxes = r.boxes.xyxy.cpu().numpy() scores = r.boxes.conf.cpu().numpy() for box, score in zip(boxes, scores): x1, y1, x2, y2 = box cx, cy = (x1 + x2) / 2, (y1 + y2) / 2 print(f"fire center=({cx:.1f}, {cy:.1f}) score={score:.2f}")注意imgsz这个参数在推理阶段常常被忘掉，训练用640，推理却默认用480，结果小目标召回率莫名下降。所以我的习惯是训练和推理用同一套尺寸参数，并为不同设备各存一份导出脚本，比如边缘设备用640加半精度FP16，服务器用960加全精度。半精度导出在GPU上能带来接近翻倍的吞吐提升，但在CPU上反而更慢，所以要按部署环境决定。
另一个值得做的验证动作是录制一段2分钟的真实场景视频，用帧间隔方式跑一遍推理，把输出的坐标点按时间序列画出来，观察框的位置是否连续。火焰目标即使抖动也应该在小范围内移动，如果轨迹忽远忽近，多半是置信度阈值过低的边缘检测在作祟。这套做法帮我在现场调参时省了很多时间，也避免了测试阶段过拟合到某一张截图上的毛病。希望帮到你。
本文还有配套的精品资源，点击获取
多项式枚举、LFSR与AES选型)
