做边缘端人员检测很多人的第一反应是直接上大算力平台但真正落到项目里成本、功耗、安装位置、散热条件每一项都会卡你一下。瑞芯微 RV1126B 配合 EASY EAI 这套板卡平台是我在智能摄像头和边缘盒子场景里绕不开的一个选择。它本身就是一颗面向智能视觉产品的 SoC内部集成了 CPU、NPU、ISP 和视频编解码单元人员检测这种典型的 AI 任务可以直接在设备端跑完不需要把所有视频流都搬到服务器。这篇文章会把从方案选型、模型取舍、RKNN 模型转换到板端推理调优的完整路径整理出来。内容基本都是可以直接“抄作业”的实操细节包括我多次调测中踩过的坑和验证过的参数配置。适合正在做边缘端人员检测/区域人数统计/电子围栏等需求的开发者也适合刚拿到开发板还不知道怎么把模型跑上 NPU 的同学。1. 为什么是 RV1126B边缘端人员检测的算力与成本平衡1.1 这颗芯片不是通吃型但目标场景很精准RV1126B 属于瑞芯微的智能视觉 SoC 系列在芯片设计上就是冲着 IPC网络摄像机、智能门禁、视频分析盒子这一类产品去的。它最值得注意的地方不是 CPU 本身有多强而是在一颗芯片里同时集成了 NPU、ISP 和硬件编码器。这意味着人员检测这个任务基本上可以闭环在单芯片上完成摄像头 Sensor 进来图像ISP 负责画质处理NPU 跑检测模型CPU 跑后处理和业务逻辑最后编码器还可以直接把视频流推出去。这颗芯片的 NPU 算力大致在 2 TOPS 级别INT8。这个数字放在手机 SoC 或者带独立 GPU 的计算平台面前确实不够看但在安防、楼宇、零售这类场景里2 TOPS 恰恰是性价比最舒服的一档。一颗芯片几十元级别整板功耗可以控制在几瓦无风扇也能压住温度部署环境要求低这些都是做批量产品时非常敏感的指标。相比之下带高性能 GPU 的通用计算平台虽然算力几十 TOPS但价格、功耗、体积都会让项目经理眉头一皱。人员检测模型本质上是检测类模型里最成熟的一类用轻量化模型加 INT8 量化在 2 TOPS 算力上完全可以跑出可用的帧率。所以我的结论比较明确如果你要做的是“人形检测 区域计数 简单跟踪”这一层业务RV1126B 这一类平台比大算力平台更贴近真实交付需求。1.2 一套方案能解决哪些“人”的问题基于这块板子做人员检测项目里通常可以衍生出一串功能室内外的人形识别、指定区域的人数统计、电子围栏触发报警、单人离岗/在岗检测、通行方向判断、门店热区分析等。核心都是“先找人再叠加业务逻辑”。我从实际落地角度做一个简单划分人形检测模型输出人体框和置信度这是基础能力目标跟踪加上简单的 IoU 跟踪或客户端跟踪算法可以实现计数和轨迹不需要很大的算力开销业务判定比如检测到人后判断是否进入某个 ROI 区域或者持续 5 秒无人时触发告警这些用 CPU 做完全够用端侧录像/推流RV1126B 自带编码器可以把检测画面叠加框线后编码存储。这套方案的直接价值就是“数据不出端”。视频流在设备端完成分析只上传结构化结果或告警消息网络带宽压力和隐私合规压力都会小很多。这在园区监控、门店管理、工地安全等场景里是非常现实的需求也是我最终选择它而不是把视频全传后台的原因。2. 硬件平台与开发环境搭建2.1 EASY EAI 平台和配套模块EASY EAI RV1126B 开发板是我用的这套硬件载体它的设计思路就是面向算法验证和产品原型快速打样。板卡整体比较规整核心是 RV1126B 主控常见的配置会带几十到上百毫秒级启动的存储方案外设上基本把项目里需要的接口都留出来了MIPI CSI 摄像头接口、千兆/百兆网口、USB、串口、TF 卡槽等等。实际使用中我建议先把摄像头和网络接口确认好。MIPI 摄像头最好选板卡适配过的型号驱动和设备树已经配好了插上就能出图省去很多调驱动的麻烦。如果是 USB 摄像头虽然也能用但有些型号对 ISP 通道的适配不完整画质和帧率会打折扣。做人员检测这种强依赖图像质量的任务我更推荐优先用 MIPI 接口的 Sensor。电源部分要特别留意。板卡标称功耗不高但接上摄像头、WiFi 模块、编码推流同时跑的时候瞬时电流会拉高最好是选一个电流裕量充足的电源适配器别用一个输出刚好卡在边缘的充电器凑合。我见过好几个“推理一会儿就死机”的案例最后查下来都是供电不稳。2.2 开发工具链和板端连接RV1126B 的模型转换主要依赖瑞芯微的 RKNN-Toolkit2 工具链。这个工具链在 PC 上完成模型转换、量化、仿真在板端则通过 RKNN Runtime 加载运行。开发机上建议用 Ubuntu 20.04/22.04 这类成熟系统Python 环境单独建一个虚拟环境避免和日常开发库互相污染。安装 RKNN-Toolkit2 直接通过 pip 装pip install rknn-toolkit2版本匹配是个容易出问题的地方。PC 端 RKNN-Toolkit2 的版本和板端 RKNN Runtime 的版本必须保持兼容否则会出现“模型加载失败”“算子不支持”之类的报错。我的习惯是每拿到一套新板卡先查一下官方文档里推荐的对应版本组合再固定版本号安装而不是无脑升级最新版。板端连接一般就是 ADB 或串口。ADB 方便传模型文件和跑 Python 脚本串口则适合看内核日志和调试启动问题。初次上手时我会先把板卡系统刷好然后单独跑一个最简单的 classify 示例确认 NPU 驱动和 Runtime 都能正常工作再开始折腾模型。3. 人员检测模型选型与数据准备3.1 模型不是越大越好适配 NPU 才是关键RV1126B 的算力决定了模型选型只能是轻量化路线。很多人一上来就在 PC 上放了 YOLOv8x 的权重转换完才发现 NPU 推理一帧要好几百毫秒根本没法用。这个坑我踩过一次之后就养成了“先定帧率指标再选模型”的习惯。我做过一组对比在相同数据集和量化配置下不同模型在 RV1126B 上的表现差异很大模型输入分辨率INT8量化后典型耗时NPU推理整体链路表现适用判断YOLOv5s640x640约 90-110ms帧率偏低后处理压力大不太建议除非只做低帧率抓拍YOLOv5n640x640约 45-60ms帧率可到 20fps 上下优先推荐YOLOv8n640x640约 50-65ms帧率和精度均衡可尝试注意转换兼容性轻量化专用检测头416x416约 25-35ms帧率较高适合室内近距离场景表格里的数据是实测参考值不是绝对的但趋势非常明显模型参数量的微小增加在 NPU 上会放大成很大的耗时差异。所以我给大多数项目的建议是先用 YOLOv5n 或同级别的轻量模型跑通全流程确认业务效果再考虑是否换更重的模型。人员检测用 COCO 预训练的权重通常可以直接起步。COCO 里有 person 这个类别你可以加载权重后只保留 person 类做 fine-tune或者干脆先用原权重做验证跑通部署链路再针对场景数据迭代。3.2 数据准备决定了后面 80% 的调试工作量模型转换前的数据质量直接决定 INT8 量化后模型精度能不能看。我的做法是先把目标场景的数据收集起来至少覆盖这几类情况不同光照白天强光、黄昏逆光、夜间红外模式不同距离远处小人、近处半身像、镜头边缘被裁切的人不同姿态站立、蹲下、弯腰、人群中部分遮挡不同视角平视、俯视很多室内场景的摄像头是高处俯视安装。公开数据集可以做底座但一定要从目标场景里抽一批真实图像出来。我见过一个项目用纯公开数据训练检测效果在演示视频里挺好一装到现场就大量漏检原因是现场摄像头安装角度偏高人物在画面中偏小而且有大量俯视角度。后来补了几天现场数据重新训练和量化误检漏检才明显降下来。标注层面有一点容易被忽略人员检测并不需要标注得特别精细但边界框的一致性很重要。如果同一个人的框一会儿紧贴身体一会儿包含大量背景模型学出来的框回归逻辑会很混乱量化后更容易掉点。标注时尽量统一标准框住人体的可见部分头部和脚部边缘适度留一点余量。4. 模型转换与 RKNN 部署全流程4.1 从 PyTorch/ONNX 到 RKNN 的转换细节模型选好之后第一步是把训练框架里的模型导出成 ONNX再用 RKNN-Toolkit2 转换成 RKNN 格式。整个流程的核心就是一段 Python 脚本from rknn.api import RKNN rknn RKNN(verboseTrue) # 配置目标平台和预处理参数 rknn.config( target_platformrv1126b, mean_values[[0, 0, 0]], std_values[[255, 255, 255]], optimization_level3 ) # 加载 ONNX 模型 rknn.load_onnx(modelyolov5n.onnx) # 构建 RKNN 模型do_quantization 开启 INT8 量化 rknn.build(do_quantizationTrue, datasetdataset.txt) # 导出 rknn.export_rknn(yolov5n.rknn)这段脚本里有几个关键点值得单独说第一mean_values 和 std_values 必须和训练时的预处理保持一致。YOLO 系列大多数训练时是把图像 BGR 读入归一化到 0~1那么 config 里 mean 填 0、std 填 255 通常是对的。如果训练时用了自定义的归一化参数这里也要跟着改不然推理结果干脆是乱的。第二dataset.txt 里每行是量化用的参考图片路径。它只用来统计激活值的分布范围不需要把训练集全部放进去但一定要“有代表性”。我强调的是把夜间红外图、逆光图、不同亮度下的图都放进去。量化校准图片太少会让 INT8 模型在局部场景掉点严重。第三如果整体 INT8 量化精度掉得太多RKNN-Toolkit2 还支持混合量化也就是只量化模型里敏感度低的部分敏感算子保留浮点。这个策略我后面会详细展开。转换完成后可以直接用 PC 端仿真接口验证模型的输出确认没有转换层面的错误再推送到板端。4.2 板端推理代码与输出解析板端推理有两种主流方式一种是 Python 层面的 RKNNLite一种是 C API。做原型验证时用 Python 很快from rknnlite.api import RKNNLite rknn RKNNLite() rknn.load_rknn(yolov5n.rknn) rknn.init_runtime() # 输入图像需为模型要求的尺寸和格式 outputs rknn.inference(inputs[img]) # 解析 outputs得到检测框Python 接口的优点是快速验证缺点是推理后处理如果也用 Python 写帧率会被拖垮。YOLO 类模型的原始输出是三组不同尺度的特征图需要做 decode、confidence 过滤和 NMS。这些操作如果在 Python 的 numpy 循环里跑一帧轻轻松松几十毫秒比 NPU 推理还慢。更高效的做法是用 C 写后处理或者把 NMS 前的 decode 逻辑放到板端 C/C 程序里再或者直接从模型输出层截断把多尺度输出在板端拼接处理。C API 的调用流程大概是rknn_init(); rknn_inputs_set(); rknn_run(); rknn_outputs_get(); rknn_destroy();在实际项目里我会把输入图像处理缩放、letterbox、通道转换放在 CPU 上并行执行NPU 在处理上一帧的推理时CPU 同时处理下一帧的图像预处理这种流水线结构能让整体吞吐量提升非常明显单纯死盯 NPU 单帧耗时意义不大。5. 性能调优与实测结果5.1 影响帧率的不是只有 NPU很多人在板子上跑通模型之后第一反应就是“怎么这么慢”然后开始怀疑 NPU 性能。实际上我在优化人员检测方案时发现帧率瓶颈经常出现在三个地方第一是图像预处理。从摄像头取到的原始图通常是 1080p 甚至更高分辨率需要缩放到 640x640还要做 letterbox 保持宽高比。这个操作如果逐像素在 Python 里做耗时巨大用板卡硬件缩放或者优化过的 C 代码可以压到几毫秒内。第二是后处理。YOLO 的输出层有大量候选框如果直接在 Python 里做双重循环帧率直接腰斩。解决思路是先用置信度阈值把明显无用的框过滤掉再进入 NMS框数量会少很多计算量呈平方级下降。第三是线程模型。板端推理我通常会开三个线程采集线程只负责取帧推理线程只负责调用 RKNN 接口后处理线程只跑解析逻辑线程之间用环形队列交换数据。这样做的好处是即使某一帧后处理突然变慢也不会阻塞采集和推理整体帧率更稳定。5.2 一组有代表性的实测表现我自己在 EASY EAI RV1126B 上做过一组配置对比前提是MIPI 摄像头输入模型为 YOLOv5nCOCO person 类权重直接转换不做额外 fine-tune。配置输入分辨率NPU推理耗时整链路帧率备注Python后处理640x640约 50ms8-10fps后处理拖累严重C后处理640x640约 50ms17-20fps流水线优化后稳定C后处理416x416约 30ms30fps小目标能力下降从表格能明显看出来单看 NPU 推理时间340 和 640 差距并不夸张但整链路帧率的提升更多来自后处理和流水线优化。所以在追帧率之前我强烈建议先写好一个“耗时打点”逻辑把采集、缩放、推理、后处理每个阶段的时间都打印出来找到真正的大头再动手优化。需要说明的是这些数字受板卡散热、系统负载、摄像头型号影响不同批次可能有波动但“后处理必须用 C 优化”“流水线能显著提帧率”这两条结论在 RV1126B 上几乎不会变。6. 常见问题排查与实用避坑清单6.1 高频问题速查表在实际调测过程中我整理了一份出现频率极高的问题速查表遇到问题时可以先对照排查现象常见原因处理建议板上推理输出全为 0 或乱码预处理 mean/std 与训练不一致复现训练时的归一化方式检测框位置偏移letterbox 的填充方式与训练不一致统一使用相同的缩放逻辑INT8 量化后精度掉得厉害校准图片代表性不足补充夜视、逆光、俯视样本模型转 RKNN 报不支持的算子模型版本与 RKNN 工具链不匹配升级 ONNX 导出方式或更换模型推理一段时间后变慢或死机散热不足或电源功率不够加强散热更换电源适配器帧率波动大后处理没有分离线程改成生产者-消费者流水线多个模型/多次推理时崩溃RKNN 并发访问冲突对推理调用加锁或单例化6.2 我踩过的几个比较值得说的坑第一个坑是关于量化校准集的。有一版模型在 PC 仿真时精度看起来正常装到板上检测夜间人形时频繁漏检。排查了很久最后才发现 dataset.txt 里放的全是白天光线充足的图夜间红外图的激活分布和白天差异太大INT8 量化后夜间特征被压没了。从那以后我的 dataset.txt 一定会按场景比例混合图片而且每加一类新场景都会重新跑一遍量化。第二个坑是锚框设置。有一段时间我为了提高小目标召回率手工修改了模型里的锚框尺寸但只在推理端改了参数没有重新训练。结果模型输出分布和锚框完全不匹配检测框大量重叠轻微调阈值就疯狂误检。锚框不是可以“调一下试试”的参数它本质上是从训练数据分布里统计出来的改它之前先确认要不要重训。第三个坑是后处理优化时机。我最初用 Python 后处理直接跑完了整个流程花了很长时间优化 Python 代码效果一般。后来改成 C 后处理后发现之前几个月的“优化”其实都是弯路的C 版本一上手帧率就翻倍了。这类板子的算力天花板很低性能敏感的代码从一开始就别用解释型语言硬扛早做 C 扩展早省时间。最后再分享一个小细节RV1126B 这类带 AI ISP 的芯片夜间红外模式下图像噪声明显增加人员检测的精度常常比白天差不少。如果项目里有夜间的场景务必把夜间图像提前放进训练和量化环节而不是最后上线了才发现白天光鲜、晚上失效。这个小操作能给你省下后面大量的误报排查时间。