1. 从一块开发板到一台盒子我为什么盯上了RK3588加Jetson这套组合去年年底帮朋友的工作室做一套本地化的视觉识别方案需求说起来不复杂几路摄像头实时跑目标检测结果要能本地展示、本地存储最好还能接个大屏直接看。一开始想的是直接上一台带独显的小主机但功耗、噪音、体积这三样摆在一起放在他们那个半开放的展示区里实在不合适。后来折腾了一圈最后落到了一个思路——用一块RK3588做主控和交互再挂一个Jetson模组专门跑推理做成一个巴掌大的AI智能盒子。这个思路其实不是我想出来的是市面上已经有一批成品在这么干了。所谓AI智能盒子你可以把它理解成一台没有屏幕、没有键盘的小电脑专门用来在本地跑AI任务。它跟云端方案最大的区别在于数据不出本地延迟低断网也能用。而RK3588加Jetson这个组合之所以有意思是因为它把两件事分开了——RK3588负责系统调度、视频编解码、网络和显示这些杂活Jetson负责纯粹的AI推理。这种分工在工程上非常合理后面我会详细拆。这篇文章适合谁看如果你正在评估本地AI部署方案或者手头有一块RK3588板子想物尽其用又或者你只是好奇这类盒子到底能干什么、值不值得入手那这篇内容应该能帮你省下不少查资料的时间。我会从硬件选型的逻辑讲起到系统怎么搭、模型怎么部署、实际跑起来会遇到哪些坑尽量把我知道的都倒出来。先说结论这套组合不是万能的它有明确的适用边界。但如果你正好落在它的舒适区里它的性价比和灵活性会让你觉得这钱花得值。2. RK3588和Jetson各自擅长什么一次把分工讲透2.1 RK3588的真实定位它是个全能管家不是推理主力很多人第一次看到RK3588的参数会兴奋8核CPU4个A76加4个A55带6TOPS算力的NPU支持8K视频编解码接口丰富得像个小型工作站。参数确实漂亮但实际用起来你会发现它的NPU更适合跑一些轻量级的模型比如分类、简单检测或者作为推理流水线里的预处理环节。RK3588真正强的地方在于它的综合能力。它有三个视频输入接口可以同时接多路摄像头它的编解码单元能硬解多路1080P甚至4K视频流CPU占用还很低它的显示输出支持多屏异显接个触摸屏做交互界面毫无压力。这些能力加在一起让它天然适合做整个盒子的中枢——管理外设、处理视频流、跑操作系统、提供用户界面。我实测过一个场景RK3588同时接入两路1080P摄像头做H.264硬编码后本地存储同时跑一个轻量级的人形检测模型在NPU上CPU占用率大概在30%到40%之间。这个负载对它来说很轻松。但如果你想把一个中等规模的YOLO模型跑出高帧率它的NPU就开始吃力了帧率会掉到个位数延迟也上来了。所以我的经验是RK3588的NPU可以用来做粗筛比如先判断画面里有没有人有人的帧再送给Jetson做精细识别。这样能有效降低Jetson的负载整体功耗和发热都会好很多。2.2 Jetson的价值把推理这件事做到极致Jetson系列的核心竞争力就一个词CUDA。英伟达的软件生态在AI推理这块的成熟度目前还没有哪个平台能完全替代。不管是TensorRT的推理加速还是各种模型转换工具链的完善程度Jetson都是最省心的选择。我用的是一块Jetson Orin Nano模组算力在40TOPS左右INT8。这个算力跑YOLOv8s这种规模的模型1080P输入下能做到实时。更重要的是TensorRT对模型的优化非常成熟一个FP16的YOLOv8s模型经过TensorRT转换后推理速度能比原生PyTorch快两到三倍。但Jetson也有它的短板。它的CPU性能相对有限如果你让它同时处理视频解码、网络通信、文件存储这些任务它会顾此失彼。而且Jetson的功耗和发热比RK3588高不少需要认真考虑散热设计。这就引出了这套组合的核心逻辑让RK3588干它擅长的杂活让Jetson专心跑推理。两者通过高速接口连接RK3588把处理好的图像数据传给JetsonJetson把推理结果传回来RK3588再负责展示和存储。各司其职谁也不拖累谁。2.3 两者怎么连接口选择直接决定整体性能RK3588和Jetson之间的连接方式是整套方案里最容易被忽视但影响最大的环节。常见的连接方式有三种USB、以太网、PCIe。我逐个说下实际体验。USB连接最简单RK3588的USB 3.0接口带宽理论上是5Gbps实际传输能到400MB/s左右。对于1080P的JPEG图像一帧大概200KB到500KB这个带宽传个几十帧每秒没问题。但USB的延迟不太稳定而且占用CPU资源较多。适合对延迟不敏感、帧率要求不高的场景。以太网连接更稳定千兆网实际能跑满110MB/s左右。如果图像经过压缩这个带宽够用。而且网络连接天然支持分布式部署RK3588和Jetson甚至可以放在不同位置。缺点是延迟比PCIe高大概在几毫秒到十几毫秒之间。PCIe是最理想的方案RK3588有一路PCIe 3.0 x4理论带宽接近4GB/s。这个带宽传原始图像数据都绰绰有余延迟也最低。但PCIe连接需要两块板子物理上靠得很近对结构设计有要求。我最终选的是PCIe方案因为要做多路视频实时分析带宽和延迟都不能妥协。如果你只是做单路视频分析USB或以太网方案完全够用没必要为了PCIe去折腾结构。但如果你要做多路、高帧率、低延迟的场景PCIe是唯一的选择。3. 系统搭建从裸板到能跑起来的完整过程3.1 系统镜像的选择与烧录RK3588这边我建议直接用厂商提供的Ubuntu镜像。虽然有些发行版也支持RK3588但厂商镜像对硬件外设的驱动支持最完整尤其是视频编解码和NPU驱动这块自己折腾驱动会非常痛苦。我用的镜像基于Ubuntu 20.04内核版本是5.10NPU驱动和RKMPP视频编解码库都已经预装好了。烧录工具用瑞芯微官方的升级工具就行把镜像写到eMMC或者SD卡里。这里有个细节如果你打算用eMMC启动需要先通过MaskROM模式把引导程序写进去。具体操作是按住板子上的恢复按键再上电等工具识别到设备后松开。这个步骤第一次做可能会有点懵但按照厂商文档走一遍就清楚了。Jetson这边相对简单用英伟达官方的SDK Manager或者直接下载镜像烧录到NVMe SSD上。我强烈建议用NVMe SSD而不是SD卡因为Jetson的系统盘读写速度直接影响模型加载和日志写入的效率。SD卡的随机读写性能太差跑起来会明显感觉到卡顿。系统装好后第一件事是更新软件源和安装基础工具。RK3588这边需要额外安装librga和librknnrt这两个库它们是调用NPU和视频处理硬件的关键。Jetson这边需要确认CUDA和TensorRT的版本用nvcc --version和dpkg -l | grep tensorrt检查一下。3.2 两块板子之间的通信搭建如果用以太网连接配置最简单给两块板子各配一个同网段的静态IP然后测试ping通就行。但要注意如果RK3588同时还要连外网就需要配置双网卡路由避免默认路由冲突。我的做法是让RK3588的WiFi连外网以太网口专门用来和Jetson通信这样互不干扰。如果用PCIe连接配置会复杂一些。RK3588作为PCIe主机Jetson作为端点设备。需要在RK3588的设备树里使能PCIe控制器在Jetson那边配置端点模式。这个过程涉及设备树修改和内核模块加载第一次搞可能需要花点时间。但一旦配通后续使用就和普通网络通信一样通过PCIe上的网络接口传数据。我实际用的是PCIe转以太网的方式相当于在PCIe通道上跑了一个虚拟网络。这样既有PCIe的高带宽低延迟又保留了网络通信的灵活性。配置好之后ifconfig会多出一个网络接口给它配个IP就能直接通信了。3.3 视频流的采集与分发RK3588采集视频流的方式取决于摄像头类型。如果是USB摄像头直接用V4L2接口就能读如果是MIPI摄像头需要配置对应的驱动和设备树。我用的是一路USB摄像头加一路RTSP网络流两种方式都试过。采集到的视频流需要做两件事一是本地显示或存储二是送给Jetson做推理。这里的关键是避免数据拷贝。RK3588的RKMPP库支持硬解码和零拷贝解码后的帧可以直接映射到内存不需要在CPU和GPU之间来回搬。我用的方案是RTSP流通过RKMPP硬解解码后的NV12帧通过DMA直接送到NPU做预处理同时通过PCIe传给Jetson。传给Jetson的数据格式需要和Jetson那边的接收程序约定好。我用的是一种简单的自定义协议每帧数据前面加一个头包含帧号、时间戳、宽度、高度、格式这些信息后面跟实际的图像数据。Jetson收到后解析头部把图像数据拷贝到GPU内存然后跑推理。这里有个坑如果RK3588和Jetson之间的时钟不同步时间戳会对不上。我的做法是RK3588在发送前先和Jetson做一次NTP对时之后用单调时钟计数避免系统时间跳变导致的问题。4. 模型部署从训练到在盒子上跑起来4.1 模型选择与转换的完整链路在Jetson上部署模型标准流程是PyTorch训练 → 导出ONNX → 转TensorRT引擎。每一步都有坑我逐个说。导出ONNX的时候要注意opset版本。TensorRT对某些opset版本的支持不完整我一般用opset 11或12兼容性最好。另外动态维度dynamic axes的设置要谨慎如果输入尺寸固定就不要开动态维度否则TensorRT优化时会受限。转TensorRT引擎用trtexec工具最方便。一个典型的命令是这样的trtexec --onnxyolov8s.onnx \ --saveEngineyolov8s_fp16.engine \ --fp16 \ --workspace4096 \ --verbose--fp16开启半精度推理速度能提升不少精度损失通常在可接受范围内。--workspace指定显存工作空间大小单位是MB根据模型大小调整。如果转换过程中报显存不足就加大这个值。转换完成后用trtexec --loadEngineyolov8s_fp16.engine --shapesinput:1x3x640x640测试一下推理速度。正常情况下YOLOv8s在Orin Nano上FP16推理能跑到30FPS以上。4.2 推理服务的封装与接口设计模型转好后需要封装成一个服务接收RK3588发来的图像返回推理结果。我用Python写了一个简单的服务基于Flask框架但后来发现Flask的性能瓶颈明显换成了FastAPI加uvicorn吞吐量提升了不少。服务的设计要考虑几点一是并发处理多个请求同时进来时不能阻塞二是批处理如果RK3588发来的帧率很高可以攒几帧一起推理提高GPU利用率三是异常处理推理失败时要有降级方案不能整个服务挂掉。我的做法是用一个队列做缓冲RK3588发来的帧先入队推理线程从队列取帧攒够一批或者超时了就送GPU推理。推理结果通过另一个队列返回。这样即使某一帧推理失败也不会影响后续帧的处理。接口方面我用的是HTTP POST请求体是二进制图像数据响应是JSON格式的检测结果。虽然HTTP有额外开销但调试方便而且在实际使用中这个开销可以接受。如果对延迟要求极高可以考虑用gRPC或者直接走共享内存。4.3 RK3588端的预处理与后处理分工一个完整的推理流水线预处理和后处理占的时间往往比推理本身还长。我的分工策略是RK3588负责图像解码、缩放、颜色空间转换这些预处理Jetson只负责推理和NMS后处理。RK3588的RKMPP库做视频解码非常快1080P的H.264解码能跑到几百帧每秒。解码后的NV12数据用RGA瑞芯微的2D加速器做缩放和格式转换也是硬件加速的几乎不占CPU。处理好的RGB数据通过PCIe传给JetsonJetson直接送TensorRT推理。后处理这块NMS非极大值抑制在CPU上做就行因为检测框的数量通常不多几十个框的NMS耗时可以忽略。但如果你的模型输出特别多可以考虑用GPU做NMSTensorRT有对应的插件。实测下来把预处理放在RK3588上做整体延迟能降低30%以上。因为Jetson的CPU性能有限如果让它同时做解码和推理会明显拖慢推理速度。5. 实际跑起来之后性能、功耗与那些没预料到的问题5.1 实测性能数据与瓶颈分析整套系统跑起来后我做了几组测试。场景是两路1080P视频流一路本地摄像头一路RTSP网络流同时做目标检测。指标数值备注单路推理帧率32 FPSYOLOv8s FP16640x640输入双路推理帧率18 FPS每路共享Jetson算力端到端延迟约80ms从摄像头采集到结果返回RK3588 CPU占用约45%含解码、预处理、通信Jetson GPU占用约70%推理负载整机功耗约25W含两块板子和外设瓶颈主要在Jetson的GPU上。双路同时推理时GPU占用到70%左右帧率从单路的32FPS降到18FPS。如果要做更多路要么降低分辨率要么换更高算力的Jetson模组。另一个瓶颈是PCIe传输。虽然PCIe 3.0 x4带宽足够但实际传输效率受驱动和协议开销影响。我实测的传输速率大概在1.5GB/s左右传1080P RGB图像约6MB一帧的话理论上一秒能传200多帧实际因为协议开销和中断处理能稳定在100帧左右。对于双路18FPS的需求这个带宽绰绰有余。5.2 散热设计一个被严重低估的环节RK3588和Jetson加在一起满载功耗25W左右听起来不高但两块板子都是BGA封装热量集中在很小的面积上。如果不加散热片RK3588跑一会儿就会降频Jetson也会因为温度过高而降低算力。我的散热方案是RK3588加一块铝制散热片尺寸尽量大覆盖CPU和NPU区域Jetson加一个主动散热风扇因为它的功耗密度更高。两块板子之间留出风道用一个小风扇做整体空气流通。外壳用铝合金材质兼做散热片。实测下来室温25度时RK3588核心温度稳定在55度左右Jetson在65度左右都没有触发降频。如果去掉风扇Jetson温度会飙到80度以上推理速度明显下降。如果你打算把盒子放在封闭空间里散热设计要加倍重视。我见过有人把板子塞进一个密封的塑料盒里结果跑十分钟就卡顿拆开一看板子烫得没法摸。5.3 那些文档里不会写的坑第一个坑是电源。RK3588和Jetson对电源的要求不一样RK3588通常12V输入Jetson Orin Nano是19V。如果用一个电源同时供电需要加DC-DC转换。而且两块板子的峰值电流都不小电源的瞬态响应要好否则会出现莫名其妙的复位。我一开始用了一个便宜的电源结果Jetson跑推理时RK3588会随机重启换了电源就好了。第二个坑是USB设备的枚举顺序。RK3588上电时如果USB摄像头和USB转串口设备同时插入有时候枚举顺序会变导致程序找不到设备。解决办法是用udev规则给设备固定名称或者在程序里通过设备路径而不是设备号来打开。第三个坑是Jetson的功耗模式。Jetson默认的功耗模式可能不是最高性能模式需要手动设置。用nvpmodel命令可以切换我一般设成最大性能模式模式0虽然功耗高一点但推理速度稳定。第四个坑是时间同步。RK3588和Jetson如果各自用自己的RTC时间会有偏差。做多路视频分析时不同路的时间戳对不上融合结果就会出错。我的做法是RK3588作为NTP服务器Jetson作为客户端定期同步。6. 这套方案适合谁以及还能怎么玩6.1 适用场景与不适用场景的清晰边界这套RK3588加Jetson的组合最适合的场景是需要本地实时AI推理但对算力要求不是特别高同时对功耗、体积、成本有约束。比如小型工作室的视觉检测、零售场景的客流分析、教育场景的AI教学演示、家庭场景的智能监控。不适合的场景也很明确需要训练模型、需要超大算力比如跑大语言模型、需要极低延迟比如工业控制里的毫秒级响应。这些场景要么需要更强的GPU要么需要完全不同的架构。我个人的判断标准是如果你的模型能在Jetson Orin Nano上跑到实时且总功耗控制在30W以内那这套方案就值得考虑。如果模型跑不动或者功耗要求更宽松那直接上一台带独显的小主机可能更省事。6.2 后续可以扩展的方向这套盒子目前只做了目标检测但它的架构是通用的。换一个模型就能做姿态估计、语义分割、OCR识别。RK3588的NPU还可以跑一些轻量级的语音模型加上麦克风阵列就能做本地语音交互。另一个扩展方向是加装4G或5G模块让盒子在没有WiFi的环境下也能联网。不过要注意如果数据要上云就得考虑数据安全和隐私问题这个要根据具体场景来权衡。还有一个有意思的方向是做多盒子协同。几个盒子通过局域网连接各自处理一路视频结果汇总到一个中心节点做融合分析。这种分布式架构在大型场景里很有用比如多个出入口的客流统计。6.3 给准备入坑的朋友几条实在建议如果你打算自己搭一套我的建议是先从单路视频、单个模型跑通开始别一上来就搞多路。跑通之后再逐步加功能每加一个功能就测一下性能和稳定性。这样出问题的时候容易定位。买板子的时候优先选厂商支持好的。RK3588的板子很多但不同厂商的驱动完善程度差别很大。选那些有活跃社区、文档齐全的能省很多事。Jetson这边相对统一但要注意模组的功耗和散热设计。最后别低估结构设计的重要性。一个合理的结构能让散热、走线、接口布局都变得顺畅。我见过太多功能跑通了但装不进壳子的案例返工的成本比一开始就设计好要高得多。这套方案我前前后后折腾了大概两个月中间踩了不少坑但也积累了很多文档里找不到的经验。如果你正在做类似的事情希望这些内容能帮你少走点弯路。有问题欢迎交流我知道的都会说。
1. 从一块开发板到一台盒子我为什么盯上了RK3588加Jetson这套组合去年年底帮朋友的工作室做一套本地化的视觉识别方案需求说起来不复杂几路摄像头实时跑目标检测结果要能本地展示、本地存储最好还能接个大屏直接看。一开始想的是直接上一台带独显的小主机但功耗、噪音、体积这三样摆在一起放在他们那个半开放的展示区里实在不合适。后来折腾了一圈最后落到了一个思路——用一块RK3588做主控和交互再挂一个Jetson模组专门跑推理做成一个巴掌大的AI智能盒子。这个思路其实不是我想出来的是市面上已经有一批成品在这么干了。所谓AI智能盒子你可以把它理解成一台没有屏幕、没有键盘的小电脑专门用来在本地跑AI任务。它跟云端方案最大的区别在于数据不出本地延迟低断网也能用。而RK3588加Jetson这个组合之所以有意思是因为它把两件事分开了——RK3588负责系统调度、视频编解码、网络和显示这些杂活Jetson负责纯粹的AI推理。这种分工在工程上非常合理后面我会详细拆。这篇文章适合谁看如果你正在评估本地AI部署方案或者手头有一块RK3588板子想物尽其用又或者你只是好奇这类盒子到底能干什么、值不值得入手那这篇内容应该能帮你省下不少查资料的时间。我会从硬件选型的逻辑讲起到系统怎么搭、模型怎么部署、实际跑起来会遇到哪些坑尽量把我知道的都倒出来。先说结论这套组合不是万能的它有明确的适用边界。但如果你正好落在它的舒适区里它的性价比和灵活性会让你觉得这钱花得值。2. RK3588和Jetson各自擅长什么一次把分工讲透2.1 RK3588的真实定位它是个全能管家不是推理主力很多人第一次看到RK3588的参数会兴奋8核CPU4个A76加4个A55带6TOPS算力的NPU支持8K视频编解码接口丰富得像个小型工作站。参数确实漂亮但实际用起来你会发现它的NPU更适合跑一些轻量级的模型比如分类、简单检测或者作为推理流水线里的预处理环节。RK3588真正强的地方在于它的综合能力。它有三个视频输入接口可以同时接多路摄像头它的编解码单元能硬解多路1080P甚至4K视频流CPU占用还很低它的显示输出支持多屏异显接个触摸屏做交互界面毫无压力。这些能力加在一起让它天然适合做整个盒子的中枢——管理外设、处理视频流、跑操作系统、提供用户界面。我实测过一个场景RK3588同时接入两路1080P摄像头做H.264硬编码后本地存储同时跑一个轻量级的人形检测模型在NPU上CPU占用率大概在30%到40%之间。这个负载对它来说很轻松。但如果你想把一个中等规模的YOLO模型跑出高帧率它的NPU就开始吃力了帧率会掉到个位数延迟也上来了。所以我的经验是RK3588的NPU可以用来做粗筛比如先判断画面里有没有人有人的帧再送给Jetson做精细识别。这样能有效降低Jetson的负载整体功耗和发热都会好很多。2.2 Jetson的价值把推理这件事做到极致Jetson系列的核心竞争力就一个词CUDA。英伟达的软件生态在AI推理这块的成熟度目前还没有哪个平台能完全替代。不管是TensorRT的推理加速还是各种模型转换工具链的完善程度Jetson都是最省心的选择。我用的是一块Jetson Orin Nano模组算力在40TOPS左右INT8。这个算力跑YOLOv8s这种规模的模型1080P输入下能做到实时。更重要的是TensorRT对模型的优化非常成熟一个FP16的YOLOv8s模型经过TensorRT转换后推理速度能比原生PyTorch快两到三倍。但Jetson也有它的短板。它的CPU性能相对有限如果你让它同时处理视频解码、网络通信、文件存储这些任务它会顾此失彼。而且Jetson的功耗和发热比RK3588高不少需要认真考虑散热设计。这就引出了这套组合的核心逻辑让RK3588干它擅长的杂活让Jetson专心跑推理。两者通过高速接口连接RK3588把处理好的图像数据传给JetsonJetson把推理结果传回来RK3588再负责展示和存储。各司其职谁也不拖累谁。2.3 两者怎么连接口选择直接决定整体性能RK3588和Jetson之间的连接方式是整套方案里最容易被忽视但影响最大的环节。常见的连接方式有三种USB、以太网、PCIe。我逐个说下实际体验。USB连接最简单RK3588的USB 3.0接口带宽理论上是5Gbps实际传输能到400MB/s左右。对于1080P的JPEG图像一帧大概200KB到500KB这个带宽传个几十帧每秒没问题。但USB的延迟不太稳定而且占用CPU资源较多。适合对延迟不敏感、帧率要求不高的场景。以太网连接更稳定千兆网实际能跑满110MB/s左右。如果图像经过压缩这个带宽够用。而且网络连接天然支持分布式部署RK3588和Jetson甚至可以放在不同位置。缺点是延迟比PCIe高大概在几毫秒到十几毫秒之间。PCIe是最理想的方案RK3588有一路PCIe 3.0 x4理论带宽接近4GB/s。这个带宽传原始图像数据都绰绰有余延迟也最低。但PCIe连接需要两块板子物理上靠得很近对结构设计有要求。我最终选的是PCIe方案因为要做多路视频实时分析带宽和延迟都不能妥协。如果你只是做单路视频分析USB或以太网方案完全够用没必要为了PCIe去折腾结构。但如果你要做多路、高帧率、低延迟的场景PCIe是唯一的选择。3. 系统搭建从裸板到能跑起来的完整过程3.1 系统镜像的选择与烧录RK3588这边我建议直接用厂商提供的Ubuntu镜像。虽然有些发行版也支持RK3588但厂商镜像对硬件外设的驱动支持最完整尤其是视频编解码和NPU驱动这块自己折腾驱动会非常痛苦。我用的镜像基于Ubuntu 20.04内核版本是5.10NPU驱动和RKMPP视频编解码库都已经预装好了。烧录工具用瑞芯微官方的升级工具就行把镜像写到eMMC或者SD卡里。这里有个细节如果你打算用eMMC启动需要先通过MaskROM模式把引导程序写进去。具体操作是按住板子上的恢复按键再上电等工具识别到设备后松开。这个步骤第一次做可能会有点懵但按照厂商文档走一遍就清楚了。Jetson这边相对简单用英伟达官方的SDK Manager或者直接下载镜像烧录到NVMe SSD上。我强烈建议用NVMe SSD而不是SD卡因为Jetson的系统盘读写速度直接影响模型加载和日志写入的效率。SD卡的随机读写性能太差跑起来会明显感觉到卡顿。系统装好后第一件事是更新软件源和安装基础工具。RK3588这边需要额外安装librga和librknnrt这两个库它们是调用NPU和视频处理硬件的关键。Jetson这边需要确认CUDA和TensorRT的版本用nvcc --version和dpkg -l | grep tensorrt检查一下。3.2 两块板子之间的通信搭建如果用以太网连接配置最简单给两块板子各配一个同网段的静态IP然后测试ping通就行。但要注意如果RK3588同时还要连外网就需要配置双网卡路由避免默认路由冲突。我的做法是让RK3588的WiFi连外网以太网口专门用来和Jetson通信这样互不干扰。如果用PCIe连接配置会复杂一些。RK3588作为PCIe主机Jetson作为端点设备。需要在RK3588的设备树里使能PCIe控制器在Jetson那边配置端点模式。这个过程涉及设备树修改和内核模块加载第一次搞可能需要花点时间。但一旦配通后续使用就和普通网络通信一样通过PCIe上的网络接口传数据。我实际用的是PCIe转以太网的方式相当于在PCIe通道上跑了一个虚拟网络。这样既有PCIe的高带宽低延迟又保留了网络通信的灵活性。配置好之后ifconfig会多出一个网络接口给它配个IP就能直接通信了。3.3 视频流的采集与分发RK3588采集视频流的方式取决于摄像头类型。如果是USB摄像头直接用V4L2接口就能读如果是MIPI摄像头需要配置对应的驱动和设备树。我用的是一路USB摄像头加一路RTSP网络流两种方式都试过。采集到的视频流需要做两件事一是本地显示或存储二是送给Jetson做推理。这里的关键是避免数据拷贝。RK3588的RKMPP库支持硬解码和零拷贝解码后的帧可以直接映射到内存不需要在CPU和GPU之间来回搬。我用的方案是RTSP流通过RKMPP硬解解码后的NV12帧通过DMA直接送到NPU做预处理同时通过PCIe传给Jetson。传给Jetson的数据格式需要和Jetson那边的接收程序约定好。我用的是一种简单的自定义协议每帧数据前面加一个头包含帧号、时间戳、宽度、高度、格式这些信息后面跟实际的图像数据。Jetson收到后解析头部把图像数据拷贝到GPU内存然后跑推理。这里有个坑如果RK3588和Jetson之间的时钟不同步时间戳会对不上。我的做法是RK3588在发送前先和Jetson做一次NTP对时之后用单调时钟计数避免系统时间跳变导致的问题。4. 模型部署从训练到在盒子上跑起来4.1 模型选择与转换的完整链路在Jetson上部署模型标准流程是PyTorch训练 → 导出ONNX → 转TensorRT引擎。每一步都有坑我逐个说。导出ONNX的时候要注意opset版本。TensorRT对某些opset版本的支持不完整我一般用opset 11或12兼容性最好。另外动态维度dynamic axes的设置要谨慎如果输入尺寸固定就不要开动态维度否则TensorRT优化时会受限。转TensorRT引擎用trtexec工具最方便。一个典型的命令是这样的trtexec --onnxyolov8s.onnx \ --saveEngineyolov8s_fp16.engine \ --fp16 \ --workspace4096 \ --verbose--fp16开启半精度推理速度能提升不少精度损失通常在可接受范围内。--workspace指定显存工作空间大小单位是MB根据模型大小调整。如果转换过程中报显存不足就加大这个值。转换完成后用trtexec --loadEngineyolov8s_fp16.engine --shapesinput:1x3x640x640测试一下推理速度。正常情况下YOLOv8s在Orin Nano上FP16推理能跑到30FPS以上。4.2 推理服务的封装与接口设计模型转好后需要封装成一个服务接收RK3588发来的图像返回推理结果。我用Python写了一个简单的服务基于Flask框架但后来发现Flask的性能瓶颈明显换成了FastAPI加uvicorn吞吐量提升了不少。服务的设计要考虑几点一是并发处理多个请求同时进来时不能阻塞二是批处理如果RK3588发来的帧率很高可以攒几帧一起推理提高GPU利用率三是异常处理推理失败时要有降级方案不能整个服务挂掉。我的做法是用一个队列做缓冲RK3588发来的帧先入队推理线程从队列取帧攒够一批或者超时了就送GPU推理。推理结果通过另一个队列返回。这样即使某一帧推理失败也不会影响后续帧的处理。接口方面我用的是HTTP POST请求体是二进制图像数据响应是JSON格式的检测结果。虽然HTTP有额外开销但调试方便而且在实际使用中这个开销可以接受。如果对延迟要求极高可以考虑用gRPC或者直接走共享内存。4.3 RK3588端的预处理与后处理分工一个完整的推理流水线预处理和后处理占的时间往往比推理本身还长。我的分工策略是RK3588负责图像解码、缩放、颜色空间转换这些预处理Jetson只负责推理和NMS后处理。RK3588的RKMPP库做视频解码非常快1080P的H.264解码能跑到几百帧每秒。解码后的NV12数据用RGA瑞芯微的2D加速器做缩放和格式转换也是硬件加速的几乎不占CPU。处理好的RGB数据通过PCIe传给JetsonJetson直接送TensorRT推理。后处理这块NMS非极大值抑制在CPU上做就行因为检测框的数量通常不多几十个框的NMS耗时可以忽略。但如果你的模型输出特别多可以考虑用GPU做NMSTensorRT有对应的插件。实测下来把预处理放在RK3588上做整体延迟能降低30%以上。因为Jetson的CPU性能有限如果让它同时做解码和推理会明显拖慢推理速度。5. 实际跑起来之后性能、功耗与那些没预料到的问题5.1 实测性能数据与瓶颈分析整套系统跑起来后我做了几组测试。场景是两路1080P视频流一路本地摄像头一路RTSP网络流同时做目标检测。指标数值备注单路推理帧率32 FPSYOLOv8s FP16640x640输入双路推理帧率18 FPS每路共享Jetson算力端到端延迟约80ms从摄像头采集到结果返回RK3588 CPU占用约45%含解码、预处理、通信Jetson GPU占用约70%推理负载整机功耗约25W含两块板子和外设瓶颈主要在Jetson的GPU上。双路同时推理时GPU占用到70%左右帧率从单路的32FPS降到18FPS。如果要做更多路要么降低分辨率要么换更高算力的Jetson模组。另一个瓶颈是PCIe传输。虽然PCIe 3.0 x4带宽足够但实际传输效率受驱动和协议开销影响。我实测的传输速率大概在1.5GB/s左右传1080P RGB图像约6MB一帧的话理论上一秒能传200多帧实际因为协议开销和中断处理能稳定在100帧左右。对于双路18FPS的需求这个带宽绰绰有余。5.2 散热设计一个被严重低估的环节RK3588和Jetson加在一起满载功耗25W左右听起来不高但两块板子都是BGA封装热量集中在很小的面积上。如果不加散热片RK3588跑一会儿就会降频Jetson也会因为温度过高而降低算力。我的散热方案是RK3588加一块铝制散热片尺寸尽量大覆盖CPU和NPU区域Jetson加一个主动散热风扇因为它的功耗密度更高。两块板子之间留出风道用一个小风扇做整体空气流通。外壳用铝合金材质兼做散热片。实测下来室温25度时RK3588核心温度稳定在55度左右Jetson在65度左右都没有触发降频。如果去掉风扇Jetson温度会飙到80度以上推理速度明显下降。如果你打算把盒子放在封闭空间里散热设计要加倍重视。我见过有人把板子塞进一个密封的塑料盒里结果跑十分钟就卡顿拆开一看板子烫得没法摸。5.3 那些文档里不会写的坑第一个坑是电源。RK3588和Jetson对电源的要求不一样RK3588通常12V输入Jetson Orin Nano是19V。如果用一个电源同时供电需要加DC-DC转换。而且两块板子的峰值电流都不小电源的瞬态响应要好否则会出现莫名其妙的复位。我一开始用了一个便宜的电源结果Jetson跑推理时RK3588会随机重启换了电源就好了。第二个坑是USB设备的枚举顺序。RK3588上电时如果USB摄像头和USB转串口设备同时插入有时候枚举顺序会变导致程序找不到设备。解决办法是用udev规则给设备固定名称或者在程序里通过设备路径而不是设备号来打开。第三个坑是Jetson的功耗模式。Jetson默认的功耗模式可能不是最高性能模式需要手动设置。用nvpmodel命令可以切换我一般设成最大性能模式模式0虽然功耗高一点但推理速度稳定。第四个坑是时间同步。RK3588和Jetson如果各自用自己的RTC时间会有偏差。做多路视频分析时不同路的时间戳对不上融合结果就会出错。我的做法是RK3588作为NTP服务器Jetson作为客户端定期同步。6. 这套方案适合谁以及还能怎么玩6.1 适用场景与不适用场景的清晰边界这套RK3588加Jetson的组合最适合的场景是需要本地实时AI推理但对算力要求不是特别高同时对功耗、体积、成本有约束。比如小型工作室的视觉检测、零售场景的客流分析、教育场景的AI教学演示、家庭场景的智能监控。不适合的场景也很明确需要训练模型、需要超大算力比如跑大语言模型、需要极低延迟比如工业控制里的毫秒级响应。这些场景要么需要更强的GPU要么需要完全不同的架构。我个人的判断标准是如果你的模型能在Jetson Orin Nano上跑到实时且总功耗控制在30W以内那这套方案就值得考虑。如果模型跑不动或者功耗要求更宽松那直接上一台带独显的小主机可能更省事。6.2 后续可以扩展的方向这套盒子目前只做了目标检测但它的架构是通用的。换一个模型就能做姿态估计、语义分割、OCR识别。RK3588的NPU还可以跑一些轻量级的语音模型加上麦克风阵列就能做本地语音交互。另一个扩展方向是加装4G或5G模块让盒子在没有WiFi的环境下也能联网。不过要注意如果数据要上云就得考虑数据安全和隐私问题这个要根据具体场景来权衡。还有一个有意思的方向是做多盒子协同。几个盒子通过局域网连接各自处理一路视频结果汇总到一个中心节点做融合分析。这种分布式架构在大型场景里很有用比如多个出入口的客流统计。6.3 给准备入坑的朋友几条实在建议如果你打算自己搭一套我的建议是先从单路视频、单个模型跑通开始别一上来就搞多路。跑通之后再逐步加功能每加一个功能就测一下性能和稳定性。这样出问题的时候容易定位。买板子的时候优先选厂商支持好的。RK3588的板子很多但不同厂商的驱动完善程度差别很大。选那些有活跃社区、文档齐全的能省很多事。Jetson这边相对统一但要注意模组的功耗和散热设计。最后别低估结构设计的重要性。一个合理的结构能让散热、走线、接口布局都变得顺畅。我见过太多功能跑通了但装不进壳子的案例返工的成本比一开始就设计好要高得多。这套方案我前前后后折腾了大概两个月中间踩了不少坑但也积累了很多文档里找不到的经验。如果你正在做类似的事情希望这些内容能帮你少走点弯路。有问题欢迎交流我知道的都会说。
