简介目标检测是计算机视觉领域的核心任务之一广泛应用于安防消防场景。YOLOv5作为经典的一阶段检测算法在精度、速度与部署生态之间取得良好平衡成为工程落地的热门选择。其模型结构可灵活配置通过调整输入尺寸与模型宽度能够适配不同算力的边缘设备。在火灾检测场景中模型需识别火焰与烟雾但受光照、背景干扰等因素影响实际部署常面临误检、漏检问题。利用RKNN工具链将训练好的PyTorch模型转换并量化可在RK3568、RV1106等边缘平台实现实时推理。本文从数据准备、环境配置、训练调优到模型转换与板端部署系统梳理了完整流程为安防消防领域开发者提供实践参考。 火灾检测这类项目我一直觉得是目标检测最容易“看着简单、做起来头大”的领域之一。火焰形态多变、烟雾半透明、光照干扰严重模型在测试集上刷到多高都没用真正装到现场摄像头上才是考验。这篇我就围绕基于YOLOv5的火灾检测把从数据集准备、环境安装、模型训练到RK3568、RV1106这类边缘设备部署的完整链路拆开讲顺便把我踩过的坑和排查思路一并写出来。内容适合刚接触YOLOv5、准备做安防消防方向的开发者实战部分默认你有Python和Linux基础。1. 项目整体设计与算法选型思路1.1 为什么选YOLOv5而不是其他检测算法火灾检测本质上是一个目标检测任务输入是摄像头视频帧输出是画面中的火焰区域或烟雾区域。市面上能选的检测模型很多YOLOv5能在大量项目里成为默认方案不是因为它的精度绝对最高而是它在精度、速度、部署难度和生态成熟度之间取得了非常难得的平衡。先看精度和速度。YOLOv5提供了s/m/l/x几个不同规模的版本从几十MB到上百MB的权重都有。消防场景如果是接普通的IPC摄像头通常不需要追求极端精度YOLOv5s在640x640输入下RTX 3060级别的显卡上能跑到几百帧换成RK3568这种边缘板子配合NPU量化后也能做到实时。如果算力更紧张比如RV1106这种IPC SoC还可以把输入尺寸缩到320甚至256YOLOv5s也能勉强扛住实时。再看生态。YOLOv5官方仓库的文档和社区资料非常全数据集格式、训练脚本、推理脚本、导出ONNX的流程统统都是现成的。做项目的时候最怕模型训好了卡在工程化上YOLOv5的导出链路很成熟从PyTorch到ONNX再到RKNN网上能找到大量现成案例。这一点对于要快速交付的火灾检测项目来说太重要了。对比过YOLOv8和YOLOv9之后我依然建议新项目直接上YOLOv5。YOLOv8的接口更现代但很多边缘部署工具链对v5的支持更稳定尤其瑞芯微的RKNN-Toolkit对YOLOv5的适配已经很成熟转模型的时候基本不需要改太多东西。YOLOv9或者更新版本虽然精度可能高一点但转端侧模型时的坑会多不少火灾检测这类场景并不需要前沿模型带来的一点精度提升稳定复现才是关键。1.2 检测目标与数据集设计火灾检测的检测目标通常分两类火焰fire和烟雾smoke。多数项目会把这两个作为两个独立类别而不是合并成一类。原因是火焰和烟雾的视觉特征差异非常大火焰有高频闪烁、颜色鲜明、边缘不规则烟雾是半透明纹理、颜色从白到黑都有、扩散方向受风影响。如果合并成一类模型很容易被训练成一个对“画面异常区域”敏感的分类器误检率会明显上升。不过类别定义也要看具体场景。如果你做的是室内机房火灾检测可能只需要火焰就够了因为烟雾在封闭空间里很快会触发烟感视频检测更多是确认起火点。如果你做的是森林防火烟雾往往是早期唯一信号这时候烟雾类别的权重反而要高一点。我一般建议在一开始就把两类都标注好哪怕当前场景暂时用不到后面切换场景时重新训练的成本会低很多。数据集的设计直接影响模型上限。火灾检测的公开数据集有少量可用的比如一些学术数据集但真实项目里基本都要补充大量自己的现场数据。原因在于火灾场景的“环境背景”极其敏感——同一个火焰在工厂车间、森林、隧道、商场里的视觉表现完全不同。模型训练时如果背景单一部署到新环境很容易误检。所以我的建议是第一轮可以先拿公开数据集跑通流程但正式交付前一定要采集目标场景的现场视频抽帧标注。1.3 技术方案整体架构整个项目从数据到部署可以拆成五层数据层负责采集、清洗、标注训练层负责配置模型、调整超参数、迭代训练评估层负责用mAP、混淆矩阵、推理速度等指标筛选模型转换层负责把训练好的权重导出为ONNX再转成边缘设备需要的RKNN格式部署层负责在RK3568/RV1106上跑推理并输出检测结果。我习惯先用一张表把方案定下来避免后面边做边改层级方案说明检测模型YOLOv5s精度速度均衡边缘设备友好输入尺寸640x640训练默认部署时按需降到320类别fire, smoke按场景可拆分或合并标注格式YOLO txt归一化坐标labelimg直接导出训练框架PyTorch 1.10官方YOLOv5仓库部署平台RK3568 / RV1106瑞芯微NPURKNN格式算法后处理NMS 置信度过滤部署时用板端后处理这套架构的好处是每一层之间边界清晰模型训练和部署调试可以并行。数据采集人员先标注一批算法人员同时搭训练环境等第一批数据到位马上开始训练部署人员同步准备转换脚本整体项目周期能压得很短。2. 环境准备与YOLOv5安装全流程2.1 硬件与软件环境先说训练环境。YOLOv5训练阶段主要吃GPU显存大小直接决定你最大能跑多大的batch。我用过8GB显存的RTX 3060 Laptop也用过24GB的RTX 3090感受非常明显。8GB显存跑YOLOv5s输入640x640batch最大也就8左右24GB显存可以跑到batch 32甚至更大。火灾检测数据集如果只有几千张batch大小对最终精度影响没有想象中大但训练时间有明显差距。软件环境我建议按这个组合来操作系统Ubuntu 20.04或Windows 10我主力是Ubuntu后面部署RKNN的工具链大多也是Linux优先。Python版本3.8或3.9不要用3.11这种太新的版本PyTorch和部分依赖可能跟不上。PyTorch版本1.10到2.0之间都可以官方YOLOv5对不同版本的兼容性还可以但没必要追新。CUDA跟随PyTorch官方推荐的版本比如PyTorch 1.12对应CUDA 11.3。RV1106/RK3568的部署环境我后面会详细讲这里先提一句瑞芯微的rknn-toolkit2最好装在一台x86的Ubuntu机器上用来完成模型转换板子端只负责推理不要在板子上直接装转换工具链会非常痛苦。2.2 YOLOv5下载与依赖安装YOLOv5本身不用pip直接安装它是个Git仓库。我习惯把仓库clone到工作目录然后在项目目录下创建虚拟环境安装依赖。git clone https://github.com/ultralytics/yolov5.git cd yolov5 python -m venv venv source venv/bin/activate pip install -U pip pip install -r requirements.txt这里有个小细节requirements.txt里的torch版本可能不是你本机适合的版本。如果你已经有了匹配CUDA的torch可以先装torch再装其他依赖避免pip因为版本冲突重新装CPU版torch。我踩过一次直接pip install -r requirements.txt结果torch被换成了CPU版训练慢得怀疑人生。正确做法是先用官方命令装好GPU版torch再执行pip install -r requirements.txt另外如果网络条件不太稳定建议把pip源换成国内镜像不然下载几十个依赖包时经常超时pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple装完依赖后还要下载预训练权重。YOLOv5官方仓库的README里放了不同规模权重的下载链接或者直接用代码下载# 在yolov5目录下执行 python -c from utils.downloads import attempt_download; attempt_download(yolov5s.pt)权重文件不大yolov5s.pt大概14MB左右。下载完成后放在仓库根目录即可训练脚本会自动识别。2.3 安装后的快速验证依赖装完建议先跑一次detect脚本确认环境没问题不要直接开始训练。找一个测试图片或视频用官方权重跑一遍python detect.py --source data/images/bus.jpg --weights yolov5s.pt --conf 0.25如果命令行输出“Detect: 1 images, 2 objects”之类的结果说明YOLOv5已经把图片中的人、车识别出来了检测结果保存在runs/detect/exp下。这一步能同时验证PyTorch、weights、opencv等依赖是否正常。我遇到过一个问题环境全部装好但跑detect时直接报错“AttributeError: Upsample object has no attribute recompute_scale_factor”。这是PyTorch版本太新和YOLOv5代码兼容性导致的问题解决方式很粗暴把PyTorch降到2.0以下或者找到models/common.py里对应的Upsample代码改成新版接口。新手建议直接按我前面推荐的PyTorch版本安装省得折腾。3. 自己数据集的标注与训练核心步骤3.1 数据采集与标注格式火灾检测的数据来源一般是现场监控视频或网络公开的视频。我通常会先把视频按每秒1到2帧抽出来避免相邻帧相似度太高导致数据集冗余。一个10分钟的视频大概能抽出600到1200张图片如果场景单一需要保留少一些如果场景变化大光照、角度、距离都不同可以适当多抽。标注工具我主力用labelimg它支持YOLO格式直接导出操作简单适合快速标注。有些团队用labelme但labelme默认输出的是JSON格式转YOLO格式还要多一步脚本我嫌麻烦。labelimg的安装方式pip install labelimg启动后打开图片目录按W键创建矩形框选择类别。对于火焰和烟雾我建议的标注原则是火焰区域画框尽量贴合可见火光的范围不要包含太多周围的暗色背景。烟雾区域画框时需要包含整个可见烟雾团即使烟雾很淡、半透明也尽量画进去。如果一个画面中有多个独立的火点或烟团分别画框。对于重叠的火焰和烟雾可以分别画两个框不做强制互斥。标注完成后每张图片会对应生成一个同名txt文件内容是“类别编号 中心点x 中心点y 框宽 框高”所有坐标都归一化到0-1之间。这个格式是YOLO系列的通用格式YOLOv5直接支持。标注质量直接决定训练效果。我在实际项目里发现很多人为了赶进度会把烟雾框画得特别松导致模型学到一个“越靠近画面边缘越容易输出大框”的倾向。这个问题很难在训练阶段完全纠正所以标注时宁可多花五分钟把细节画好也不要想着靠后续清洗数据来补救。3.2 数据集划分与data.yaml配置标注完成后要把数据集划分成训练集、验证集、测试集。我用一个简单脚本自动完成比例一般设成8:1:1。每个集合里只放图片文件路径标注文件由YOLOv5自动按同名规则寻找所以图片和txt必须保持在同一个子目录下。最终的目录结构可以这样组织datasets/fire_dataset/ images/ train/ val/ test/ labels/ train/ val/ test/然后写一个data.yaml告诉YOLOv5数据在哪里、类别是什么train: datasets/fire_dataset/images/train val: datasets/fire_dataset/images/val test: datasets/fire_dataset/images/test nc: 2 names: [fire, smoke]这里要注意train和val路径是相对yolov5仓库根目录的。如果你把数据集放在仓库外最好写绝对路径避免训练时找不到数据。我在项目里遇到过路径写错导致训练脚本直接报错“AssertionError: train: No images in datasets/...”检查了十分钟才发现是相对路径的问题。3.3 单通道灰度图训练改造火灾检测里有个特殊需求很多工业摄像头是黑白或者红外模式输出的是单通道灰度图。YOLOv5默认输入是三通道RGB直接训练单通道数据会报错。这个改造其实不难但要动两个地方。第一步修改模型配置。打开models/yolov5s.yaml把输入通道数从3改成1# YOLOv5s backbone nc: 2 # 原来是3 ch: 1 # 新增默认没有这一项时是3 depth_multiple: 0.33 width_multiple: 0.50如果不想改全局配置也可以在训练命令里直接指定模型参数但那样更麻烦建议直接改yaml。第二步修改数据集加载逻辑。YOLOv5的datasets.py里LoadImagesAndLabels类读取图片时默认用cv2.imread得到的是三通道BGR。你需要改成用灰度模式读取并在加载后不转为三通道。我常用的做法是在datasets.py里加一个参数# 在LoadImagesAndLabels的__init__参数里增加single_channelFalse # 在读取图片后 img cv2.imread(path, cv2.IMREAD_GRAYSCALE if self.single_channel else cv2.IMREAD_COLOR) if self.single_channel: img img[:, :, None] # 保持HWC格式同时要处理增强部分YOLOv5的RGB色彩增强色调、饱和度、明度变化对单通道图没有意义需要跳过。我通常在增强函数里判断一下如果是单通道就直接走几何增强和mosaic把hsv增强部分绕过。还有一种偷懒的方案加载灰度图后依然复制成三个通道喂给模型这样不需要改模型结构但会让模型有额外的通道冗余参数量和计算量没有减少而且迁移到板端时可能还是需要特殊处理。我的体会是如果你确定最终部署输入的也是单通道图就老老实实改模型收益是实打实的。3.4 超参数选择与训练命令YOLOv5的超参数主要有两类训练超参数学习率、batch、epochs和模型超参数anchors、loss权重。训练前我一般先调整几个关键项epochs火灾数据集如果是2000到5000张100到150个epoch就够。再多容易过拟合。batch size显存允许下尽量大至少8。batch太大对收敛速度提升有限但batch太小会导致loss波动很大。img-size训练默认640。如果准备部署到RV1106这种算力有限的板子也可以从384或320开始训练避免训练和部署输入尺寸差异太大导致精度下降。lr0初始学习率默认0.01。用小数据集训练时我习惯降到0.005更稳。mosaic默认1.0数据增强里mosaic对火灾检测很有帮助能增强模型对不同尺度和背景的适应能力。训练命令我用的是python train.py --img 640 --batch 16 --epochs 150 \ --data datasets/fire_dataset/fire.yaml \ --weights yolov5s.pt \ --cache \ --name fire_v5s这里--weights指定预训练权重例如yolov5s.pt可以显著加速收敛。如果数据集比较小也可以不加载预训练权重改用--weights 让模型从头开始训练。火灾检测这种场景预训练权重是在COCO上训练的虽然类别和火灾完全不同但底层的纹理、边缘特征迁移价值还是很大的建议默认加载。如果你用了单通道改造加载yolov5s.pt的时候会因为第一层卷积通道数不匹配报错。这种情况下要么改用随机初始化要么用我下面这个粗糙但有效的方法把预训练权重的第一层卷积权重在通道维度上做平均把3个通道的平均值复制到1个通道。不过说实话直接把预训练权重舍弃从零训练单通道模型在数据量几千张时效果也还过得去不必过度纠结。4. 训练过程监控与模型评估4.1 训练日志与loss曲线解读YOLOv5训练过程中会在终端输出每个epoch的loss、mAP、速度和显存占用。这些信息一定要盯住不要等训练结束再看。我最常看三个指标训练loss包含box_loss、obj_loss、cls_loss三个分量。验证集mAP50和mAP50-95。验证集precision和recall。训练开始后loss通常会先快速下降后面进入平稳期。如果loss在训练集上持续下降但在验证集上不再提升说明开始过拟合了这时候可以提前停止或者降低数据增强的强度。一个常见误区是只看loss曲线忽略mAP。loss低不代表检测效果好尤其是火灾数据集中负样本少的时候模型可能把所有区域都预测为背景此时loss看起来很低但mAP也低得可怜。我习惯在训练到一半时人工看一些检测输出比看指标更直观。训练过程中的权重会自动保存runs/train/fire_v5s/weights/best.pt和last.pt。best.pt是验证集mAP最高的权重可以用来后续评估和部署。last.pt是最后一个epoch的权重。4.2 mAP与混淆矩阵评估训练完成后用best.pt跑一次验证得到更详细的评估结果python val.py --data datasets/fire_dataset/fire.yaml \ --weights runs/train/fire_v5s/weights/best.pt \ --img 640命令结束后会生成混淆矩阵、F1曲线、PR曲线等图表保存到runs/val/exp下。我主要看两类一是mAP50。对火灾检测来说mAP50如果能达到85%以上基本可以满足大部分场景的需求。mAP50-95要求框和真实标注的重合度更严格如果这个值不高说明模型框的位置不够准在部署时可能影响叠加在监控画面上的显示效果。二是混淆矩阵。由于火灾检测通常只有两个类别混淆矩阵能很直观地告诉我们模型是把火焰误判成烟雾还是把背景误判成火焰。如果背景误判火焰的比例高说明负样本不够或者置信度阈值设得太低。如果火焰误判成烟雾说明两类样本的特征区分度还不够可以考虑增加标注的边界质量或者尝试用更强的数据增强。4.3 误检漏检优化方向火灾检测项目里最怕的是误检。工厂里一个红色灯光、太阳反射、暖风机都可能被模型当成火焰。这类误判在演示阶段问题不大一上正式环境就容易被投诉。我的优化路线一般是这样的先排查是不是数据问题。加入大量目标场景的负样本比如没有火灾的车间画面、夜景、灯光闪烁画面。YOLOv5训练时可以通过在数据目录里放一些没有标注文件的图片来充当负样本模型会学到这些图片里没有目标。这个方法在某些情况下很有效但要注意负样本比例不要太高否则模型会对检测目标过于保守漏检率上升。再排查是不是后处理问题。部署时置信度阈值不要设太低我一般设为0.4到0.5之间。如果屏幕上全是误检框很可能是阈值太低换成0.5能过滤掉大量低置信度误检。如果漏检严重再把阈值下调到0.3同时配合NMS的iou阈值调整。如果数据和后处理都调过还是不行考虑做类别拆分或增加一个“疑似火源”类别。曾有项目里场景中有红色机械臂和火焰颜色很像模型难以区分。我们在标注时单独增加了一个“red_object”负样类别让模型明确区分误检率下降了一大截。虽然这不是必须的做法但在特定场景下非常有用。5. 边缘设备部署RK3568与RV1106实战5.1 端侧部署方案选型火灾检测部署到边缘设备考虑的维度主要是算力、内存、成本。RK3568和RV1106都是瑞芯微旗下常见的芯片两者的定位不同RK3568算力更强适合多路摄像头或需要跑中等模型的场景RV1106是一颗IPC专用SoC算力更小适合单路摄像头做本地火灾检测。RK3568内置NPU算力达到1TOPs左右实际有效算力依量化情况而定跑YOLOv5s在640x640下能做实时但CPU占用会比较紧张。RV1106的NPU算力更弱通常建议把输入尺寸降到320x320模型进一步换成更轻量的版本比如把YOLOv5s的width_multiple调整成0.25或者直接选YOLOv5n。从部署工具链来说两块板子都使用瑞芯微的rknn-toolkit2。转换流程基本一致先导出ONNX再把ONNX转成RKNN。区别在于target_platform设置不同rk3568和rv1106对应的平台标识不一样转出来的RKNN模型不通用。我在选型时还有一个习惯先看项目需要几路摄像头。单路低功耗RV1106合适两路以上RK3568合适。如果还要求联动报警、存储录像那RK3568或更高端的RK3588更合适。这个决策要先定下来否则后面转换模型时会发现平台选错白费功夫。5.2 ONNX导出与RKNN转换YOLOv5官方仓库自带导出脚本可以直接导出ONNXpython export.py --weights runs/train/fire_v5s/weights/best.pt \ --img 640 \ --batch 1 \ --include onnx \ --simplify导出后得到的best.onnx是包含检测头的完整模型输出三个不同尺度的特征图。如果你打算直接用ONNX做CPU推理这个就够了但如果要转RKNN我建议先用Netron打开看一下输出节点名称记下三个输出的名字。RKNN转换时需要用到这些名字。接下来在Ubuntu x86机器上安装rknn-toolkit2。这个工具依赖很多建议单独建Python虚拟环境。安装后转换脚本大致如下from rknn.api import RKNN rknn RKNN() rknn.config( mean_values[[0, 0, 0]], std_values[[255, 255, 255]], target_platformrk3568, quantized_dtypew8a8, quantized_algorithmnormal ) rknn.load_onnx(modelbest.onnx) rknn.build(do_quantizationTrue, datasetdataset.txt) rknn.export_rknn(fire_yolov5s.rknn)这里的dataset.txt是量化校准的图片路径列表每行一张图片。尽量从训练集中随机选100到200张覆盖不同场景的图片不要选太相似的视频抽帧否则量化后的精度会崩。rknn.build时do_quantizationTrue表示要做int8量化这也是在RK3568/RV1106上获得实时性能的关键。转完之后在板子上用rknn-toolkit2的Python接口加载模型推理from rknnlite.api import RKNNLite rknn_lite RKNNLite() rknn_lite.load_rknn(fire_yolov5s.rknn) rknn_lite.init_runtime() outputs rknn_lite.inference(inputs[frame])RKNN的输出不是YOLOv5原始输出那种直接可用的边界框你需要写一个后处理函数对三个尺度的输出分别解码做NMS再映射回原图坐标。网上有很多现成的解码代码但要注意输入尺寸和anchor配置是否和你的模型一致。5.3 部署后的精度与性能调优部署到板端后最常见的两个问题是检测框偏了、推理时间太长。检测框偏了多半是输入预处理不一致。YOLOv5训练时会对图片做letterbox等比缩放加灰色填充部署时也一定要用同样方式预处理。很多人转RKNN后直接resize到640x640导致物体变形检测框自然不准。我建议在板端代码里写死一个letterbox函数和训练时的做法保持一致。推理时间太长先看是不是没做量化。如果加载的是fp16甚至fp32的模型NPU算力优势完全发挥不出来。用rknn_toolkit2的profiling功能可以看到每一层在NPU和CPU上的耗时如果发现大量层落在CPU上很可能是因为某些算子NPU不支持需要调整模型结构或版本。对于RV1106如果推理仍无法达到25fps以上我会采取这些手段把输入尺寸从640降到320检测精度会下降一些但速度提升非常明显。把模型从YOLOv5s换成YOLOv5n或者在yolov5s.yaml里把width_multiple改成0.25。在训练时就以低分辨率输入重新训练不要用高分辨率权重直接转低分辨率。检查代码里是否在inference后做了不必要的图像转换尽量把BGR转RGB的操作一次性做完。我在实际部署中用RK3568跑YOLOv5s 640量化模型推理耗时大概在20到30msRV1106跑YOLOv5n 320量化模型推理耗时能压在40到50ms左右。这个数据在不同固件版本下会有差异但可以作为参考。6. 常见坑与排查技巧实录6.1 训练阶段典型问题训练阶段我遇到的坑可以列一张表新手照着排查能省很多时间现象可能原因解决方案训练报“No labels in data/train.cache”标签目录或data.yaml路径不对检查路径确认labels和images目录对应loss直接变成NaN学习率过高或数据中有异常值降低lr0到0.001检查标注文件是否越界训练集loss很低验证集mAP也低过拟合或数据增强过强降低epochs减少mosaic增加数据量单通道训练报conv2d通道不匹配模型配置文件未改ch1修改yolov5s.yaml并重新初始化权重mAP50很高但实际部署误检多数据分布和部署场景差异大补充现场场景负样本调整阈值其中一个我特别想提醒的是“cuda out of memory”。很多人遇到后第一反应是调小batch然后反复重启训练。更好的做法是先用1个batch跑一次前向确认显存占用再按比例调整。或者用--cache参数把数据预先加载到内存中避免训练过程中频繁读取数据导致显存抖动。6.2 部署阶段典型问题部署阶段的问题更多是平台相关的。RKNN转换过程中常见的错误包括load_onnx失败提示模型格式不合法。大部分情况是ONNX版本太新或者导出的算子太复杂建议用onnxsim简化或者换低版本PyTorch重新导出。RKNN build时quantization失败可能原因是校准数据集图片读取失败。检查dataset.txt里的路径是否存在以及图片是否损坏。RKNN推理结果全为零或全为背景框一般是预处理和后处理没对齐。建议先用一张训练集中的图片跑一次rknn推理和PyTorch输出对比逐步排查。rknnlite在板子上初始化失败多半是固件中NPU驱动版本和rknn-toolkit2版本不匹配。瑞芯微的工具链版本更新很快装的时候一定要对应你板子固件版本否则会出现奇怪的运行时错误。我做项目时习惯把转换、推理、后处理拆成三个独立脚本每个阶段都能单独验证。转换完先看rknn推理输出的shape和数值范围再确认后处理结果最后再接入摄像头视频流。这样做问题定位非常快不会出现所有代码都写完然后又不知道是哪一步出错的情况。6.3 火灾检测场景专属避坑最后单独说几个和火灾检测本身强相关的坑。火焰检测对颜色非常敏感。如果训练数据大部分是白天晴天拍摄到了夜晚或者阴天模型很容易漏检。我的建议是训练数据里至少包含白昼、黑夜、黄昏、逆光四种光照场景。如果现场有条件最好做一次24小时的录制再抽帧标注。烟雾检测难在半透明。烟雾的边缘是渐变的模型很难定位精确的边界。我在标注时会把烟雾的“可见影响范围”全部框进去而不是只框最浓的部分。训练时烟雾类别的损失权重可以微调但YOLOv5默认的类别权重已经比较均衡不需要大改。火灾视频里火焰会有明显的闪烁和形变。单帧检测时模型有时会把同一个火源裂成好几个检测框一会儿有框一会儿没框。我在部署时会在后处理里加一个简单的时序平滑对连续几帧的检测框做加权平均或者只有当同一个位置连续出现多帧时才输出报警。这个机制对误报抑制很有帮助虽然会增加一点代码量但实际效果比单帧阈值调优好得多。还有就是摄像头安装角度。如果摄像头俯视安装火焰和烟雾的形态会和平视差别很大。所以训练时一定要用和目标安装角度接近的样本。如果项目是旧摄像头改造最好先到现场拍一段视频看实际视角再决定数据补充方案。我个人的实测感受是YOLOv5做火灾检测真正难的地方从来不是模型训练本身而是数据和部署之间的那条鸿沟。训练好的模型在PC上效果再好不经过现场数据校准、不量化部署验证、不做时序平滑最终效果一样会打折扣。建议你在做这类项目时把至少三分之一的时间留给现场测试和数据补充而不是一味地调模型结构。先跑通一套最小闭环从摄像头取流到模型推理到报警输出再逐步优化各个环节这个节奏比完美主义式的反复训练要靠谱得多。本文还有配套的精品资源点击获取 YOLOv5火灾检测模型训练与RK3568/RV1106边缘部署实战
简介目标检测是计算机视觉领域的核心任务之一广泛应用于安防消防场景。YOLOv5作为经典的一阶段检测算法在精度、速度与部署生态之间取得良好平衡成为工程落地的热门选择。其模型结构可灵活配置通过调整输入尺寸与模型宽度能够适配不同算力的边缘设备。在火灾检测场景中模型需识别火焰与烟雾但受光照、背景干扰等因素影响实际部署常面临误检、漏检问题。利用RKNN工具链将训练好的PyTorch模型转换并量化可在RK3568、RV1106等边缘平台实现实时推理。本文从数据准备、环境配置、训练调优到模型转换与板端部署系统梳理了完整流程为安防消防领域开发者提供实践参考。 火灾检测这类项目我一直觉得是目标检测最容易“看着简单、做起来头大”的领域之一。火焰形态多变、烟雾半透明、光照干扰严重模型在测试集上刷到多高都没用真正装到现场摄像头上才是考验。这篇我就围绕基于YOLOv5的火灾检测把从数据集准备、环境安装、模型训练到RK3568、RV1106这类边缘设备部署的完整链路拆开讲顺便把我踩过的坑和排查思路一并写出来。内容适合刚接触YOLOv5、准备做安防消防方向的开发者实战部分默认你有Python和Linux基础。1. 项目整体设计与算法选型思路1.1 为什么选YOLOv5而不是其他检测算法火灾检测本质上是一个目标检测任务输入是摄像头视频帧输出是画面中的火焰区域或烟雾区域。市面上能选的检测模型很多YOLOv5能在大量项目里成为默认方案不是因为它的精度绝对最高而是它在精度、速度、部署难度和生态成熟度之间取得了非常难得的平衡。先看精度和速度。YOLOv5提供了s/m/l/x几个不同规模的版本从几十MB到上百MB的权重都有。消防场景如果是接普通的IPC摄像头通常不需要追求极端精度YOLOv5s在640x640输入下RTX 3060级别的显卡上能跑到几百帧换成RK3568这种边缘板子配合NPU量化后也能做到实时。如果算力更紧张比如RV1106这种IPC SoC还可以把输入尺寸缩到320甚至256YOLOv5s也能勉强扛住实时。再看生态。YOLOv5官方仓库的文档和社区资料非常全数据集格式、训练脚本、推理脚本、导出ONNX的流程统统都是现成的。做项目的时候最怕模型训好了卡在工程化上YOLOv5的导出链路很成熟从PyTorch到ONNX再到RKNN网上能找到大量现成案例。这一点对于要快速交付的火灾检测项目来说太重要了。对比过YOLOv8和YOLOv9之后我依然建议新项目直接上YOLOv5。YOLOv8的接口更现代但很多边缘部署工具链对v5的支持更稳定尤其瑞芯微的RKNN-Toolkit对YOLOv5的适配已经很成熟转模型的时候基本不需要改太多东西。YOLOv9或者更新版本虽然精度可能高一点但转端侧模型时的坑会多不少火灾检测这类场景并不需要前沿模型带来的一点精度提升稳定复现才是关键。1.2 检测目标与数据集设计火灾检测的检测目标通常分两类火焰fire和烟雾smoke。多数项目会把这两个作为两个独立类别而不是合并成一类。原因是火焰和烟雾的视觉特征差异非常大火焰有高频闪烁、颜色鲜明、边缘不规则烟雾是半透明纹理、颜色从白到黑都有、扩散方向受风影响。如果合并成一类模型很容易被训练成一个对“画面异常区域”敏感的分类器误检率会明显上升。不过类别定义也要看具体场景。如果你做的是室内机房火灾检测可能只需要火焰就够了因为烟雾在封闭空间里很快会触发烟感视频检测更多是确认起火点。如果你做的是森林防火烟雾往往是早期唯一信号这时候烟雾类别的权重反而要高一点。我一般建议在一开始就把两类都标注好哪怕当前场景暂时用不到后面切换场景时重新训练的成本会低很多。数据集的设计直接影响模型上限。火灾检测的公开数据集有少量可用的比如一些学术数据集但真实项目里基本都要补充大量自己的现场数据。原因在于火灾场景的“环境背景”极其敏感——同一个火焰在工厂车间、森林、隧道、商场里的视觉表现完全不同。模型训练时如果背景单一部署到新环境很容易误检。所以我的建议是第一轮可以先拿公开数据集跑通流程但正式交付前一定要采集目标场景的现场视频抽帧标注。1.3 技术方案整体架构整个项目从数据到部署可以拆成五层数据层负责采集、清洗、标注训练层负责配置模型、调整超参数、迭代训练评估层负责用mAP、混淆矩阵、推理速度等指标筛选模型转换层负责把训练好的权重导出为ONNX再转成边缘设备需要的RKNN格式部署层负责在RK3568/RV1106上跑推理并输出检测结果。我习惯先用一张表把方案定下来避免后面边做边改层级方案说明检测模型YOLOv5s精度速度均衡边缘设备友好输入尺寸640x640训练默认部署时按需降到320类别fire, smoke按场景可拆分或合并标注格式YOLO txt归一化坐标labelimg直接导出训练框架PyTorch 1.10官方YOLOv5仓库部署平台RK3568 / RV1106瑞芯微NPURKNN格式算法后处理NMS 置信度过滤部署时用板端后处理这套架构的好处是每一层之间边界清晰模型训练和部署调试可以并行。数据采集人员先标注一批算法人员同时搭训练环境等第一批数据到位马上开始训练部署人员同步准备转换脚本整体项目周期能压得很短。2. 环境准备与YOLOv5安装全流程2.1 硬件与软件环境先说训练环境。YOLOv5训练阶段主要吃GPU显存大小直接决定你最大能跑多大的batch。我用过8GB显存的RTX 3060 Laptop也用过24GB的RTX 3090感受非常明显。8GB显存跑YOLOv5s输入640x640batch最大也就8左右24GB显存可以跑到batch 32甚至更大。火灾检测数据集如果只有几千张batch大小对最终精度影响没有想象中大但训练时间有明显差距。软件环境我建议按这个组合来操作系统Ubuntu 20.04或Windows 10我主力是Ubuntu后面部署RKNN的工具链大多也是Linux优先。Python版本3.8或3.9不要用3.11这种太新的版本PyTorch和部分依赖可能跟不上。PyTorch版本1.10到2.0之间都可以官方YOLOv5对不同版本的兼容性还可以但没必要追新。CUDA跟随PyTorch官方推荐的版本比如PyTorch 1.12对应CUDA 11.3。RV1106/RK3568的部署环境我后面会详细讲这里先提一句瑞芯微的rknn-toolkit2最好装在一台x86的Ubuntu机器上用来完成模型转换板子端只负责推理不要在板子上直接装转换工具链会非常痛苦。2.2 YOLOv5下载与依赖安装YOLOv5本身不用pip直接安装它是个Git仓库。我习惯把仓库clone到工作目录然后在项目目录下创建虚拟环境安装依赖。git clone https://github.com/ultralytics/yolov5.git cd yolov5 python -m venv venv source venv/bin/activate pip install -U pip pip install -r requirements.txt这里有个小细节requirements.txt里的torch版本可能不是你本机适合的版本。如果你已经有了匹配CUDA的torch可以先装torch再装其他依赖避免pip因为版本冲突重新装CPU版torch。我踩过一次直接pip install -r requirements.txt结果torch被换成了CPU版训练慢得怀疑人生。正确做法是先用官方命令装好GPU版torch再执行pip install -r requirements.txt另外如果网络条件不太稳定建议把pip源换成国内镜像不然下载几十个依赖包时经常超时pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple装完依赖后还要下载预训练权重。YOLOv5官方仓库的README里放了不同规模权重的下载链接或者直接用代码下载# 在yolov5目录下执行 python -c from utils.downloads import attempt_download; attempt_download(yolov5s.pt)权重文件不大yolov5s.pt大概14MB左右。下载完成后放在仓库根目录即可训练脚本会自动识别。2.3 安装后的快速验证依赖装完建议先跑一次detect脚本确认环境没问题不要直接开始训练。找一个测试图片或视频用官方权重跑一遍python detect.py --source data/images/bus.jpg --weights yolov5s.pt --conf 0.25如果命令行输出“Detect: 1 images, 2 objects”之类的结果说明YOLOv5已经把图片中的人、车识别出来了检测结果保存在runs/detect/exp下。这一步能同时验证PyTorch、weights、opencv等依赖是否正常。我遇到过一个问题环境全部装好但跑detect时直接报错“AttributeError: Upsample object has no attribute recompute_scale_factor”。这是PyTorch版本太新和YOLOv5代码兼容性导致的问题解决方式很粗暴把PyTorch降到2.0以下或者找到models/common.py里对应的Upsample代码改成新版接口。新手建议直接按我前面推荐的PyTorch版本安装省得折腾。3. 自己数据集的标注与训练核心步骤3.1 数据采集与标注格式火灾检测的数据来源一般是现场监控视频或网络公开的视频。我通常会先把视频按每秒1到2帧抽出来避免相邻帧相似度太高导致数据集冗余。一个10分钟的视频大概能抽出600到1200张图片如果场景单一需要保留少一些如果场景变化大光照、角度、距离都不同可以适当多抽。标注工具我主力用labelimg它支持YOLO格式直接导出操作简单适合快速标注。有些团队用labelme但labelme默认输出的是JSON格式转YOLO格式还要多一步脚本我嫌麻烦。labelimg的安装方式pip install labelimg启动后打开图片目录按W键创建矩形框选择类别。对于火焰和烟雾我建议的标注原则是火焰区域画框尽量贴合可见火光的范围不要包含太多周围的暗色背景。烟雾区域画框时需要包含整个可见烟雾团即使烟雾很淡、半透明也尽量画进去。如果一个画面中有多个独立的火点或烟团分别画框。对于重叠的火焰和烟雾可以分别画两个框不做强制互斥。标注完成后每张图片会对应生成一个同名txt文件内容是“类别编号 中心点x 中心点y 框宽 框高”所有坐标都归一化到0-1之间。这个格式是YOLO系列的通用格式YOLOv5直接支持。标注质量直接决定训练效果。我在实际项目里发现很多人为了赶进度会把烟雾框画得特别松导致模型学到一个“越靠近画面边缘越容易输出大框”的倾向。这个问题很难在训练阶段完全纠正所以标注时宁可多花五分钟把细节画好也不要想着靠后续清洗数据来补救。3.2 数据集划分与data.yaml配置标注完成后要把数据集划分成训练集、验证集、测试集。我用一个简单脚本自动完成比例一般设成8:1:1。每个集合里只放图片文件路径标注文件由YOLOv5自动按同名规则寻找所以图片和txt必须保持在同一个子目录下。最终的目录结构可以这样组织datasets/fire_dataset/ images/ train/ val/ test/ labels/ train/ val/ test/然后写一个data.yaml告诉YOLOv5数据在哪里、类别是什么train: datasets/fire_dataset/images/train val: datasets/fire_dataset/images/val test: datasets/fire_dataset/images/test nc: 2 names: [fire, smoke]这里要注意train和val路径是相对yolov5仓库根目录的。如果你把数据集放在仓库外最好写绝对路径避免训练时找不到数据。我在项目里遇到过路径写错导致训练脚本直接报错“AssertionError: train: No images in datasets/...”检查了十分钟才发现是相对路径的问题。3.3 单通道灰度图训练改造火灾检测里有个特殊需求很多工业摄像头是黑白或者红外模式输出的是单通道灰度图。YOLOv5默认输入是三通道RGB直接训练单通道数据会报错。这个改造其实不难但要动两个地方。第一步修改模型配置。打开models/yolov5s.yaml把输入通道数从3改成1# YOLOv5s backbone nc: 2 # 原来是3 ch: 1 # 新增默认没有这一项时是3 depth_multiple: 0.33 width_multiple: 0.50如果不想改全局配置也可以在训练命令里直接指定模型参数但那样更麻烦建议直接改yaml。第二步修改数据集加载逻辑。YOLOv5的datasets.py里LoadImagesAndLabels类读取图片时默认用cv2.imread得到的是三通道BGR。你需要改成用灰度模式读取并在加载后不转为三通道。我常用的做法是在datasets.py里加一个参数# 在LoadImagesAndLabels的__init__参数里增加single_channelFalse # 在读取图片后 img cv2.imread(path, cv2.IMREAD_GRAYSCALE if self.single_channel else cv2.IMREAD_COLOR) if self.single_channel: img img[:, :, None] # 保持HWC格式同时要处理增强部分YOLOv5的RGB色彩增强色调、饱和度、明度变化对单通道图没有意义需要跳过。我通常在增强函数里判断一下如果是单通道就直接走几何增强和mosaic把hsv增强部分绕过。还有一种偷懒的方案加载灰度图后依然复制成三个通道喂给模型这样不需要改模型结构但会让模型有额外的通道冗余参数量和计算量没有减少而且迁移到板端时可能还是需要特殊处理。我的体会是如果你确定最终部署输入的也是单通道图就老老实实改模型收益是实打实的。3.4 超参数选择与训练命令YOLOv5的超参数主要有两类训练超参数学习率、batch、epochs和模型超参数anchors、loss权重。训练前我一般先调整几个关键项epochs火灾数据集如果是2000到5000张100到150个epoch就够。再多容易过拟合。batch size显存允许下尽量大至少8。batch太大对收敛速度提升有限但batch太小会导致loss波动很大。img-size训练默认640。如果准备部署到RV1106这种算力有限的板子也可以从384或320开始训练避免训练和部署输入尺寸差异太大导致精度下降。lr0初始学习率默认0.01。用小数据集训练时我习惯降到0.005更稳。mosaic默认1.0数据增强里mosaic对火灾检测很有帮助能增强模型对不同尺度和背景的适应能力。训练命令我用的是python train.py --img 640 --batch 16 --epochs 150 \ --data datasets/fire_dataset/fire.yaml \ --weights yolov5s.pt \ --cache \ --name fire_v5s这里--weights指定预训练权重例如yolov5s.pt可以显著加速收敛。如果数据集比较小也可以不加载预训练权重改用--weights 让模型从头开始训练。火灾检测这种场景预训练权重是在COCO上训练的虽然类别和火灾完全不同但底层的纹理、边缘特征迁移价值还是很大的建议默认加载。如果你用了单通道改造加载yolov5s.pt的时候会因为第一层卷积通道数不匹配报错。这种情况下要么改用随机初始化要么用我下面这个粗糙但有效的方法把预训练权重的第一层卷积权重在通道维度上做平均把3个通道的平均值复制到1个通道。不过说实话直接把预训练权重舍弃从零训练单通道模型在数据量几千张时效果也还过得去不必过度纠结。4. 训练过程监控与模型评估4.1 训练日志与loss曲线解读YOLOv5训练过程中会在终端输出每个epoch的loss、mAP、速度和显存占用。这些信息一定要盯住不要等训练结束再看。我最常看三个指标训练loss包含box_loss、obj_loss、cls_loss三个分量。验证集mAP50和mAP50-95。验证集precision和recall。训练开始后loss通常会先快速下降后面进入平稳期。如果loss在训练集上持续下降但在验证集上不再提升说明开始过拟合了这时候可以提前停止或者降低数据增强的强度。一个常见误区是只看loss曲线忽略mAP。loss低不代表检测效果好尤其是火灾数据集中负样本少的时候模型可能把所有区域都预测为背景此时loss看起来很低但mAP也低得可怜。我习惯在训练到一半时人工看一些检测输出比看指标更直观。训练过程中的权重会自动保存runs/train/fire_v5s/weights/best.pt和last.pt。best.pt是验证集mAP最高的权重可以用来后续评估和部署。last.pt是最后一个epoch的权重。4.2 mAP与混淆矩阵评估训练完成后用best.pt跑一次验证得到更详细的评估结果python val.py --data datasets/fire_dataset/fire.yaml \ --weights runs/train/fire_v5s/weights/best.pt \ --img 640命令结束后会生成混淆矩阵、F1曲线、PR曲线等图表保存到runs/val/exp下。我主要看两类一是mAP50。对火灾检测来说mAP50如果能达到85%以上基本可以满足大部分场景的需求。mAP50-95要求框和真实标注的重合度更严格如果这个值不高说明模型框的位置不够准在部署时可能影响叠加在监控画面上的显示效果。二是混淆矩阵。由于火灾检测通常只有两个类别混淆矩阵能很直观地告诉我们模型是把火焰误判成烟雾还是把背景误判成火焰。如果背景误判火焰的比例高说明负样本不够或者置信度阈值设得太低。如果火焰误判成烟雾说明两类样本的特征区分度还不够可以考虑增加标注的边界质量或者尝试用更强的数据增强。4.3 误检漏检优化方向火灾检测项目里最怕的是误检。工厂里一个红色灯光、太阳反射、暖风机都可能被模型当成火焰。这类误判在演示阶段问题不大一上正式环境就容易被投诉。我的优化路线一般是这样的先排查是不是数据问题。加入大量目标场景的负样本比如没有火灾的车间画面、夜景、灯光闪烁画面。YOLOv5训练时可以通过在数据目录里放一些没有标注文件的图片来充当负样本模型会学到这些图片里没有目标。这个方法在某些情况下很有效但要注意负样本比例不要太高否则模型会对检测目标过于保守漏检率上升。再排查是不是后处理问题。部署时置信度阈值不要设太低我一般设为0.4到0.5之间。如果屏幕上全是误检框很可能是阈值太低换成0.5能过滤掉大量低置信度误检。如果漏检严重再把阈值下调到0.3同时配合NMS的iou阈值调整。如果数据和后处理都调过还是不行考虑做类别拆分或增加一个“疑似火源”类别。曾有项目里场景中有红色机械臂和火焰颜色很像模型难以区分。我们在标注时单独增加了一个“red_object”负样类别让模型明确区分误检率下降了一大截。虽然这不是必须的做法但在特定场景下非常有用。5. 边缘设备部署RK3568与RV1106实战5.1 端侧部署方案选型火灾检测部署到边缘设备考虑的维度主要是算力、内存、成本。RK3568和RV1106都是瑞芯微旗下常见的芯片两者的定位不同RK3568算力更强适合多路摄像头或需要跑中等模型的场景RV1106是一颗IPC专用SoC算力更小适合单路摄像头做本地火灾检测。RK3568内置NPU算力达到1TOPs左右实际有效算力依量化情况而定跑YOLOv5s在640x640下能做实时但CPU占用会比较紧张。RV1106的NPU算力更弱通常建议把输入尺寸降到320x320模型进一步换成更轻量的版本比如把YOLOv5s的width_multiple调整成0.25或者直接选YOLOv5n。从部署工具链来说两块板子都使用瑞芯微的rknn-toolkit2。转换流程基本一致先导出ONNX再把ONNX转成RKNN。区别在于target_platform设置不同rk3568和rv1106对应的平台标识不一样转出来的RKNN模型不通用。我在选型时还有一个习惯先看项目需要几路摄像头。单路低功耗RV1106合适两路以上RK3568合适。如果还要求联动报警、存储录像那RK3568或更高端的RK3588更合适。这个决策要先定下来否则后面转换模型时会发现平台选错白费功夫。5.2 ONNX导出与RKNN转换YOLOv5官方仓库自带导出脚本可以直接导出ONNXpython export.py --weights runs/train/fire_v5s/weights/best.pt \ --img 640 \ --batch 1 \ --include onnx \ --simplify导出后得到的best.onnx是包含检测头的完整模型输出三个不同尺度的特征图。如果你打算直接用ONNX做CPU推理这个就够了但如果要转RKNN我建议先用Netron打开看一下输出节点名称记下三个输出的名字。RKNN转换时需要用到这些名字。接下来在Ubuntu x86机器上安装rknn-toolkit2。这个工具依赖很多建议单独建Python虚拟环境。安装后转换脚本大致如下from rknn.api import RKNN rknn RKNN() rknn.config( mean_values[[0, 0, 0]], std_values[[255, 255, 255]], target_platformrk3568, quantized_dtypew8a8, quantized_algorithmnormal ) rknn.load_onnx(modelbest.onnx) rknn.build(do_quantizationTrue, datasetdataset.txt) rknn.export_rknn(fire_yolov5s.rknn)这里的dataset.txt是量化校准的图片路径列表每行一张图片。尽量从训练集中随机选100到200张覆盖不同场景的图片不要选太相似的视频抽帧否则量化后的精度会崩。rknn.build时do_quantizationTrue表示要做int8量化这也是在RK3568/RV1106上获得实时性能的关键。转完之后在板子上用rknn-toolkit2的Python接口加载模型推理from rknnlite.api import RKNNLite rknn_lite RKNNLite() rknn_lite.load_rknn(fire_yolov5s.rknn) rknn_lite.init_runtime() outputs rknn_lite.inference(inputs[frame])RKNN的输出不是YOLOv5原始输出那种直接可用的边界框你需要写一个后处理函数对三个尺度的输出分别解码做NMS再映射回原图坐标。网上有很多现成的解码代码但要注意输入尺寸和anchor配置是否和你的模型一致。5.3 部署后的精度与性能调优部署到板端后最常见的两个问题是检测框偏了、推理时间太长。检测框偏了多半是输入预处理不一致。YOLOv5训练时会对图片做letterbox等比缩放加灰色填充部署时也一定要用同样方式预处理。很多人转RKNN后直接resize到640x640导致物体变形检测框自然不准。我建议在板端代码里写死一个letterbox函数和训练时的做法保持一致。推理时间太长先看是不是没做量化。如果加载的是fp16甚至fp32的模型NPU算力优势完全发挥不出来。用rknn_toolkit2的profiling功能可以看到每一层在NPU和CPU上的耗时如果发现大量层落在CPU上很可能是因为某些算子NPU不支持需要调整模型结构或版本。对于RV1106如果推理仍无法达到25fps以上我会采取这些手段把输入尺寸从640降到320检测精度会下降一些但速度提升非常明显。把模型从YOLOv5s换成YOLOv5n或者在yolov5s.yaml里把width_multiple改成0.25。在训练时就以低分辨率输入重新训练不要用高分辨率权重直接转低分辨率。检查代码里是否在inference后做了不必要的图像转换尽量把BGR转RGB的操作一次性做完。我在实际部署中用RK3568跑YOLOv5s 640量化模型推理耗时大概在20到30msRV1106跑YOLOv5n 320量化模型推理耗时能压在40到50ms左右。这个数据在不同固件版本下会有差异但可以作为参考。6. 常见坑与排查技巧实录6.1 训练阶段典型问题训练阶段我遇到的坑可以列一张表新手照着排查能省很多时间现象可能原因解决方案训练报“No labels in data/train.cache”标签目录或data.yaml路径不对检查路径确认labels和images目录对应loss直接变成NaN学习率过高或数据中有异常值降低lr0到0.001检查标注文件是否越界训练集loss很低验证集mAP也低过拟合或数据增强过强降低epochs减少mosaic增加数据量单通道训练报conv2d通道不匹配模型配置文件未改ch1修改yolov5s.yaml并重新初始化权重mAP50很高但实际部署误检多数据分布和部署场景差异大补充现场场景负样本调整阈值其中一个我特别想提醒的是“cuda out of memory”。很多人遇到后第一反应是调小batch然后反复重启训练。更好的做法是先用1个batch跑一次前向确认显存占用再按比例调整。或者用--cache参数把数据预先加载到内存中避免训练过程中频繁读取数据导致显存抖动。6.2 部署阶段典型问题部署阶段的问题更多是平台相关的。RKNN转换过程中常见的错误包括load_onnx失败提示模型格式不合法。大部分情况是ONNX版本太新或者导出的算子太复杂建议用onnxsim简化或者换低版本PyTorch重新导出。RKNN build时quantization失败可能原因是校准数据集图片读取失败。检查dataset.txt里的路径是否存在以及图片是否损坏。RKNN推理结果全为零或全为背景框一般是预处理和后处理没对齐。建议先用一张训练集中的图片跑一次rknn推理和PyTorch输出对比逐步排查。rknnlite在板子上初始化失败多半是固件中NPU驱动版本和rknn-toolkit2版本不匹配。瑞芯微的工具链版本更新很快装的时候一定要对应你板子固件版本否则会出现奇怪的运行时错误。我做项目时习惯把转换、推理、后处理拆成三个独立脚本每个阶段都能单独验证。转换完先看rknn推理输出的shape和数值范围再确认后处理结果最后再接入摄像头视频流。这样做问题定位非常快不会出现所有代码都写完然后又不知道是哪一步出错的情况。6.3 火灾检测场景专属避坑最后单独说几个和火灾检测本身强相关的坑。火焰检测对颜色非常敏感。如果训练数据大部分是白天晴天拍摄到了夜晚或者阴天模型很容易漏检。我的建议是训练数据里至少包含白昼、黑夜、黄昏、逆光四种光照场景。如果现场有条件最好做一次24小时的录制再抽帧标注。烟雾检测难在半透明。烟雾的边缘是渐变的模型很难定位精确的边界。我在标注时会把烟雾的“可见影响范围”全部框进去而不是只框最浓的部分。训练时烟雾类别的损失权重可以微调但YOLOv5默认的类别权重已经比较均衡不需要大改。火灾视频里火焰会有明显的闪烁和形变。单帧检测时模型有时会把同一个火源裂成好几个检测框一会儿有框一会儿没框。我在部署时会在后处理里加一个简单的时序平滑对连续几帧的检测框做加权平均或者只有当同一个位置连续出现多帧时才输出报警。这个机制对误报抑制很有帮助虽然会增加一点代码量但实际效果比单帧阈值调优好得多。还有就是摄像头安装角度。如果摄像头俯视安装火焰和烟雾的形态会和平视差别很大。所以训练时一定要用和目标安装角度接近的样本。如果项目是旧摄像头改造最好先到现场拍一段视频看实际视角再决定数据补充方案。我个人的实测感受是YOLOv5做火灾检测真正难的地方从来不是模型训练本身而是数据和部署之间的那条鸿沟。训练好的模型在PC上效果再好不经过现场数据校准、不量化部署验证、不做时序平滑最终效果一样会打折扣。建议你在做这类项目时把至少三分之一的时间留给现场测试和数据补充而不是一味地调模型结构。先跑通一套最小闭环从摄像头取流到模型推理到报警输出再逐步优化各个环节这个节奏比完美主义式的反复训练要靠谱得多。本文还有配套的精品资源点击获取