简介一套基于YOLOv8的火灾检测系统部署资源面向具备一定深度学习基础、希望将目标检测落地到实际安全监控场景的开发者和学习者。项目围绕火源实时识别展开从模型训练、评估到部署推理均有覆盖适合课程设计、毕业设计或工程入门。资源包共九个文件压缩包大小约19.82MB整体内容包含源代码、编译文件、模型权重、依赖清单及说明文档。其中三个脚本分别承担检测启动、配置管理和工具封装等角色配合权重文件可直接运行推理有效降低二次开发门槛。另外还附带环境依赖和说明文档便于快速搭建与参数调整。当前已有两百四十七人学习下载说明内容具有参考价值。对于需要快速搭建火灾检测示例或研究目标检测部署流程的读者来说这份资源能节省大量环境配置和代码整理时间值得动手实践。1. 基于yolov8的火灾检测部署先搞清楚它在解决什么问题把基于yolov8的火灾检测部署这六个字拆开看它其实是一套组合拳先用yolov8训练出能识别火焰和烟雾的模型再把它接到真实的摄像头视频流上实现秒级告警。我做过的现场里最常见的诉求不是模型精度不够而是部署之后误报多、延迟高、边缘设备跑不动。这篇文章写给要把系统落到厂区、仓库、园区监控里的工程师也写给拿它做毕业设计或比赛演示的学生。先说一个反直觉的结论火灾检测部署最大的坑不在训练阶段而在部署阶段的类别混淆和性能瓶颈很多团队在测试集上拿到不错的mAP一接现场视频就翻车。2. 火灾检测的数据与模型选型为什么选yolov8而不是传统视觉方案2.1 火灾检测的场景约束大空间、室外与烟雾遮挡火灾检测和普通的目标检测有个本质差别火焰没有固定形状它一直在抖动、变色、分裂烟雾的透明度还随浓度变化。做过传统视觉方案的人应该都有体会用颜色阈值加形态学处理做火焰分割在实验室环境里效果还行一放到有路灯、晚霞、红色车身的现场就崩了。RGB空间的火焰颜色聚类看着很美好但夕阳下的天空和火焰的像素分布几乎重叠这是传统CV方案很难绕过的硬伤。yolov8这种基于深度学习的目标检测器之所以适合做火灾检测有三个原因。第一它用特征学习替代人工设计规则火焰的纹理、边缘、运动模糊都能被卷积层捕获泛化能力比颜色阈值高一个量级。第二yolov8是anchor-free的检测头不需要像yolov5那样预先设置anchor尺寸对火焰这种尺度变化极大的目标更友好——火焰可以从一个打火机大小迅速蔓延到整面墙。第三ultralytics的工程化做得完整训练、验证、导出一条龙部署环节只要处理推理和业务逻辑不用自己写数据处理流水线。但选yolov8不等于万事大吉。火灾检测场景里有几个特有的约束需要在一开始就想清楚。室外场景要应对光照变化太阳角度不同会让火焰和背景的对比度剧烈波动室内场景要面对烟雾遮挡火焰被货架或设备挡住时只能看到烟雾如果只训练火焰类而忽略烟雾类漏检率会非常高。所以我在大多数项目里都坚持两个类别一起训fire和smoke而不是只识别火焰。另一个约束是边缘设备的算力。火灾检测要接摄像头很多现场是rtsp流接入跑在Jetson、rk3588、或者一台老旧的gtx1660ti机器上没有谁会给这个业务配A100。模型尺寸和推理速度必须从一开始就纳入选型考量。yolov8n和yolov8s在精度和速度之间比较平衡适合火灾检测这种对延迟敏感的告警系统yolov8l和yolov8x精度更高但部署成本会成倍上升。2.2 数据准备公开数据集与自建数据的标注尺度数据是火灾检测部署绕不开的第一道坎。公开数据集方面常见的有FLAME、Fire-Detection-Image-Dataset这类火灾图像集风格偏场景姿态适合做预训练和初期验证。但公开数据集普遍有个问题它们大多采集自实验室燃烧实验或网络图片缺少现场环境的负样本。你拿这些数据训练出来的模型会在现场把红灯笼、晚霞、电焊火花甚至红色卡车当成火焰这是我在多个项目里反复踩过的坑。所以数据准备的正确姿势是公开数据打底、现场数据补充。我一般会做这么几步先用公开数据集把模型训到能跑然后带着这个初版模型去现场采集一周到两周的监控视频把模型漏报的、误报的帧全部截出来。漏报帧标成对应的fire或smoke类误报帧标成background重新做一次增量训练。这里的标注尺度要注意火焰目标小标注框稍微松一点没关系但不要把整片火光标成一个框——一个火场里往往有多个火源宁可多标几个小框也不要合并成一个松散的大框。数据格式上直接走yolov8的标准格式一张图片配一个txt标签每行是class x_center y_center width height坐标全部归一化到0到1。如果你手里是VOC格式的xml或者COCO格式的json常见做法是写一个转换脚本把坐标从像素值换算成归一化值。转换时最容易翻车的点是xml里的坐标是左上角和右下角而yolo需要的是中心点和宽高换算公式是x_center(xminxmax)/2/widthy_center(yminymax)/2/heightw(xmax-xmin)/widthh(ymax-ymin)/height。这些看着简单但宽高比不规范时容易把目标框弄偏转换完一定要抽几张图可视化验证。类别的定义也需要提前统一。fire类只标注有明显火焰的区域包括火焰本体和被火焰染亮的边缘区smoke类只标注烟雾主体不标注淡淡的尾气或水蒸气。背景不需要专门标注yolov8会默认把所有未标注区域当背景。如果你在标注时把烟雾的透明区域也框进去了模型会被迫去学习半透明的东西是烟雾到了雨天或雾天就会疯狂误报。2.3 用yolov8训练自己的火灾数据集最小可跑通的命令数据准备完成之后训练阶段反而简单ultralytics把大部分逻辑封装好了。先装环境Python 3.8以上版本直接pip安装即可pip install ultralytics这一条命令会带上torch、opencv、numpy等依赖。需要注意torch的版本要和CUDA匹配如果你用的是gtx1660ti这种老卡建议装CUDA 11.8对应的torch版本否则推理阶段会出现显存无法分配或者kernel启动失败的问题。数据集目录结构按yolov8的规范组织然后写一个data.yamlpath: ./datasets/fire train: images/train val: images/val nc: 2 names: [fire, smoke]注意事项path字段写的是相对于当前工作目录的路径yolov8在读取yaml时会先拼接path和train/val路径配错是最常见的启动报错原因。nc必须和names的长度一致这个不一致会直接导致训练过程中维度错误连第一个epoch都跑不完。训练命令如下yolo train datafire.yaml modelyolov8s.pt epochs100 imgsz640 batch16 device0这里做了迁移学习model参数给的是yolov8s在coco上的预训练权重而不是从零开始训练。迁移学习对火灾检测尤其重要因为fire和smoke在coco里没有对应类别但coco训出来的骨干网络已经具备很强的纹理和边缘特征提取能力从小数据集上微调也能收敛得很快。imgsz设640是精度和速度的折中如果你现场的火源目标特别小可以提到768或832但推理延迟会明显上升。batch要按显存调gtx1660ti的6G显存跑yolov8s建议batch16跑yolov8l就降到8否则会OOM。训练过程中的关键参数还有epochs。火灾检测数据量通常不大几千张图时100个epoch足够设太大反而容易过拟合让模型在val集上mAP下降。如果看到训练日志里val损失在某个epoch之后开始回升说明过拟合了可以把epochs减半或者在yaml里加一句augment参数来增加数据增强强度。训练完成后验证一下模型在val集上的表现yolo val modelruns/detect/train/weights/best.pt datafire.yaml这里会输出mAP50和mAP50-95两个指标。对于火灾检测我更看重mAP50和低置信度下的召回率因为告警系统可以接受mAP50-95不高但绝不能接受漏报。如果mAP50还能接受但召回率偏低先别急着调模型回到数据层面看看是不是fire和smoke的样本数量不均衡或者烟雾类样本太少导致模型对smoke的召回率拉胯。3. 把训练好的模型部署成可用服务导出、接口与视频流接入3.1 模型导出从pt到onnx再到engine的路径选择训练完成后的best.pt是PyTorch权重不能直接拿来上线。部署阶段第一步是把模型导出成推理引擎能加载的格式常见的路径是pt→onnx→engine。onnx是中间格式几乎所有推理框架都认engine是TensorRT专用格式只有在NVIDIA GPU上才能用。如果是rk3588这类瑞芯微平台则是pt→onnx→rknn走的是另一条工具链。导出onnx的命令很简单yolo export modelruns/detect/train/weights/best.pt formatonnx opset12导出的时候有几个参数值得注意。opset默认值是12如果后续要用TensorRT的某些高版本算子可以提到13或14但对yolov8s来说opset12已经够用。如果想用半精度推理可以在导出时加halfTrue但这也要求后续的推理设备支持FP16否则会报精度不匹配的错误。另外导出的onnx里默认带的是动态batch还是固定batch取决于你导出的方式如果走yolo命令默认是静态shape想要动态shape需要在Python接口里指定dynamicTrue。对GPU部署来说onnx的直接推理效率已经不错但要榨干GPU性能还是应该再转成TensorRT的engine。常见做法是用ultralytics的Python接口一步导出from ultralytics import YOLO model YOLO(best.pt) model.export(formatengine, imgsz640, workspace4)这里workspace参数是TensorRT构建引擎时允许使用的最大显存单位是GB设置太小会导致engine构建失败设置太大在共享GPU机器上会影响别人。engine的构建时间取决于模型大小和机器性能yolov8s一般几分钟内能完成。需要注意的是TensorRT的engine与GPU型号和驱动版本强绑定在同一台机器上构建的engine换到另一张不同型号的GPU上大概率无法加载所以现场部署时要么在目标机器上重新构建要么用onnx在目标机器上现场转换。我个人的建议是如果现场是NVIDIA GPU直接走onnx运行时做首版部署确认功能没问题后再上TensorRT优化如果现场是rk3588这种NPU平台直接从onnx转rknn并全程在NPU上跑。不要在部署第一天就追求极致性能先保证监控视频能正常拉流、模型能稳定推理、告警能正确触发性能优化放在第二阶段。3.2 用Flask把推理封装成HTTP服务代码与参数说明部署形态上火灾检测服务最常见的接入方式是HTTP接口摄像头抓拍或视频抽帧后把图片POST给推理服务服务返回检测框和置信度。这样业务系统、告警平台、甚至一个简单的Web界面都能复用这个检测能力。用Flask封装推理服务是社区里最常见的做法代码量小、上手快、和yolov8的Python接口无缝衔接。下面这个例子是完整的推理服务核心代码from flask import Flask, request, jsonify import cv2 import numpy as np from ultralytics import YOLO app Flask(__name__) model YOLO(best.pt) TARGET_CLASSES [0, 1] # 0是fire1是smoke CONF_THRESHOLD 0.45 app.route(/detect, methods[POST]) def detect(): # 读取上传的图片文件 img_file request.files[image] img_bytes img_file.read() img cv2.imdecode(np.frombuffer(img_bytes, np.uint8), cv2.IMREAD_COLOR) if img is None: return jsonify({error: invalid image}), 400 # 推理过滤类别、控制置信度 results model.predict( img, confCONF_THRESHOLD, classesTARGET_CLASSES, verboseFalse ) detections [] for r in results: for box in r.boxes: detections.append({ cls_id: int(box.cls[0]), conf: round(float(box.conf[0]), 4), xyxy: [float(v) for v in box.xyxy[0].tolist()] }) return jsonify({count: len(detections), detections: detections}) if __name__ __main__: app.run(host0.0.0.0, port8080, threadedTrue)这段代码的逻辑分三层。第一层是图片解码Flask拿到的是multipart/form-data里的二进制文件需要先用np.frombuffer转成numpy数组再交给cv2.imdecode还原成BGR图像。这里有个隐藏的坑cv2.imdecode要求传入的是numpy数组直接传bytes会报错很多新手在这里翻车。第二层是模型推理注意这里用的是model.predict而不是直接调用model(img)原因是predict方法支持verboseFalse关闭日志输出——如果每帧请求都往标准输出打日志并发高的时候日志会拖慢处理速度。第三层是结果序列化把box的tensor转成Python原生类型再返回JSON因为tensor不能直接被jsonify序列化。参数说明上CONF_THRESHOLD我设的是0.45这个值来自实际部署的经验而不是理论推导。火灾检测场景里误报的代价是告警疲劳漏报的代价是安全事故所以阈值不能一概而论。如果现场误报多先把阈值往上拉到0.6如果漏报多往下调到0.3。用HTTP接口的好处是阈值可以在调用方配置不需要每次改代码重启服务。threadedTrue这个参数容易被忽略。Flask默认是单线程处理请求一张图推理耗时可能几十毫秒到上百毫秒单线程下并发一上来请求就会排队阻塞。开启threaded之后每个请求在独立线程里处理但要注意yolov8的推理本身是线程安全的因为每次predict都是独立执行上下文。3.3 接RTSP视频流做实时检测线程模型与帧缓冲HTTP接口适合抓拍和低频检测但火灾检测的现场大多是24小时视频监控需要直接接入RTSP流做连续检测。这时候最大的挑战不是模型推理而是视频流的读取稳定性。OpenCV的VideoCapture默认行为是从RTSP源拉流并缓存帧如果下游推理速度跟不上拉流速度缓冲区会一直堆积造成延迟越来越大。这里要用生产者消费者模型来解决。一个专门的线程负责从摄像头拉流把最新帧丢进一个固定大小的队列主线程只从队列取最新的一帧做推理。队列容量限制能自动丢帧保证系统处理的是实时画面而不是几秒钟前的旧帧这才是实时检测的正确打开方式。import cv2 import threading from collections import deque from ultralytics import YOLO model YOLO(best.pt) cap cv2.VideoCapture(rtsp://user:pass192.168.1.10:554/stream) # 帧缓冲只保留最新2帧拉流快于推理时自动丢弃旧帧 frame_queue deque(maxlen2) def read_frames(): while True: ret, frame cap.read() if ret: frame_queue.append(frame) t threading.Thread(targetread_frames, daemonTrue) t.start() while True: if len(frame_queue) 0: frame frame_queue.pop() results model(frame, conf0.45) annotated results[0].plot() cv2.imshow(fire_detect, annotated) if cv2.waitKey(1) 0xFF ord(q): break逻辑说明read_frames线程里不断调用cap.read()这个是阻塞的网络抖动时会一直阻塞在读取上但因为是独立线程主线程的推理循环不会跟着卡死。deque的maxlen2是关键它保证了队列最多只有2帧如果推理一帧耗时200ms队列里的帧会被新的覆盖读取的永远是最近的一帧而不是积压的旧帧。这里弹出来的帧是队列末尾的最新帧配合maxlen的覆盖机制延迟可以控制在两帧以内。如果觉得这个手写循环太简陋可以用更工程化的写法把队列换成queue.Queue(maxsize1)然后put_nowait失败时丢弃当前帧。但对于火灾检测这种场景deque maxlen的丢帧语义已经够清楚了我倾向于用最直白的方式表达。推理后的可视化部分有个性能隐患results[0].plot()和cv2.imshow都占用CPU如果只是做后台告警而不需要实时显示画面这两个步骤可以去掉只保留检测结果输出。现场部署时我一般会在主循环里加一个告警回调函数检测到fire或smoke且置信度超过阈值时直接把结果推给下游——这个下游可以是MQTT、钉钉机器人或者消防主机的HTTP接口而不是把画面显示在屏幕上。显示窗口只适合开发调试阶段长时间运行时不关掉它反而会积累大量窗口缓存拖垮整个进程。4. 部署避坑误报、漏检与性能瓶颈的现场排查4.1 现象测试集mAP不错现场狂误报这是火灾检测部署里出现频率最高的问题。现象是模型在val集上mAP50能到0.85但现场跑起来后傍晚的晚霞、路口的红色卡车、甚至反光的红色灭火器都被识别成火焰告警手机一天能被轰炸几十次。原因不复杂训练集里的正样本大多是典型的火焰形态——明亮的橙色、蜂窝状纹理、有明确边界但现场的自然场景里有大量像火焰但不是火焰的东西它们和火焰共享了颜色和亮度特征模型没有足够的负样本去区分边界。解决方案分三步走。第一步提高置信度阈值从默认的0.45提到0.6甚至0.7这一步能挡掉一半以上的弱误报第二步采集现场误报图像在训练集里显式添加background类——注意不是重新标一个类而是把这些误报图放在背景目录里用空标签文件表示此图无目标第三步加入帧间判定逻辑单帧检测结果不直接触发告警改为连续3帧中至少有2帧命中同一位置才告警。这三步做完误报量通常会下降一个数量级。提示现场负样本的采集周期要覆盖不同时间段。只采白天的画面晚上路灯亮起时照样误报报警。一个稳妥做法是部署系统跑一周把这一周的帧级告警和触发截图全部存档再统一做负样本筛选。4.2 现象GPU利用率不高帧率却上不去有段时间我在gtx1660ti上部署yolov8s显存占用2GB出头但GPU利用率只有30%多帧率卡在10fps左右。第一反应以为是模型太大换成yolov8n还是差不多。查了一圈才发现瓶颈根本不在GPU——每一帧都要经历摄像头拉流、CPU解码、BGR转RGB、letterbox resize、numpy转tensor、GPU推理、结果回传CPU这个过程其中大部分预处理步骤都在CPU上串行执行CPU成了瓶颈GPU只能等着喂数据。解决办法有几个方向。最直接的是把预处理挪到GPU上用torch的tensor操作替代numpy和OpenCV做resize其次是尽量用model.predict的批量推理把多帧合成一个batch喂给GPU利用GPU的并行能力代价是单帧延迟会稍微增加更彻底的是直接上TensorRT把模型构建成engine之后预处理和推理可以合并到一条优化过的计算流里CPU的参与度大幅降低。我实际测试下来同一张gtx1660ti上从onnxruntime切到TensorRT engine帧率能提升2到3倍。4.3 现象rk3588上onnx推理明显慢于预期把训练好的onnx模型部署到rk3588上时如果直接拿onnxruntime跑你会发现速度慢得让人怀疑人生——yolov8s在640输入下只有3到5fps。原因是rk3588的算力主要在NPU上而onnxruntime默认只在CPU上执行完全没有利用NPU。rk3588要走的是瑞芯微的RKNN工具链先把onnx转成rknn格式再通过RKNN的Python接口在NPU上推理。转换时有两个关键点。第一模型的算子要兼容RKNNyolov8s里如果有不支持的算子转换过程会报错或降级到CPU执行推理速度依然上不来第二RKNN的量化校准需要一组代表真实场景的校准图片通常几百张就够了用训练集的子集就可以。如果不做校准直接转int8精度损失可能大到无法接受现场漏报率会显著上升。所以rk3588的正确部署路径是训练好的pt权重导出onnx再用rknn-toolkit2转rknn最后在板子上加载rknn做推理这样才能跑到20fps以上的水平。4.4 现象跑几天后视频延迟越来越大系统刚部署时一切正常但运行几天后告警响应的延迟从秒级变成几十秒甚至分钟级。这个问题在RTSP接入场景里很常见。现象背后是OpenCV的VideoCapture在拉流时内部有一个缓冲队列推理速度跟不上拉流速度时还没来得及消费的帧在缓冲区里越积越多最终系统处理的画面是几分钟前的旧帧。另一个元凶是如果推流端和拉流端之间的网络有抖动TCP重传会导致接受端的解码队列堆积。解决思路就是前面3.3说的丢帧策略。内存里的帧缓冲严格限定大小处理不过来就直接丢帧保证永远只分析最新帧。同时可以显式设置OpenCV的拉流缓冲区大小cap cv2.VideoCapture(rtsp_url) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)CAP_PROP_BUFFERSIZE设为1意味着OpenCV内部只缓冲很少的帧这能一定程度上缓解堆积问题但不是所有RTSP摄像头都支持这个属性不支持时OpenCV会静默忽略没有任何报错。我的习惯是缓冲策略在代码层做硬限制不依赖OpenCV内部行为因为那个行为在不同平台、不同OpenCV版本下表现不一致属于玄学区域。5. 验证与进阶把部署从能跑做到敢用5.1 部署后的验证指标怎么测部署完成不等于上线至少要过三道验证关。第一关是端到端延迟在视频帧上叠加时间戳从摄像头采集到帧到告警消息发出整个链路延迟控制在3秒以内才算合格——火灾蔓延的速率很快几十秒的延迟会让系统失去意义。第二关是现场漏报率把部署首周的监控录像完整回放一遍统计模型漏了几次真实火情漏报率必须为零这个没有妥协空间。误报率可以用每天真实告警占总告警的比例来衡量低于10%可以接受高于这个值说明置信度阈值或者负样本策略还要调。5.2 进阶帧间去抖与告警联动最后一个常用技巧是帧间去抖。单帧检测的置信度会有抖动比如连续10帧里火焰在第3帧、第7帧、第9帧被检出其余帧漏检了直接用单帧告警会产生大量重复推送。常见做法是滑动窗口判定以最近5帧作为一个窗口如果窗口内超过3帧检出火焰且位置重叠才触发一次告警。这样既保证了漏报率不上升又把告警推送量压缩到原来的几分之一。告警联动上HTTP webhook是最通用的出口一条简单的POST请求就能把检测结果推给消防主机或企业微信机器人代码逻辑和3.2的Flask服务天然兼容。做这个项目这么久我养成的习惯是任何模型部署后都要留一周的现场数据做回归测试用真实录像重新跑一遍模型对比告警记录和实际火情记录。我第一次上火灾检测时客户的仓库门口傍晚夕阳照在地面上系统连续半小时误报场面非常尴尬。后来我总结了一条经验部署不是训练的终点现场数据回灌才是闭环的最后一公里。希望帮到你。本文还有配套的精品资源点击获取