RK3588边缘视频分析平台实战：多路检测跟踪与容器化部署

1. 从一块 RK3588 开发板说起：为什么我要折腾边缘视频分析

手里攒了几块 RK3588 的开发板，从 4GB 到 16GB 内存的版本都试过。最开始的想法很简单，就是想看看这块号称"边缘计算神器"的芯片，到底能不能扛住多路视频流的实时分析。市面上很多方案要么依赖云端推理，延迟高、带宽吃紧；要么就是单路跑个 YOLO 演示，离"平台"两个字差得远。我真正想要的是一个能落地的东西：插上网线、接上摄像头，就能对多路视频做检测、跟踪、结构化，还能把结果推给上层业务系统。

这个需求听起来不复杂，但真动手做才发现坑不少。RK3588 的 NPU 算力标称 6 TOPS，可实际能跑多少路、每路能到什么帧率、内存带宽会不会成为瓶颈、编解码和推理怎么协同，这些都没有现成答案。更麻烦的是，很多开源方案要么只支持单路，要么对 RK3588 的硬件编码器利用不充分，CPU 占用高得离谱。于是我花了几个月时间，搭了一套完整的视频分析平台，从底层驱动到上层接口全部跑通，中间踩的坑、做的取舍、验证过的参数，都在下面慢慢说。

这篇文章适合两类人看：一类是手里有 RK3588 板子、想做视频分析但不知道从哪下手的开发者；另一类是在选型边缘 AI 方案、想了解真实性能边界的架构师。我会把平台的功能全景拆开讲，再把三种不同的使用方式（命令行、API、容器化）分别说清楚，最后给出一份实测数据和调优经验。所有内容都基于我实际跑过的环境，参数和结论可以直接参考。

2. 平台功能全景：一块盒子到底能扛多少活

2.1 视频接入与解码：别小看这一层

很多人做边缘视频分析，第一反应是"把 RTSP 流拉进来，解码成帧，送进模型"。听起来简单，但 RK3588 的硬件解码器（VPU）和 CPU 软解之间的差距，直接决定了你能跑几路。我实测下来，用 FFmpeg 软解 1080p@25fps 的 H.264 流，单路就要吃掉将近两个 A76 大核，四路基本就把 CPU 占满了，NPU 再强也没用。

正确做法是走 RK3588 的 MPP（Media Process Platform）硬件解码。MPP 支持 H.264/H.265 的硬解，1080p 单路解码 CPU 占用不到 5%，功耗也低。平台里我把解码层封装成独立模块，输入支持 RTSP、RTMP、本地文件、USB 摄像头（V4L2）四种源，输出统一成 NV12 格式的帧缓冲，直接给后续推理用，避免了一次颜色空间转换的开销。

这里有个细节值得说：MPP 解码出来的帧在 DMA 缓冲区里，如果直接拷到用户态再送 NPU，内存拷贝的带宽消耗会很明显。我的做法是用 RKNN 的零拷贝接口，让 NPU 直接访问 DMA 缓冲，省掉一次 memcpy。实测四路 1080p 场景下，这个优化能降低约 15% 的 CPU 占用。

2.2 推理引擎：RKNN 的脾气得摸透

RK3588 的 NPU 通过 RKNN 工具链使用。模型要先从 ONNX 或 PyTorch 转成 RKNN 格式，转换时可以选择量化方式。这里有个关键取舍：不量化（FP16）精度高但速度慢，量化成 INT8 速度快但精度会掉。我拿 YOLOv5s 做过对比，输入 640x640，FP16 单帧推理约 28ms，INT8 约 12ms，但 INT8 的 mAP 会掉 2 到 3 个百分点。

对于视频分析场景，我的建议是：检测类模型用 INT8，因为目标框的位置对量化不敏感；但如果是做属性识别（比如颜色、车型分类），建议保留 FP16，否则分类准确率下降明显。平台里我做了模型配置化，每个模型可以单独指定量化精度，运行时按需加载。

另一个坑是 NPU 的多核调度。RK3588 有 3 个 NPU 核心，RKNN 默认可能只用一个。要在初始化时显式设置core_mask，让三个核心并行跑不同路数的推理。实测三核全开比单核，多路场景下的总吞吐能提升 2.2 倍左右，但不是线性三倍，因为内存带宽会成为新瓶颈。

2.3 分析能力：检测、跟踪、结构化一条龙

平台目前集成了几类核心分析能力。第一是目标检测，支持 YOLO 系列和 SSD 系列，覆盖人、车、常见物体。第二是多目标跟踪，我用的是 ByteTrack 的轻量实现，在 NPU 上跑检测、CPU 上跑关联，1080p 下每路跟踪耗时约 3ms，基本不拖后腿。第三是区域入侵和越线检测，这块是业务侧最常用的，我用多边形区域配置，支持多个区域独立设防。

第四是属性结构化，比如人的上衣颜色、是否戴头盔，车的颜色、车型。这部分模型较小，但需要和检测框做级联，我用了简单的 ROI 裁剪加二次推理，注意裁剪时要留 10% 的边距，否则边缘目标容易漏特征。第五是视频摘要，把检测结果按时间轴聚合成结构化数据，输出 JSON 给上层。

这些能力不是全部同时开。实际部署时，我建议按业务优先级组合：如果只做入侵检测，检测加区域判断就够了，跟踪可以关掉省算力；如果要做轨迹分析，跟踪必须开，但属性结构化可以降频，比如每 5 帧做一次。

2.4 结果输出与联动：别让分析结果烂在盒子里

分析结果如果只存在本地，价值就少了一半。平台支持三种输出方式：MQTT 推送到消息队列、HTTP POST 到业务接口、本地 SQLite 存储供查询。MQTT 适合实时告警，HTTP 适合和现有系统对接，SQLite 适合事后检索。

我踩过一个坑：告警推送如果每条都发，高频场景下会把网络打满。后来加了告警抑制逻辑，同一区域同一类型的事件，在可配置的时间窗口内只推一次，窗口默认 10 秒。这个逻辑看似简单，但没它的话，一个持续入侵事件能刷出几百条告警，业务侧根本没法用。

3. 三种打开方式：从命令行到容器，按需选择

3.1 命令行方式：调试和验证的最快路径

刚拿到板子、想快速验证功能的时候，命令行是最直接的。平台提供了一个主程序，通过参数指定输入源、模型、分析类型和输出方式。比如要跑一路 RTSP 流做人员检测，命令大概是这样：

./video_analyzer \ --input rtsp://192.168.1.100:554/stream1 \ --model models/yolov5s_int8.rknn \ --task detect \ --labels configs/coco_80.txt \ --output mqtt \ --mqtt-broker tcp://192.168.1.200:1883 \ --mqtt-topic edge/detection

这种方式的好处是启动快、日志直接打在终端、参数一目了然。调试模型效果时，我会加--save-frames把带框的帧存下来，肉眼确认检测准不准。注意这个参数会写磁盘，长时间跑要记得关，否则 eMMC 很快满。

命令行方式还有个用途是压测。我会用--loop参数让同一路视频反复跑，配合top和npu-smi观察 CPU、NPU、内存的占用曲线，找出瓶颈在哪。实测下来，单路 1080p 检测加跟踪，CPU 占用约 35%（四核 A76 中的 1.5 核），NPU 占用约 40%，内存占用约 600MB，还有很大余量。

3.2 HTTP API 方式：让业务系统随时调用

命令行适合调试，但生产环境需要的是服务化。平台内置了一个轻量 HTTP 服务，基于 libmicrohttpd 实现，资源占用低，启动后监听 8080 端口。通过 RESTful 接口，可以动态添加、删除、查询分析任务，不用重启进程。

添加任务的接口是POST /api/tasks，请求体是 JSON：

{ "task_id": "gate_01", "input": "rtsp://192.168.1.101:554/stream1", "model": "yolov5s_int8", "task_type": "intrusion", "regions": [[100,200,500,200,500,600,100,600]], "output": { "type": "mqtt", "broker": "tcp://192.168.1.200:1883", "topic": "edge/alarm" } }

这个接口的设计有个考虑：task_id由调用方指定，方便业务侧做幂等。如果重复提交同一个task_id，平台会返回 409 冲突，而不是默默创建两个任务。这个细节在对接时能省很多事。

查询任务状态用GET /api/tasks/{task_id}，返回当前帧率、检测数量、运行时长。删除用DELETE /api/tasks/{task_id}。实测下来，动态增删任务时，已有任务的帧率波动不超过 5%，说明资源隔离做得还可以。

注意：HTTP 服务默认没有鉴权，生产环境一定要放在内网，或者在前面加一层反向代理做认证。我见过有人直接把端口暴露出去，结果被扫到后乱加任务，把盒子跑挂了。

3.3 容器化方式：批量部署和版本管理的正解

如果只有一两台盒子，命令行和 API 都够用。但如果是几十上百台，手动部署就是灾难。平台提供了 Docker 镜像，把运行时、模型、配置全部打包，一条docker run就能拉起。

镜像基于 Ubuntu 20.04 构建，里面预装了 RKNN 运行时、MPP 库、FFmpeg 和平台主程序。模型文件通过 volume 挂载，方便单独更新。启动命令：

docker run -d \ --name edge-analyzer \ --privileged \ -v /dev/mpp_service:/dev/mpp_service \ -v /dev/rknpu:/dev/rknpu \ -v /data/models:/app/models \ -v /data/configs:/app/configs \ -p 8080:8080 \ edge-analyzer:latest

这里--privileged是必须的，因为要访问 NPU 和 VPU 的设备节点。如果不想给特权，也可以精确挂载/dev/mpp_service和/dev/rknpu，但实测某些内核版本下权限会出问题，所以生产上我还是用特权模式，配合宿主机的安全策略控制。

容器化的另一个好处是版本回滚。新模型效果不好，直接换回旧镜像就行，不用在板子上折腾依赖。我用这个方式管理过三个版本的检测模型，切换时间不到 30 秒。

4. 实测数据与调优：那些文档不会告诉你的数字

4.1 多路并发到底能跑几路

这是被问得最多的问题。我拿 16GB 内存的 RK3588 板子做了系统测试，输入统一是 1080p@25fps 的 H.264 流，模型是 YOLOv5s INT8，任务类型是检测加跟踪。结果如下：

结论是：稳定跑 4 路 1080p 检测加跟踪没问题，8 路是极限，12 路就别想了。如果只做检测不做跟踪，8 路能稳在 22fps 左右。如果降到 720p，路数可以翻倍。

这个数据比官方标称的"16 路解码"要保守，因为官方那个数字只算解码，不算推理。实际业务里推理才是大头。

4.2 内存带宽：隐藏的瓶颈

跑 8 路的时候，我发现 NPU 占用到了 95%，但帧率还是上不去。用npu-smi看，三个核心都在忙，但每个核心的利用率只有 60% 左右。这说明瓶颈不在算力，而在数据搬运。

RK3588 的内存带宽是共享的，解码、推理、跟踪、编码都在抢。我做了个实验：把跟踪关掉，8 路帧率从 18fps 升到 22fps；再把属性结构化关掉，升到 24fps。所以如果业务允许，尽量把非必要的分析环节降频或关闭，把带宽留给检测。

另一个优化是降低帧的拷贝次数。前面提到的零拷贝接口，在 8 路场景下能提升约 10% 的帧率。还有就是把模型的输入尺寸从 640 降到 416，帧率能提升 30% 左右，但小目标的检测率会下降，这个取舍要看业务场景。

4.3 功耗与散热：别忽略物理限制

RK3588 满载功耗能到 10W 以上，如果盒子散热不好，会触发降频。我测过，不加散热片的情况下，跑 4 路 20 分钟后，CPU 频率从 2.4GHz 降到 1.8GHz，帧率掉了 15%。加了铝制散热片和一个小风扇后，连续跑 8 小时频率稳定。

如果部署环境没有风扇，建议把盒子放在通风处，或者用被动散热的大面积铝壳。另外，NPU 的功耗和路数强相关，4 路时整机约 6W，8 路时约 9W，选电源适配器要留余量，我用的 12V/2A 比较稳。

5. 踩过的坑与对应解法

5.1 模型转换后的精度骤降

第一次转 YOLOv5 到 RKNN，用 INT8 量化，结果 mAP 从 0.56 掉到 0.41，几乎不能用。排查后发现是量化校准集的问题。我一开始随便找了 100 张图做校准，里面大部分是风景，和目标场景（路口监控）差太远。后来换成从实际视频里抽的 200 帧，覆盖白天、夜晚、雨天，mAP 恢复到 0.53，只比 FP16 低 0.03。

经验：量化校准集必须来自真实业务场景，数量 200 到 500 张，要覆盖各种光照和天气。这个坑我踩了两次，第二次是换场景后忘了重新校准，又掉了一次精度。

5.2 RTSP 断流后的任务卡死

RTSP 流不稳定，断流是常事。早期版本里，断流后任务线程会阻塞在av_read_frame，整个任务卡死，也不报错。后来加了超时和重连机制：读取超时设 5 秒，超时后关闭连接，等 3 秒重连，重连失败最多重试 10 次，之后标记任务异常并上报。

这个逻辑看起来简单，但超时时间设多少有讲究。设太短，网络抖动就重连，频繁重连反而更不稳定；设太长，断流后要等很久才恢复。实测 5 秒是个比较平衡的值。

5.3 多任务下的 NPU 抢占

多个任务同时跑的时候，NPU 是共享的。早期没做调度，高优先级的任务会被低优先级的拖慢。后来我加了一个简单的优先级队列，每个任务有优先级，NPU 推理请求按优先级排队。高优先级任务（比如实时告警）的帧率波动从 ±30% 降到 ±5%。

提示：优先级不要设太多级，3 级就够了（高、中、低），级数多了调度开销反而大。

5.4 容器里的设备权限问题

用 Docker 部署时，最常见的问题是容器里访问不到 NPU。报错通常是Failed to open /dev/rknpu。原因是设备节点没挂载，或者挂载了但权限不对。解法是启动时加--privileged，或者精确挂载设备并设置--device-cgroup-rule。我试过后者，在某些内核版本下还是不行，所以最后统一用特权模式，配合宿主机的用户组控制。

6. 这套平台适合谁，以及后续还能怎么扩展

如果你手里有 RK3588 的板子，想做视频分析但不想从零造轮子，这套平台可以直接拿去用。命令行方式适合快速验证，API 方式适合对接业务系统，容器化方式适合批量部署。三种方式共用同一套底层，切换成本很低。

从实测数据看，4 路 1080p 检测加跟踪是稳定区间，8 路是极限。如果业务需要更多路，建议用多台盒子做分布式，而不是硬压单台。分布式的话，上层可以用 MQTT 做结果汇聚，平台本身不负责跨设备调度，这块留给业务侧更灵活。

后续我打算加两个东西：一是模型热更新，不重启进程就能换模型；二是更细粒度的资源监控，把每路任务的 CPU、NPU、内存占用单独统计出来，方便定位是哪一路在拖后腿。这两个需求在实际运维里挺刚需的，等做完再分享。

最后说个个人体会：边缘 AI 盒子这东西，硬件参数只是起点，真正决定能不能落地的是软件栈的成熟度。RK3588 的算力够用，但工具链的坑不少，尤其是模型转换和多媒体框架的配合。我花了大概三分之一的时间在调通链路上，剩下三分之二在调优和填坑。如果你正准备入坑，建议先把 MPP 解码和 RKNN 推理这两个基础链路跑通，再往上叠功能，会顺很多。