企业官网建设流程全解析

1. 从一块开发板到一台"盒子"：我为什么盯上了这个组合

前阵子有个做工业视觉的朋友甩给我一句话："你要是还在用x86小主机跑边缘推理，真该看看现在ARM这边的玩法了。"他说的就是RK3588+Jetson这套组合拳。我一开始没太当回事，毕竟RK3588这颗芯片出来有段时间了，Jetson系列更是老面孔，两个凑一起能玩出什么新花样？直到我自己上手搭了一台所谓的"AI智能盒子"，把本地大模型推理、多路视频分析、NAS轻量服务全塞进一个巴掌大的金属壳里，功耗还压在20W以内，我才意识到这个方向确实值得认真聊一聊。

这篇文章不是产品评测，也不是厂商软文，就是我自己从选型、采购、组装到调优的一整套实操记录。AI智能盒子这个词听起来有点营销味，但拆开看本质很简单：一颗擅长多媒体编解码和接口扩展的RK3588，加一颗擅长并行推理和CUDA生态的Jetson模块，通过高速总线协同工作，形成一个既能"看"又能"想"的边缘计算节点。它解决的核心问题是——在不上云、不依赖网络、不烧电费的前提下，让AI能力真正落到本地设备上。

适合谁看？如果你是做边缘计算方案的工程师、想搞一台家用AI服务器的折腾党、或者单纯对ARM平台AI推理感兴趣的学生，这篇内容应该能给你省下不少试错时间。我会把选型逻辑、硬件搭配、系统部署、模型跑分、踩过的坑全部摊开讲，尽量做到你照着抄作业就能复现。

2. 核心架构拆解：RK3588和Jetson到底谁干什么活

2.1 两颗芯片的分工逻辑

很多人第一反应是：这俩不都是SoC吗，放一起不冲突？其实它们的定位差异非常明显，这也是整个盒子设计的根基。

RK3588的强项在于多媒体处理和接口扩展。它自带8核CPU（4×A76+4×A55）、Mali-G610 GPU、6TOPS算力的NPU，最关键的是它有丰富的视频输入输出接口——HDMI 2.1输入输出、MIPI CSI多路摄像头、PCIe 3.0、USB 3.1、双千兆网口、SATA。这意味着它天然适合做"数据入口"和"调度中心"：接摄像头、接屏幕、接硬盘、接网络，把数据汇聚起来。

Jetson模块（我用的是Orin Nano 8GB版本）的强项在于CUDA生态和推理性能。它的GPU有1024个CUDA核心和32个Tensor Core，配合JetPack SDK，跑TensorRT、跑PyTorch、跑各种视觉模型都非常顺。40TOPS的INT8算力虽然不算顶天，但在边缘端已经能覆盖绝大多数实时推理需求。

所以分工就很清楚了：RK3588负责"搬运和呈现"，Jetson负责"计算和决策"。两者之间通过PCIe 3.0 x4或者千兆/2.5G以太网通信，前者带宽高延迟低，后者布线简单成本低。

2.2 为什么不用单颗芯片搞定

有人会问，RK3588自己就有6TOPS NPU，为什么还要加Jetson？这个问题我认真算过账。

第一，生态差距。RK3588的NPU要用RKNN工具链，模型转换、量化、算子支持都有坑，尤其是Transformer类模型支持不够成熟。而Jetson那边TensorRT的成熟度是另一个量级，社区资源、文档、现成模型库都丰富得多。

第二，算力天花板。6TOPS跑个YOLOv5s还行，跑多路视频分析或者7B级别的语言模型就力不从心了。Jetson Orin Nano的40TOPS能撑起更复杂的场景。

第三，灵活性。Jetson模块可以单独升级换代，RK3588主板不用动。这种"计算单元可插拔"的设计在长期维护上很划算。

当然代价也有：成本上去了，功耗上去了，系统复杂度上去了。所以这套方案适合对本地AI能力有真实需求、且能接受一定折腾成本的场景。如果只是做个视频播放器或者简单的人脸检测，RK3588单干就够了。

2.3 通信链路的选型对比

两颗芯片怎么连，是整个硬件设计里最关键的决策。我实测过三种方案，直接上对比表：

我最终选了PCIe 3.0 x4方案，因为我要跑4路1080p@30fps的视频分析，原始码流加起来大概80Mbps，但预处理后的张量数据量会大很多，以太网会成为瓶颈。PCIe直连还有个好处是Jetson可以直接访问RK3588侧的内存映射区域，做零拷贝传输。

注意：PCIe方案对载板设计要求高，走线阻抗、时钟同步都要处理好，否则会出现链路不稳定、掉设备的问题。如果你是第一次做，建议先用现成的载板方案，别一上来就自己画板。

3. 硬件选型与组装实录：从清单到点亮

3.1 物料清单与采购思路

我把整个盒子的物料分成四块：核心板、载板、存储、外围。下面是我实际用的配置，价格是当时的采购价，仅供参考。

核心计算部分：

• RK3588核心板（8GB LPDDR4X + 64GB eMMC）：约450元
• Jetson Orin Nano 8GB模块：约1800元
• 定制载板（支持PCIe x4互联、双网口、4路MIPI CSI）：约600元

存储部分：

• NVMe SSD 1TB（PCIe 3.0 x4）：约400元
• microSD卡 64GB（系统盘备份）：约40元

外围部分：

• 金属外壳（带散热鳍片和风扇位）：约120元
• 5V/6A电源适配器：约60元
• 散热风扇×2（4010规格）：约30元
• 天线、排线、螺丝等杂项：约50元

总计大概3550元左右。这个价格比买一台同等算力的x86小主机便宜不少，功耗更是低一个数量级。

选型时有几个点值得展开说。RK3588核心板我选了带eMMC的版本，因为系统启动速度比SD卡快很多，而且eMMC的读写寿命更适合做系统盘。Jetson模块选Orin Nano而不是Xavier NX，主要是性价比——Orin Nano的40TOPS对绝大多数边缘场景够用，价格却便宜近一半。载板是最需要花心思的部分，我对比了三家方案，最终选了一家开源设计改的，接口布局合理，PCIe走线也做了阻抗匹配。

3.2 组装过程中的关键细节

组装本身不难，但有几个细节如果忽略，后面会吃大亏。

散热是第一优先级。RK3588满载功耗能到8W左右，Jetson Orin Nano满载15W，两个加起来20多W塞在密闭金属壳里，不加主动散热必降频。我的方案是RK3588上方一个4010风扇吹，Jetson模块上方一个4010风扇抽，形成对流。实测满载时RK3588核心温度稳定在65度左右，Jetson在70度左右，都在安全范围内。

供电要分开。两颗芯片的峰值电流都不小，如果共用一路电源，瞬态响应可能跟不上导致重启。我用的是双路独立供电，RK3588走5V/3A，Jetson走5V/4A，电源适配器总输出6A留足余量。

PCIe排线要短。我一开始用了20cm的排线，结果链路训练经常失败。换成10cm的屏蔽排线后问题消失。PCIe 3.0对信号完整性很敏感，排线越短越好，能直连就别用排线。

天线布局别马虎。如果要用WiFi，天线要远离PCIe排线和电源线，否则2.4G频段干扰严重。我把天线贴在壳体外侧，用IPEX转SMA的馈线引出来，信号质量好了很多。

3.3 首次上电与系统验证

第一次上电前，务必先不接Jetson模块，单独验证RK3588能否正常启动。因为如果载板有问题，两颗芯片一起上电可能互相影响，排查起来更麻烦。

RK3588侧我用的是官方提供的Debian镜像，烧录到eMMC后启动，串口打印正常，HDMI输出正常，网口能拿到IP，说明基础功能没问题。然后关机，插上Jetson模块，再上电。

Jetson侧需要单独烧录JetPack系统。我用的是SDK Manager通过USB-C口烧录，过程比较标准。烧录完成后，在RK3588的Linux系统里用lspci命令检查PCIe设备，应该能看到NVIDIA的设备和对应的BAR空间。如果看不到，先检查dmesg里的PCIe链路训练日志，大概率是硬件连接问题。

# 在RK3588侧检查PCIe设备 lspci -v # 预期输出中应包含NVIDIA Corporation的设备条目 # 检查链路速率和宽度 sudo lspci -vv -s 01:00.0 | grep -i "lnksta" # 应显示 Speed 8GT/s, Width x4

两边系统都跑起来后，我用iperf3测了一下PCIe虚拟网卡的吞吐，能跑到2.3Gbps左右，虽然没跑满PCIe 3.0 x4的理论带宽，但对我的视频流场景已经绰绰有余。

4. 软件栈部署：让两颗芯片真正协同起来

4.1 系统架构与通信中间件

硬件通了只是第一步，软件层面怎么让两颗芯片高效协作才是真正的挑战。我的架构设计是这样的：

RK3588侧跑一个主控服务，负责视频采集、预处理、任务调度和结果呈现。Jetson侧跑一个推理服务，接收RK3588发来的张量数据，跑模型，返回结果。两者之间用gRPC over PCIe虚拟网卡通信，协议用Protobuf定义，兼顾效率和可维护性。

为什么选gRPC而不是自己写socket？因为gRPC自带流式传输、超时重试、负载均衡这些能力，省去大量造轮子的时间。Protobuf的序列化效率也比JSON高一个数量级，对带宽敏感的PCIe链路很友好。

通信中间件这块我踩过一个坑：一开始用HTTP RESTful接口，结果每次请求的header开销太大，延迟下不来。换成gRPC的流式接口后，端到端延迟从80ms降到了25ms左右。

4.2 RK3588侧环境搭建

RK3588侧的系统我用的Debian 11，需要装几个关键组件：

# 更新源 sudo apt update && sudo apt upgrade -y # 安装视频处理相关库 sudo apt install -y ffmpeg libopencv-dev python3-opencv # 安装gRPC和Protobuf sudo apt install -y protobuf-compiler-grpc python3-grpcio # 安装RKNN工具链（用于NPU加速的轻量任务） pip3 install rknn-toolkit2

视频采集这块，我用的是GStreamer管道，因为它对硬件编解码的支持最好。RK3588的VPU支持H.264/H.265的硬解，4路1080p同时解码CPU占用率不到20%。

# 4路MIPI摄像头同时采集的GStreamer管道示例 gst-launch-1.0 \ v4l2src device=/dev/video0 ! video/x-raw,width=1920,height=1080,framerate=30/1 ! \ queue ! mppvideodec ! videoconvert ! appsink & # 重复4次，分别对应video0到video3

预处理部分我做了个优化：把RGB转换、归一化、resize这些操作全部放在RK3588侧用OpenCL加速完成，传给Jetson的已经是模型可以直接吃的张量。这样Jetson的GPU可以专注于推理，不用浪费算力在数据预处理上。

4.3 Jetson侧推理服务部署

Jetson侧我用的JetPack 5.1.2，自带CUDA 11.4和TensorRT 8.5。推理服务用Python写，核心是TensorRT的Python API。

模型转换是第一个坎。我拿YOLOv8s做例子，流程是PyTorch → ONNX → TensorRT engine。ONNX导出时要注意opset版本，太新太旧都可能出问题，我实测opset 12比较稳。

# PyTorch转ONNX import torch model = torch.load('yolov8s.pt') dummy_input = torch.randn(1, 3, 640, 640) torch.onnx.export( model, dummy_input, 'yolov8s.onnx', opset_version=12, input_names=['images'], output_names=['output'], dynamic_axes={'images': {0: 'batch'}} )

ONNX转TensorRT用trtexec工具，关键是精度选择。FP16精度下YOLOv8s在Orin Nano上能跑到45FPS左右，INT8量化后能到80FPS，但精度会掉1-2个点。我的场景对精度要求不高，所以用了INT8。

# ONNX转TensorRT INT8 engine trtexec --onnx=yolov8s.onnx \ --saveEngine=yolov8s_int8.engine \ --int8 \ --calib=calibration_data/ \ --workspace=4096

推理服务的gRPC接口定义大概长这样：

service InferenceService { rpc Infer (InferRequest) returns (InferResponse); rpc InferStream (stream InferRequest) returns (stream InferResponse); } message InferRequest { bytes tensor_data = 1; repeated int32 shape = 2; string dtype = 3; } message InferResponse { bytes result_data = 1; repeated int32 shape = 2; float inference_time_ms = 3; }

4.4 端到端联调与性能数据

两边服务都跑起来后，我做了一轮完整的性能测试。测试场景是4路1080p视频流，每路跑YOLOv8s目标检测，帧率30fps。

这个数据我比较满意。整机功耗实测：RK3588侧约7W，Jetson侧约14W，加上外围总共约23W。对比之下，一台带独立显卡的x86小主机跑同样任务至少要80W。

5. 典型应用场景与扩展玩法

5.1 本地智能监控分析

这是我最开始做的场景。4路摄像头接入RK3588，Jetson跑检测和跟踪模型，实现人员检测、越界报警、轨迹记录。所有数据本地处理，不上云，隐私性很好。

实际部署时有个细节要注意：摄像头的时间戳同步。4路视频如果时间戳不同步，做跨摄像头跟踪时会出问题。我的做法是用RK3588的硬件定时器给每帧打上统一时间戳，精度能到毫秒级。

5.2 本地大模型对话终端

Jetson Orin Nano 8GB能跑量化后的7B级别语言模型，虽然速度不快（大概5-8 token/s），但做本地问答助手够用了。我用llama.cpp的CUDA后端，把模型转成GGUF格式，Q4_K_M量化后大概4GB左右。

RK3588在这边负责语音输入输出：麦克风阵列采集、语音识别（用轻量模型）、TTS合成、屏幕显示。整个交互链路完全本地，断网也能用。

提示：Jetson Orin Nano的内存是共享的，跑大模型时要注意给GPU留足显存。我一般设置GPU显存上限为6GB，留2GB给系统。

5.3 轻量NAS与家庭服务器

RK3588的SATA和PCIe接口可以接硬盘，跑个Samba或者NFS服务，就是个低功耗NAS。Jetson侧可以跑照片智能分类、视频转码这些任务。整套系统待机功耗不到10W，7×24小时开着也不心疼电费。

我还试过在上面跑Home Assistant做智能家居中枢，RK3588的GPIO和串口可以直连各种传感器和执行器，Jetson负责处理摄像头和语音相关的自动化逻辑。

5.4 工业边缘质检

这个场景是我朋友那边实际在用的。产线上的工业相机通过MIPI或GigE接入RK3588，Jetson跑缺陷检测模型，检测结果通过GPIO输出控制信号。整套系统装在产线旁边的控制柜里，环境温度能到45度，散热设计要留足余量。

工业场景对稳定性要求极高，我做了几个加固：系统盘用eMMC做RAID1冗余、看门狗定时器防止死机、推理服务加健康检查自动重启。跑了三个月没出过问题。

6. 踩坑记录与常见问题排查

6.1 硬件层面的坑

PCIe链路不稳定是最常见的问题。表现是lspci时有时无，或者跑高负载时掉设备。原因通常是排线质量差、走线太长、或者电源纹波大。我的解决顺序是：先换短排线，再检查电源，最后才怀疑载板设计。

散热不足导致降频也很典型。RK3588的NPU满载时发热很大，如果散热片接触不良，温度会迅速冲到85度以上触发降频。我的做法是用导热硅脂而不是导热垫，接触更紧密。风扇转速用PWM根据温度自动调节，兼顾噪音和散热。

供电不足导致重启。Jetson模块启动瞬间电流能到4A以上，如果电源响应慢，电压会跌落导致重启。选电源时要看瞬态响应指标，别只看额定功率。

6.2 软件层面的坑

RKNN模型转换失败。RK3588的NPU对算子支持有限，很多PyTorch的自定义算子转不过去。我的建议是：能用Jetson跑的就别用RKNN，RKNN只用来跑一些标准的轻量模型。

TensorRT engine不兼容。TensorRT engine是和具体GPU架构绑定的，在Orin Nano上生成的engine不能拿到别的型号上用。部署时要确保目标设备和生成engine的设备一致。

gRPC超时设置不合理。默认超时太短，大张量传输时容易触发重试。我把超时设成5秒，并且加了流控，问题解决。

6.3 常见问题速查表

6.4 几条独家避坑经验

第一，先跑通单芯片再联调。RK3588和Jetson各自先独立验证，确认没问题再连起来。这样出问题时排查范围小很多。

第二，保留串口调试口。HDMI和网络都可能出问题，串口是最可靠的调试通道。载板上一定要留出串口排针。

第三，系统镜像做好备份。调优过程中很容易把系统搞崩，有个备份镜像能省大量重装时间。我用dd把eMMC完整备份到NVMe上，恢复只要几分钟。

第四，别追求极致性能。边缘设备稳定运行比跑分重要。我一开始把Jetson功耗模式开到最大，结果夏天温度压不住，后来降到15W模式，性能只掉了10%，但稳定性好了很多。

第五，文档和版本管理。两颗芯片的工具链版本、驱动版本、模型版本都要记录清楚，不然过两个月自己都忘了当时怎么配的。我用Git管理所有配置文件和脚本，每次改动都提交。

这套RK3588+Jetson的AI智能盒子我前后折腾了大概两个月，从最初的想法到最终稳定运行，中间踩的坑比预想的多，但收获也大。它让我重新认识了ARM平台在边缘AI上的可能性——不是替代x86，而是在功耗、成本、体积敏感的場景里开辟了一条新路。如果你也在做类似的方向，希望这些记录能帮你少走点弯路。后面我打算试试把Jetson模块换成更新的型号，看看算力提升能带来哪些新玩法，到时候再整理出来分享。