1. 先交代一下这个安全帽检测项目为什么非要在端侧做1.1 项目现场的真实情况网络、摄像头、报警闭环我接到这个需求的时候第一反应其实跟大多数人一样安全帽检测这种识别任务库里随便找个开源模型接到 GPU 服务器上跑不就行了真正到项目现场转了一圈之后我才发现这个思路在工地上根本走不通。现场的情况是这样的一个在建园区分了三个施工标段每标段少则四五路、多则十几路摄像头分布在出入口、塔吊底部、钢筋加工棚、临边防护区域这些位置。摄像头倒是不缺但全部是普通的网络摄像头大部分通过工地自建的临时局域网汇聚到一台 NVR 上再通过一条很一般的上行链路接到外部。真正的痛点不在能不能识别而在识别结果怎么闭环。安全帽检测的最终应用不是出一张截图给人看而是要联动现场的音柱做语音提醒或者在值班室的大屏上弹报警记录。这意味着从摄像头取流、到检测、到输出告警整个链路必须在几秒内走完否则工人早就走过去了提醒也就没有任何意义。把视频推到云端再拉回结果或者等人工去翻录像这两个方案在时间上都不可接受。1.2 云端方案算完三笔账之后被否了当时我其实先正经评估过一条云端路线所有摄像头通过 RTSP 推流到云服务器在云上用 GPU 实例跑检测检测结果通过接口回传。技术上行得通但算完账就有点犹豫了我又结合现场实际条件逐条对了一下最后彻底放弃。第一笔账是带宽。一路 1080P 的 H.264 主码流平稳场景下码率 2~4Mbps遇到风吹草动或者傍晚画面噪点增多能到 5Mbps 往上。就算只取其中 10 路做主检测上行也需要 30Mbps 以上的稳定带宽。但工地现场的网络不是写字楼的专线高峰期对讲机、门禁、视频回传都在抢带宽实际稳定性根本没法保证。而且我们当时不止一个工地每个工地都要这么搞专线费用直接变成一笔固定成本。第二笔账是时延。视频从现场推到云端经过编码、传输、解码、检测再返回结果理想状态下也要 1~2 秒。这里还没算网络抖动和排队。对安全帽检测这个场景来说告警的价值就在那几秒内超过 3 秒基本就是无效信息。更麻烦的是现场音柱联动如果依赖云端回转断网或者网络波动时整个系统就哑了。第三笔账是数据合规。很多企业现在对视频数据外传非常敏感摄像头画面跨越园区边界本身就需要审批流程有些项目甚至明确要求视频不能出工地。这其实是个很现实的限制很多时候它不是技术问题而是管理问题。1.3 端侧部署的核心矛盾算力有限但必须实时云端方案被否掉之后端侧部署就成了唯一选项。但端侧也有端侧的难处没有数据中心那种几乎无限的算力池没有成熟的 GPU 生态甚至没有宽松的功耗条件——很多项目现场只有普通 220V 插座不能像机房一样搞一个高功耗主机。所以我当时给自己设定了几条硬指标单台设备要能同时处理至少 4 路 1080P 视频流从取流到告警输出端到端时延要控制在 1 秒以内设备功耗控制在 20W 以内方便放在弱电箱或者立杆机箱里设备必须支持 Web 管理界面方便现场运维人员做简单的配置和重启。这几条指标把很多方案挡在门外了。第一轮筛选之后我手里实际上只有三条路线Jetson 系列、树莓派加边缘算力卡、以及 RK3588 平台。它们各有各的取舍后面我会详细展开我的对比过程。2. 硬件选型对比我在 Jetson、树莓派和 RK3588 之间怎么选的2.1 一开始的候选清单和筛选逻辑很多人选边缘硬件容易犯一个毛病只看一个指标比如谁 NPU 算力高就选谁或者谁的生态资料多就选谁。这种做法在个人项目上问题不大但放到一个要走交付流程的项目里很容易在中后期翻车。我的候选清单如下Jetson Orin NX 系列、树莓派 5外接算力卡、RK3588 平台。三条路线的核心参数差异我整理在下表方便对照看。评估维度Jetson Orin NX 16GB树莓派 5 算力卡RK3588 平台标称算力100 TOPS稀疏算力口径NPU 算力由外接卡决定6 TOPS INT8编解码能力支持 H.265/H.264 硬编解码仅 H.264/H.265 硬解性能一般支持 8K30/4K120 解码H.264/H.265 硬编解CPU 核心8 核 A78AE4 核 A764×A76 4×A55典型功耗10~25W5~8W不含算力卡8~15W开发资料很全社区体量大多但算力卡部分碎片化原厂工具链完整社区资料略少采购周期波动大部分型号供货紧现货为主现货充足国产供应链这里先说明一下TOPS 这个数字不能直接横向比各家统计口径不一样有的算稀疏、有的算稠密标称算力和实际跑模型的速度之间差了十万八千里。真正有效的对比方式只有一个拿你的模型在对应平台上分别跑一遍看延迟和帧率。2.2 Jetson 的顾虑生态香但周期和散热劝退Jetson 系列我其实很熟因为它的软件生态确实是这几条路线里最完整的。CUDA 那套东西在 Jetson 上基本是即插即用PyTorch 模型可以很平滑地迁移过去社区里踩坑记录也多遇到问题基本搜得到答案。如果这个项目只做一台演示样机我大概率会选 Jetson。但到了实际交付环节有几个问题绕不过去。首先是供货周期和价格。当时项目排期比较紧而 Jetson Orin NX 模块的采购周期明显拉长价格也跟着水涨船高还要搭配定制载板。对于每工地放 2~3 台盒子这种批量需求来说这个成本不是小数。其次是散热和封装。Jetson Orin NX 的功耗虽然不高但它是高频高密度设计满载时发热集中被动散热机箱需要仔细设计风道主动风扇则要考虑现场粉尘环境下的可靠性。工地粉尘有多大就不用我形容了风扇积灰之后噪音、过热、降频是早晚的事。相比之下RK3588 这种面向工规、商规场景的 ARM SoC整体热密度要低不少一个铝制被动散热壳就能压住。2.3 树莓派是无 NPU 平台编解码和推理抢资源树莓派 5 刚出的时候我特意测过一次它的 CPU 性能确实比前代提升明显跑一些轻量级逻辑非常够用。但安全帽检测需要的是解码 推理 绘制 推流这个完整的视频处理管线树莓派在这条链路里有两个硬伤。硬伤之一是它是无 NPU 平台。纯靠 CPU 跑 YOLOv5s 这种模型640×640 输入在全核满载的情况下也就跑到 5~10FPS而且这时候 CPU 已经被推理吃干了解码、绘制、叠加文字这些操作全部排队等资源。我实测过一旦开始做 H.264 硬解和画面缩放帧率会进一步掉到 3~5FPS这个水平做实时检测太勉强。硬伤之二是外接算力卡的软件栈割裂。树莓派本身是通用 Linux 生态外接算力卡通常要走私有 SDK模型转换工具链和主流的深度学习框架之间往往需要很多手工适配。做 demo 可以做产品就要承担很多额外开发量。而且算力卡同样面临散热、供电、机械固定的问题等于把一套本来可以紧凑集成的方案拆成了两台设备。2.4 RK3588 的 NPUMPPRGA 组合刚好卡在需求甜点上RK3588 进入视野是在我对比完前两条路线之后。它给我的第一印象是规格很全4 个 A76 大核 4 个 A55 小核6 TOPS NPU自带 8K 解码能力和 4K 编码能力还集成了 RGA 图形加速单元。这些东西分开看每个都不算惊艳但组合在一起几乎就是视频分析盒子需要的完整拼图。最关键的是RK3588 的解码、缩放、推理这三件事是由三个独立硬件单元完成的MPP 负责视频硬解码RGA 负责图像缩放和格式转换NPU 负责模型推理。三者并行工作的时候互不抢占 CPU主 CPU 只负责调度和业务逻辑。我用单路 1080P 视频流做预处理基线测试时MPP 解码几乎不占 A76 核心RGA 做 NV12 到 RGB 的转换和缩放也非常快这给后续业务逻辑留下了充足的运算余量。如果你的场景只有一到两路视频算力要求很低那其实随便哪个平台都行选 RK3588 反而浪费。但当多路取流 实时检测 本地闭环这几个条件同时成立时RK3588 的这种异构加速架构几乎就是为这个场景准备的。3. 从 PyTorch 到 RKNN模型转换过程的真实坑3.1 版本组合必须先对齐工具链版本、runtime 和驱动硬件定了之后我以为模型部署会很快训练一个 YOLOv5s导出 ONNX转换 RKNN上板跑通完事。实际做下来第一步就折腾了我一个下午。RK3588 的 NPU 推理需要把 ONNX 或者 PyTorch 模型转换成 RKNN 格式这套工具链叫 RKNN-Toolkit2。它有两种使用方式一种是在 x86 主机上用 Python 跑转换和模拟推理另一种是直接在板子上用 RKNN-Lite 跑推理。问题在于主机端的 RKNN-Toolkit2 版本、板端的 RKNN runtime 版本、NPU 驱动版本这三者必须严格对齐版本不匹配的话转换出来的模型可能上板直接加载失败甚至出现莫名其妙的精度下降。我当时就吃了版本不对齐的亏主机端用的 RKNN-Toolkit2 版本比较新但板端刷的系统镜像里自带的 runtime 驱动还是旧版结果模型转换时 API 报了一个很隐晦的版本不支持错误排查了很久。后来我总结出一个规矩先确认板端系统镜像里 runtime 的版本再到原厂发布页找对应的 Toolkit2 版本而不是反过来用最新版工具链去迁就旧板子。3.2 量化要用现场数据而非通用图片RKNN 转换里有个容易忽略但又非常影响结果的参数量化数据集。INT8 量化需要一个校准数据集用来统计每层 activation 的数值范围然后决定怎么把浮点权重压缩到 8bit。很多人图省事直接用验证集里随便挑几十张图就过一遍这样出来的模型在测试视频上表现很差。我的做法是从现场采集的样本里抽取 200 张左右图片作为量化集覆盖白天、傍晚、夜间红外、阴天、雨天各个时段。因为工地场景的视觉分布和通用数据集差别很大——安全帽颜色鲜艳、背景有大片灰扑扑的混凝土、夜间有红外补光带来的高噪点画面——如果量化集不能代表这些分布模型在端侧的表现就会和训练时严重脱节。量化之后一定要先做精度对比。我在同样的测试集上对比过 FP32 模型和 INT8 量化模型的 mAP 结果掉点在 2~3 个点是正常的属于可接受范围如果某个类别掉点超过 5 个点那就是量化集选得有问题或者某个层对量化特别敏感。3.3 算子兼容性问题一个 Decode 层让精度掉 4 个点的排查模型转换过程中遇到的最典型的坑是一个后处理算子的兼容性问题。我用的是 YOLOv5s 6.2 版本模型自带 Detect 头导出 ONNX 后里面有一些把预测结果解码成坐标的算子。RKNN 工具链对这部分算子的支持是分版本的旧版本工具链在转换时会发生部分算子被降级到 CPU 执行的情况或者被替换成精度损失较大的实现。我第一次转换完量化后的模型在测试集上精度比 FP32 掉了将近 4 个点。tools 自带的模拟推理看起来正常但上板实测 loss 大得离谱。排查过程很枯燥先把模型里各个层逐个去掉来定位敏感层然后在 GitHub 的 issue 里翻到一条关于 Detect 层解码算子兼容性的讨论这才意识到是工具链版本的问题。解决方式有两种一是升级 RKNN-Toolkit2 到支持该算子的版本二是把模型改写成只保留主干 检测头输出 raw 预测把 decode 和 NMS 挪到 NPU 之外用普通 C 代码在 CPU 上做。我选了第二种——从工程角度看后处理放在 CPU 上更安全以后换模型结构也不用再担心工具链的算子支持度问题。这个决定在后面调模型的时候帮了大忙。3.4 后处理放 NPU 还是 CPU我的选择关于后处理放哪里的问题简单说下我的体会。NPU 理论上可以跑完整的模型包括一部分后处理但现实是它的算子支持列表有限有些高效实现比如特定版本的 NMS、某些动态 shape 的 gather 操作转换不了强行转换会让模型超过预期 size 或者变慢。我最终把 NMS 和坐标解码都做在了吃 CPU 的一侧。640×640 输入、单路视频流每帧检测结果里的目标数量不会太多这部分计算量完全可以忽略。最直观的好处是训练团队后来换模型结构、调置信度阈值、改类别过滤逻辑都只需要重新生成 .rknn 文件和调整推理代码里的参数不用再跟工具链的兼容性问题纠缠。4. 视频管线搭建解码、缩放、推理之间的排队问题4.1 MPP 硬解码 RGA 预处理别让 CPU 干图像处理的活模型搞定之后新的问题又冒出来了怎么把摄像头视频流高效地送进 NPU如果沿用通用的 OpenCV 方案用 cv::VideoCapture 拉 RTSP 流再 imread 取帧在 RK3588 上会非常浪费——CPU 做软解不仅占用大量 A76 核心还会让整个设备在 4 路并发时直接卡顿。正确的做法是走 RK3588 的 MPP 硬解码接口让它用硬件解码器把视频码流解成 NV12 格式的图像帧。MPP 对 H.264/H.265 码流的兼容性很好RTSP 取流的职责交给 FFmpeg 的 avformat 层拿到编码后的 AVPacket 再喂给 MPP 硬解。解码出来的 NV12 帧还不能直接喂给 NPU。我的模型输入是 RGB 格式、640×640 分辨率而摄像头原始帧是 1080P 的 NV12。这一步如果直接写代码逐像素转换CPU 占用率会直接飙上去。RK3588 自带的 RGA 模块可以一次性完成裁剪/缩放 NV12 到 RGB 的格式转换RGA 本身是硬件加速做这一组操作对 CPU 几乎零负担。我建议的取流链路是FFmpeg 负责解协议拿 packetsMPP 负责硬件解码RGA 负责预处理的缩放和颜色转换NPU 只拿干净的标准 RGB 帧做推理。这条链路里没有任何一步需要 CPU 深度参与像素计算多路视频并发时 CPU 才能腾出手来做业务逻辑和告警推送。4.2 双线程队列设计采集和推理解耦用有界队列兜底视频管线搭起来之后下一个问题是架构上的取流、解码、推理这几个环节是串行执行还是并行处理如果每帧都取流 - 解码 - 推理串行处理任何一环出现瞬时抖动整个管线都会被拖慢最终结果是帧率忽高忽低时延像过山车。我用的方案是标准的双线程结构采集线程负责取流和解码把解码后的图像帧放入一个有界队列推理线程从队列里取帧做缩放、推理、后处理然后推送结果。两个线程之间通过一个带互斥锁的队列通信队列容量固定为 4~6 帧。这个设计的最关键点是有界两个字。队列满的时候采集线程必须主动丢帧——永远不能让采集线程无限阻塞等待队列腾出空间否则输入侧压力会传导到输出侧。// 伪代码有界队列的消费者逻辑 void InferenceThread() { while (running) { Frame* frame queue.Pop(); // 队列为空时阻塞等待 if (frame nullptr) continue; cv::Mat rgb RgaConvert(frame); // RGA 硬件转换 auto dets rknn_run(rgb); // NPU 推理 ProcessDetections(dets); // 告警判断 推流叠加 queue.Recycle(frame); // 回收帧内存 } }这里还有一个容易被忽略的细节帧内存要复用。不要在每一轮循环里重新分配 cv::Mat 内存频繁的 malloc/free 会让内存碎片越来越严重跑几个小时之后设备开始变慢。我是预先申请了一个帧缓冲池采集线程从缓冲池取空帧、推理线程用完归还整个运行过程中内存分配次数非常少。4.3 抽帧策略全帧检测反而拉高时延跳帧更稳最开始我自然是来一帧测一帧全帧也不卡但一旦视频路数增加到 4 路以上推理线程的负载就会明显上来。后来我冷静想了一下安全帽检测真的需要每秒 25 帧的检测频率吗工人进入镜头到走到警戒区域这个过程至少持续几秒。检测频率只需要保证人在画面里出现过、且被抓拍到了若干帧就够了。实测下来每 3 帧取 1 帧做检测也就是在 25FPS 视频流里做到约 8FPS 的检测频率对安全帽这种运动速度很慢的目标来说完全足够。重要的是跳帧不能只是数到第几帧丢多少帧那么机械最好加一个时间戳判断。如果没有时间戳当视频源帧率波动时跳帧后的实际检测频率会不稳定。我的做法是采集线程每拿到一帧就检查当前时间距离上一次送入队列超过 120ms 才允许入队这样检测频率会稳定在 8FPS 左右。这里有一个反直觉的结论全帧检测在实时性上不如跳帧检测。其原因在于推理线程的处理速度是固定的当输入帧积压到队列里排长队时每帧从入队到被推理的时间拉长最终系统的输出延迟反而变大。适度丢帧让队列保持低水位才能保证最新一帧被及时处理。这也是我在这个项目里学到的很实用的一课。4.4 全链路实测数据CPU、NPU、时延、帧率经过一番调整我在一台被动散热的 RK3588 盒子上跑通了完整流程用 4 路 1080P 视频流实测了下数据。项目全帧检测25FPS跳帧检测约 8FPSCPU 占用率55~70%35~45%NPU 占用率60~75%45~55%单帧推理耗时20~30ms20~30ms端到端时延从摄像头画面到告警输出约 800ms 以上约 300~400ms漏检率无明显差异无明显差异偶发帧乱序/卡顿有基本没有之前纯 CPU OpenCV 软解软编方案单路 1080P 时 CPU 已经跑到 90% 以上帧率还上不去切到 MPP 硬解 RGA NPU 之后4 路并发时 CPU 还有大量余量去做告警推送和 Web 服务这就是异构加速组合带来的直接收益。端到端时延从 800ms 降到三四百毫秒听音柱联动报警的时候差异非常明显。5. 精度和误报的二次调优工地环境比数据集复杂得多5.1 逆光、夜视、灰尘数据增强要做现场数据采样模型在测试集上跑得很好不代表在现场就能跑好。工地的光照环境是真的恶劣白天大太阳底下工人戴安全帽逆光的时候安全帽整个变成一团黑傍晚光线不足时摄像头自动切换红外夜视画面变成低饱和度的灰绿色还有雨天水雾、扬尘天气画面就像蒙了一层纱。我处理这些问题的思路是不要自己闷头想数据增强直接去现场采集真正会出现的画面段。我在不同时间段、不同天气条件下分别录制了每个摄像头视角的视频片段从中抽帧补进训练集。针对逆光问题我加了对整图做暗角、降对比度、曝光偏移的增强操作针对红外夜视画面我单独做了一组灰度化 噪声抖动的增强。这一步对最终的 F1 值提升非常明显。原来模型在夜间画面下漏检率很高原因很简单——训练集里根本就没有红外画面模型没见过这种风格的图。补了现场夜视样本之后夜间检测效果一下子就正常了。如果你的项目也是这种固定机位场景最有效的数据增强不是随机裁剪翻转那些通用 Trick而是从真实现场的机位视角去采集数据。5.2 小目标30 米外的安全帽只有 15×15 像素怎么办安全帽检测一个隐性问题是小目标——在工地入口这种宽阔视野下工人离摄像头远的时候整个头部的像素高度可能只有二三十个像素安全帽本体就更小了大概 15×15 像素左右。这种尺寸的目标对 YOLOv5s 来说非常吃力。我试过两条路。一条是用更大输入尺寸的模型比如把 640×640 换成 1280×1280小目标检出率确实提升但 NPU 推理耗时几乎翻倍多路并发时扛不住。另一条是切图检测把 1080P 原图切成四块分别推理但这个方案不仅推理次数增加四倍还引入了跨块目标的拼接问题工程复杂度太高。最终我的选择是分场景处理出入口和塔吊底部这些近距离机位使用常规模型配置保证实时性开阔区域的大范围机位单独训练一个更高输入分辨率的模型且降低检测触发频率只在关键帧或 I 帧附近做一次检测。这个一台设备内加载多套模型配置的思路把算力花在刀刃上小目标漏检率降了不少同时没有牺牲整体实时性。如果你的项目也是固定机位场景建议按机位实际覆盖范围分别调整模型配置而不是一个模型通吃所有画面。5.3 误报防线人脸和黄色安全帽之间的斗争精度问题搞完之后真正让我头大的是误报。安全帽检测的误报五花八门黄色铁皮、塑料桶、反光背心都可能被认成黄色安全帽最离谱的是因为颜色太接近模型会把肤色附近的人脸区域识别成黄色安全帽。解决误报不能光靠训练还要在推理后处理上加业务级判断。我加了这么几层防线第一层是目标属性过滤。安全帽和目标检测框有位置关系头部往往在画面中呈现为检测框安全帽应该出现在头部上方区域。我把明显不在合理位置关系内的候选框直接丢弃。这个先验知识非常朴素但能把大量贴在身体两侧的误报干掉。第二层是时序稳定性。单帧的检测结果不可信但连续帧的检测结果就很可信。我给每个检测目标加了生命周期同一目标在连续 3 帧内都被检出且区域重叠度超过 60%才认为这是一个真实事件。这层逻辑实测下来把误报率降了一半以上。// 伪代码连续帧确认逻辑目标生命周期管理 if (matched_frame_count 3) { TriggerAlarm(target_id, bbox); matched_frame_count 0; // 防止重复触发 }第三层是颜色特征辅助。安全帽的 HSV 颜色分布比通用目标更集中黄色安全帽的色相、饱和度都有比较稳定的区间。我在检测框内部再做一次简单的颜色统计如果候选框内部的黄色像素占比过低就降低置信度。这一层不是用来做主要判断只是给置信度做一个参考修正。三层叠加之后误报率从最初的高频噪音降到可以接受的低水平现场值守人员也明显更信任这套系统了。6. 这次权衡最后教会我的几件事6.1 边缘 vs 云端的成本账算完再动手这次项目做下来我对边缘 vs 云端有了更具体的认知。如果单纯看一次性开发成本云端方案确实更省力——不用做硬件适配、不用处理端侧各种异常情况一套 GPU 服务器上的代码跑遍所有项目。但这个账要拉长到部署规模和运营周期来看单台边缘盒子的硬件成本对多数项目来说不到一个季度云服务器的租用费。算上带宽费用10 路视频的云端方案一年的持续成本明显高于一次性采购边缘盒子。更重要的不在于省多少钱而在于边缘方案把检测能力沉淀成了固定资产放在现场的盒子里不吃带宽、不受网络波动影响、数据不出门。对于长期运营的工地项目这种模式天然更稳。6.2 模型更新和视频管线的维护成本错位如果让我复盘整个项目的工时分配大概是这样的模型训练和调优占了三成NPU 转换和算子适配占了两成视频管线取流、解码、绘制、推流、告警联动、配置管理占了四成剩下的一成是现场联调和部署。大部分人第一反应会觉得模型是主角实际项目里视频管线的繁琐程度远远超过想象。这里有个经验供参考在项目架构上尽量让模型更新只影响 .rknn 文件 少量参数这一层把解码、绘制、推流、告警策略这些业务逻辑和模型解耦。这样算法团队后来迭代模型只需要替换文件、改一下类别配置业务逻辑完全不用动。如果一开始把后处理也塞进模型里每次模型结构变动都可能引发一遍全链路测试那工作量会让人崩溃。6.3 什么情况下我会劝你别抄这份作业最后说几句掏心窝的话。RK3588 方案并不是万能的以下情况我建议你别照搬第一如果项目现场有可靠网络、视频允许上云而且检测结果的闭环可以在云端走通那直接用云端 GPU 服务器是明智能的选择。边缘方案的硬件适配、现场调试成本不会低没必要为了边缘而边缘。第二如果算法团队坚持要用超大模型追求极致精度比如用 YOLO-X 级别甚至更大规模的模型RK3588 的 6 TOPS 算力会比较吃力。这种情况下只能考虑边缘做前置初筛、云端做精检的两级架构或者换更高算力的硬件平台。第三如果只是做一个几路视频的演示系统根本不需要考虑多路并发和长时间稳定运行那树莓派或者一台普通工控机加一个加速卡也完全能应付选择 RK3588 只会增加不必要的开发量。我最终选定 RK3588是因为这个项目的具体约束——多路并发、实时闭环、网络不稳、长期运行、成本敏感——恰好能用它的异构加速架构来满足。我的建议是先写清楚你项目的硬指标和约束条件再对照硬件参数做取舍而不是拿着一个现成方案去套需求。最后再分享一个小技巧视频分析盒子到了现场之后最怕的其实不是检测不准而是 RTSP 流断线之后整个程序挂掉。实验室里你很难模拟出摄像头掉线 5 分钟再恢复这种场景但工地现场几乎每周都会发生。从一开始就给取流模块加上断线重连、超时保护、以及整机看门狗重启机制会让你的系统在现场少挨很多骂。
