聊到第七篇我先把之前几篇的进度简单对一下方便没看过前面内容的朋友接上这一路从给 RK3588 刷系统、装 RKNN-Toolkit2到把 YOLOv5s 导出 ONNX 再转成 RKNN 格式的模型再到写 C 和 Python 两套推理 Demo、验证 NPU 单帧性能和精度链路基本跑通了。但那会儿推理程序只能算能跑离能用还很远——没有对外接口没有摄像头输入模型跑得再快也只是个 demo。这篇记录的就是最后一步把推理塞进一个真正的服务层里接上摄像头让 YOLOv5s 在 RK3588 上变成一个能实时出检测结果的完整应用外加那个让我折腾了整整两天、最后查明白时哭笑不得的坑。1. 服务层方案定型为什么我没有一上来就写死一个 WebSocket很多人在 RK3588 这类板子上做部署第一步想到的就是开个 HTTP 服务POST 一张图进去返回检测框。我也这么试了但真要把它当产品用的时候问题马上就来了。1.1 先理清楚服务层到底要承担什么我的目标不是跑通 demo而是让板子上的检测能力可以被其他设备调用。具体的调用方有三个局域网里的一台电脑往板子提交一张图片拿回检测结果离线分析网页前端实时显示摄像头直播画面并在画面上叠加检测框可视化监控另一个边缘设备通过标准接口拿检测结果做联动比如检测到人之后触发报警。这三种场景的通信模式完全不同。图片提交是典型的请求-响应一次调用一次返回网页端实时画面是持续的视频流后端需要主动把画面推给前端设备联动则要求延迟足够低、接口足够简单。如果我只做一个 HTTP POST 接口网页端的实时画面就得靠前端不断轮询拉流延迟高、浪费带宽不说帧率根本起不来。如果我只做 WebSocket纯图片提交的调用方又得自己维护连接状态对临时工具来说太繁琐了。折中的方案最省心HTTP 接口处理一次性请求WebSocket 处理持续推流两者共用同一个推理核心。1.2 接口设计一次性请求和长连接并存最终的服务层骨架长这样RK3588 YOLOv5s 服务层 ├── HTTP POST /detect // 上传单张图片返回检测框 JSON ├── HTTP GET /status // 返回 NPU 温度、推理帧率、连接数等状态 ├── WebSocket /stream // 推流带检测框标注的视频帧 └── 后端推理核心 // 线程池 队列统一管理摄像头采集和模型推理/detect的请求体是二进制图片返回 JSON格式类似{ success: true, detections: [ { class: person, confidence: 0.87, bbox: [120, 45, 268, 310] } ], inference_ms: 18.5 }/stream走 WebSocket后端把每一帧压缩成 JPEG 之后通过二进制帧推给前端。为什么推 JPEG 而不是原始 YUV 或者 BMPRK3588 的 NPU 推理输出之后画完检测框的原图是一张 BGR 图直接转 JPEG 再推带宽大概是 720p 一帧 60~120KB质量系数 80 左右千兆局域网下 50ms 一张完全没压力。要是推原始数据一帧 720p BGR 就是 921600×3 字节约 2.7MB前端几乎没法实时渲染。服务层用 C 写还是 Python 写我犹豫了很久。最终选择了 C 一个轻量 HTTP 库理由有两个第一RKNN Runtime 的 C API 调用开销比 Python 的 rknnlite 更可控省掉 pybind 和 GIL 的干扰第二板上跑摄像头的 GStreamer 管道、硬件解码调用C 接口更顺手。推理核心用 C 写死HTTP/WebSocket 部分用现成的库解决整个工程结构非常清晰。1.3 线程模型不要让采集和推理互相等服务层跑起来之后最容易出现的性能陷阱是线程模型设计得不对。我见过有人把摄像头采集和推理放在同一个循环里先读一帧再推理再推流结果帧率被推理耗时卡死。RK3588 的 NPU 推理 640×640 的 YOLOv5s 大约 15~25ms取决于 NPU 频率和模型量化的位数如果采集也串行那整条链路每帧至少要消耗采集耗时 推理耗时。正确做法是生产者-消费者模型采集线程生产者只负责从摄像头或 RTSP 拿帧塞进一个有界队列推理线程消费者从队列取帧送 NPU 推理画框然后把帧放进出帧队列推流线程从出帧队列取已标注的帧压缩成 JPEG通过 WebSocket 发出去。队列长度要有限制否则摄像头跑 30fps、推理只能跑 20fps队列会越积越长延迟越来越大。我实测下来输入队列深度 3 就够了——队列满时直接丢弃最旧帧保证推理永远处理最新数据。2. 摄像头接入从物理连接到数据格式对齐摄像头接入这部分有意思因为 RK3588 接摄像头有两条完全不同的路线各自的坑也完全不同。2.1 本地 MIPI/USB 摄像头一路踩过去的配置过程先说我最早用的方案USB 摄像头直连板子。RK3588 的 USB 3.0 接口带宽完全足够UVC 协议也是 Linux 原生支持理论上插上就能用。实际操作确实顺利lsusb能看到设备v4l2-ctl --list-devices也能列出/dev/video0。但一跑采集就发现两个问题第一便宜的 USB 摄像头输出格式默认是 YUYV不是板子 VPU 和 NPU 友好的 NV12 或 BGR转换得当心第二设备节点是自动分配的如果同时插两个摄像头/dev/video0和/dev/video1的对应关系不固定服务稳定之后一旦重启可能就换位了。针对第一个问题我的解决方案是在采集层统一转成 NV12再直接送 VPU 硬解/硬编。RK3588 的 VPUVideo Processing Unit支持 NV12 的硬件转换比 CPU 内存拷贝快得多。中间涉及的具体命令是这样的# 查看设备支持的像素格式 v4l2-ctl -d /dev/video0 --list-formats-ext # 设置像素格式为 NV12分辨率 1280x720帧率 30 v4l2-ctl -d /dev/video0 --set-fmt-videowidth1280,height720,pixelformatNV12 v4l2-ctl -d /dev/video0 --set-parm30第二个问题我用 udev 规则解决按摄像头的物理 USB 端口号固定设备节点名。写一个/etc/udev/rules.d/99-camera.rulesSUBSYSTEMvideo4linux, ATTRS{product}Camera, KERNELS1-1, SYMLINKcam_front SUBSYSTEMvideo4linux, ATTRS{product}Camera, KERNELS1-2, SYMLINKcam_rear重启之后代码里直接打/dev/cam_front就行再也不用担心设备漂移。2.2 RTSP 网络摄像头延迟和取流的平衡用到 RTSP 网络摄像头是因为有个场景需要把海康的 IPC 摄像头接入检测链路。RK3588 有千兆网口走 RTSP 取流很自然。但这里有第一个坑直接拿 OpenCV 的cv::VideoCapture去拉 RTSP 流虽然能出画面延迟和稳定性都一言难尽。OpenCV 的 RTSP 后端用的是 FFmpeg 的基础封装遇到网络抖动会缓冲堆积延迟能到两三秒以上对实时检测来说基本不可用。我换成了 GStreamer 管道取流这是 RK3588 板载解码最优雅的路径。核心 pipeline 长这样gst-launch-1.0 rtspsrc locationrtsp://user:pass192.168.1.64:554/Streaming/Channels/101 \ latency100 ! rtph264depay ! h264parse ! mpph264dec ! video/x-raw,formatNV12 ! \ fakesink注意几个关键参数latency100把 GStreamer 内部的缓冲延迟压到 100ms默认值 2000ms不改就别想实时mpph264dec用的瑞芯微 MPP 硬解码器走 VPU 解码 H.264CPU 占用极低formatNV12硬解码输出直接是 NV12后续送给 RKNN 的输入预处理省一步转换。拿到 NV12 帧之后我做了两手准备如果后续要显示/推流NV12 直接送 MPP 硬编码成 H.264 推流全链路硬件加速如果要送 YOLOv5s 推理NV12 需要先转成 RGB 再归一化到 0~1 的 float 张量。这里有一个特别容易踩的细节YOLOv5s 训练时的输入是 RGB 还是 BGR不同的模型导出方式预处理的通道顺序完全不同。我用 ONNX 导出时写死了 RGB 顺序所以推理前必须把摄像头帧从 NV12 转成 RGB。NV12 的 Y 分量在前UV 分量交错在后转 RGB 时色度分量要从 2×2 的像素块里采样。这一步千万别自己手写转换直接调 MPP 的mpi_pp或者用 RKNPU 的rknn_init自带的RKNN_IMG_NV12输入格式让 NPU 驱动内部做转换。我第一次自己手写了 NV12→BGR 的转换忘记 UV 分量的行序是隔行存储的导致推理结果出来之后检测框全部往上偏移半个身位精度惨不忍睹。2.3 主码流还是子码流选错就是白折腾接海康摄像头时还遇到一个问题RTSP 地址里Streaming/Channels/101是主码流102是子码流。主码流分辨率 2560×1440帧率 25带宽 4~8Mbps子码流分辨率 704×576帧率 12带宽几百 kbps。这个选择对 RK3588 的部署影响很大。很多人觉得检测肯定用主码流分辨率越高越准但主码流 2K 分辨率对 YOLOv5s 来说有两个问题第一VPU 硬解码 2K H.264 不是问题但往上送 NPU 之前还要缩放成 640×640缩放这一步如果用 CPU 做那 2K 图缩到 640 的耗时大约 5~8ms抵得上一次推理的三分之一第二网络带宽和磁盘占用都是子码流的十倍往上如果只是做检测告警子码流完全够用。我最终的配置是检测输入用子码流704×576足够识别行人车辆同时保留主码流 RTSP 地址作为预览拉流。检测线程跑子码流丢帧率极低延迟稳定在 100ms 上下。3. 折腾最久的坑第一帧推理耗时 40 秒服务彻底假死这一节是重头戏。标题里写的那个折腾最久的坑就是它服务层跑起来之后摄像头画面正常WebSocket 推流正常但一旦有客户端请求推理整个进程就像卡死一样第一帧结果要等 40 秒以上才出来然后后续帧又恢复正常。如果你只跑一次推理 demo你根本不会遇到这个问题只有把它做成服务层、暴露接口之后才会炸出来。3.1 表面现象请求一进来整机就像被掐住脖子复现步骤很简单启动服务/detect提交一张图阻塞 38~45 秒后才返回检测结果等返回之后连续提交第二、第三张图每张 18ms 左右速度正常重启服务重复第一步又变成 40 秒如果在等待第一个请求时再发第二个请求两个请求全部卡住直到第一个完成。最迷惑人的地方在于第二帧完全正常所以一开始我根本没往模型初始化方向想还以为是服务层代码里写了什么隐式同步锁。3.2 排查链路一:从服务代码里找锁我先怀疑是线程模型有死锁。推理线程等待队列条件变量推流线程又在等出帧队列互相等死。我把线程模型简化到极致去掉摄像头去掉推流只保留一个 HTTP 请求线程直接同步调用推理函数。问题依旧第一次调用推理函数要 40 秒。这就排除了线程并发问题问题一定出在推理函数本身——准确地说出在rknn_run的首次调用上。3.3 排查链路二怀疑是 NPU 变频和 DDR 带宽调度RK3588 的 NPU 频率是可变的默认驱动的调频策略是按需。我猜第一帧是不是因为 NPU 从最低频往上爬升导致首次推理特别慢。这个猜测看起来很有道理因为 RK3588 的 NPU 频率范围是 300MHz~1GHz如果首帧时 NPU 停在 300MHz推理 40 秒也说得过去。于是我手动锁了 NPU 频率到最高档echo 1000000000 /sys/class/devfreq/fdab0000.npu/userspace/request_frequency echo userspace /sys/class/devfreq/fdab0000.npu/governor实测结果第一帧从 40 秒降到了 9 秒。注意确实降了但还有 9 秒这对一个 15ms 就能完成的推理来说依然是不可接受的。但这也给了我一个重要线索NPU 变频是影响因素之一但不是全部。3.4 排查链路三rknn_run 之前有没有隐藏的系统调用我打开了 RKNN Runtime 的 debug 日志。RKNN Toolkit 的 C API 支持通过设置环境变量打开内部日志export RKNN_LOG_LEVEL3重新跑服务第一帧推理期间打印出了大量日志。我终于看到关键信息了日志里有malloc大量申请物理连续内存、mmap映射 NPU 内存空间、以及一段之前没见过的load_weight之类的操作。看到这里我反应过来了——第一次rknn_run之前RKNN Runtime 其实在做模型的懒加载初始化包括把模型的权重从磁盘加载进内存、在 NPU 里分配中间张量的缓冲区、建立算子执行计划。RKNN Runtime 的初始化时机默认是在第一次推理时触发而不是在rknn_init创建上下文时。这意味着模型文件多大、网络结构多复杂首次推理的额外耗时就有多大。YOLOv5s 的 RKNN 模型权重文件接近 50MB加载、解析、分配内存加上 NPU 从低频爬升综合下来就是几十秒。3.5 解决方案把热身放到服务启动阶段找到根因之后解决方案非常朴素服务启动时在后台线程里跑一次空推理把 RKNN Runtime 的初始化预热完成。这样对外提供服务时第一次请求直接走正常的 15ms 推理路径。实际的预热代码很简单在服务初始化完成后、开始监听端口之前选一张纯黑或纯灰的 640×640 图像跑一次完整的rknn_inputs_setrknn_runrknn_get_outputs。这一步通常需要 5~10 秒但被放到了服务启动流程里对调用方透明。我甚至写了一个读第一帧摄像头画面做预热的版本理由是摄像头画面比纯色图更接近真实推理场景能让 NPU 的缓存命中更准确但实测和纯色图差别不大。这里是一个值得所有人记住的结论RK3588 上跑 RKNN 模型别只测连续推理帧率一定要测冷启动首帧耗时。如果你的应用启动后第一个推理请求恰好是用户触发的那几十秒的卡顿会让用户觉得板子死机了。更合理的设计是把预热作为服务生命周期的一部分让服务 ready比你实际开始接流晚那么几秒。3.6 这个坑的深层原因RKNN Runtime 的初始化被设计成惰性的为什么 RKNN Runtime 不把初始化放到rknn_init里一次做完而是拖到第一次rknn_run我的理解是rknn_init只做了上下文创建和模型文件加载 NPU 内存分配、算子调优这类开销较大的操作被设计成惰性执行是出于省内存的考虑——如果初始化阶段就把所有中间缓冲区分配好那一个进程同时加载多个模型时内存占用会飙升。这种惰性设计对加载模型后不一定立刻推理的场景友好但代价就是初次推理延迟爆炸。想明白这一点之后我也顺手查了一下是否有官方 API 可以强制立即初始化。结果发现确实有在rknn_init之后调用一次rknn_query查询模型输入输出属性可以在一定程度上触发模型加载流程但并不能完全替代一次完整的rknn_run。最稳妥的还是没有技术含量的预热一帧。3.7 附赠的第二个坑预热线程和正式推理线程不能共用同一个 rknn_context预热阶段我踩了个小坑差点让我误判成预热不生效。我最初的设计是在业务线程池启动之前在主线程里直接调用推理函数做预热然后业务请求来了之后也调用同一个推理函数。看起来没问题但有一个隐藏雷区RKNN 的rknn_context并不是完全线程安全的多个线程同时往同一个 context 里提交推理请求需要外部加锁。如果预热完成之后业务线程带着锁来调用推理那没问题。但我当时的代码里预热的推理函数和业务的推理函数走的是同一条路径但业务侧额外套了一个互斥锁而预热侧的锁没套——结果是预热推理还没跑完业务请求已经进来抢 context 了两个线程搅在一起预热就等于白做。正确的做法是二选一要么预热和业务都走同一把锁要么预热用一个独立的rknn_context初始化完就丢。我最终选了前者在 RKNN 推理类内部统一用std::mutex串行化所有推理调用预热和业务请求一视同仁。反正 NPU 本身是单任务执行的串行化不影响吞吐只是把多个请求排成队列。4. 接上摄像头之后的性能账:帧率、延迟和资源占用坑填完了服务也跑通了最后说说性能账。很多人问RK3588 跑 YOLOv5s 到底能到多少帧这个问题的标准答案永远是取决于你的摄像头、解码链路和服务层开销量但给一个实测参考还是有意义的。4.1 我的实测数据我的测试环境RK3588 标准开发板8GB 内存版本NPU 频率锁定 1GHz系统 Ubuntu 20.04摄像头用的是海康子码流 RTSP704×576/25fps同时保留一路 USB 摄像头1280×720/30fps做对比。链路配置推理耗时640×640端到端延迟采集到输出CPU 占用USB 摄像头 NV12→RGB NPU18~22ms约 70ms25%RTSP 子码流 VPU 硬解 NPU18~22ms约 110ms15%RTSP 主码流 VPU 硬解 NPU18~22ms约 160ms20%多路 RTSP2 路并发每路 18~22ms约 180ms45%注意端到端延迟里包含了网络取流、解码、推理、画框、JPEG 压缩和 WebSocket 推流的全链路110ms 对实时监控场景已经算非常好用了。CPU 占用 15% 的核心原因是 H.264 解码和 JPEG 编码都走了 VPU 的硬件加速如果这两步全部用 CPU 软解软编CPU 占用直接翻三倍。4.2 NPU 和 VPU 真的不打架吗一个常说的问题NPU 推理和 VPU 解码/编码同时跑会不会争抢资源实测下来两者共享 DDR 带宽但独立计算单元在 4K 解码 720p 编码 NPU 推理同时跑的重负载下DDR 带宽会成为瓶颈帧率会掉 10~20%但没有出现死锁或长时间卡顿。如果你的应用需要极致性能注意控制总体视频路数不要太贪心。4.3 一个容易忽略的优化JPEG 质量系数推流给前端时JPEG 质量系数我一开始设 95一帧 720p JPEG 能到 300KB千兆网卡虽然扛得住但浏览器解码和 WebSocket 传输都有额外延迟。后来调成 80肉眼几乎看不出画框视频的质量差异但每帧体积减到 80~120KB传输时间缩短一半。这个优化零成本但很多人根本不会去调。5. 多路并发和模型热切换部署到产品级必须考虑的两件事服务层和摄像头跑通之后我继续往产品化方向推了两步多路并发和模型热切换。5.1 多路摄像头的资源调度多路摄像头同时检测最朴素的方案是每路一个推理线程各自持有独立的rknn_context。但 RK3588 的 NPU 单次只能跑一个推理任务多 context 并不能提升并行度反而增加了内存开销。我用的是单 context 请求队列的方案N 路摄像头共享一个推理线程采集线程把帧扔进队列推理线程按帧到达顺序处理检测结果再按摄像头 ID 回写。实测两路 576p 流每路推理耗时还是 18~22ms只是推理总吞吐量被 NPU 单核算力限制住了。如果 N 路同时有强实时需求唯一的出路是把部分路数切到 CPU 上的 RKNN 模型RK3588 支持 NPU 和 CPU 混合推理或者降低输入分辨率。具体降多少得看你把模型轻量化到什么程度——这也是很多人在 RK3588 上部署 YOLOv8 时一直在做模型剪枝和蒸馏的原因目标就是把单帧推理时间从 20ms 压到 10ms 以内腾出算力给多路。5.2 模型热切换别在生产环境做我还尝试过在服务运行中直接换模型比如白天用 YOLOv5s 检测人车晚上换成另一个专门检测动物闯入的模型。理想状态是通过接口切换不用重启服务。实际做下来发现RKNN 的 context 加载新模型后旧模型的内存不会完全释放反复切换几次内存碎片化严重能稳定涨十几 MB。我最终放弃了热切换改成启动时同时加载两个 context运行时通过同一个推理线程按需选 context 执行。这个方案稳定代价是内存多占一份但对 8GB 内存的 RK3588 来说完全不是问题。6. 最后想说的:部署和开发是两种完全不同的活把 RK3588 上 YOLOv5s 的部署链路完整走一遍之后我最大的感受是模型训练和模型部署中间隔着的不是一条线而是一整片沼泽。训练时你关注 mAP、过拟合、数据增强部署时你关心的是内存对齐、线程锁、NPU 冷启动、驱动行为、摄像头格式转换。每个环节单独拎出来都不难但串起来之后任何一个隐性坑都会让你怀疑人生。那个冷启动 40 秒的坑我把排查过程写出来其实是希望大家记住一个方法论当服务出现第一次调用异常慢、后续正常的现象优先怀疑延迟初始化和惰性分配而不是先冲进业务逻辑里找锁。这个直觉帮我省了很多时间也希望对你下次排查边缘设备上的服务问题有点启发。我把完整工程代码放到了我的代码仓库里服务层、摄像头接入、预热逻辑都在。如果你也在 RK3588 上折腾 YOLOv5s 或者 YOLOv8 部署卡在某个环节了欢迎来交流——特别是如果你遇到过比冷启动 40 秒更离谱的坑记得来说说我很好奇还有什么更刁钻的问题在等着。
