简介这是一份面向安防领域算法工程师与部署人员的YOLOv11实战技术手册聚焦人脸识别与异常行为检测的完整落地路径。手册从YOLOv11基础讲起涵盖算法原理、骨干网络与检测头结构并详细展开人脸检测、特征提取及匹配识别同YOLOv11的融合方法异常行为检测部分则介绍基于规则、机器学习与深度学习的技术原理以及目标关联、特征融合与联合训练等建模思路。针对工程化需求内容还覆盖软硬件环境搭建、数据集清洗与增强、模型训练调优、量化剪枝推理加速及本地或云端部署并结合商场安防、工业厂区、校园保障等案例给出效果评估与优化建议。资源为单份PDF文档共34页约2.02MB支持目录跳转和章节快速定位方便读者按需查阅。目前已有125人学习使用适合正在搭建智能安防监控系统、需要提升目标检测效率或研究YOLOv系列与行为识别结合的开发者参考。1. 安防场景下YOLOv11人脸识别与异常行为检测的端到端部署摄像头建了几十万路真正在用的经常只剩事后回放。白天靠人盯屏晚上靠回放查问题出在传统安防平台把人脸抓拍、目标检测和行为分析拆成三套独立系统链路长、联调复杂。YOLOv11把目标检测、姿态估计放在同一个网络结构里之后人脸识别和异常行为检测第一次能共享同一个推理出口。端到端部署的意思是从摄像头取流到输出“谁、在哪、做了什么、要不要报警”所有环节在系统内闭环不再依赖第三方比对服务或人工盯屏。这套方案更适合集成商、算法工程师和负责边缘设备落地的部署岗接下来按模型选型、训练参数、管道联调和落地细节四个顺序展开。2. YOLOv11网络结构与人脸识别算法选型2.1 YOLOv11的网络结构变化与检测优势拿YOLOv11和上一代YOLOv8对比结构变化集中在三处backbone把C2f模块换成C3k2backbone末端新增C2PSA自注意力模块检测头保持anchor-free解耦头。C3k2前段是CSP风格的特征split后段用两个小kernel bottleneck堆叠计算量分配比C2f更均衡C2PSA负责在深层捕捉全局上下文顺便把小目标区域的特征激活得更充分。讨论yolov11网络结构时不要死记层号抓住“C3k2替换C2f”和“C2PSA引入注意力”两个改动就足够。放到安防场景里yolov11更重要的特征是同一权重可以输出检测、分类和姿态估计三类结果。同一个模型在detect模式下输出人体框切到pose模式后输出17个关键点摔倒、起立、抬手的判断可以完全基于关键点省掉单独部署OpenPose的开销。行为检测从多级系统变成同一个网络的不同输出头这正是端到端部署真正省时间的点。模型尺度选择要跟着算力走。树莓派和Jetson Nano先选yolo11n或yolo11sx86服务器带GPU可以上yolo11m。先用最小配置把全链路跑通再按实测帧率逐级放大不要一开始就扎进网络结构魔改。这里要提醒一句网络结构改造的收益在数据量不够时几乎看不出来。现有yolo11n足够把安防场景的人体框稳定检出与其花精力魔改C3k2不如先收集现场数据并校准规则阈值。固定ultralytics版本也很关键频繁升级会引入推理结果微调直接影响已经写好的报警规则。2.2 人脸识别算法对比opencv人脸识别、dlib与insightface人脸识别和检测是两件事检测负责定位人在哪里识别负责判断他是谁。端到端部署里这两个模块分工不同选型差异也很明显。下表按从易到难排序方案识别精度CPU推理速度部署依赖适用场景OpenCV Haar LBPH低正脸且光照稳定可用极低树莓派可实时opencv-python门禁机、小规模白名单face_recognition(dlib)中侧脸和暗光会掉点单次识别0.3~0.6秒dlib、CMake内网小规模人员库InsightFace(ArcFace)高支持大角度和遮挡需要GPU或NPUonnxruntime生产环境、人员库较大提到“opencv人脸识别”时多数门禁机里用的是Haar级联加LBPH。Haar负责找脸LBPH负责把局部二值模式直方图拿来做人脸比对训练时生成一个本地特征库不依赖任何外部网络。问题在于特征维度低人员库超过50人之后误报率上升明显。face_recognition库把dlib包了一层128维特征向量比LBPH高一个量级但安装依赖重编译dlib在边缘设备上很耗时。对识别率有硬性要求的现场直接在onnxruntime上跑InsightFace更省心模型文件大几十MB不是问题要的是输出稳定、误识率可控。端到端里的选型最终由人员库规模决定50人以内用LBPH足够50到几百人用face_recognition或MTCNN加ArcFace上千人就要考虑向量检索库单靠人脸识别库本身的线性比对已经撑不住。这个边界在设计阶段就要定下来避免上线后频繁换识别引擎。2.3 异常行为检测不靠“异常分类”靠检测加跟踪加规则很多项目栽在同一个坑上试图训练一个“异常行为”分类器指望把一切异常都识别出来。异常形态没有上限摔倒、挣扎、翻越、聚集、奔跑数据永远标不完类别边界也划不清。常见的做法是分层处理第一层用YOLOv11输出人体框和关键点第二层写规则引擎根据框的位置、速度、面积变化和重叠关系判断是否异常。摔倒的判断逻辑是人体宽高比从站立时的“瘦高型”变成躺倒的“扁平型”同时质心高度在半秒内快速下降打架则表现为两个人体框长时间高重叠骨架关键点位移幅度超过阈值。这些规则来自现场经验必须按摄像头安装高度、俯仰角微调。某些动作如果稳定复现比如“翻越栏杆”可以作为单独类别训练剩下的大范围行为还是交给规则引擎。这一层跑在CPU上即可不占显卡资源也让整个管道的算力分配更有弹性。3. 用YOLOv11训练自己的异常行为模型数据准备与训练参数3.1 标注规范与YOLO数据集目录结构第一版建议标注三个类别person、fighting、falling。person作为基类规则引擎判断行为时要依赖它fighting和falling是异常类别。标注时使用YOLO框格式每行内容为class_id center_x center_y width height坐标全部归一化到0到1。目录结构保持YOLO标准dataset/ ├── fall.yaml ├── images/ │ ├── train/ │ │ ├── fall_001.jpg │ │ └── fight_001.jpg │ └── val/ ├── labels/ │ ├── train/ │ │ ├── fall_001.txt │ │ └── fight_001.txt │ └── val/fall.yaml中的信息很简单path: /data/dataset train: images/train val: images/val nc: 3 names: [person, fighting, falling]训练集数据不要直接拿公开数据集凑。公开数据能把大致的视觉特征训练出来但现场摄像头的俯视角、夜视效果、雨雾环境完全不同必须混入现场截流素材至少2000帧异常帧数量不够时做上下翻转、亮度扰动等数据增强。标注框要紧贴目标边缘倒地姿态特别容易标松宽松的框会把背景并进来训练时模型反而学不到精确位置。3.2 YOLOv11环境配置与训练核心命令环境安装用一条pip命令但之前要确认CUDA、PyTorch、显卡驱动三者匹配pip install ultralytics训练前先下载对应尺度的预训练权重yolo11n.pt然后按下面的命令训练yolo detect train \ modelyolo11n.pt \ datadataset/fall.yaml \ epochs120 \ imgsz640 \ batch16 \ device0 \ patience20 \ projectruns/fallpatience20表示连续20轮验证指标不涨时提前停止适合样本规模不大的异常数据集。imgsz640在人体占画面较大时足够走廊尽头、远端小目标场景直接调到960后面单独讲。batch16在单张显卡上不算大如果显存允许可以增加到32以提高训练稳定性。下面这几个参数是逐项调优时最值得动的参数第一版推荐值作用与调法lr00.01损失震荡就降到0.005lrf0.01末期学习率缩放比例mosaic1.0目标重叠严重时降到0.5hsv_h0.015夜晚监控数据适当加大到0.03close_mosaic10最后10轮关闭拼图适应真实尺度跌倒样本量不足时先在类别权重上把falling提上来比直接改网络结构更实际。看训练日志要同时关注mAP和混淆矩阵两个异常类别之间如果相互误检要回到数据里检查是不是标注框张冠李戴。一个容易被忽略的点是训练集和验证集不要取自同一段视频的连续帧否则验证指标虚高上线后被真实场景直接打脸。3.3 训练结果评估与模型导出训练完成后runs/fall/train/weights/下会生成best.pt和last.pt。验证指标里mAP50-95比mAP50重要因为fighting和falling的形状差异大把IoU阈值放宽会虚高。用yolo metrics查看具体数值再打开混淆矩阵确认跨类别误检比例。部署需要的文件从best.pt导出导出命令如下yolo export modelruns/fall/train/weights/best.pt formatonnx opset12 simplifyTrue yolo export modelruns/fall/train/weights/best.pt formatengine device0 halfTrueONNX格式用于跨平台部署engine格式是TensorRT的专用格式适合GPU边缘盒子。导出后用onnxruntime跑一遍同一段测试视频确认检测框坐标和PyTorch推理基本一致防止个别算子实现差异造成偏移。这一步验证的是“yolov11预测后保存”的基础链路保存命令如下yolo predict modelruns/fall/train/weights/best.pt sourcetest.mp4 saveTrue conf0.35参数saveTrue会把每一帧的推理结果保存成标注后的图片或视频适合先确认模型打包后输出正常。conf0.35在测试阶段可以低一些看模型完整的目标输出能力正式部署再回到0.4或0.5。4. 端到端部署管道YOLOv11目标跟踪、人脸识别与预警保存4.1 管道框架设计与线程划分管道事件顺序固定为视频解码、检测与目标跟踪、人体框裁剪、行为规则引擎、人脸识别子任务、报警记录保存。摄像头帧率和分辨率确定后系统就是典型的生产者消费者模型。解码线程不断向队列放帧推理线程从队列取帧队列满时丢弃最旧的帧保证实时性优先于完整性这是安防流媒体最常见的手段。人脸识别不能放在主推理路径上这是整个管道性能的关键。YOLOv11在CPU上处理一帧640分辨率大约要0.15到0.3秒dlib的face_recognition识别一个人脸还要0.5秒左右。如果每帧把所有检测出来的人脸都做一次识别整个管道立刻被塞死。常见做法是开单独的人脸识别线程只处理首次出现的人体框或由行为规则触发的裁剪图。端到端部署里“实时”的体验完全靠这种层次化任务划分来维持而不是靠运气。4.2 YOLOv11目标跟踪与推理循环代码跟踪选用Ultralytics内置的BoT-SORT它负责在多帧之间维持目标ID行为规则依赖track_id做历史轨迹判断。示例代码如下from ultralytics import YOLO import cv2 model YOLO(runs/fall/train/weights/best.pt) cap cv2.VideoCapture(rtsp://10.0.0.12:554/stream1) def check_fall_rule(x1, y1, x2, y2, frame_h): ratio (x2 - x1) / max(1, y2 - y1) cy (y1 y2) / 2 if ratio 1.0 and cy frame_h * 0.7: return fall return None while cap.isOpened(): ret, frame cap.read() if not ret: break results model.track(frame, persistTrue, conf0.4, iou0.5) if results[0].boxes.id is None: continue frame_h frame.shape[0] for box, track_id in zip( results[0].boxes.xyxy.cpu().numpy(), results[0].boxes.id.cpu().numpy() ): x1, y1, x2, y2 [int(v) for v in box] event check_fall_rule(x1, y1, x2, y2, frame_h) if event: # 触发报警保存实现见4.4 passpersistTrue保证连续帧间ID不重新分配否则无法形成轨迹。conf0.4在安防画面中可接受夜间误检变多再提到0.5。check_fall_rule里的宽高比阈值1.0是按平拍视角估的从高处俯拍时要改成0.8左右质心位置取画面底部70%以下是为了过滤正常坐姿具体比例必须结合实际场景校准。这段代码最需要改的是触发策略单帧满足条件就报警会把正常行走中偶然宽高比波动误报成摔倒实际项目要改成连续3帧满足条件才触发。4.3 OpenCV、face_recognition与人脸识别联动人脸识别子线程拿到裁剪图之后需要和注册人员库比对。用face_recognition的简化实现如下import face_recognition def load_known_faces(known_map): ids, encodings [], [] for pid, path in known_map.items(): img face_recognition.load_image_file(path) enc face_recognition.face_encodings(img) if enc: ids.append(pid) encodings.append(enc[0]) return ids, encodings def recognize(crop, ids, encodings): locs face_recognition.face_locations(crop) if not locs: return None encs face_recognition.face_encodings(crop, locs) if not encs: return None matches face_recognition.compare_faces(encodings, encs[0], tolerance0.45) if True not in matches: return None return ids[matches.index(True)]tolerance0.45是实测比较稳妥的阈值默认0.6在这种场景里误识率偏高。如果现场人员全部戴安全帽或口罩要重新采集注册照片不能沿用之前的特征向量。低算力设备上跑不动dlib时切换回OpenCV LBPH是最直接的办法把特征比对替换成predict方法即可速度能快十倍代价是识别率下降。识别线程的阻塞不要拖累主推理用队列把待识别裁剪图积压起来队列上限设200满了丢旧图保证管道永远朝最新事件推进。4.4 yolov11预测后保存与报警输出“yolov11预测后保存”不只在推理阶段用于验证也是报警记录的核心。报警帧以时间戳和目标ID命名写入磁盘的代码很简单import time, os alarm_dir alarm os.makedirs(alarm_dir, exist_okTrue) def save_alarm_frame(frame, track_id, event): ts time.strftime(%Y%m%d_%H%M%S) filename f{alarm_dir}/{ts}_{track_id}_{event}.jpg cv2.imwrite(filename, frame)报警记录要同时推送现有平台时用HTTP回调但超时时间必须短import requests def notify_platform(payload): try: requests.post(http://10.0.0.5:8080/api/alarm, jsonpayload, timeout1) except requests.RequestException: passtimeout1是硬性要求外部平台响应慢或被防火墙阻断时不能阻塞主管道。推送失败不回滚主流程报警帧已经落盘事后可以补发。到这里“从摄像头取流到报警落盘”的端到端闭环已经成立剩下的问题基本都集中在性能和小目标上。5. 部署后的三个门槛yolov11小目标优化、树莓派选型和验证方法5.1 yolov11小目标优化先动输入分辨率小目标优化最容易见效的不是改网络结构而是调输入分辨率。把imgsz从640调到960远端较矮的人体和半身人脸的检测率会有明显提升代价是推理耗时增加约一倍。先拿离线视频跑一遍960分辨率的推理对比确认漏检率下降后再决定是否长期使用。如果设备算力撑不住960可以采用双模型方案主模型按960检测人体人脸识别用OpenCV Haar级联做预筛把可能的人脸区域先裁出来再送小网络。小目标优化的另一条路是调预测阶段的conf和iou一般小目标漏检时先降conf再单独调iou避免相邻目标被合并。5.2 树莓派与低算力边缘设备的实际取舍面向“基于树莓派的人脸识别”这类需求时先要把预期值放低。树莓派4B上跑yolo11n的640分辨率推理能到4到6fps加上OpenCV LBPH人脸识别链路整体8到10fps对楼宇门禁够用。换成face_recognition库之后dlib的特征向量提取单价太贵整个系统直接掉到1fps以下所以边缘设备要回归到opencv人脸识别。还有人问树莓派能不能跑yolo11 pose实践下来虽然能跑但量化后精度损失明显不如在服务器端做姿态推理。硬件层面的坑也要提一句供电不稳导致的死机在边缘设备上高发问题往往与算法无关。5.3 用一段自录视频验证端到端链路部署完成后录一段40秒视频包含正常行走、奔跑、模拟摔倒、双人扭打四个场景按时间轴标注事件发生秒数。跑完全链路后统计报警记录事件漏报一次就回溯是检测框丢失还是规则阈值卡得太死还是队列丢帧。报警延迟超过2秒重点查推理线程是否被人脸识别阻塞查抽帧策略是否丢掉关键帧。整个验证过程要保留原始视频和报警截图方便和现场负责人对齐。把报警延迟控制在2秒以内再谈扩大监控区域数量不迟。本文还有配套的精品资源点击获取 YOLOv11端到端部署：人脸识别与异常行为检测实战
简介这是一份面向安防领域算法工程师与部署人员的YOLOv11实战技术手册聚焦人脸识别与异常行为检测的完整落地路径。手册从YOLOv11基础讲起涵盖算法原理、骨干网络与检测头结构并详细展开人脸检测、特征提取及匹配识别同YOLOv11的融合方法异常行为检测部分则介绍基于规则、机器学习与深度学习的技术原理以及目标关联、特征融合与联合训练等建模思路。针对工程化需求内容还覆盖软硬件环境搭建、数据集清洗与增强、模型训练调优、量化剪枝推理加速及本地或云端部署并结合商场安防、工业厂区、校园保障等案例给出效果评估与优化建议。资源为单份PDF文档共34页约2.02MB支持目录跳转和章节快速定位方便读者按需查阅。目前已有125人学习使用适合正在搭建智能安防监控系统、需要提升目标检测效率或研究YOLOv系列与行为识别结合的开发者参考。1. 安防场景下YOLOv11人脸识别与异常行为检测的端到端部署摄像头建了几十万路真正在用的经常只剩事后回放。白天靠人盯屏晚上靠回放查问题出在传统安防平台把人脸抓拍、目标检测和行为分析拆成三套独立系统链路长、联调复杂。YOLOv11把目标检测、姿态估计放在同一个网络结构里之后人脸识别和异常行为检测第一次能共享同一个推理出口。端到端部署的意思是从摄像头取流到输出“谁、在哪、做了什么、要不要报警”所有环节在系统内闭环不再依赖第三方比对服务或人工盯屏。这套方案更适合集成商、算法工程师和负责边缘设备落地的部署岗接下来按模型选型、训练参数、管道联调和落地细节四个顺序展开。2. YOLOv11网络结构与人脸识别算法选型2.1 YOLOv11的网络结构变化与检测优势拿YOLOv11和上一代YOLOv8对比结构变化集中在三处backbone把C2f模块换成C3k2backbone末端新增C2PSA自注意力模块检测头保持anchor-free解耦头。C3k2前段是CSP风格的特征split后段用两个小kernel bottleneck堆叠计算量分配比C2f更均衡C2PSA负责在深层捕捉全局上下文顺便把小目标区域的特征激活得更充分。讨论yolov11网络结构时不要死记层号抓住“C3k2替换C2f”和“C2PSA引入注意力”两个改动就足够。放到安防场景里yolov11更重要的特征是同一权重可以输出检测、分类和姿态估计三类结果。同一个模型在detect模式下输出人体框切到pose模式后输出17个关键点摔倒、起立、抬手的判断可以完全基于关键点省掉单独部署OpenPose的开销。行为检测从多级系统变成同一个网络的不同输出头这正是端到端部署真正省时间的点。模型尺度选择要跟着算力走。树莓派和Jetson Nano先选yolo11n或yolo11sx86服务器带GPU可以上yolo11m。先用最小配置把全链路跑通再按实测帧率逐级放大不要一开始就扎进网络结构魔改。这里要提醒一句网络结构改造的收益在数据量不够时几乎看不出来。现有yolo11n足够把安防场景的人体框稳定检出与其花精力魔改C3k2不如先收集现场数据并校准规则阈值。固定ultralytics版本也很关键频繁升级会引入推理结果微调直接影响已经写好的报警规则。2.2 人脸识别算法对比opencv人脸识别、dlib与insightface人脸识别和检测是两件事检测负责定位人在哪里识别负责判断他是谁。端到端部署里这两个模块分工不同选型差异也很明显。下表按从易到难排序方案识别精度CPU推理速度部署依赖适用场景OpenCV Haar LBPH低正脸且光照稳定可用极低树莓派可实时opencv-python门禁机、小规模白名单face_recognition(dlib)中侧脸和暗光会掉点单次识别0.3~0.6秒dlib、CMake内网小规模人员库InsightFace(ArcFace)高支持大角度和遮挡需要GPU或NPUonnxruntime生产环境、人员库较大提到“opencv人脸识别”时多数门禁机里用的是Haar级联加LBPH。Haar负责找脸LBPH负责把局部二值模式直方图拿来做人脸比对训练时生成一个本地特征库不依赖任何外部网络。问题在于特征维度低人员库超过50人之后误报率上升明显。face_recognition库把dlib包了一层128维特征向量比LBPH高一个量级但安装依赖重编译dlib在边缘设备上很耗时。对识别率有硬性要求的现场直接在onnxruntime上跑InsightFace更省心模型文件大几十MB不是问题要的是输出稳定、误识率可控。端到端里的选型最终由人员库规模决定50人以内用LBPH足够50到几百人用face_recognition或MTCNN加ArcFace上千人就要考虑向量检索库单靠人脸识别库本身的线性比对已经撑不住。这个边界在设计阶段就要定下来避免上线后频繁换识别引擎。2.3 异常行为检测不靠“异常分类”靠检测加跟踪加规则很多项目栽在同一个坑上试图训练一个“异常行为”分类器指望把一切异常都识别出来。异常形态没有上限摔倒、挣扎、翻越、聚集、奔跑数据永远标不完类别边界也划不清。常见的做法是分层处理第一层用YOLOv11输出人体框和关键点第二层写规则引擎根据框的位置、速度、面积变化和重叠关系判断是否异常。摔倒的判断逻辑是人体宽高比从站立时的“瘦高型”变成躺倒的“扁平型”同时质心高度在半秒内快速下降打架则表现为两个人体框长时间高重叠骨架关键点位移幅度超过阈值。这些规则来自现场经验必须按摄像头安装高度、俯仰角微调。某些动作如果稳定复现比如“翻越栏杆”可以作为单独类别训练剩下的大范围行为还是交给规则引擎。这一层跑在CPU上即可不占显卡资源也让整个管道的算力分配更有弹性。3. 用YOLOv11训练自己的异常行为模型数据准备与训练参数3.1 标注规范与YOLO数据集目录结构第一版建议标注三个类别person、fighting、falling。person作为基类规则引擎判断行为时要依赖它fighting和falling是异常类别。标注时使用YOLO框格式每行内容为class_id center_x center_y width height坐标全部归一化到0到1。目录结构保持YOLO标准dataset/ ├── fall.yaml ├── images/ │ ├── train/ │ │ ├── fall_001.jpg │ │ └── fight_001.jpg │ └── val/ ├── labels/ │ ├── train/ │ │ ├── fall_001.txt │ │ └── fight_001.txt │ └── val/fall.yaml中的信息很简单path: /data/dataset train: images/train val: images/val nc: 3 names: [person, fighting, falling]训练集数据不要直接拿公开数据集凑。公开数据能把大致的视觉特征训练出来但现场摄像头的俯视角、夜视效果、雨雾环境完全不同必须混入现场截流素材至少2000帧异常帧数量不够时做上下翻转、亮度扰动等数据增强。标注框要紧贴目标边缘倒地姿态特别容易标松宽松的框会把背景并进来训练时模型反而学不到精确位置。3.2 YOLOv11环境配置与训练核心命令环境安装用一条pip命令但之前要确认CUDA、PyTorch、显卡驱动三者匹配pip install ultralytics训练前先下载对应尺度的预训练权重yolo11n.pt然后按下面的命令训练yolo detect train \ modelyolo11n.pt \ datadataset/fall.yaml \ epochs120 \ imgsz640 \ batch16 \ device0 \ patience20 \ projectruns/fallpatience20表示连续20轮验证指标不涨时提前停止适合样本规模不大的异常数据集。imgsz640在人体占画面较大时足够走廊尽头、远端小目标场景直接调到960后面单独讲。batch16在单张显卡上不算大如果显存允许可以增加到32以提高训练稳定性。下面这几个参数是逐项调优时最值得动的参数第一版推荐值作用与调法lr00.01损失震荡就降到0.005lrf0.01末期学习率缩放比例mosaic1.0目标重叠严重时降到0.5hsv_h0.015夜晚监控数据适当加大到0.03close_mosaic10最后10轮关闭拼图适应真实尺度跌倒样本量不足时先在类别权重上把falling提上来比直接改网络结构更实际。看训练日志要同时关注mAP和混淆矩阵两个异常类别之间如果相互误检要回到数据里检查是不是标注框张冠李戴。一个容易被忽略的点是训练集和验证集不要取自同一段视频的连续帧否则验证指标虚高上线后被真实场景直接打脸。3.3 训练结果评估与模型导出训练完成后runs/fall/train/weights/下会生成best.pt和last.pt。验证指标里mAP50-95比mAP50重要因为fighting和falling的形状差异大把IoU阈值放宽会虚高。用yolo metrics查看具体数值再打开混淆矩阵确认跨类别误检比例。部署需要的文件从best.pt导出导出命令如下yolo export modelruns/fall/train/weights/best.pt formatonnx opset12 simplifyTrue yolo export modelruns/fall/train/weights/best.pt formatengine device0 halfTrueONNX格式用于跨平台部署engine格式是TensorRT的专用格式适合GPU边缘盒子。导出后用onnxruntime跑一遍同一段测试视频确认检测框坐标和PyTorch推理基本一致防止个别算子实现差异造成偏移。这一步验证的是“yolov11预测后保存”的基础链路保存命令如下yolo predict modelruns/fall/train/weights/best.pt sourcetest.mp4 saveTrue conf0.35参数saveTrue会把每一帧的推理结果保存成标注后的图片或视频适合先确认模型打包后输出正常。conf0.35在测试阶段可以低一些看模型完整的目标输出能力正式部署再回到0.4或0.5。4. 端到端部署管道YOLOv11目标跟踪、人脸识别与预警保存4.1 管道框架设计与线程划分管道事件顺序固定为视频解码、检测与目标跟踪、人体框裁剪、行为规则引擎、人脸识别子任务、报警记录保存。摄像头帧率和分辨率确定后系统就是典型的生产者消费者模型。解码线程不断向队列放帧推理线程从队列取帧队列满时丢弃最旧的帧保证实时性优先于完整性这是安防流媒体最常见的手段。人脸识别不能放在主推理路径上这是整个管道性能的关键。YOLOv11在CPU上处理一帧640分辨率大约要0.15到0.3秒dlib的face_recognition识别一个人脸还要0.5秒左右。如果每帧把所有检测出来的人脸都做一次识别整个管道立刻被塞死。常见做法是开单独的人脸识别线程只处理首次出现的人体框或由行为规则触发的裁剪图。端到端部署里“实时”的体验完全靠这种层次化任务划分来维持而不是靠运气。4.2 YOLOv11目标跟踪与推理循环代码跟踪选用Ultralytics内置的BoT-SORT它负责在多帧之间维持目标ID行为规则依赖track_id做历史轨迹判断。示例代码如下from ultralytics import YOLO import cv2 model YOLO(runs/fall/train/weights/best.pt) cap cv2.VideoCapture(rtsp://10.0.0.12:554/stream1) def check_fall_rule(x1, y1, x2, y2, frame_h): ratio (x2 - x1) / max(1, y2 - y1) cy (y1 y2) / 2 if ratio 1.0 and cy frame_h * 0.7: return fall return None while cap.isOpened(): ret, frame cap.read() if not ret: break results model.track(frame, persistTrue, conf0.4, iou0.5) if results[0].boxes.id is None: continue frame_h frame.shape[0] for box, track_id in zip( results[0].boxes.xyxy.cpu().numpy(), results[0].boxes.id.cpu().numpy() ): x1, y1, x2, y2 [int(v) for v in box] event check_fall_rule(x1, y1, x2, y2, frame_h) if event: # 触发报警保存实现见4.4 passpersistTrue保证连续帧间ID不重新分配否则无法形成轨迹。conf0.4在安防画面中可接受夜间误检变多再提到0.5。check_fall_rule里的宽高比阈值1.0是按平拍视角估的从高处俯拍时要改成0.8左右质心位置取画面底部70%以下是为了过滤正常坐姿具体比例必须结合实际场景校准。这段代码最需要改的是触发策略单帧满足条件就报警会把正常行走中偶然宽高比波动误报成摔倒实际项目要改成连续3帧满足条件才触发。4.3 OpenCV、face_recognition与人脸识别联动人脸识别子线程拿到裁剪图之后需要和注册人员库比对。用face_recognition的简化实现如下import face_recognition def load_known_faces(known_map): ids, encodings [], [] for pid, path in known_map.items(): img face_recognition.load_image_file(path) enc face_recognition.face_encodings(img) if enc: ids.append(pid) encodings.append(enc[0]) return ids, encodings def recognize(crop, ids, encodings): locs face_recognition.face_locations(crop) if not locs: return None encs face_recognition.face_encodings(crop, locs) if not encs: return None matches face_recognition.compare_faces(encodings, encs[0], tolerance0.45) if True not in matches: return None return ids[matches.index(True)]tolerance0.45是实测比较稳妥的阈值默认0.6在这种场景里误识率偏高。如果现场人员全部戴安全帽或口罩要重新采集注册照片不能沿用之前的特征向量。低算力设备上跑不动dlib时切换回OpenCV LBPH是最直接的办法把特征比对替换成predict方法即可速度能快十倍代价是识别率下降。识别线程的阻塞不要拖累主推理用队列把待识别裁剪图积压起来队列上限设200满了丢旧图保证管道永远朝最新事件推进。4.4 yolov11预测后保存与报警输出“yolov11预测后保存”不只在推理阶段用于验证也是报警记录的核心。报警帧以时间戳和目标ID命名写入磁盘的代码很简单import time, os alarm_dir alarm os.makedirs(alarm_dir, exist_okTrue) def save_alarm_frame(frame, track_id, event): ts time.strftime(%Y%m%d_%H%M%S) filename f{alarm_dir}/{ts}_{track_id}_{event}.jpg cv2.imwrite(filename, frame)报警记录要同时推送现有平台时用HTTP回调但超时时间必须短import requests def notify_platform(payload): try: requests.post(http://10.0.0.5:8080/api/alarm, jsonpayload, timeout1) except requests.RequestException: passtimeout1是硬性要求外部平台响应慢或被防火墙阻断时不能阻塞主管道。推送失败不回滚主流程报警帧已经落盘事后可以补发。到这里“从摄像头取流到报警落盘”的端到端闭环已经成立剩下的问题基本都集中在性能和小目标上。5. 部署后的三个门槛yolov11小目标优化、树莓派选型和验证方法5.1 yolov11小目标优化先动输入分辨率小目标优化最容易见效的不是改网络结构而是调输入分辨率。把imgsz从640调到960远端较矮的人体和半身人脸的检测率会有明显提升代价是推理耗时增加约一倍。先拿离线视频跑一遍960分辨率的推理对比确认漏检率下降后再决定是否长期使用。如果设备算力撑不住960可以采用双模型方案主模型按960检测人体人脸识别用OpenCV Haar级联做预筛把可能的人脸区域先裁出来再送小网络。小目标优化的另一条路是调预测阶段的conf和iou一般小目标漏检时先降conf再单独调iou避免相邻目标被合并。5.2 树莓派与低算力边缘设备的实际取舍面向“基于树莓派的人脸识别”这类需求时先要把预期值放低。树莓派4B上跑yolo11n的640分辨率推理能到4到6fps加上OpenCV LBPH人脸识别链路整体8到10fps对楼宇门禁够用。换成face_recognition库之后dlib的特征向量提取单价太贵整个系统直接掉到1fps以下所以边缘设备要回归到opencv人脸识别。还有人问树莓派能不能跑yolo11 pose实践下来虽然能跑但量化后精度损失明显不如在服务器端做姿态推理。硬件层面的坑也要提一句供电不稳导致的死机在边缘设备上高发问题往往与算法无关。5.3 用一段自录视频验证端到端链路部署完成后录一段40秒视频包含正常行走、奔跑、模拟摔倒、双人扭打四个场景按时间轴标注事件发生秒数。跑完全链路后统计报警记录事件漏报一次就回溯是检测框丢失还是规则阈值卡得太死还是队列丢帧。报警延迟超过2秒重点查推理线程是否被人脸识别阻塞查抽帧策略是否丢掉关键帧。整个验证过程要保留原始视频和报警截图方便和现场负责人对齐。把报警延迟控制在2秒以内再谈扩大监控区域数量不迟。本文还有配套的精品资源点击获取