这次我们聊一个弱电圈的老问题监控装了但“看”这件事始终靠人肉。值班室常年摆着一台大电视16 分割画面循环播放晚上盯着一片雪花就等于没事。问题是多数监控系统只有在事件发生之后才显得有用真正要防的时候人做不到 24 小时保持注意。本地 AI 监控这类免费方案就是要把“盯屏幕”这个岗位替代掉。做法很直接摄像头继续用原来的视频流进入本地推理服务AI 负责识别画面里有没有人、有没有进禁区、有没有异常行为一旦确定事件立刻推一条带截图的报警到手机。这个方案最大的价值不在识别而在“本地”和“免费”两个词。视频画面不出内网数据留存在自己硬盘里不需要给云服务商送钱也不需要每年购买额外的智能分析授权。从落地路径看现在主流的做法有三类一是直接部署 Frigate 这类开源 NVR 平台AI 检测基本开箱即用二是用 Python 接 YOLO 模型自建轻量服务按自己的需求定制规则三是用海康、大华等厂商 NVR 自带的智能分析功能但容易受设备型号和授权限制。这篇文章会从硬件选型、架构设计、部署过程和效果验证几个角度展开重点解决“本地 AI 监控到底怎么落地”的问题。1. 核心能力速览能力项说明方案类型本地 AI 视频监控分析开源 NVR 自建模型检测核心功能人员检测、车辆检测、区域入侵报警、异常行为识别、事件快照、告警推送摄像头要求支持 RTSP/ONVIF 的标准 IP 摄像头海康、大华等品牌均可接入硬件门槛有 GPU 体验最好无 GPU 可用 CPU 推理或低功耗盒子效果取决于路数和分辨率数据存储本地存储可选择事件录像 快照模式避免 7x24 小时全量录像告警方式Webhook、钉钉、企业微信、邮件等按方案自行集成批量任务支持多路摄像头轮询或并行推理API 能力Frigate 自带接口自建服务可通过 Flask/FastAPI 提供 HTTP 接口软件费用开源方案免费综合成本主要是硬件、电费和维护时间适合用户弱电工程师、安防集成商、运维人员、有合规授权的场所管理者从能力速览可以看出这类方案不是把原来的监控系统推翻而是在原有摄像头基础上增加一层 AI 分析。真正要投入的资源是算力设备、部署时间和后续误报调优的工作量。2. 适用场景与使用边界本地 AI 监控在弱电工程里最常用的场景包括仓库和周界夜间防闯入、工地夜间防盗、园区出入口进出复核、商店半夜有人进入、数据中心机房限制区域提醒、配电房等无人值守场所的异常逗留检测。这些场景有一个共同点平时没有人看屏幕但事件一旦发生就希望立刻知道。另一种常见需求是辅助值班。值班人员仍然盯着屏幕但 AI 负责把画面里的目标框出来降低视觉疲劳。比如通过监控视频进行人员行为检测时AI 可以标记出倒地的、长时间逗留的、越过警戒线的目标值班人员只需要关注 AI 标出来的事件即可不需要逐格看画面。使用边界也很明确。当前本地 AI 方案在目标检测上已经比较成熟但对“行为意图”的判断仍然有限。比如“两个人争吵”和“两个人在正常聊天”仅靠单路摄像头画面很难稳定区分。如果项目要求高精度的人体姿态、摔倒识别、多模态行为识别就需要额外的专用模型和更复杂的推理链路不能把普通 YOLO 检测当成行为分析来用。部署前如果有类似需求先做一个 PoC用现场真实视频跑一遍比看技术参数更靠谱。合规是硬边界。任何视频监控方案都必须提前确认授权范围企业内部区域、自有仓库、授权管理的园区可以使用未经告知和授权的公共区域、他人私有空间、员工宿舍等场景不能私自部署智能识别。本地存储也不能完全豁免隐私责任建议做到三件事安装区域有明显标识、告警截图和录像设置合理留存周期、访问接口和 Web 面板设置强密码避免内网横向泄露。涉及人脸识别、车牌识别等高敏感信息时需要更严格的合规评审。3. 硬件选型与环境准备硬件怎么选取决于三件事接入多少路摄像头、做多复杂的模型推理、以及有没有现成的设备能用。如果是从零开始选硬件优先考虑带 NVIDIA GPU 的机器哪怕是入门级的独立显卡也能在 4 到 8 路摄像头场景下获得不错的检测体验。原因很简单当前主流的 YOLO 系列模型对 CUDA 支持最好部署资料最多。如果没有 GPU也不必急着买卡可以先在一台普通电脑或 N100 这类低功耗小主机上用 CPU 跑一个小模型先把流程跑通再评估算力是否需要升级。摄像头选型尽量选择支持 RTSP 和 ONVIF 的型号。海康、大华等主流品牌都有 RTSP 取流地址但不同品牌格式差异很大。海康常见路径是rtsp://username:password192.168.1.64:554/Streaming/Channels/101大华常见路径是rtsp://username:password192.168.1.64:554/cam/realmonitor?channel1subtype0具体以厂家文档为准。比较容易踩坑的地方是主码流和子码流的选择。AI 检测不一定需要主码流很多项目反而用子码流做检测、用主码流做录像这样能大幅降低解码压力。配置点位时先确认摄像头固件里的编码格式尽量使用 H.264部分老设备对 H.265 支持不完整拉流时会黑屏或花屏。环境准备阶段建议按下面的清单检查一遍检查项说明操作系统Linux 服务器最常用Windows 也可部署教程和坑相对多GPU 驱动如果用 NVIDIA GPU需要安装对应驱动并确认 CUDA 版本容器环境推荐安装 Docker 和 docker composeFrigate 等方案以容器方式启动最方便Python 环境自建方案需要 Python 3.8 以上推荐使用虚拟环境隔离依赖摄像头网络摄像头和 AI 服务主机要在同一网段防火墙放行 RTSP 端口存储空间事件快照和录像按天消耗空间建议预留系统盘之外的独立存储目录NTP 时间同步摄像头和服务器都要做时间同步时间不一致会导致事件时间错乱如果只是测试一台带独显的旧电脑、一个可用的摄像头就足够了。不要一开始就追求十几路接入先跑通一路再扩展。4. 整体架构设计一套完整的本地 AI 监控系统可以拆成下面几个环节摄像头 RTSP 拉流。AI 服务持续从摄像头获取视频帧。视频解码。通过 FFmpeg、OpenCV 或 GStreamer 把 RTSP 流解码成帧。抽帧和预处理。不是每一帧都要推理可以按 1 到 5 秒间隔抽帧也可以按帧率设置比如每秒 2 帧。AI 模型推理。检测画面中的目标输出类别、置信度和目标框坐标。业务规则判断。对检测结果做过滤比如“只在晚上检测”“只在这个多边形区域内检测”“连续 N 帧确认后再告警”。事件触发。命中规则后保存快照、截取事件视频、发送告警通知。管理查看。提供 Web 界面或 API用于查看实时画面、历史事件和检测结果。这套架构里最容易忽略的是第五步。直接把模型输出当事件处理会造成大量误报。比如对面的行人穿过镜头、车辆灯光扫过、树叶晃动都可能会被模型当成目标。解决方法是设置区域过滤、时间过滤和连续帧确认。存储策略也需要在架构上提前确定。建议把“全量录像”和“事件录像”分开。全量录像成本高AI 方案更适合以事件为中心平时只做检测事件发生时才保存前后几秒的快照或视频片段这样存储压力会小很多。5. 方案 AFrigate 部署与效果验证Frigate 是目前社区里比较成熟的开源 NVR 方案定位就是本地 AI 物体检测和事件录像。它支持 RTSP 摄像头接入提供了一个 Web 管理界面能直接在画面上看到检测框。部署方式以 Docker 为主下面是简化后的 docker compose 示例字段需要按你的实际环境和官方最新文档调整version: 3.9 services: frigate: container_name: frigate restart: unless-stopped image: ghcr.io/blakeblackshear/frigate:stable shm_size: 64mb devices: - /dev/bus/usb:/dev/bus/usb volumes: - ./config.yml:/config/config.yml - ./storage:/media/frigate ports: - 8971:5000 environment: FRIGATE_RTSP_PASSWORD: change_me这段配置里./config.yml是挂载进来的主配置./storage是事件录像存储目录。ports把容器内的 5000 端口映射到宿主机的 8971访问时用浏览器打开http://服务器IP:8971即可。config.yml 的核心内容大概是这个结构不同版本的字段会有差异具体以官方文档为准mqtt: enabled: false detectors: detector: type: cpu num_threads: 2 cameras: front_gate: ffmpeg: inputs: - path: rtsp://username:password192.168.1.64:554/Streaming/Channels/101 roles: - detect - record detect: width: 1280 height: 720 fps: 5 objects: track: - person - car snapshots: retain: default: 3启动服务后建议按下面的步骤验证执行docker compose up -d启动容器。查看日志确认摄像头拉流成功docker logs -f frigate。浏览器打开 Web 界面看实时画面是否正常。让人走进画面观察检测框是否在人员身上出现。到 Events 页面查看事件快照是否生成。确认事件里能区分 person 和 car 两类目标。如果画面没有检测框优先检查三件事RTSP 地址是否能在 VLC 里正常播放、detect 分辨率是否过高导致解码太慢、objects.track是否包含人员类别。这里要说明一下CPU 检测模式下延迟会明显高于 GPU。一路 720p 视频、每秒 5 帧检测CPU 占用可能就相当可观了。如果有多路摄像头或检测的帧率要求更高考虑给 Frigate 配置 GPU 检测器或者改用后面的 Python 自建方案把推理参数精细化控制。6. 方案 BPython YOLO 自建轻量检测服务如果你需要更多定制逻辑或者在特定场景下要控制模型大小和检测精度自建检测服务是更灵活的路子。最简单的实现是 Python OpenCV 拉流 YOLO 模型推理。先安装依赖pip install ultralytics opencv-python模型权重文件需要通过官方渠道下载放在本地目录写代码时按本地路径加载。下面是一段可以跑通的检测服务框架核心逻辑是读取 RTSP 流抽帧后用 YOLO 检测输出结果并保存告警快照。import cv2 from ultralytics import YOLO # 从本地加载权重文件避免每次启动联网下载 model YOLO(yolov8n.pt) RTSP_URL rtsp://username:password192.168.1.64:554/Streaming/Channels/102 cap cv2.VideoCapture(RTSP_URL) if not cap.isOpened(): print(RTSP 拉流失败请检查网络和摄像头路径) exit(1) frame_interval 2 # 每 2 帧检测一次 frame_count 0 while True: ret, frame cap.read() if not ret: print(断流尝试重连...) cap.release() cap cv2.VideoCapture(RTSP_URL) continue frame_count 1 if frame_count % frame_interval ! 0: continue results model(frame, verboseFalse) for det in results[0].boxes: cls_id int(det.cls[0]) conf float(det.conf[0]) label model.names[cls_id] # 只关心 person 类别且置信度超过阈值 if label person and conf 0.5: cv2.imwrite(falert_{label}_{conf:.2f}.jpg, frame) print(f检测到人员置信度: {conf:.2f})这段代码能跑通基本检测但它只是把每一帧的检测结果打印和保存距离“自动看着”还差一步需要结合区域判断和告警推送一起用。区域入侵是弱电监控最常见的需求。比如只允许某块区域在特定时间有人其他时间一旦出现人员就告警。下面是射线法判断点是否在多边形内的函数可以直接用摄像头画面坐标做配置def point_in_polygon(x, y, polygon): 射线法判断点是否在多边形内 n len(polygon) inside False j n - 1 for i in range(n): xi, yi polygon[i] xj, yj polygon[j] if ((yi y) ! (yj y)) and (x (xj - xi) * (y - yi) / (yj - yi) xi): inside not inside j i return inside把这些逻辑组合起来就可以在检测到人员目标后再判断目标中心点是否落在禁止区域内。如果落入了禁止区域再触发下一节的告警机制。调试阶段建议在画面上把多边形的边框画出来方便校准坐标。实际项目中摄像头安装角度、透视形变都会影响多边形准确度至少要调试一两次才能稳定。7. 告警通知与批量任务本地 AI 监控的核心价值是把事件推出来否则它只是另一个没人看的 NVR。最简单的做法是发送到钉钉或企业微信的自定义机器人这里给一个钉钉机器人调用的通用示例。先在自己的钉钉群添加自定义机器人拿到 Webhook 地址再写推送函数import requests def send_dingtalk(webhook_url, text): payload { msgtype: text, text: {content: text} } # 注意真实调用需要加上安全设置要求的签名参数 response requests.post(webhook_url, jsonpayload, timeout10) if response.status_code 200: result response.json() if result.get(errcode) 0: print(告警推送成功) else: print(推送失败:, result) else: print(HTTP 错误:, response.status_code)接入了 Webhook 之后可以把前面检测代码里的保存截图逻辑扩展为发送告警消息消息文本里附带时间、摄像头名称、目标类别和置信度。钉钉机器人可以直接发送 Markdown 文本但不建议把图片体积做得太大截图先压缩到 300KB 以下推送成功率会更高。告警推送必须加冷却机制否则一辆汽车经过的画面里连续 20 帧识别出人就会推 20 条消息。这也是弱电项目上线后最容易被人质疑的地方。用一个简单的冷却类来控制import time class AlertCooldown: def __init__(self, seconds30): self.seconds seconds self.last_alert_time 0 def should_alert(self): now time.time() if now - self.last_alert_time self.seconds: self.last_alert_time now return True return False cooldown AlertCooldown(seconds30)批量处理多路摄像头时可以使用线程池实现并行拉流和检测。摄像头数量不多的情况下线程模型比进程模型更省资源import concurrent.futures def process_camera(camera_config): rtsp_url camera_config[rtsp] cap cv2.VideoCapture(rtsp_url) while True: ret, frame cap.read() if not ret: print(f{camera_config[name]} 断流尝试重连) cap.release() cap cv2.VideoCapture(rtsp_url) continue # 推理逻辑... # 告警逻辑... cameras [ {name: front_gate, rtsp: rtsp://...}, {name: back_yard, rtsp: rtsp://...}, ] with concurrent.futures.ThreadPoolExecutor(max_workers4) as executor: executor.map(process_camera, cameras)多路并发时最需要注意的是推理资源竞争。使用 GPU 推理时并发数过大容易把显存打满甚至导致 CUDA OOM。建议先从一路开始跑观测 GPU 利用率和显存占用再逐步增加并发路数。自定义服务如果要和其他系统对接建议用 FastAPI 包一层 HTTP 接口把“触发检测”和“查询事件记录”暴露出来。比如在检测到事件后把事件信息写入本地数据库再通过接口让第三方平台查询这样就能和现有的弱电集成平台、运维大屏或者工单系统联动起来。8. 资源占用与性能观察本地 AI 监控上线前至少要用一套数据回答四个问题推理延迟能控制在多少、显存或 CPU 占用是否稳定、单台设备能处理几路摄像头、误报率能不能接受。先看显存。使用 NVIDIA GPU 时推荐用以下命令实时观察nvidia-smi如果 GPU 版本较新也可以使用nvidia-smi dmon持续刷新显存、温度、利用率。自建 Python 服务的进程显存占用会随着模型加载和视频推理逐渐稳定如果持续增长要排查是否存在内存或显存泄漏。CPU 推理时可以使用top、htop或者glances观察进程占用。CPU 推理的特点是占用率波动明显抽帧间隔越长越省资源但检测漏报率也会随之上升。性能优化可以从几个方向入手降低抽帧频率。从每秒 5 帧降到每秒 2 帧CPU 占用能降一半以上对人员移动检测影响并不大。降低推理分辨率。YOLO 默认输入 640x640很多场景用 416x416 就够检测人员了。换更小的模型。yolov8n 比 yolov8s 更快精度低一点但对大多数人员检测场景足够。使用 GPU 半精度推理。在自建服务里设置model YOLO(yolov8n.pt).half()前提是 GPU 支持半精度。关于“AI 监控服务本身也要监控”这个话题也值得多说一句。弱电工程部署完一套 AI 监控之后还需要知道这个服务是否存活、摄像头是否在拉流、推理进程是否卡死。可选的方案是把服务状态暴露成一个 Prometheus metrics 接口然后接入现有的 Prometheus Grafana 监控体系这样 AI 监控服务就和机房里的其他设备一样可观测了。对于嵌入式环境或边缘盒子也可以直接把服务日志写入文件由计划任务定期检查心跳文件时间戳。实际业务中摄像头夜间断流是最容易出现的性能问题。很多低端摄像头在长时间运行后RTSP 连接会异常断开检测服务如果没有重连机制就会从某一刻开始静默失效。这个坑在测试阶段很难发现建议在代码里增加断线重连和心跳上报摄像头断流超过 30 秒就主动告警提醒运维人员。9. 常见问题与排查方法问题现象可能原因排查方式解决方案RTSP 拉流失败地址格式不对、账号密码错误、摄像头不在同一网段用 VLC 或 FFmpeg 测试拉流地址按摄像头厂家文档核对路径检查网络和防火墙拉流正常但没有检测框detect 分辨率过高、模型未配置人员类别、推理间隔过长查看检测日志和画面预览降低 detect 分辨率确认 objects.track 有 person推理速度很慢CPU 推理、帧率设置过高、输入分辨率过大观察 CPU 占用和检测耗时抽帧降频、缩小输入尺寸、换更小的模型或 GPUCUDA GPU 不识别驱动版本过低、CUDA 环境错误、容器未传设备运行 nvidia-smi 验证驱动重装驱动确认容器配置里有设备映射告警通知没收到Webhook 地址错误、无冷却机制被限流、网络不通手动调用 Webhook URL 测试检查签名参数和机器人安全设置加日志重试频繁重复告警连续多帧命中事件、无冷却机制、检测区域过宽查看告警日志时间戳增加冷却时间缩小检测区域摄像头凌晨断流设备固件不稳定、网络供电波动、RTSP 连接数超限检查摄像头在线状态和日志增加断线重连调整设备供电和固件事件录像占用空间大录像保留时间过长、画质码率过高统计每日录像增长量缩短保留周期使用子码流做检测录像容器启动失败端口冲突、配置语法错误、镜像拉取失败查看 docker compose 日志换端口、修正配置缩进、更换镜像源人员检测效果差摄像头角度太高、目标太小、逆光查看告警截图调整摄像头角度结合现场光线做针对性调优排查时不要只看代码层面。很多弱电现场的摄像头是 PoE 供电线路老化或交换机供电不足会导致设备间歇性重启这种问题在告警数据里表现为“凌晨一段时间完全没有检测事件”但摄像头又显示在线。遇到这种场景先检查交换机和 PoE 供电状态比反复调模型参数更有效。10. 最佳实践与使用建议本地 AI 监控上线建议遵循下面这些实践原则能少走不少弯路。第一先做 PoC再谈规模。用一台摄像头、一台测试主机跑通“检测到人 - 生成截图 - 推送报警 - 手动复核”完整链路再决定是否扩展到几十路。第一套系统暴露的问题往往不是 AI 模型精度而是摄像头码流不一致、网络带宽不足、告警打扰等工程问题。第二模型权重、输入素材、输出结果分目录管理。项目目录建议按照models、samples、outputs、logs划分这样在排查告警质量、回看截图和清理磁盘时都方便。批量任务要加任务日志记录每个摄像头每次告警的事件时间、截图路径和推送结果出了问题才能回溯。第三告警阈值要按现场真实样本调优。训练用数据是通用的现场画面会有自己特有的干扰比如反光、强光、树枝晃动、动物经过。上线第一周积累真实截图逐一分析误报原因再决定是缩小检测区域、降低置信度阈值还是增加连续帧确认。第四内网访问要有边界。Web 管理界面和 API 接口不要直接暴露到公网。弱电项目里很多 AI 监控服务部署在客户内网远程访问通常通过厂商的服务转发或内网穿透方案这类方案的安全性取决于你的服务是否有强密码和访问控制。稳妥的做法是绑定内网地址启动比如127.0.0.1或内网固定 IP再通过专用网关做权限管理。第五合规记录要做完整。部署点位、检测范围、告警截图留存周期、数据访问权限都要写成一份简单的文档存档。尤其是涉及园区、办公场所的项目提前和甲方确认合规要求避免后续纠纷。第六系统本身要可持续维护。摄像头固件和 AI 服务依赖会不定期更新更新前先在测试环境跑一遍避免升级后原有配置失效。如果用了 Docker 部署锁定镜像版本不要每次都拉取latest否则某次升级可能造成服务不可用。11. 总结与下一步这次把本地 AI 监控从痛点分析到落地路径做了一次完整梳理。如果是从弱电集成角度进入这个方向先用一台办公室摄像头跑通 Frigate体验一下“自动检测 事件录像”是什么感觉。如果项目里有夜间周界、区域入侵、行为检测这类定制化需求再尝试 Python YOLO 自建服务把检测区域、告警冷却和 Webhook 推送串起来。最值得先验证的三个场景分别是夜间人员检测、区域入侵报警、告警去重降噪。这三个点验证通过了一套基础的本地 AI 监控系统就能承担替代人肉盯屏的工作。最容易踩的坑会在上线第一周集中出现摄像头码流格式不一致、推理间隔太长导致漏报、告警太频繁被值班人员直接关掉通知。别想着一次部署就完美预留一周做现场调优比任何参数都更重要。后面可以继续扩展的方向包括接入更多摄像头并做性能压测、把告警事件接入工单系统、用 Grafana 对 AI 服务本身做监控、在边缘盒子或 NAS 上部署轻量版本。先从最小可运行方案开始再逐步完善这套思路对弱电人对 AI 监控的落地应该会有实际帮助。
本地AI视频监控实战：基于RTSP与YOLO的智能告警与部署方案
这次我们聊一个弱电圈的老问题监控装了但“看”这件事始终靠人肉。值班室常年摆着一台大电视16 分割画面循环播放晚上盯着一片雪花就等于没事。问题是多数监控系统只有在事件发生之后才显得有用真正要防的时候人做不到 24 小时保持注意。本地 AI 监控这类免费方案就是要把“盯屏幕”这个岗位替代掉。做法很直接摄像头继续用原来的视频流进入本地推理服务AI 负责识别画面里有没有人、有没有进禁区、有没有异常行为一旦确定事件立刻推一条带截图的报警到手机。这个方案最大的价值不在识别而在“本地”和“免费”两个词。视频画面不出内网数据留存在自己硬盘里不需要给云服务商送钱也不需要每年购买额外的智能分析授权。从落地路径看现在主流的做法有三类一是直接部署 Frigate 这类开源 NVR 平台AI 检测基本开箱即用二是用 Python 接 YOLO 模型自建轻量服务按自己的需求定制规则三是用海康、大华等厂商 NVR 自带的智能分析功能但容易受设备型号和授权限制。这篇文章会从硬件选型、架构设计、部署过程和效果验证几个角度展开重点解决“本地 AI 监控到底怎么落地”的问题。1. 核心能力速览能力项说明方案类型本地 AI 视频监控分析开源 NVR 自建模型检测核心功能人员检测、车辆检测、区域入侵报警、异常行为识别、事件快照、告警推送摄像头要求支持 RTSP/ONVIF 的标准 IP 摄像头海康、大华等品牌均可接入硬件门槛有 GPU 体验最好无 GPU 可用 CPU 推理或低功耗盒子效果取决于路数和分辨率数据存储本地存储可选择事件录像 快照模式避免 7x24 小时全量录像告警方式Webhook、钉钉、企业微信、邮件等按方案自行集成批量任务支持多路摄像头轮询或并行推理API 能力Frigate 自带接口自建服务可通过 Flask/FastAPI 提供 HTTP 接口软件费用开源方案免费综合成本主要是硬件、电费和维护时间适合用户弱电工程师、安防集成商、运维人员、有合规授权的场所管理者从能力速览可以看出这类方案不是把原来的监控系统推翻而是在原有摄像头基础上增加一层 AI 分析。真正要投入的资源是算力设备、部署时间和后续误报调优的工作量。2. 适用场景与使用边界本地 AI 监控在弱电工程里最常用的场景包括仓库和周界夜间防闯入、工地夜间防盗、园区出入口进出复核、商店半夜有人进入、数据中心机房限制区域提醒、配电房等无人值守场所的异常逗留检测。这些场景有一个共同点平时没有人看屏幕但事件一旦发生就希望立刻知道。另一种常见需求是辅助值班。值班人员仍然盯着屏幕但 AI 负责把画面里的目标框出来降低视觉疲劳。比如通过监控视频进行人员行为检测时AI 可以标记出倒地的、长时间逗留的、越过警戒线的目标值班人员只需要关注 AI 标出来的事件即可不需要逐格看画面。使用边界也很明确。当前本地 AI 方案在目标检测上已经比较成熟但对“行为意图”的判断仍然有限。比如“两个人争吵”和“两个人在正常聊天”仅靠单路摄像头画面很难稳定区分。如果项目要求高精度的人体姿态、摔倒识别、多模态行为识别就需要额外的专用模型和更复杂的推理链路不能把普通 YOLO 检测当成行为分析来用。部署前如果有类似需求先做一个 PoC用现场真实视频跑一遍比看技术参数更靠谱。合规是硬边界。任何视频监控方案都必须提前确认授权范围企业内部区域、自有仓库、授权管理的园区可以使用未经告知和授权的公共区域、他人私有空间、员工宿舍等场景不能私自部署智能识别。本地存储也不能完全豁免隐私责任建议做到三件事安装区域有明显标识、告警截图和录像设置合理留存周期、访问接口和 Web 面板设置强密码避免内网横向泄露。涉及人脸识别、车牌识别等高敏感信息时需要更严格的合规评审。3. 硬件选型与环境准备硬件怎么选取决于三件事接入多少路摄像头、做多复杂的模型推理、以及有没有现成的设备能用。如果是从零开始选硬件优先考虑带 NVIDIA GPU 的机器哪怕是入门级的独立显卡也能在 4 到 8 路摄像头场景下获得不错的检测体验。原因很简单当前主流的 YOLO 系列模型对 CUDA 支持最好部署资料最多。如果没有 GPU也不必急着买卡可以先在一台普通电脑或 N100 这类低功耗小主机上用 CPU 跑一个小模型先把流程跑通再评估算力是否需要升级。摄像头选型尽量选择支持 RTSP 和 ONVIF 的型号。海康、大华等主流品牌都有 RTSP 取流地址但不同品牌格式差异很大。海康常见路径是rtsp://username:password192.168.1.64:554/Streaming/Channels/101大华常见路径是rtsp://username:password192.168.1.64:554/cam/realmonitor?channel1subtype0具体以厂家文档为准。比较容易踩坑的地方是主码流和子码流的选择。AI 检测不一定需要主码流很多项目反而用子码流做检测、用主码流做录像这样能大幅降低解码压力。配置点位时先确认摄像头固件里的编码格式尽量使用 H.264部分老设备对 H.265 支持不完整拉流时会黑屏或花屏。环境准备阶段建议按下面的清单检查一遍检查项说明操作系统Linux 服务器最常用Windows 也可部署教程和坑相对多GPU 驱动如果用 NVIDIA GPU需要安装对应驱动并确认 CUDA 版本容器环境推荐安装 Docker 和 docker composeFrigate 等方案以容器方式启动最方便Python 环境自建方案需要 Python 3.8 以上推荐使用虚拟环境隔离依赖摄像头网络摄像头和 AI 服务主机要在同一网段防火墙放行 RTSP 端口存储空间事件快照和录像按天消耗空间建议预留系统盘之外的独立存储目录NTP 时间同步摄像头和服务器都要做时间同步时间不一致会导致事件时间错乱如果只是测试一台带独显的旧电脑、一个可用的摄像头就足够了。不要一开始就追求十几路接入先跑通一路再扩展。4. 整体架构设计一套完整的本地 AI 监控系统可以拆成下面几个环节摄像头 RTSP 拉流。AI 服务持续从摄像头获取视频帧。视频解码。通过 FFmpeg、OpenCV 或 GStreamer 把 RTSP 流解码成帧。抽帧和预处理。不是每一帧都要推理可以按 1 到 5 秒间隔抽帧也可以按帧率设置比如每秒 2 帧。AI 模型推理。检测画面中的目标输出类别、置信度和目标框坐标。业务规则判断。对检测结果做过滤比如“只在晚上检测”“只在这个多边形区域内检测”“连续 N 帧确认后再告警”。事件触发。命中规则后保存快照、截取事件视频、发送告警通知。管理查看。提供 Web 界面或 API用于查看实时画面、历史事件和检测结果。这套架构里最容易忽略的是第五步。直接把模型输出当事件处理会造成大量误报。比如对面的行人穿过镜头、车辆灯光扫过、树叶晃动都可能会被模型当成目标。解决方法是设置区域过滤、时间过滤和连续帧确认。存储策略也需要在架构上提前确定。建议把“全量录像”和“事件录像”分开。全量录像成本高AI 方案更适合以事件为中心平时只做检测事件发生时才保存前后几秒的快照或视频片段这样存储压力会小很多。5. 方案 AFrigate 部署与效果验证Frigate 是目前社区里比较成熟的开源 NVR 方案定位就是本地 AI 物体检测和事件录像。它支持 RTSP 摄像头接入提供了一个 Web 管理界面能直接在画面上看到检测框。部署方式以 Docker 为主下面是简化后的 docker compose 示例字段需要按你的实际环境和官方最新文档调整version: 3.9 services: frigate: container_name: frigate restart: unless-stopped image: ghcr.io/blakeblackshear/frigate:stable shm_size: 64mb devices: - /dev/bus/usb:/dev/bus/usb volumes: - ./config.yml:/config/config.yml - ./storage:/media/frigate ports: - 8971:5000 environment: FRIGATE_RTSP_PASSWORD: change_me这段配置里./config.yml是挂载进来的主配置./storage是事件录像存储目录。ports把容器内的 5000 端口映射到宿主机的 8971访问时用浏览器打开http://服务器IP:8971即可。config.yml 的核心内容大概是这个结构不同版本的字段会有差异具体以官方文档为准mqtt: enabled: false detectors: detector: type: cpu num_threads: 2 cameras: front_gate: ffmpeg: inputs: - path: rtsp://username:password192.168.1.64:554/Streaming/Channels/101 roles: - detect - record detect: width: 1280 height: 720 fps: 5 objects: track: - person - car snapshots: retain: default: 3启动服务后建议按下面的步骤验证执行docker compose up -d启动容器。查看日志确认摄像头拉流成功docker logs -f frigate。浏览器打开 Web 界面看实时画面是否正常。让人走进画面观察检测框是否在人员身上出现。到 Events 页面查看事件快照是否生成。确认事件里能区分 person 和 car 两类目标。如果画面没有检测框优先检查三件事RTSP 地址是否能在 VLC 里正常播放、detect 分辨率是否过高导致解码太慢、objects.track是否包含人员类别。这里要说明一下CPU 检测模式下延迟会明显高于 GPU。一路 720p 视频、每秒 5 帧检测CPU 占用可能就相当可观了。如果有多路摄像头或检测的帧率要求更高考虑给 Frigate 配置 GPU 检测器或者改用后面的 Python 自建方案把推理参数精细化控制。6. 方案 BPython YOLO 自建轻量检测服务如果你需要更多定制逻辑或者在特定场景下要控制模型大小和检测精度自建检测服务是更灵活的路子。最简单的实现是 Python OpenCV 拉流 YOLO 模型推理。先安装依赖pip install ultralytics opencv-python模型权重文件需要通过官方渠道下载放在本地目录写代码时按本地路径加载。下面是一段可以跑通的检测服务框架核心逻辑是读取 RTSP 流抽帧后用 YOLO 检测输出结果并保存告警快照。import cv2 from ultralytics import YOLO # 从本地加载权重文件避免每次启动联网下载 model YOLO(yolov8n.pt) RTSP_URL rtsp://username:password192.168.1.64:554/Streaming/Channels/102 cap cv2.VideoCapture(RTSP_URL) if not cap.isOpened(): print(RTSP 拉流失败请检查网络和摄像头路径) exit(1) frame_interval 2 # 每 2 帧检测一次 frame_count 0 while True: ret, frame cap.read() if not ret: print(断流尝试重连...) cap.release() cap cv2.VideoCapture(RTSP_URL) continue frame_count 1 if frame_count % frame_interval ! 0: continue results model(frame, verboseFalse) for det in results[0].boxes: cls_id int(det.cls[0]) conf float(det.conf[0]) label model.names[cls_id] # 只关心 person 类别且置信度超过阈值 if label person and conf 0.5: cv2.imwrite(falert_{label}_{conf:.2f}.jpg, frame) print(f检测到人员置信度: {conf:.2f})这段代码能跑通基本检测但它只是把每一帧的检测结果打印和保存距离“自动看着”还差一步需要结合区域判断和告警推送一起用。区域入侵是弱电监控最常见的需求。比如只允许某块区域在特定时间有人其他时间一旦出现人员就告警。下面是射线法判断点是否在多边形内的函数可以直接用摄像头画面坐标做配置def point_in_polygon(x, y, polygon): 射线法判断点是否在多边形内 n len(polygon) inside False j n - 1 for i in range(n): xi, yi polygon[i] xj, yj polygon[j] if ((yi y) ! (yj y)) and (x (xj - xi) * (y - yi) / (yj - yi) xi): inside not inside j i return inside把这些逻辑组合起来就可以在检测到人员目标后再判断目标中心点是否落在禁止区域内。如果落入了禁止区域再触发下一节的告警机制。调试阶段建议在画面上把多边形的边框画出来方便校准坐标。实际项目中摄像头安装角度、透视形变都会影响多边形准确度至少要调试一两次才能稳定。7. 告警通知与批量任务本地 AI 监控的核心价值是把事件推出来否则它只是另一个没人看的 NVR。最简单的做法是发送到钉钉或企业微信的自定义机器人这里给一个钉钉机器人调用的通用示例。先在自己的钉钉群添加自定义机器人拿到 Webhook 地址再写推送函数import requests def send_dingtalk(webhook_url, text): payload { msgtype: text, text: {content: text} } # 注意真实调用需要加上安全设置要求的签名参数 response requests.post(webhook_url, jsonpayload, timeout10) if response.status_code 200: result response.json() if result.get(errcode) 0: print(告警推送成功) else: print(推送失败:, result) else: print(HTTP 错误:, response.status_code)接入了 Webhook 之后可以把前面检测代码里的保存截图逻辑扩展为发送告警消息消息文本里附带时间、摄像头名称、目标类别和置信度。钉钉机器人可以直接发送 Markdown 文本但不建议把图片体积做得太大截图先压缩到 300KB 以下推送成功率会更高。告警推送必须加冷却机制否则一辆汽车经过的画面里连续 20 帧识别出人就会推 20 条消息。这也是弱电项目上线后最容易被人质疑的地方。用一个简单的冷却类来控制import time class AlertCooldown: def __init__(self, seconds30): self.seconds seconds self.last_alert_time 0 def should_alert(self): now time.time() if now - self.last_alert_time self.seconds: self.last_alert_time now return True return False cooldown AlertCooldown(seconds30)批量处理多路摄像头时可以使用线程池实现并行拉流和检测。摄像头数量不多的情况下线程模型比进程模型更省资源import concurrent.futures def process_camera(camera_config): rtsp_url camera_config[rtsp] cap cv2.VideoCapture(rtsp_url) while True: ret, frame cap.read() if not ret: print(f{camera_config[name]} 断流尝试重连) cap.release() cap cv2.VideoCapture(rtsp_url) continue # 推理逻辑... # 告警逻辑... cameras [ {name: front_gate, rtsp: rtsp://...}, {name: back_yard, rtsp: rtsp://...}, ] with concurrent.futures.ThreadPoolExecutor(max_workers4) as executor: executor.map(process_camera, cameras)多路并发时最需要注意的是推理资源竞争。使用 GPU 推理时并发数过大容易把显存打满甚至导致 CUDA OOM。建议先从一路开始跑观测 GPU 利用率和显存占用再逐步增加并发路数。自定义服务如果要和其他系统对接建议用 FastAPI 包一层 HTTP 接口把“触发检测”和“查询事件记录”暴露出来。比如在检测到事件后把事件信息写入本地数据库再通过接口让第三方平台查询这样就能和现有的弱电集成平台、运维大屏或者工单系统联动起来。8. 资源占用与性能观察本地 AI 监控上线前至少要用一套数据回答四个问题推理延迟能控制在多少、显存或 CPU 占用是否稳定、单台设备能处理几路摄像头、误报率能不能接受。先看显存。使用 NVIDIA GPU 时推荐用以下命令实时观察nvidia-smi如果 GPU 版本较新也可以使用nvidia-smi dmon持续刷新显存、温度、利用率。自建 Python 服务的进程显存占用会随着模型加载和视频推理逐渐稳定如果持续增长要排查是否存在内存或显存泄漏。CPU 推理时可以使用top、htop或者glances观察进程占用。CPU 推理的特点是占用率波动明显抽帧间隔越长越省资源但检测漏报率也会随之上升。性能优化可以从几个方向入手降低抽帧频率。从每秒 5 帧降到每秒 2 帧CPU 占用能降一半以上对人员移动检测影响并不大。降低推理分辨率。YOLO 默认输入 640x640很多场景用 416x416 就够检测人员了。换更小的模型。yolov8n 比 yolov8s 更快精度低一点但对大多数人员检测场景足够。使用 GPU 半精度推理。在自建服务里设置model YOLO(yolov8n.pt).half()前提是 GPU 支持半精度。关于“AI 监控服务本身也要监控”这个话题也值得多说一句。弱电工程部署完一套 AI 监控之后还需要知道这个服务是否存活、摄像头是否在拉流、推理进程是否卡死。可选的方案是把服务状态暴露成一个 Prometheus metrics 接口然后接入现有的 Prometheus Grafana 监控体系这样 AI 监控服务就和机房里的其他设备一样可观测了。对于嵌入式环境或边缘盒子也可以直接把服务日志写入文件由计划任务定期检查心跳文件时间戳。实际业务中摄像头夜间断流是最容易出现的性能问题。很多低端摄像头在长时间运行后RTSP 连接会异常断开检测服务如果没有重连机制就会从某一刻开始静默失效。这个坑在测试阶段很难发现建议在代码里增加断线重连和心跳上报摄像头断流超过 30 秒就主动告警提醒运维人员。9. 常见问题与排查方法问题现象可能原因排查方式解决方案RTSP 拉流失败地址格式不对、账号密码错误、摄像头不在同一网段用 VLC 或 FFmpeg 测试拉流地址按摄像头厂家文档核对路径检查网络和防火墙拉流正常但没有检测框detect 分辨率过高、模型未配置人员类别、推理间隔过长查看检测日志和画面预览降低 detect 分辨率确认 objects.track 有 person推理速度很慢CPU 推理、帧率设置过高、输入分辨率过大观察 CPU 占用和检测耗时抽帧降频、缩小输入尺寸、换更小的模型或 GPUCUDA GPU 不识别驱动版本过低、CUDA 环境错误、容器未传设备运行 nvidia-smi 验证驱动重装驱动确认容器配置里有设备映射告警通知没收到Webhook 地址错误、无冷却机制被限流、网络不通手动调用 Webhook URL 测试检查签名参数和机器人安全设置加日志重试频繁重复告警连续多帧命中事件、无冷却机制、检测区域过宽查看告警日志时间戳增加冷却时间缩小检测区域摄像头凌晨断流设备固件不稳定、网络供电波动、RTSP 连接数超限检查摄像头在线状态和日志增加断线重连调整设备供电和固件事件录像占用空间大录像保留时间过长、画质码率过高统计每日录像增长量缩短保留周期使用子码流做检测录像容器启动失败端口冲突、配置语法错误、镜像拉取失败查看 docker compose 日志换端口、修正配置缩进、更换镜像源人员检测效果差摄像头角度太高、目标太小、逆光查看告警截图调整摄像头角度结合现场光线做针对性调优排查时不要只看代码层面。很多弱电现场的摄像头是 PoE 供电线路老化或交换机供电不足会导致设备间歇性重启这种问题在告警数据里表现为“凌晨一段时间完全没有检测事件”但摄像头又显示在线。遇到这种场景先检查交换机和 PoE 供电状态比反复调模型参数更有效。10. 最佳实践与使用建议本地 AI 监控上线建议遵循下面这些实践原则能少走不少弯路。第一先做 PoC再谈规模。用一台摄像头、一台测试主机跑通“检测到人 - 生成截图 - 推送报警 - 手动复核”完整链路再决定是否扩展到几十路。第一套系统暴露的问题往往不是 AI 模型精度而是摄像头码流不一致、网络带宽不足、告警打扰等工程问题。第二模型权重、输入素材、输出结果分目录管理。项目目录建议按照models、samples、outputs、logs划分这样在排查告警质量、回看截图和清理磁盘时都方便。批量任务要加任务日志记录每个摄像头每次告警的事件时间、截图路径和推送结果出了问题才能回溯。第三告警阈值要按现场真实样本调优。训练用数据是通用的现场画面会有自己特有的干扰比如反光、强光、树枝晃动、动物经过。上线第一周积累真实截图逐一分析误报原因再决定是缩小检测区域、降低置信度阈值还是增加连续帧确认。第四内网访问要有边界。Web 管理界面和 API 接口不要直接暴露到公网。弱电项目里很多 AI 监控服务部署在客户内网远程访问通常通过厂商的服务转发或内网穿透方案这类方案的安全性取决于你的服务是否有强密码和访问控制。稳妥的做法是绑定内网地址启动比如127.0.0.1或内网固定 IP再通过专用网关做权限管理。第五合规记录要做完整。部署点位、检测范围、告警截图留存周期、数据访问权限都要写成一份简单的文档存档。尤其是涉及园区、办公场所的项目提前和甲方确认合规要求避免后续纠纷。第六系统本身要可持续维护。摄像头固件和 AI 服务依赖会不定期更新更新前先在测试环境跑一遍避免升级后原有配置失效。如果用了 Docker 部署锁定镜像版本不要每次都拉取latest否则某次升级可能造成服务不可用。11. 总结与下一步这次把本地 AI 监控从痛点分析到落地路径做了一次完整梳理。如果是从弱电集成角度进入这个方向先用一台办公室摄像头跑通 Frigate体验一下“自动检测 事件录像”是什么感觉。如果项目里有夜间周界、区域入侵、行为检测这类定制化需求再尝试 Python YOLO 自建服务把检测区域、告警冷却和 Webhook 推送串起来。最值得先验证的三个场景分别是夜间人员检测、区域入侵报警、告警去重降噪。这三个点验证通过了一套基础的本地 AI 监控系统就能承担替代人肉盯屏的工作。最容易踩的坑会在上线第一周集中出现摄像头码流格式不一致、推理间隔太长导致漏报、告警太频繁被值班人员直接关掉通知。别想着一次部署就完美预留一周做现场调优比任何参数都更重要。后面可以继续扩展的方向包括接入更多摄像头并做性能压测、把告警事件接入工单系统、用 Grafana 对 AI 服务本身做监控、在边缘盒子或 NAS 上部署轻量版本。先从最小可运行方案开始再逐步完善这套思路对弱电人对 AI 监控的落地应该会有实际帮助。