写这篇分享之前先说一下背景。我手里这块RK3588开发板已经吃灰了快一个月之前一直拿它跑一些简单的OpenCV demo总觉得有点浪费这颗8核NPU 6 TOPS算力的SoC。直到最近接了个边缘计算盒子的预研需求要在板端实时跑YOLOv8做目标检测才正经把从模型训练到C推理上板整个链路完整走了一遍。这中间踩了不少坑尤其是模型转换格式和C工程里张量内存对齐的问题折腾了好几个晚上。今天把整个过程和关键细节整理出来给打算在RK3588上部署YOLOv8的朋友做个参考。这篇内容适合谁如果你是刚接触RK3588 NPU部署、对RKNN工具链还不太熟或者已经能跑通Python推理但想转成C工程上生产环境那这篇文章应该能帮你省下至少一周的试错时间。我会从硬件特性、工具链选型、模型转换、C工程实现、性能调优、常见坑六个方面完整展开所有步骤都是我实测跑通的。1. 项目概述为什么选择RK3588跑YOLOv81.1 硬件平台核心参数RK3588是瑞芯微推出的一款旗舰级SoC我之前在选型的时候对比过好几款边缘计算芯片最后敲定它主要是因为几个硬指标CPU部分采用4核Cortex-A762.4GHz 4核Cortex-A551.8GHz的big.LITTLE架构算力足够跑复杂的图像预处理和多线程调度。NPU算力6 TOPSINT8支持混合量化对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编译出的二进制文件启动快、内存可控、没有解释器依赖部署到客户的设备上省心得多。所以我的选型很明确模型转换和验证用Pythonrknn-toolkit2推理和后处理用CRKNN 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 modelyolov8s.pt formatonnx opset12 simplifyTrue这个命令有几个隐含的配置点opset12我试过opset 13和14转换到RKNN时会报一些算子不兼容的warning用opset 12最稳妥。simplifyTrue会调用onnx-simplifier对模型结构进行简化去掉一些冗余的Reshape、Cast操作减少算子数量转换后的NPU推理速度会快一些。imgsz默认是640建议不要改RK3588跑640x640输入是性能和精度的平衡点。补充一个细节导出ONNX时模型的输出会是一个包含三个特征图的列表形状分别是[1, 84, 8400]、[1, 84, 8400]、[1, 84, 8400]如果输入是640x640yolov8的三个检测头融合后总共输出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_platformrk3588 ) ret rknn.load_onnx(modelyolov8s.onnx) ret rknn.build(do_quantizationTrue, datasetdataset.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_quantizationTrue表示使用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.soCMakeLists.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参数有个讲究。如果设为1RKNN Runtime会把INT8输出自动反量化为float方便你直接解析但会增加额外的计算开销。如果设为0拿到的是原始INT8数据需要手动结合量化参数scale和zero_point反量化。实测下来手动反量化的速度至少快一倍所以生产环境建议设0。4.3 后处理实现解析输出与NMSYOLOv8的C后处理是整个项目中最容易写错的部分我来拆解一下思路。模型输出是三个特征图每个特征图的通道数为844个坐标 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] 是每个输出通道的量化scaleqnt_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, hNMS之前需要转换成左上角和右下角坐标格式x1, y1, x2, y2映射回原图尺寸时乘上缩放比例即可。YOLOv8的类别得分不需要经过softmax。训练时用的是BCE loss输出经过sigmoid后就是0-1之间的概率直接取最大值比softmax省事且结果更准。NMS实现用的是标准IoU计算类别间互相独立。我用的是最简单朴素的排序循环在8400个候选框全部进入NMS的情况下单次耗时大约5毫秒左右已经是够用了。如果后续觉得不够快可以考虑用TensorRT里面那种网格NMS的优化思路但现阶段没必要。最后根据自己的业务场景调一下conf_threshold和nms_threshold。我这边检测目标是行人和车辆用的conf_threshold0.25、nms_threshold0.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_quantizationFalse重新转一个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转换阶段的典型报错报错信息可能原因解决方案E RKNN: Output [xxx] has mismatch shapeONNX导出时模型输入输出shape不符合RNNK要求检查opset版本尝试换成12再导出E RKNN: Cannot find OP: xxx in any format模型中包含NPU不支持的算子升级rknn-toolkit2版本或修改模型算子W RKNN: The input shape of the layer [resize] is abnormalUpsample算子的scale参数异常用simplify导出ONNX消除动态shapeE RKNN: Build failed with code: 3量化数据集有问题检查dataset.txt路径和图片格式Run time error: Invalid RKNN model filerknn模型和Runtime版本不匹配统一工具链和Runtime版本为1.6.0转换阶段如果卡住了可以打开调试日志rknn.config(verboseTrue)这样会输出每个算子的转换状态方便定位具体是哪个算子出了问题。6.2 C运行时常见crash现象可能原因解决方案调用rknn_run后程序崩溃输入buffer大小不对或格式错误检查输入尺寸是否与模型输入一致确认fmt是否为RKNN_TENSOR_NHWC偶发段错误无固定复现路径输出buffer内存对齐不足使用aligned_alloc(16, size)分配输出buffer推理结果全为0模型加载失败或权重文件损坏检查rknn_init返回值确保rkn模型完整高频调用下性能逐渐下降没有释放每次推理的临时内存检查是否调用了rknn_outputs_release程序退出时卡死RKNN上下文未正确释放在退出前调用rknn_destroy(ctx)这里重点强调一个细节rknn_outputs_get获取的输出用完一定要调rknn_outputs_release释放。如果不释放NPU可能认为输出缓冲区还被占用下一次推理会一直等待导致性能逐渐下降甚至卡死。这个问题非常隐蔽我排查了整整一个下午才发现是内存没有释放。6.3 性能不达标时的排查思路如果你跑出来的帧率远低于预期按照下面的顺序排查先确认NPU推理本身的耗时。在rknn_run前后打点如果推理耗时已经超过20毫秒/帧对应50 FPS那性能瓶颈在NPU算子优化或模型复杂度上可以考虑换更轻量的模型如yolov8n或者降低输入分辨率到480x480。如果推理耗时很低但整体帧率不行说明瓶颈在数据链路。检查图像解码、缩放、格式转换这三个环节的耗时逐一优化。查看是否有CPU频率限制。RK3588在散热条件不佳时会自动降频可以使用cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq查看实时频率。如果长时间运行后发现性能下降多半是过热降频需要改善散热。打开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端开发同样重要我建议从一开始就用CMakeGit管理整个工程。尤其要注意把模型文件和数据文件分离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内存限制这时需要把其中一个模型改成串行推理或者降低输入分辨率。我做过一个测试YOLOv8s640x640和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_LEVELWARN ./rknn_yolov8 --model yolov8s.rknn --source rtsp://xxx:554/stream1RKNN_LOG_LEVEL环境变量很实用开发阶段设成DEBUG能看到详细的日志部署时设成WARN或ERROR避免日志刷屏影响性能。我还习惯在程序里加一个SIGINT信号处理函数保证程序在收到CtrlC或系统停止信号时能优雅退出正确释放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帧率轻松上百不是问题关键是数据管线和调度要做到位。希望这篇工程实践笔记能帮你顺利把模型部署到板子上少踩几个我踩过的坑。