做吸烟行为检测这个项目起因是一位做安防集成的朋友找我说工厂仓储区禁烟靠保安盯着监控不现实一个班次8小时眼睛根本盯不住。于是我用深度学习里的目标检测思路做了一个“吸烟行为检测系统”把模型封装成网页版服务前端打开浏览器就能实时检测摄像头画面后端同时保留了YOLOv8/v7/v6/v5的完整训练代码和标注好的训练数据集。这篇博客把整套方案从数据准备、模型训练到网页部署的细节都拆开来讲给准备做类似项目的朋友一个可以直接上手的参考。这个项目解决的核心问题不是“识别一个人”而是“识别一个人手上有没有点燃的香烟”。别看就多了这么一点细节实际落地时的坑非常多香烟在监控画面里往往只有几十个像素属于典型的小目标检测光照变化大室内外、白天黑夜完全是不同的分布手指夹着的笔、手机、打火机反光都容易造成误检。所以这个项目真正难的不是搭个框架而是把数据、模型、部署三件事串起来。如果你是想学YOLO目标检测的初学者这项目是个特别好的完整案例如果你是接安防、工地、加油站这类禁烟监控需求的技术人员这里面的数据集制作思路和网页部署方案可以直接抄作业。下面我从需求拆解开始一步步说清楚。1. 需求拆解与方案选型1.1 吸烟行为检测的本质是“小目标时序动作”问题先想清楚一个问题我们到底要检测什么很多人第一反应是检测香烟本身这没错但在监控场景里单独检测香烟非常难。一根燃烧的香烟长度大约8厘米在1080P画面、10米视距下可能只占20乘20像素的区域比人脸小得多。所以工业界普遍的做法是检测“手持香烟”这个整体语义也就是把烟头、烟身和捏烟的手指一起框住让模型学到“人手里拿着冒烟的细小物体”这个模式而不是死抠烟头那几点像素。这个思路决定了后续的标注标准。我在项目里把类别名定为smoke标注时框选的是手掌附近、包含烟头烟身的小矩形而不是整根香烟连带胸部。这样做有两个好处第一模型不需要区分具体烟支品牌泛化能力更好第二检测框更集中后续在网页端画框时不会因为框太大而显得识别“糊”。另一个容易被忽略的点是“时序”。单帧检测必然有漏检和误检比如有人拿笔在嘴边晃动某一帧极像在吸烟。解决思路有两种一种是在模型后面加一个轻量级动作分类器把连续若干帧的特征串起来判断另一种更简单的做法是后端做一个时间窗口统计只在连续N帧中都检测到smoke时才算一次有效告警。对于禁烟监控这类场景第二种方法性价比更高也更容易跟客户解释。1.2 为什么选择YOLO系列而不是其他算法检测方案不是没别的选择。两阶段检测器Faster R-CNN精度高但推理速度在视频流上不尽如人意基于Transformer的DeTR、RT-DETR精度也不差但训练显存占用大、部署链路长对小目标的优化不如YOLO成熟落地。在监控场景里我们通常需要一台普通GPU服务器同时处理多路视频推理速度是第一优先级YOLO这种单阶段检测器在速度与精度之间平衡得最好。标题里提到YOLOv8/v7/v6/v5四个版本我全都跑过一遍说下实际感受版本特点适合场景部署便利性YOLOv5生态最成熟、教程多、PTQ量化资料多新手学习、老设备CPU部署pytorch导出onnx顺手TensorRT有大量现成案例YOLOv6美团开源工业部署优化好推理速度快高并发服务端推理量化感知训练支持不错但更新节奏慢YOLOv7训练技巧丰富精度在同等算力下略高追求精度的离线分析E2E版本可去掉NMS但环境兼容坑比较多YOLOv8ultralytics官方维护训练/导出/推理API统一新项目首选、快速迭代导出onnx/tflite/tensorrt一条命令省心我的建议是如果不是要复现老项目新项目直接上YOLOv8如果边缘设备算力特别紧张可以用YOLOv8nnano版代替YOLOv5s如果客户明说了必须跑在已有的老推理框架里再考虑YOLOv5。v7虽然精度不错但PyTorch版本一升级就容易报错调试成本不低。1.3 网页版架构的整体规划网页版我采用了最常见的B/S架构浏览器做展示和交互后端用Python Flask提供HTTP接口YOLO模型作为推理核心。流程是摄像头RTSP流或上传的图片/视频进入后端后端抽帧后交给模型推理把检测框坐标和置信度返回前端前端在画面上框出目标并触发告警提示。为什么不用桌面客户端因为实际客户往往是安保中心的多个人同时看监控浏览器零部署、跨平台领导还方便在大屏上查看。而且Flask写接口加前端页面一个人两三天就能搞定比开发桌面程序省太多事。如果后续要接现有安防平台只需要把HTTP接口对接给平台方改动成本也很低。2. 训练数据集精挑细选比盲目堆量重要2.1 数据来源与标注规范训练数据是这项目里最花时间的环节我前后整理了两周才凑出像样的数据集。来源主要有三块一是公开目标检测数据集里的吸烟场景图片比如一些烟火识别比赛数据里有佩戴防毒面具和吸烟的画面可以筛选出来二是自己在办公室、厂房走廊、地下车库等场景用手机和摄像头拍摄的模拟吸烟画面这部分数据虽然量不大但和真实监控视角最接近价值最高三是网上能找到的零散禁烟宣传图、新闻配图这类图片分辨率高、场景杂可以作为补充。关于标注数量我踩过的坑是别一上来就想标一万张。单类别检测起步1000到2000个标注实例就能训练出一个可用的模型但必须保证场景多样性。你可以这样分配室内固定监控视角500张、室外白天300张、夜间或暗光200张、逆光150张、远距离小目标200张剩下的再随机补充杂项。这比同样3000张但全是同一个办公室的画面有用得多。标注规范上一句话总结框住“手烟头”的小区域类别统一为smoke。多人同时吸烟也要逐个标注不要漏框。如果有拿笔、拿手机、吃东西的负样本单独放在另一个目录不标注作为背景图参与训练。这里注意负样本一定不要打标签YOLO训练时会把没有标注文件的图片当作纯背景参与负采样。2.2 标注工具与格式转换细节YOLO训练需要的标签格式是txt文件每一行代表一个目标格式为class_id x_center y_center width height四个坐标值都是归一化到0到1的小数。比如一张宽1920像素、高1080像素的图片某个烟盒检测框中心在x960、y540宽120、高80那对应的一行就是0 0.5 0.5 0.0625 0.07407手工算太容易错所以我用X-AnyLabeling做标注。这工具可以直接输出YOLO格式还自带一个辅助自动标注模型可以先让模型预打框我再手动修正速度至少快三倍。LabelImg是老牌选择但界面多年没更新高分屏下体验一般。Roboflow在线标注也行但图片上传下载流程在国外服务器上速度不稳定数据敏感的项目不建议用。标注完一定要做一轮清洗打开标签文件检查有没有坐标值大于1或小于0的异常数据逐类统计图片数量防止某个类别图片过少随机抽100张图人工复核框的位置和大小这一步能避免训出来的模型学到错误特征。清洗完成后按9比1切成train和val目录目录结构如下datasets/smoke/ ├── images/ │ ├── train/ │ └── val/ └── labels/ ├── train/ └── val/2.3 数据增强与负样本策略YOLOv8在训练时会默认开启Mosaic、随机仿射、HSV色彩空间增强等策略这些能显著提升模型对光照和角度的泛化能力。但对吸烟检测这种小目标场景有几个增强参数需要单独调。旋转角度我限制在正负15度以内角度太大会把香烟旋转成几乎竖直朝下的奇怪姿态反而增加学习难度。HSV饱和度增强可以保留但亮度增强幅度不要过大否则暗光数据会被增强成过曝画面影响模型对夜间场景的判别。负样本是我的重点补充项。这个项目里误检来源特别明确人手夹笔、夹手机、拿打火机点烟前的手势、甚至夹着棒棒糖都会诱发模型在某种程度上“觉得像”。我的策略是准备300到500张这种高度相似的负样本图不标注任何目标混入训练数据。这样模型在训练过程中会看到大量“看似有烟但没标签”的背景被迫学会区分细腻特征。实测这个操作能把误检率从每百帧七八次压到一两次比单纯调置信度阈值有效得多。3. 训练模型参数、曲线与版本对比3.1 环境配置与硬件选型训练环境我建议用conda建虚拟环境避免把系统Python搞乱。YOLOv8的安装最简单一条pip命令解决conda create -n yolo-smoke python3.10 -y conda activate yolo-smoke pip install ultralytics如果机器是NVIDIA显卡还需要安装对应版本的PyTorch。以CUDA 11.8为例pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118硬件方面我的训练机是RTX 3060 12G训练yolov8sbatch size设到16、imgsz设到640显存占用大约8G一张卡足够。如果只有CPU也不是不能跑但一个epoch可能要好几分钟建议要么用yolov8n小模型要么直接上云GPU。我用过的AutoDL、矩池云这类云GPU平台按小时计费训练一轮100个epoch大概几十块钱比自己买卡划算。3.2 训练参数逐项拆解以YOLOv8为例训练命令如下yolo detect train \ datasmoke.yaml \ modelyolov8s.pt \ epochs100 \ imgsz640 \ batch16 \ device0 \ patience20 \ projectrun_smoke \ nameexp1这里几个参数值得展开说。epochs100是我在中小数据集上的默认值配合patience20早停机制如果验证集指标连续20个epoch没有提升训练会自动停止省时间也防止过拟合。imgsz对小目标检测非常关键640是速度和精度的平衡点如果你发现监控画面里烟头目标很小可以试768甚至960精度会提升但推理变慢需要自己权衡。modelyolov8s.pt表示加载官方预训练权重做迁移学习。不建议从零训练预训练模型已经学会了大量通用视觉特征我们在它的基础上微调5000多张图也能收敛得很快。训练数据配置smoke.yaml内容如下path: ./datasets/smoke train: images/train val: images/val names: 0: smoke注意path最好写绝对路径或者使用相对路径时确保你在项目根目录下运行命令否则YOLO很容易报找不到图片的错误。另外记得在配置文件里设nc: 1来覆盖类别数不然会沿用预训练模型的80类导致最后的输出维度对不上。3.3 YOLOv5/v6/v7/v8训练差异与实测对比这四个版本我都跑过同样的数据集训练方式有一些差异。YOLOv5需要clone官方仓库到本地然后用train.py训练git clone https://github.com/ultralytics/yolov5 cd yolov5 pip install -r requirements.txt python train.py --img 640 --batch 16 --epochs 100 \ --data ../datasets/smoke/smoke.yaml --weights yolov5s.ptYOLOv6是美团开源的仓库结构相对独立训练入口是tools/train.py数据集格式也是YOLO格式但需要在配置里指定和YOLOv5略有不同的数据字段稍微麻烦一点。YOLOv7的环境要求比较敏感我遇到过PyTorch 2.0以上版本跑v7训练时模型参数初始化类型不匹配的问题后来固定用PyTorch 1.13才稳定下来。如果是新项目我还是推荐YOLOv8它的命令行设计和配置管理最规范。对同一批5000张数据训练100个epoch我得到的实测数据大概是这样RTX 3060单卡推理640分辨率模型参数量mAP50推理耗时(ms/帧)YOLOv5s7.2M86.1%8.2YOLOv6s17.2M87.0%7.5YOLOv7-tiny6.2M84.5%8.8YOLOv8s11.2M87.4%7.8差异不算大YOLOv8s略胜一筹。如果你的设备是Jetson、树莓派这类边缘盒子YOLOv8n或YOLOv5s更合适模型体积小一半速度更快损失的精度在小目标检测上没有想象中那么大。3.4 从损失曲线和指标看训练效果训练结束后run_smoke/exp1目录下会生成results.png里面有box_loss、cls_loss、dfl_loss三条损失曲线以及mAP50、mAP50-95、precision、recall四个指标曲线。先看损失曲线是否收敛正常情况是前20个epoch下降很快后面趋于平缓训练末期的loss值不再大起大落。如果val损失在后期明显回升而train损失还在下降说明过拟合了要回到数据层面增加样本或增强而不是继续拉长epoch。再看精度和召回率。吸烟检测这个场景我宁可牺牲一点精确率也要保住召回率理由很简单漏掉一次吸烟行为可能引发安全事故而误报一次顶多是广播提示工作人员去现场看一眼。所以我在网页端设置置信度阈值时通常用0.3到0.35而不是默认的0.5。对应的precision和recall数值我的模型能达到precision约88%、recall约82%mAP50约87%mAP50-95在62%左右够用了。4. 网页版系统实现与部署4.1 后端接口设计Flask快速搭建检测服务我选择Flask而不是FastAPI主要考虑是Flask生态太成熟了踩坑成本低对方即使不会Python也能看懂逻辑。核心代码很简洁模型加载到全局变量避免每个请求都重新加载from flask import Flask, request, jsonify import cv2 import numpy as np from ultralytics import YOLO app Flask(__name__) model YOLO(best.pt) # 训练好的权重 app.route(/detect, methods[POST]) def detect(): file request.files.get(image) if file is None: return jsonify({error: no image}), 400 data np.frombuffer(file.read(), np.uint8) img cv2.imdecode(data, cv2.IMREAD_COLOR) results model(img, conf0.3, iou0.5, verboseFalse) boxes results[0].boxes detections [] for box in boxes: x1, y1, x2, y2 box.xyxy[0].tolist() conf float(box.conf[0]) detections.append({bbox: [int(x1), int(y1), int(x2), int(y2)], conf: round(conf, 4)}) return jsonify({count: len(detections), detections: detections}) if __name__ __main__: app.run(host0.0.0.0, port8000)这里有个容易忽略的点model()内部如果传了verboseTrue每个请求都会打印推理日志大量并发时控制台会被刷爆CPU也被无谓占用。另外Flask自带的开发服务器不适合生产建议用gunicorn部署gunicorn -w 2 -b 0.0.0.0:8000 app:app注意worker数不要设太多2到4个就够因为每个worker都会加载一个模型副本到显存里设多了显存直接爆。4.2 视频流实时检测的实现方式图片检测接口只能处理单张图监控场景需要视频流。我做了两种模式。第一种是H.264视频流抽帧后端用OpenCV打开RTSP流地址import cv2 import threading from collections import deque cap cv2.VideoCapture(rtsp://admin:password192.168.1.100:554/stream1) frame_queue deque(maxlen1) lock threading.Lock() def read_frames(): while True: ret, frame cap.read() if not ret: cap.set(cv2.CAP_PROP_POS_FRAMES, 0) continue with lock: frame_queue.append(frame) threading.Thread(targetread_frames, daemonTrue).start()后台线程持续拉流并保存最新一帧避免主线程阻塞在网络读取上。前端视频展示我用的方式是MJPEG流式输出app.route(/video_feed) def video_feed(): def generate(): while True: with lock: if len(frame_queue) 0: continue frame frame_queue[-1].copy() results model(frame, conf0.3, verboseFalse) annotated results[0].plot() ret, jpg cv2.imencode(.jpg, annotated) yield (b--frame\r\n bContent-Type: image/jpeg\r\n\r\n jpg.tobytes() b\r\n) return Response(generate(), mimetypemultipart/x-mixed-replace; boundaryframe)这段代码虽然简单但效果直观浏览器直接img src/video_feed就能看到实时标注画面。缺点是对模型推理耗时要求高如果一帧推理超过1秒视频会明显卡顿。所以我在generate里只处理最新帧如果队列里已有更新的帧旧帧直接丢弃保证画面是实时的而不是排队处理历史。第二种视频检测方式是本地视频或图片上传前端用input typefile传文件后端逐帧或间隔抽帧检测再把结果用HTML展示。这种适合甲方手里有一段监控录像让你帮忙分析里面有没有人抽烟的场景实际项目里经常遇到。4.3 前端页面与交互设计前端我没有用大型框架纯HTMLJavaScript一点CSS就够。页面分三块区域左上角是视频实时预览检测框直接画在画面上右侧是告警列表每次检测到smoke就把时间、置信度、截图存下来推送到列表里底部是上传入口支持图片和视频。最关键的一个交互设计是“告警去重”。因为视频流是连续帧检测同一人吸烟可能连续几十帧都命中如果每帧都往告警列表里插一条几分钟列表就爆了。我的做法是设置一个10秒钟的时间窗同一个摄像头在10秒内只记录一次有效告警后续命中只更新告警列表里该条记录的“最近命中时间”。这样既保留了完整证据链又不会刷屏。告警记录存到SQLite里一条表结构大概是这样CREATE TABLE alarm_record ( id INTEGER PRIMARY KEY AUTOINCREMENT, camera_name TEXT, detect_time TEXT, conf REAL, snapshot_path TEXT );每天凌晨自动清理30天前的记录并打包导出方便客户留档。4.4 推理性能优化清单模型训练完推理性能直接决定系统能带几路摄像头。我在这个项目里做了四层优化加起来效果非常明显。第一层是模型导出。训练好的.pt权重可以直接用但YOLOv8还支持一键导出成ONNX格式yolo export modelbest.pt formatonnx opset12ONNX格式配合onnxruntime推理比PyTorch原生推理在CPU上能快30%以上。我实测同一台机器PyTorch推理每帧65毫秒ONNX推理每帧45毫秒。如果你有NVIDIA显卡可以继续导出TensorRTyolo export modelbest.pt formatengine device0 halfTrueTensorRT在GPU上的加速更大我的RTX 3060上可以把推理压到12毫秒左右。第二层是输入尺寸动态化。YOLOv8的imgsz在推理时可以动态指定比如24小时监控场景白天光线好可以用640夜间暗光场景因为目标特征弱、噪声大可以动态切成768。代价是模型每次切换输入尺寸会多一次环境初始化所以实际做法是每隔5分钟根据环境光传感器或图像灰度均值做一次尺寸决策而不是每帧都切换。第三层是帧采样。很多吸烟动作持续时间至少在3秒以上如果视频是25fps完全没必要每帧都推理。我把检测频率设在5fps也就是每5帧取一帧检测已经足够覆盖绝大多数吸烟行为。如果摄像头数量多这个参数还可以拉低到2fps能大幅降低GPU占用只是对持续时间短的吸烟动作不够敏感需要根据现场情况权衡。第四层是批量推理。如果后端同时接4路摄像头把4路的帧拼成一个batch一次推理出4个结果比单个依次推理吞吐量翻倍。YOLOv8的Python接口天然支持传入列表实际这样做frames [frames_cam1, frames_cam2, frames_cam3, frames_cam4] results model(frames, conf0.3, verboseFalse)执行下来4路视频推理总消耗相当于单路推理的1.8倍左右省了一半以上的GPU资源。5. 常见问题与排错实录5.1 训练阶段典型问题速查现象原因解决办法训练时报“CUDA out of memory”batch size或imgsz过大把batch从16降到8或4imgsz降到640或改用更小模型loss为NaN且不下降学习率过大或数据里有异常值把lr0从0.01降到0.001检查图片是否有损坏文件验证集mAP一直为0val目录里没有真值标签检查labels/val目录是否存在且文件内容非空训练完检测不到烟头训练图片里烟的尺寸太小导致特征学不到用768/960分辨率训练或使用带P2层的yolov8s-p2.yaml检测框乱跳或漏检数据标注框太大语义不纯重新框选“手烟头”区域不要框整个上半身负样本被识别成smoke误检样本在训练时占比过低采集大量“拿笔、拿手机、吃东西”的负样本图不加标签放入训练集其中显存不足是个高频问题。我的经验是先把batch降到能跑起来为止然后把imgsz从640降到512看mAP掉多少。如果掉得不多说明你的目标本身不算特别小以后就用512推理速度还快。如果掉得厉害说明检测目标确实小只能换分辨率更高或带P2层的模型。还有一个我认为新手最容易踩的坑用torch.load直接加载.pt文件来做推理然后报各种版本错误。YOLOv8的.pt文件包含的不只是模型权重还有配置和训练信息用YOLO(best.pt)这种方式加载才是对的不要手动拆权重。5.2 部署阶段典型问题速查现象原因解决办法网页打开后一直转圈不显示视频RTSP流地址无法访问先在服务端用VLC或ffmpeg测试地址是否为局域网IP需设置摄像头码流为H.264上传图片检测报错500OpenCV不认中文路径用np.fromfile(file, dtypenp.uint8)替代cv2.imread读图推理很慢CPU占用100%用的PyTorch推理而非ONNX导出ONNX并用onnxruntime跑推理速度提升明显gunicorn启动后一直报警告worker加载模型复制到显存占资源减少worker数到2个或在preload_appTrue里预先加载模型浏览器无法访问接口服务器防火墙限制开放8000端口或者用Nginx反向代理到内网地址Flask返回JSON里含NaN置信度或坐标算出无效值检查模型推理结果是否为Pytorch tensor需要.tolist()转换后再序列化部署阶段还有个很隐蔽的问题OpenCV的imshow调试窗口会和Flask线程冲突导致程序莫名卡死。排查了半天才发现是某段残留代码里调用了cv2.waitKey(0)把事件循环阻塞了。这种代码在正式服务里一定要删干净调试窗口只适合本地跑GUI的环境。另外网页版如果部署在云服务器上一定要在接口层做一个简单的Token认证。否则监控地址一旦泄露任何知道接口地址的人都能调用你的检测服务虽然不涉及隐私数据但会白白消耗你服务器的算力。我用了一个最简单的方案在Flask里加一个装饰器校验请求头里的X-Api-Key字段。5.3 检测效果不理想时的调优思路如果训练不出满意的效果第一步永远不是换模型而是回去看数据。我总结出一个三不换原则数据集质量不过关不换模型训练曲线没看明白不换模型硬件瓶颈没排除不换模型。换了模型结果也不会好只会浪费更多时间。具体调到什么程度算可以我给自己定了个指标在真实监控录像上测试漏检率不超过10%误检率不超过每5分钟1次。如果漏检率高优先增加对应场景的数据。比如夜间漏检多就多拍夜间画面而不是盲目加所有场景的图。如果误检率高就把误检的截图收集起来标注成负样本丢到训练集里重新训练一轮。这个“错误分析-数据补充-重训”的循环一般做两三轮就能看到明显改善。还有一个经验值得单独说监控画面中距离摄像头远的小目标很难检测但如果摄像头支持数字变焦或可以调整安装角度尽量让吸烟高发区域占据画面更多像素。算法再强也受限于输入分辨率这是物理规律不是调参能解决的问题。能调整现场机位永远比后处理调参性价比高。我后续在这个项目上的扩展想法是把检测结果和现场广播系统联动。后端检测到smoke后除了在网页上告警还自动给现场喇叭发一条播放指令提示“禁止吸烟”。这需要对接现场的广播控制协议难度不大但价值很高。这类从“前端识别”到“业务闭环”的需求才是这类AI项目真正能交付给客户的核心价值。