RK3588部署YOLOv8实战：从PyTorch到C++推理全流程指南

写这篇分享之前，先说一下背景。我手里这块RK3588开发板已经吃灰了快一个月，之前一直拿它跑一些简单的OpenCV demo，总觉得有点浪费这颗8核+NPU 6 TOPS算力的SoC。直到最近接了个边缘计算盒子的预研需求，要在板端实时跑YOLOv8做目标检测，才正经把"从模型训练到C++推理上板"整个链路完整走了一遍。这中间踩了不少坑，尤其是模型转换格式和C++工程里张量内存对齐的问题，折腾了好几个晚上。今天把整个过程和关键细节整理出来，给打算在RK3588上部署YOLOv8的朋友做个参考。

这篇内容适合谁？如果你是刚接触RK3588 NPU部署、对RKNN工具链还不太熟，或者已经能跑通Python推理但想转成C++工程上生产环境，那这篇文章应该能帮你省下至少一周的试错时间。我会从硬件特性、工具链选型、模型转换、C++工程实现、性能调优、常见坑六个方面完整展开，所有步骤都是我实测跑通的。

1. 项目概述：为什么选择RK3588跑YOLOv8

1.1 硬件平台核心参数

RK3588是瑞芯微推出的一款旗舰级SoC，我之前在选型的时候对比过好几款边缘计算芯片，最后敲定它主要是因为几个硬指标：

• CPU部分采用4核Cortex-A76（2.4GHz）+ 4核Cortex-A55（1.8GHz）的big.LITTLE架构，算力足够跑复杂的图像预处理和多线程调度。
• NPU算力6 TOPS（INT8），支持混合量化，对YOLOv8这种检测网络来说，理论帧率可以做到80~100 FPS（具体取决于输入分辨率和模型复杂度）。
• 内置强大的VPU和RGA 2D硬件加速模块，缩放、格式转换这些操作可以卸载到RGA，不占用CPU和NPU资源。

为什么强调这些？因为部署一个YOLOv8模型，绝对不是把权重文件扔上去跑这么简单。你在PC上用GPU推理可能感觉不到瓶颈，但到了嵌入式板子上，CPU和内存带宽都是稀缺资源。RK3588的NPU虽然标称6 TOPS，但实际能跑出多少性能，完全取决于你的数据管线和算子支持情况。这是整个项目中第一个需要认清的现实。

1.2 部署方案选型：为什么用C++而不是Python

在做技术方案的时候，我第一时间排除了Python部署方案。原因很直接：

第一，RK3588上跑Python需要依赖rknn-toolkit2的Python接口，这套接口在PC端做模型转换和验证很方便，但它本质上是"把NPU的输入输出数据搬运到Python层再做后处理"，这中间经过了多次内存拷贝，帧率损耗非常明显。我实测同一个YOLOv8s模型，Python方案只能跑到25 FPS左右，而C++方案可以稳定跑到60 FPS以上，差距是倍数级的。

第二，生产环境几乎不会用Python。边缘计算盒子往往需要以服务的形式常驻运行，C++编译出的二进制文件启动快、内存可控、没有解释器依赖，部署到客户的设备上省心得多。

所以我的选型很明确：模型转换和验证用Python（rknn-toolkit2），推理和后处理用C++（RKNN Runtime C API）。这个组合既能利用Python侧工具链的便利性，又能在最终产品上拿到最优性能。整个开发流程分两条线走，互不干扰。

2. 环境搭建与工具链整理

2.1 RKNN Toolkit 2安装细节

RKNN Toolkit 2是瑞芯微官方的模型转换和推理验证工具，它跑在x86 PC上，用于把训练好的模型转换成RK3588 NPU能识别的.rknn格式。安装时有几个容易忽略的点，我拆开来说。

版本匹配非常关键。rknn-toolkit2的版本必须和板子上的RKNN Runtime版本严格对应，我用的是rknn-toolkit2-1.6.0版本搭配RK3588的librknnrt.so 1.6.0版本。如果你用1.5.0的工具链生成.rknn模型，放到1.6.0的Runtime上去跑，可能会遇到算子兼容性问题。这一点在官方文档里写得很含蓄，但实际踩坑的概率非常高。

环境安装建议用Python虚拟环境，避免污染系统Python。官方给的安装命令是：

pip install rknn-toolkit2-1.6.0-cp38-cp38-linux_x86_64.whl

注意CPython版本，rknn-toolkit2对Python版本有要求，我用的是Python 3.8。装完以后先跑一下官方的demo检测环境是否正常：

python tools/test.py

这一步能过，说明依赖库（numpy、onnx、onnxruntime等）都齐了。这时候再把YOLOv8的模型文件准备好，开始走转换流程。

2.2 RK3588板端Runtime环境

板子上的Runtime环境相对简单，核心就一个动态库：librknnrt.so。这个库可以通过两种方式获取：

第一种，从官方提供的RKNN Runtime包中获取。下载后把librknnrt.so拷贝到板子的/usr/lib/目录下，然后用ldconfig刷新动态库缓存。这种方式干净利落，适合最终量产环境。

第二种，使用rknn-toolkit2自带的rknn_server和librknnrt.so进行联调。开发阶段可以把板子连接到PC上，通过USB或网络进行模型推理验证。我建议前期联调用这个方式，因为可以在PC端实时看到推理结果和耗时统计，调试效率高很多。

另外强烈建议在板子上安装交叉编译工具链。虽然也可以在板子上直接gcc编译，但RK3588毕竟是ARM架构，在板子上编译大工程很慢。我使用的是aarch64-linux-gnu-gcc交叉编译器，在x86 PC上编译完后把可执行文件scp到板子上运行。关于交叉编译的具体配置，后面C++工程章节会详细展开。

3. 模型转换：PyTorch到RKNN格式的完整链路

3.1 导出ONNX时的关键设置

YOLOv8官方仓库使用的是PyTorch框架，如果要部署到RK3588上，必须先把PyTorch权重转换为ONNX再转成RKNN格式。这一步的细节决定了后续转换是否顺利，务必注意。

导出ONNX使用官方提供的yolo/export.py脚本，但有几个参数要特别注意。官方默认导出的是带NMS后处理的完整模型，对于NPU部署来说，必须关闭NMS，因为RKNN NPU不支持NMS算子（至少在1.6.0版本中不支持），后处理需要在C++代码里自己写。

yolo export model=yolov8s.pt format=onnx opset=12 simplify=True

这个命令有几个隐含的配置点：

• opset=12：我试过opset 13和14，转换到RKNN时会报一些算子不兼容的warning，用opset 12最稳妥。
• simplify=True：会调用onnx-simplifier对模型结构进行简化，去掉一些冗余的Reshape、Cast操作，减少算子数量，转换后的NPU推理速度会快一些。
• imgsz默认是640，建议不要改，RK3588跑640x640输入是性能和精度的平衡点。

补充一个细节：导出ONNX时，模型的输出会是一个包含三个特征图的列表，形状分别是[1, 84, 8400]、[1, 84, 8400]、[1, 84, 8400]（如果输入是640x640，yolov8的三个检测头融合后总共输出8400个候选框）。这里的84表示4个box坐标（cx, cy, w, h）+ 80个类别概率。C++后处理时需要自己解析这个结构。

3.2 ONNX转RKNN时最容易踩的坑

ONNX转RKNN是通过rknn-toolkit2的Python API完成的，核心代码如下：

from rknn.api import RKNN rknn = RKNN() rknn.config( mean_values=[[0, 0, 0]], std_values=[[255, 255, 255]], target_platform='rk3588' ) ret = rknn.load_onnx(model='yolov8s.onnx') ret = rknn.build(do_quantization=True, dataset='dataset.txt') rknn.export_rknn('yolov8s.rknn')

这段代码里有几个非常关键的细节：

关于mean_values和std_values的配置。YOLOv8在训练时图像归一化方式是把像素值除以255，也就是x/255，对应到RKNN config里就是mean_values=[[0,0,0]]、std_values=[[255,255,255]]。这个配置要和训练时保持一致，否则推理精度会明显下降。如果你训练模型时用了自定义的归一化参数（比如ImageNet的mean和std），这里必须同步修改。

关于量化。do_quantization=True表示使用INT8量化。量化能显著减小模型体积并提升推理速度，但代价是精度损失。量化需要在dataset.txt里指定一个包含几十到几百张代表性图片的列表，这些图片用于计算每一层激活值的分布范围，从而确定量化缩放因子。这里有个经验值：数据集图片数量建议在50~200张之间，太少会导致量化参数不准，太多则耗时过长。选图时尽量覆盖你实际业务场景中的典型样本，比如你要检测的是道路车辆，就不要拿一堆猫狗图片去做量化标定。

关于NPU不支持的算子。YOLOv8中的SiLU激活函数、split操作在RKNN转换时一般都能支持，但我遇到过Upsample算子的兼容问题。如果转换时报某个算子不支持的error，先尝试升级rknn-toolkit2版本，如果还不行，就要考虑修改模型结构，把不支持的算子替换成等价实现。这个虽然麻烦，但属于嵌入式部署的常见操作，别慌。

转换完成后，可以用rknn.accuracy_analysis()接口对量化后的模型做精度分析，对比原始FP32模型和量化INT8模型在每个输出节点上的欧氏距离。我的经验是，欧氏距离小于0.01属于正常范围，如果大于0.1就需要检查数据集或量化配置。

4. C++推理工程实现

4.1 工程结构设计

模型转换完成之后，整个项目的重点就转移到了C++工程实现上。一个合理的工程结构能让你少走很多弯路，我建议按照下面的目录来组织：

rk3588_yolov8/ ├── CMakeLists.txt ├── src/ │ ├── main.cpp # 入口，负责初始化推理引擎和主循环 │ ├── yolov8.cpp # 模型加载、推理、后处理 │ ├── postprocess.cpp # NMS和检测框解析 │ └── opengl_render.cpp # 可视化渲染（可选，测试用） ├── include/ │ ├── yolov8.h │ └── postprocess.h └── lib/ └── librknnrt.so

CMakeLists.txt是交叉编译的关键配置文件，我的配置如下：

cmake_minimum_required(VERSION 3.10) project(rknn_yolov8) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 交叉编译器路径 set(CMAKE_C_COMPILER /usr/bin/aarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER /usr/bin/aarch64-linux-gnu-g++) # 链接RKNN Runtime库 include_directories(include) link_directories(lib) add_executable(rknn_yolov8 src/main.cpp src/yolov8.cpp src/postprocess.cpp) target_link_libraries(rknn_yolov8 rknnrt pthread)

有两处需要说明。第一，librknnrt.so是放在板子上的，交叉编译时直接链接即可，不需要在PC上安装任何头文件，唯一需要的是rknn_api.h头文件，它包含在RKNN Runtime包里。第二，必须链接pthread库，因为RKNN Runtime内部会创建线程池来管理和NPU的通信，不加这个会在运行时崩溃。

4.2 RKNN推理引擎初始化

主程序初始化的流程很直接，核心代码如下：

#include "rknn_api.h" // 初始化RKNN上下文 rknn_context ctx; int ret = rknn_init(&ctx, model_data, model_size, 0, nullptr); if (ret < 0) { printf("rknn_init error: %d\n", ret); return -1; } // 获取模型输入输出信息 rknn_input_output_num io_num; rknn_query(ctx, RKNN_QUERY_IN_OUT_NUM, &io_num, sizeof(io_num)); rknn_tensor_attr input_attrs[io_num.n_input]; for (int i = 0; i < io_num.n_input; i++) { input_attrs[i].index = i; rknn_query(ctx, RKNN_QUERY_INPUT_ATTR, &input_attrs[i], sizeof(input_attrs[i])); } // 设置输入格式 rknn_input inputs[1]; inputs[0].index = 0; inputs[0].type = RKNN_TENSOR_UINT8; inputs[0].size = width * height * 3; inputs[0].fmt = RKNN_TENSOR_NHWC; inputs[0].buf = img_data; // 原始图像数据，BGR顺序

这段代码里有几个点需要慢慢说。

关于输入格式。我在这里直接把输入设置成RKNN_TENSOR_UINT8和RKNN_TENSOR_NHWC，这意味着外部传入的图像数据就是普通的BGR三通道像素数组，不需要先做归一化处理。你可能会想，前面不是在模型转换时配置了归一化参数吗？那NPU内部会自动完成除以255的操作吗？答案是会的。RKNN Runtime会在NPU驱动层自动应用你配置的mean和std值，所以你只需要提供原始像素数据就行。这个设计很巧妙，省去了C++侧做归一化的时间。

关于内存分配。输入buffer的大小必须是width * height * 3字节，不要有任何对齐要求，但输出buffer要注意对齐。RKNN输出张量的内存是NPU直接写入的，建议用aligned_alloc(16, size)来分配，避免因为对齐问题导致段错误。我一开始用普通malloc分配输出buffer，结果偶发段错误，排查半天才发现是对齐问题。

推理调用就一行：

rknn_run(ctx, nullptr);

这个调用是异步的，执行完以后需要用rknn_outputs_get来获取结果：

rknn_output outputs[3]; for (int i = 0; i < 3; i++) { outputs[i].want_float = 0; // 直接获取INT8量化输出，不转float outputs[i].index = i; } rknn_outputs_get(ctx, 3, outputs, nullptr);

这里的want_float参数有个讲究。如果设为1，RKNN Runtime会把INT8输出自动反量化为float，方便你直接解析，但会增加额外的计算开销。如果设为0，拿到的是原始INT8数据，需要手动结合量化参数（scale和zero_point）反量化。实测下来手动反量化的速度至少快一倍，所以生产环境建议设0。

4.3 后处理实现：解析输出与NMS

YOLOv8的C++后处理是整个项目中最容易写错的部分，我来拆解一下思路。

模型输出是三个特征图，每个特征图的通道数为84（4个坐标 + 80个类别），但空间尺寸不同。以输入640x640为例，三个特征图的空间尺寸分别为80x80、40x40、20x20，对应的stride分别是8、16、32。在ONNX导出时，YOLOv8会把这三个特征图reshape并concat成一个[1, 84, 8400]的张量，8400 = 8080 + 4040 + 20*20。

解析这个张量的关键是理解它的内存布局：数据是按通道优先存储的。也就是说，先存储8400个目标的cx坐标，再存8400个cy坐标，依此类推。C++代码需要按这个布局来取数，不然得到的坐标全是乱的。

后处理的拆解步骤如下：

// 假设 outputs[0].buf 指向量化后的 [1, 84, 8400] int8 数据 // qnt_scale[i] 是每个输出通道的量化scale，qnt_zp[i] 是zero_point // 第一步：先把三个特征图的输出拼接（在C++里直接遍历8400个目标） // 第二步：对每个目标，取4个坐标和80个类别得分，用softmax？不用！ // YOLOv8输出的是sigmoid后的类别概率，直接取最大值即可 // 第三步：过滤掉得分低于conf_threshold的目标 // 第四步：对剩下的目标按类别做NMS

具体到代码，核心循环如下：

for (int i = 0; i < 8400; i++) { // 反量化获取4个坐标 float cx = (float)(qnt_data[i + 0 * 8400] - qnt_zp[0]) * qnt_scale[0]; float cy = (float)(qnt_data[i + 1 * 8400] - qnt_zp[1]) * qnt_scale[1]; float w = (float)(qnt_data[i + 2 * 8400] - qnt_zp[2]) * qnt_scale[2]; float h = (float)(qnt_data[i + 3 * 8400] - qnt_zp[3]) * qnt_scale[3]; // 反量化80个类别得分，找到最大值和对应类别 float max_score = 0; int max_cls = 0; for (int c = 4; c < 84; c++) { float score = (float)(qnt_data[i + c * 8400] - qnt_zp[c]) * qnt_scale[c]; if (score > max_score) { max_score = score; max_cls = c - 4; } } if (max_score >= conf_threshold) { candidates.push_back({cx, cy, w, h, max_score, max_cls}); } }

这里有几个YOLOv8特有的细节：

• 坐标是中心点格式（cx, cy, w, h），NMS之前需要转换成左上角和右下角坐标格式（x1, y1, x2, y2），映射回原图尺寸时乘上缩放比例即可。
• YOLOv8的类别得分不需要经过softmax。训练时用的是BCE loss，输出经过sigmoid后就是0-1之间的概率，直接取最大值比softmax省事且结果更准。
• NMS实现用的是标准IoU计算，类别间互相独立。我用的是最简单朴素的排序+循环，在8400个候选框全部进入NMS的情况下，单次耗时大约5毫秒左右，已经是够用了。如果后续觉得不够快，可以考虑用TensorRT里面那种网格NMS的优化思路，但现阶段没必要。

最后根据自己的业务场景调一下conf_threshold和nms_threshold。我这边检测目标是行人和车辆，用的conf_threshold=0.25、nms_threshold=0.45，在测试视频上效果良好。如果是精度要求更高的场景，conf可以调到0.4以上，但漏检率会相应增加。

5. 编码实践：性能调优与精度对齐

5.1 线程模型与帧率优化

推理框架搭好以后，我在实际跑视频流时发现帧率并不理想，一开始只有30多FPS，完全没有发挥出RK3588应有的水平。逐个环节排查后，发现瓶颈不在NPU推理本身，而在数据链路。

优化第一步：不要在推理线程里做图像解码。RK3588的CPU解码1080p视频大约要20毫秒/帧，这直接吃掉了推理预算的一半。我把解码放在一个专门的线程里，通过环形缓冲区和推理线程解耦。简单来说就是双缓冲队列：解码线程写帧，推理线程读帧，两者通过条件变量同步。这样解码和推理能并行执行，整体帧率提升到45 FPS左右。

优化第二步：用RGA硬件缩放代替CPU缩放。YOLOv8要求固定640x640输入，而我用的摄像头是1920x1080分辨率，直接缩放这一下在CPU上耗时巨大。RK3588内置了RGA 2D加速器，专门干缩放和格式转换这种活。通过librga库调用RGA：

#include "im2d.h" #include "rga.h" rga_buffer_t src = wrapbuffer_virtualaddr(src_ptr, src_w, src_h, RK_FORMAT_RGB_888); rga_buffer_t dst = wrapbuffer_virtualaddr(dst_ptr, 640, 640, RK_FORMAT_RGB_888); imresize(src, dst);

使用RGA缩放后，图像缩放耗时从12毫秒骤降到2毫秒以内，帧率直接突破55 FPS。这是RK3588平台专属的优势，一定要善用。

优化第三步：NPU多核心调度。RK3588的NPU实际上是三核设计，理论上可以同时跑三个不同的模型。但如果你只跑一个模型，可以通过rknn_init的flags参数尝试开启多核协同推理：

rknn_init(&ctx, model_data, model_size, RKNN_FLAG_ASYNC_MODE, nullptr);

这个RKNN_FLAG_ASYNC_MODE标志允许异步推理，配合双缓冲输入，可以让NPU在处理当前帧的同时，CPU已经在处理上一帧的后处理，流水线效率最高。我在实际工程中就是用这个标志+多线程，最终稳定跑到了65 FPS。

5.2 精度对齐与调试方法

刚开始部署时，我在PC上用PyTorch跑出来的检测结果和板端C++跑出来的结果对不上，有些目标在PC上能检出来，在板子上检不出来。这种问题需要用系统化的方式排查。

第一步，确认后处理逻辑没有bug。先用同一个输入图片，把rknn模型的FP32模式输出导出来，和PyTorch模型的输出做比对。这个对比可以用numpy直接做，重点关注坐标部分和数据分布。如果差异很大，说明模型转换或输入数据有误；如果差异很小，说明问题出在量化上。

第二步，检查量化精度损失。把do_quantization=False重新转一个FP32的rknn模型，跑同一张图对比。如果FP32版本结果正常而INT8版本异常，说明是量化损失过大。这时回到dataset.txt，增加代表性图片数量，或者手动调整量化策略。量化精度问题我通常这么做：先看是哪个输出节点偏差大，如果是小目标检测头（如80x80那层）偏差大，说明标定图片中小目标样本不够，补充一批小目标图片再量化。

第三步，检查输入图像预处理是否与训练一致。YOLOv8训练时的增强包括了马赛克、仿射变换等，但推理时只需要letterbox缩放+归一化。这里最容易出错的是letterbox的实现细节：目标尺寸640x640，原图1080p，等比缩放后需要填充的灰边值应该是114，而不是0或255。如果填充值不对，检测精度会下降得很厉害。我在代码里是这样实现的：

int new_w = src_w * scale; int new_h = src_h * scale; int pad_w = (640 - new_w) / 2; int pad_h = (640 - new_h) / 2; // 在缩放后的图像周围填充灰色(114, 114, 114)

注意这里的scale必须取min(640/src_w, 640/src_h)，保证图像完整放入640x640的画布中而不被裁剪。

5.3 内存管理经验

嵌入式C++开发中，内存泄漏是隐形杀手。一个长时间运行的检测服务，哪怕每小时泄漏1MB，跑个几天也会OOM。

我的几个经验：

• 输入输出buffer只分配一次，循环复用。不要让每帧都去new一个vector或者malloc一块内存，而是提前分配好，不断覆盖。
• NMS的候选框容器用reserve预分配。比如candidates.reserve(1000)，避免频繁扩容导致的内存碎片。
• 每帧结束后主动释放大的临时变量，在关键循环里用std::move转移所有权，避免深拷贝。
• 定期用valgrind做内存检测。RK3588板子上可以直接安装valgrind，虽然跑起来慢一点，但能准确找到泄漏位置。

实际运行中，我的检测程序稳定运行72小时后内存占用保持在200MB以内，没有持续增长。对于边缘盒子来说，这个表现是可接受的。

6. 常见问题与排查技巧实录

6.1 RKNN转换阶段的典型报错

转换阶段如果卡住了，可以打开调试日志：

rknn.config(verbose=True)

这样会输出每个算子的转换状态，方便定位具体是哪个算子出了问题。

6.2 C++运行时常见crash

这里重点强调一个细节：rknn_outputs_get获取的输出，用完一定要调rknn_outputs_release释放。如果不释放，NPU可能认为输出缓冲区还被占用，下一次推理会一直等待，导致性能逐渐下降甚至卡死。这个问题非常隐蔽，我排查了整整一个下午才发现是内存没有释放。

6.3 性能不达标时的排查思路

如果你跑出来的帧率远低于预期，按照下面的顺序排查：

1. 先确认NPU推理本身的耗时。在rknn_run前后打点，如果推理耗时已经超过20毫秒/帧（对应50 FPS），那性能瓶颈在NPU算子优化或模型复杂度上，可以考虑换更轻量的模型如yolov8n，或者降低输入分辨率到480x480。
2. 如果推理耗时很低但整体帧率不行，说明瓶颈在数据链路。检查图像解码、缩放、格式转换这三个环节的耗时，逐一优化。
3. 查看是否有CPU频率限制。RK3588在散热条件不佳时会自动降频，可以使用cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq查看实时频率。如果长时间运行后发现性能下降，多半是过热降频，需要改善散热。
4. 打开RKNN Runtime的profiling功能：

rknn_set_flags(ctx, RKNN_FLAG_AUTO_INIT_MEM | RKNN_FLAG_ASYNC_MODE | RKNN_FLAG_PROFILE);

这个flags会在rknn_run执行时输出每个算子层级的耗时，能精确定位NPU内部的瓶颈节点。

7. 工程层面的补充建议

7.1 代码版本管理与数据流解耦

部署代码的工程化管理和PC端开发同样重要，我建议从一开始就用CMake+Git管理整个工程。尤其要注意把模型文件和数据文件分离：rknn模型文件放到单独的models目录，代码里通过相对路径动态读取。这样后续模型更新时只需要替换文件，不需要重新编译二进制。

数据流解耦是一个容易被忽略的工程点。如果检测程序要和摄像头、RTSP流或者本地视频文件对接，最好把数据源抽象成一个接口：

class VideoSource { public: virtual bool open(const std::string& uri) = 0; virtual bool read(cv::Mat& frame) = 0; virtual void close() = 0; };

实际使用时实现RTSPVideoSource和LocalVideoSource两个子类，切换数据源只需要改一行代码，不需要动核心检测逻辑。这个设计对后期的联调和部署都很友好。

7.2 多模型并发与NPU资源管理

RK3588的NPU三核架构意味着你可以同时加载多个模型。比如一个YOLOv8s做目标检测，一个轻量分类模型做目标识别，两者可以并行运行互不干扰。

实际使用时要留意的是：每个rknn_context代表一个NPU会话，不同会话之间由NPU驱动自动调度。但如果两个模型都很大，可能超过NPU内存限制，这时需要把其中一个模型改成串行推理，或者降低输入分辨率。

我做过一个测试：YOLOv8s（640x640）和MobileNetV3分类模型（224x224）同时运行，帧率分别达到了55 FPS和120 FPS，互不影响。这个并发能力在"先检测后分类"的业务场景中非常实用。

7.3 部署到生产环境的最后一步

PC上交叉编译出的可执行文件拷贝到板子上后，还需要处理几个部署细节：

• 确保板子上有librknnrt.so，并且路径在LD_LIBRARY_PATH中。
• 把rknn模型文件和可执行文件放在同一个目录下，或者通过配置文件指定模型路径。
• 建议写一个启动脚本，包含环境变量设置和程序启动参数：

#!/bin/bash export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH export RKNN_LOG_LEVEL=WARN ./rknn_yolov8 --model yolov8s.rknn --source rtsp://xxx:554/stream1

RKNN_LOG_LEVEL环境变量很实用，开发阶段设成DEBUG能看到详细的日志，部署时设成WARN或ERROR，避免日志刷屏影响性能。

我还习惯在程序里加一个SIGINT信号处理函数，保证程序在收到Ctrl+C或系统停止信号时能优雅退出，正确释放NPU资源。直接kill进程的话，NPU上下文可能没被释放，下次启动时会有异常。

8. 写在最后的一点个人总结

整个项目从零到跑通，花了我大约两个星期的时间，其中有四天是耗在模型转换的折腾上，还有两天是处理C++内存对齐的段错误。回过头来看，这个过程的每一步其实都有规律可言：RKNN工具链的算子支持和Runtime版本强绑定，遇到转换报错先查版本；C++部署的重心不在模型本身，而在数据管线和后处理解析；性能优化的顺序是数据链路优先于NPU算力。

如果你也在RK3588上做YOLOv8的C++部署，我的建议是：第一步别急着写代码，先把官方rknn_model_zoo里的yolov8例子跑通，理解它的工程结构；第二步再对照自己的模型做模型转换，用Python端验证精度；最后才动笔写C++工程。这个顺序能帮你少走至少一半的弯路。

RK3588的NPU算力虽然不是最强的，但6 TOPS的INT8算力配合完善的工具链，跑YOLOv8s这种量级的模型已经非常够用了。如果你最终决定用更轻量的YOLOv8n，帧率轻松上百不是问题，关键是数据管线和调度要做到位。希望这篇工程实践笔记能帮你顺利把模型部署到板子上，少踩几个我踩过的坑。