RK3588 与 Jetson NX 双端部署：TensorRT、RKNN 与 YUV 接口
编写时间：2023-08
这个部署工作有两条线：Jetson NX 上走 TensorRT，RK3588 上走 RKNN。两边的共同目标是一样的：输入 YUV 帧，输出 ROI 框。但模型转换、后处理、量化和运行时完全不同。
双端差异
| 端侧 | 推理框架 | 模型链路 | 关键问题 |
|---|---|---|---|
| Jetson NX | TensorRT | PyTorch/ONNX -> Engine | 插件、显存、C++ 接口 |
| RK3588 | RKNN | PyTorch -> ONNX -> RKNN | 输出层、anchor、量化、RGA |
Jetson NX 侧
Jetson 侧重点在 TensorRT C++ 部署。输入分辨率不能裁剪信息，所以要支持多种尺寸。初始化阶段遇到过内存占用过高的问题，换 yolov5s/m 之后差异并不大，说明内存压力不一定只来自模型参数，也可能来自 engine、plugin、中间 tensor 和预处理 buffer。
trtexec --loadEngine=<model.engine> --plugins=<yolo_plugin.so>命令本身可以保留，路径和设备信息不保留。
RK3588 侧
RKNN 的工具链要分清：完整 toolkit 用于 x86 上模型转换，lite 侧主要在板端推理。不能指望板端完成所有转换。
关键问题主要是：
| 问题 | 处理方式 |
|---|---|
| YOLO 输出 concat 不适配 | 拆成三个输出，CPU 后处理 |
| anchor 不一致 | 导出时保存 anchor，并同步修改后处理 |
| demo 后处理旧 | 对齐 yolov5 v6.2 或用 onnx 修改工具 |
| 量化不稳 | 准备 200+ 张代表性校准图 |
| 首层输出不一致 | 打印第一层输出，对比 RKNN 与 ONNXRuntime |
统一接口
部署目标不是跑 demo，而是把推理封成业务接口：
INT8 与 FP16
边缘端部署一定会遇到精度和速度的取舍。FP16 通常更稳，INT8 更省资源但依赖校准集质量。对检测任务来说，量化后不能只看总体 mAP，还要看小目标、特殊字体、边缘裁切和低对比度区域的漏检误检。
核心经验是：同一个模型在不同端侧不是“转换一下就完了”。模型输出、预处理格式、后处理 anchor、量化校准、内存生命周期，每一项都会影响最后的可用性。