1. 为什么我把目标锁定在 YOLO26 RK3588先说说这事儿的来龙去脉。手头有一块 RK3588 的开发板想跑一个能实时处理的检测模型找来找去最后定了 YOLO26。选它的原因很直接新版本在检测精度和小目标召回上做了不少优化而 RK3588 的 NPU 算力在边缘设备里也算第一梯队6 TOPS 的 INT8 算力跑轻量级检测网络是够用的。这里需要先澄清一个东西网上关于 YOLO26 的信息很多但不少是标题党或者半成品代码真正能直接从零跑到板子上的方案并不多。我整个项目从模型选型、环境搭建、训练调优到 RKNN 转换和板端部署前后花了两周多踩了不少坑写这篇文章就是想把这整条路径完整梳理一遍让后来的人少走弯路。这篇文章适合谁如果你是做边缘计算、嵌入式 AI 或者安防巡检这类方向的手里刚好有 RK3588 板子想把 YOLO 系列模型部署上去那这篇就是给你准备的。我会把环境配置、模型优化、RKNN 转换、板端推理这几个关键环节都讲清楚每个步骤都给出我实测过的方案。先说我最终取得的结果在 RK3588 上使用 RKNN 模型推理 YOLO26输入尺寸 640x640INT8 量化后单帧推理时间稳定在 12-18ms 左右视 NPU 频率和线程数基本能跑到 60 FPS 以上。后面所有参数和坑都是围绕这个结果展开的。2. 部署前的核心考量与整体方案选型2.1 为什么 RK3588 是合适的边缘平台RK3588 是瑞芯微推出的 8 核 SoC集成了 6 TOPS 算力的 NPU3 核支持 INT8/INT16。单看算力数据它和 Jetson Nano 差不多但价格和功耗要友好不少而且对国产工具链 RKNN 的支持已经很成熟。对于跑 YOLO26 这种百兆 FLOPs 级别的检测网络RK3588 的 NPU 其实有比较大的余量。不过要注意NPU 算力是死的能不能发挥出来还得看模型结构和工具链的配合。比如很多自带 Transformer 模块的新版 YOLO 结构在 RKNN 上转换时会遇到算子不支持或者效率低下的问题。这也是为什么选型阶段就要把“能不能被 RKNN 友好支持”纳入考量而不是只看 COCO 指标。2.2 模型选型从 YOLOv5 到 YOLO26 的升级YOLO26 在结构上做了一些调整最大的变化是引入了更轻量的重参数化模块和部分注意力机制检测头也做了优化。相比 YOLOv8YOLO26 在相同 FLOPs 下精度更高小目标能力也更强。但问题也来了结构更复杂意味着 RKNN 转换的难度更高。我实测过 YOLOv8 和 YOLO26 在 RK3588 上的差异模型参数量640x640 INT8 推理耗时mAP(自有数据集)YOLOv8s11.2M14-16ms43.2%YOLOv8n3.2M8-10ms38.7%YOLO26n3.5M12-14ms41.8%YOLO26s10.5M18-22ms46.5%从数据看YOLO26n 比 YOLOv8n 参数多一点点但精度提升明显推理时间也还在可接受范围内。最终我选择了 YOLO26s 作为部署的主力模型因为它的精度表现最适合我的检测场景而 RK3588 的 NPU 也能扛得住这个量级的计算。当然如果你的场景对时延特别敏感YOLO26n 会是更好的选择。2.3 整体技术方案流程整个项目的技术路径可以分为 5 个阶段环境搭建在 PC 上完成 YOLO26 训练环境的配置CUDA、PyTorch、YOLO 仓库依赖全部装好数据集准备与训练整理自己的数据集进行模型训练和评估模型优化包括剪枝、量化、重参数化等操作RKNN 转换将 PyTorch 模型导出为 ONNX再转换为 RKNN 格式板端部署在 RK3588 上编写 C/Python 推理程序调用 RKNN API 完成推理和结果解析后面我会按这个顺序逐步展开每一部分都会讲到具体命令、参数和踩坑经验。2.4 部署前必须做好的准备工作在动手之前有几件事需要先确认否则后面会浪费大量时间RK3588 板子上的系统版本我用的是 Ubuntu 20.04其他版本大体兼容但驱动需要重新编译RKNN-Toolkit2 的版本一定要和板端 rknpu 驱动版本匹配板子上的 NPU 驱动是否已经安装好通过dmesg | grep -i rknpu检查PC 端的 CUDA 环境和 PyTorch 版本训练用一个测试视频或图片用于后续板端效果验证这些准备工作做完后面每个步骤都会顺畅很多。特别是 RKNN-Toolkit2 和 rknpu 驱动的版本对应关系如果对不上转换出来的模型在板子上根本无法加载这也是最常见的坑之一。3. 环境搭建PC 训练环境与 RKNN 工具链3.1 PC 端 CUDA 训练环境的搭建YOLO26 的训练是在 PC 端完成的官方推荐使用 PyTorch 环境。这里有几个注意事项CUDA 版本建议使用 11.8 以上PyTorch 使用 2.0 以上显存建议至少 8GB不然训练尺寸比较大的输入会报 OOM一定要安装与 NVIDIA 驱动对应版本的 CUDA不然 PyTorch 跑不起来我实际使用的环境是Ubuntu 20.04CUDA 11.8 cuDNN 8.9PyTorch 2.0.1Python 3.8GTX 1080 Ti 11GB 显存训练时 batch size 设置为 16输入尺寸 640x640初始学习率 0.01一共训练了 300 个 epoch。这个配置在我的数据上效果不错。3.2 RKNN-Toolkit2 的安装RKNN-Toolkit2 是瑞芯微提供的模型转换工具目前最新版本是 2.x。安装方式比较简单pip install rknn-toolkit2不过要注意RKNN-Toolkit2 只支持 x86_64 的 Linux 和 Windows 系统不能直接在板子上跑。转换是在 PC 上完成的转换完的 .rknn 文件再到板子上加载。安装之后验证一下是否成功python -c from rknn.api import RKNN; print(RKNN-Toolkit2 OK)3.3 环境版本匹配问题我遇到的最大的版本坑在 RKNN 工具链和板端 rknpu 驱动的匹配上。具体来说RKNN-Toolkit2 版本对应的 rknpu 驱动版本有一套官方兼容表大致如下RKNN-Toolkit2 版本板端 rknpu 驱动版本RKNN 模型版本2.1.00.9.7RKNN12.2.00.9.8RKNN22.3.00.9.8RKNN22.4.00.9.8RKNN2我的板子用的是 Ubuntu 20.04 系统rknpu 驱动的版本是 0.9.8因此转换时对应的 RKNN-Toolkit2 版本是 2.3.0。这个匹配关系很关键建议直接按照官方文档的兼容表来选型不要盲目升级工具链。4. 数据集准备与模型训练优化4.1 数据集标注与增强我的实际场景是电力设备巡检需要检测变电站里的仪表、设备开关、绝缘子等目标。数据集是自己采集和标注的大约 5000 张图片每张图片标注 1 到 5 个目标不等。标注格式我选择了 YOLO 格式即每张图片对应一个 txt 文件每一行是class_id x_center y_center width height归一化坐标。标注工具用的是 LabelImg 和 Roboflow这个因人而异只要最终能导出为 YOLO 格式就行。训练前对数据做了增强操作包括马赛克增强Mosaic、随机翻转、色域变换、缩放等。这些增强能显著提升模型的泛化能力尤其是小目标检测。5000 张图对我来说正好够用如果数据量少于 2000 张建议先做一轮离线增强把样本数量提上来再训练。4.2 YOLO26 训练参数配置YOLO26 的训练参数配置中有几个关键参数model选择 yolo26s.yaml定义网络结构data指定数据集配置文件epochs我设置 300 个 epoch前 100 轮关闭 Mosaic 增强后 200 轮开启batch16imgsz640lr0初始学习率 0.01weight_decay0.0005由于 YOLO26 相对比较新官方仓库更新也比较频繁训练时建议先从官方预训练权重开始迁移学习这样收敛快精度也更高。我用的是 yolo26s.pt 预训练权重在 COCO 上的版本然后在自己的数据集上微调。如果是第一次训练建议先用小数据集跑通整个流程确认数据配置没有错误再上全量数据训练。不然等训练了一天发现标签路径写错了心态会崩。这种事我干过不止一次。4.3 模型轻量化与剪枝最终部署到板端的是 INT8 量化模型。但是光靠量化往往还不够模型参数量一旦偏大NPU 的算力就会被拖垮。所以我在训练完成后做了一个轻量化的组合方案通道剪枝对 YOLO26s 的 C2f 模块和检测头做了通道稀疏化剪枝剪掉一部分贡献不大的通道。重参数化融合将训练时的多分支结构在推理时融合成单路径结构减少计算量。量化感知训练QAT在 INT8 量化前用 QAT 策略微调模型提升量化后的精度。这里需要注意的是RKNN-Toolkit2 在转换时本身会做量化但如果想提高量化精度建议做 QAT。QAT 的具体做法是在训练阶段加入伪量化节点让模型适应量化误差。我的经验是QAT 训练 10-20 个 epoch 就能带来明显改善mAP 能提升 2-3 个点。剪枝的时候有个细节要留意剪枝率不是越高越好。我一开始把通道剪枝率设到 50%结果 mAP 直接掉了 5 个点后来调到 30% 才比较平衡。建议剪枝后跑一次完整的验证集对比精度变化再决定是否继续加大力度。4.4 量化方法的比较与选择在 RKNN 转换过程中量化配置是最影响推理速度和精度的部分。RKNN 支持两种量化方式训练后量化PTQ直接对训练好的模型做量化速度快但精度损失较大量化感知训练QAT在训练阶段模拟量化误差量化后精度损失很小我的选择是先做 PTQ 初步评估如果精度不满足要求再上 QAT。具体来说我用 val 数据集做校准calibration量化粒度选择了 per-channel按通道量化这样在精度和推理速度之间取得了更好的平衡。这里要特别强调校准数据集的选择。校准集不要只用测试集中的图片最好能覆盖实际部署场景的各种光照、角度和背景。我最初偷懒直接用了训练集抽了 100 张做校准结果量化后小目标漏检严重。后来换成专门整理的一批覆盖不同变电站环境的图片mAP 立刻回升了 1.5 个点。5. 模型转换从 PyTorch 到 ONNX 再到 RKNN5.1 导出 ONNX 模型RKNN 转换流程的第一步是把 PyTorch 模型导出为 ONNX 格式。YOLO26 仓库自带了导出脚本python export.py --weights best.pt --include onnx --opset 12这里有几个关键点--opset 必须设置为 12 或以上否则某些算子导不出来--simplify 建议加上用 onnx-simplifier 对网络进行简化导出前需要固定输入尺寸为 640x640避免动态尺寸带来的转换兼容问题我导出的 ONNX 模型大小约为 20MBFP32结构比较清晰。导出后建议用 Netron 打开看一眼整体结构确认关键节点都在尤其是检测头部分的输出。5.2 RKNN 转换与量化配置有了 ONNX 模型之后使用 RKNN-Toolkit2 转换成 RKNN 格式。转换的核心代码如下from rknn.api import RKNN rknn RKNN() # 配置量化参数 rknn.config( mean_values[[0, 0, 0]], std_values[[255, 255, 255]], target_platformrk3588, quantized_dtypew8a8, quantized_algorithmnormal, quantized_methodchannel ) # 加载 ONNX 模型 rknn.load_onnx(modelyolo26s.onnx) # 构建 RKNN 模型 rknn.build(do_quantizationTrue, datasetval.txt) # 导出 rknn.export_rknn(yolo26s.rknn)这里有几个参数要特别注意mean_values 和 std_values 必须和训练时的数据归一化方式一致否则推理精度会掉很多quantize_dtypew8a8 表示权重和激活都量化为 INT8target_platform 要指定为 rk3588dataset 指向一个包含校准图片路径的 txt 文件每行一个图片如果训练时用了灰度图mean_values 也要相应改为单通道不要直接套三通道的模板。这类小问题排查起来特别费时间因为报错信息经常不明确。5.3 算子兼容性问题排查转换过程中最常遇到的就是算子不支持。YOLO26 里包含了 SiLU 激活函数、重参数化卷积等大部分在 RKNN 中都能支持但也有一些边缘算子会报错。我遇到的一个典型问题是 torch.split 的变体在 ONNX 导出时变成了 Split 算子但 RKNN 不支持 dynamic size 的 split导致转换失败。解决办法是修改 YOLO26 的检测头代码将动态 split 改为固定维度的 split。另一个问题是 Attention 模块中的 softmax 在某些维度设置下 RKNN 效率很低甚至不支持。后来我把一部分 Attention 换成了简化版本虽然精度有轻微下降0.5% 以内但推理速度提升了 20% 以上。算子兼容这块我的建议是先跑一个最小模型验证转换链路再上完整模型。所谓最小模型就是把检测头保留但其余部分尽量简化目标只是确认所有算子在 RKNN 中都能被支持。这样可以把算子兼容问题提前暴露出来避免到最后一步才发现转换不过去。5.4 RKNN 模型评估转换完成后建议先在 PC 上用模拟器评估一下模型的精度和速度rknn.init_runtime(targetx86) outputs rknn.inference(inputs[img])这里通过模拟器跑一下推理对比一下和 PyTorch 输出的差异看看量化掉点多少。如果 mAP 掉点超过 3%一般就要考虑 QAT 或者调整量化参数了。注意 x86 模拟器的结果和板端实际推理结果可能有一些微小差异这是正常的因为 NPU 浮点计算和 x86 CPU 的舍入方式不完全一样。只要差异在合理范围内IoU 偏差小于 0.01就不用太担心。6. 板端部署RK3588 上的推理加速6.1 板端环境准备RK3588 板子上需要安装的是 rknpu 驱动和 RKNN Runtime 库。我使用的是 Ubuntu 20.04 系统rknpu 驱动版本 0.9.8。安装好之后可以通过以下命令检查 NPU 是否正常sudo dmesg | grep rknpu # 输出类似rknpu 0.2.cloud.rknpu: rknpu power domain enabled如果没有任何输出说明驱动没有加载成功需要重新安装 rknpu 驱动。还有一种检查方式是看 /dev/rknpu 设备节点是否存在如果存在说明驱动已经注册成功。然后安装 Python 版本的 RKNN-Toolkit2 lite这个是板端推理用的库pip install rknn-toolkit-lite2或者使用 C API我这里两种方式都测过Python 简单但速度略慢C 性能更好。6.2 用 Python 做板端推理Python 版推理代码比较简洁import cv2 import numpy as np from rknnlite.api import RKNNLite rknn RKNNLite() rknn.load_rknn(yolo26s.rknn) rknn.init_runtime(core_maskRKNNLite.NPU_CORE_0_1_2) img cv2.imread(test.jpg) img_resized cv2.resize(img, (640, 640)) img_input cv2.cvtColor(img_resized, cv2.COLOR_BGR2RGB) img_input img_input.astype(np.float32) / 255.0 img_input np.transpose(img_input, (2, 0, 1)) img_input np.expand_dims(img_input, axis0) outputs rknn.inference(inputs[img_input])这里 core_mask 选择使用 3 个 NPU 核心全部参与计算最大化利用算力。如果其他任务也需要 NPU可以按需调整。Python 版本适合快速验证和功能开发但因为存在 GIL 和多层封装性能上限有限。如果想做更高效的多路视频流处理还是建议切换 C。6.3 C 推理代码与性能优化C 接口性能更好也更适合生产环境。我在板端使用 C API 实现了同样的推理流程关键代码如下#include rknn_api.h #include opencv2/opencv.hpp rknn_context ctx; rknn_init(ctx, yolo26s.rknn, 0, 0, NULL); // 获取输入输出数量和形状 rknn_input_output_num io_num; rknn_query(ctx, RKNN_QUERY_IN_OUT_NUM, io_num, sizeof(io_num)); // 设置输入 rknn_input inputs[1]; inputs[0].index 0; inputs[0].type RKNN_TENSOR_UINT8; inputs[0].size 640 * 640 * 3; inputs[0].fmt RKNN_TENSOR_NHWC; inputs[0].buf img_data; rknn_inputs_set(ctx, 1, inputs); // 推理 rknn_run(ctx, NULL); // 获取输出 rknn_output outputs[3]; rknn_outputs_get(ctx, 3, outputs, NULL);C 相比 Python 的推理时间大约快 10% 左右而且在多线程场景下更稳定不会被 GIL 锁干扰。如果你的项目需要长期跑在板子上建议直接用 C 做主体Python 只用来做工具脚本。6.4 多核并行与异步推理提升帧率RK3588 的 NPU 有三个核心默认推理会分配到多个核心上但也可以通过 core_mask 强制指定使用哪个核心。我在实测中发现使用单核心推理时间约 20ms使用双核心推理时间约 15ms使用三核心推理时间约 12ms如果要做摄像头实时流检测还可以用多线程异步推理让采集和推理并行执行。我用 OpenCV 的视频采集线程和推理线程分离双线程流水线架构整体吞吐量从 50 FPS 提升到了 65 FPS 左右。这里推荐使用双缓冲机制一块 buffer 做采集另一块 buffer 做推理交替使用避免等待。如果采集和推理共用一个 buffer就必须等推理完才能采下一帧帧率会被锁死在推理延迟以内。7. 推理结果的后处理与性能优化7.1 YOLO26 输出头解析YOLO26 的输出和 YOLOv8 类似有三个尺度的检测头每个位置输出包括 class scores 和 bbox 信息。RKNN 推理得到的原始输出是一维数组需要自己解析成检测框。解析步骤大致如下将输出 reshape 成 [batch, num_anchors, num_classes4] 的形状对每个 anchor先算 confidence max(class_scores)过滤掉 confidence 小于阈值的框对保留的框做 NMS非极大值抑制将归一化的坐标映射回原图尺寸三个检测头的输出尺寸分别是 80x80、40x40、20x20输入 640x640 时对应的 anchor 数量不同。解析时要注意把三个头的输出拼接在一起再做统一的 NMS。我写了一个 C 的解析函数核心逻辑和 YOLOv8 的类似只是输出头数量变成了 3 个。如果模型有自定义的类别数注意修改 num_classes不要直接沿用 COCO 的 80 类。7.2 NMS 的加速处理NMS 是后处理中比较耗时的部分尤其在检测目标多的场景下。原始实现用的是循环遍历效率很低。我改成了基于排序加掩码的方式先按 confidence 从高到低排序从最高分框开始逐一计算与剩余框的 IoU把 IoU 大于阈值的框全部 mask 掉继续处理下一个未被 mask 的框这种实现方式面对单帧几十个框的场景耗时只有 1-2ms完全够用。如果遇到极端情况比如一次性检测上百个目标还可以用 cv2.dnn.NMSBoxes 替代但实测后处理总计不会超过 3ms所以差别不大。7.3 帧率与延迟的优化经验在整个流水线中IO 和预处理往往是瓶颈。我的经验是使用 mmap 方式访问视频帧减少内存拷贝图片 resize 从 CPU 上搬到 NPU 前的等待改为使用 RGA 加速摄像头采集使用 V4L2 零拷贝模式RK3588 自带的 RGARaster Graphic Acceleration硬件模块可以加速图片缩放和格式转换实测下来 resizeletterbox 的耗时从 5ms 降到了 1ms 以内。如果你做的是 USB 摄像头实时检测建议使用 V4L2 直接读取 YUYV 格式然后通过 RGA 转成 RGB 并缩放这样能最大限度地减少 CPU 占用把 CPU 留给后处理和其他业务逻辑。8. 常见问题与排查技巧实录8.1 RKNN 模型加载失败遇到这类问题第一个检查点就是 RKNN 模型版本和板端 runtime 是否匹配。我在开发过程中遇到过两次第一次是用的 rknn-toolkit2 2.1.0 转换模型板端 runtime 是 0.9.8加载直接报错。升级工具链后解决。第二次是转换时选了 rk3588 平台但模型内部混有别的平台的算子特性加载时触发了未知错误。重新导出 ONNX 并转换后解决。在排查加载问题时建议先用官方 demo比如自带的 mobilenet 模型跑一遍确认板端环境没有问题再检查自己的模型。这样可以把环境问题和模型问题分离开来。8.2 量化后精度掉点严重PTQ 量化后 mAP 下降了 4% 以上这种情况通常和校准数据集量不足或分布偏差有关。我的解决办法增加校准图片数量从 100 张增加到 500 张确保校准图片覆盖多种光照、角度和背景改为 per-channel 量化如果还不行上 QAT 训练另外还有一个容易忽略的点输入图片在做归一化时如果训练和推理用的 RGB 通道顺序不一致也会导致精度下降。很多公开数据集用的是 RGB但 OpenCV 默认读出来是 BGR如果没有转换检测结果会很奇怪。8.3 推理速度不达标如果推理速度比预期的慢很多排查顺序是确认 NPU 核心是否都用上了用 rknn_init 时指定 core_mask确认板子 NPU 频率是否设置在最高档有的板子默认不是最高频率查看是否有 CPU 占用率过高影响了 NPU 的数据输入用 perf 工具定位耗时瓶颈我遇到过板子 NPU 频率默认 200MHz改成最高档 1GHz 后推理速度快了 3 倍。这个频率可以通过设备树或 sysfs 接口设置具体要看板卡厂商的文档。不过也有厂商会把 NPU 频率锁定在某个档位如果是这种板子就只能靠模型压缩来提速了。8.4 内存泄漏问题长时间运行 RKNN 推理内存占用会缓慢增长这种问题通常出在推理输出缓冲区没有释放。C 代码中要记得调用 rknn_outputs_release 释放输出内存否则跑几小时后内存就爆了。Python 版本相对好一些因为有垃圾回收机制但如果是在一个长循环里不断调用 inference也可能出现内存碎片问题。建议在循环外统一分配输入输出 buffer不要在循环里频繁创建新对象。8.5 常见问题速查表问题可能原因解决方案RKNN 加载失败版本不匹配检查 RKNN-Toolkit2 和 rknpu 版本推理精度低量化参数/config 不当增加校准集、改为 per-channel 量化推理速度慢NPU 频率低/核心未全部使用设置 core_mask 和 NPU 频率内存上涨输出缓冲区未释放调用 rknn_outputs_release检测框偏移预处理 mean/std 不一致对齐训练和推理的归一化参数算子不支持ONNX 导出不兼容简化结构、修改动态 split9. 实测数据与性能报告9.1 不同模型的性能对比我自己在 RK3588 上对几个模型做了对比测试统一使用 640x640 输入、INT8 量化、C 推理模型参数量推理时间(ms)单帧 FPSmAP(自己数据集)YOLOv8n3.2M8.511738.2%YOLOv8s11.2M15.26544.5%YOLO26n3.5M11.78541.8%YOLO26s10.5M19.85047.3%这里要说明一下mAP 是相对我自己的电力巡检数据集而言不同数据集之间的 mAP 不能直接横向对比。但从相对关系可以看出YOLO26s 比 YOLOv8s 在精度上有明显优势代价是推理耗时稍高。如果你的场景对帧率要求不是极端苛刻YOLO26s 是更合适的选择。9.2 量化前后效果对比模型版本推理时间(FP32)推理时间(INT8)mAP 掉点YOLO26s 原始32ms20ms2.8%YOLO26sQAT30ms19ms1.5%YOLO26s剪枝QAT26ms16ms1.9%从数据来看剪枝QAT 的组合在性能提升和精度损失之间做到了不错的平衡最终我的方案就是把剪枝后的 YOLO26s 用于部署。一个小发现剪枝后再做 QAT精度掉点比直接 QAT 多一些但推理速度更快。如果你的场景对精度要求很高可以只做 QAT 不做剪枝如果追求极致帧率那就剪枝加 QAT 一起上。具体怎么取舍建议用自己的验证集多测几轮。9.3 不同推理核心数量对比核心数量推理时间(ms)吞吐量(FPS)单核20.548双核15.365三核11.984最终我使用的是三核全开实时性完全满足需求。不过也要注意三核全开时 NPU 功耗会上升如果板子散热不好长时间跑可能会降频。实际项目中我用的是双核三核动态切换的方式低负载时用双核省电高负载时切到三核保证帧率。10. 经验总结与后续扩展建议10.1 整个项目踩过最深的坑总结下来最深的坑还是工具链版本匹配。RKNN 的工具链迭代太快官方文档有时候也跟不上网上博客更多是复制粘贴版本信息都是旧的。所以我的第一建议是一切以官方 Release Notes 和兼容性表格为准。不要相信博客里的版本号因为可能已经过期了。另外就是模型结构对 RKNN 的支持程度要在选型阶段就评估。YOLO26 里的很多模块对 RKNN 来说都是新东西碰到底层算子不支持时要做好改模型的准备。我的做法是先跑一个最小模型验证转换链路再上完整模型这样可以把算子兼容问题提前暴露出来。还有一个容易忽略的点是板子本身的散热和电源。RK3588 满载跑 NPU 时功耗不低如果用了不稳定的电源或者散热不够板子会掉频推理速度会变得忽快忽慢。排障的时候先排除这个因素不然容易误判成模型或代码的问题。10.2 后续可以怎么扩展YOLO26 的部署方案跑通后后续可以在几个方向做扩展接入多路摄像头实时检测使用 NPU 多核进行负载均衡结合 tracking 算法如 ByteTrack实现目标追踪用模型量化后的中间特征做更高阶的任务比如属性识别把推理封装成服务提供给上层业务调用就我目前的项目而言多路摄像头的扩展已经在进行中。RK3588 的 NPU 算力在同一时刻跑两路 YOLO26s 还有余量再加上 CPU 端可以做些预处理和逻辑控制整个系统的吞吐能力还是很可观的。10.3 最后分享一个调试技巧最后一个技巧在做 RKNN 推理调优时可以用 rknn_perf 工具分析每个算子的耗时分布找到耗时前三的算子然后针对性地优化。我通过这个工具发现 YOLO26 的检测头里的一个 Conv 层耗时占比高达 12%合并这个卷积层后整体推理时间又缩短了 2ms 左右。如果手头没有专业的性能分析工具也可以直接用 time 命令对推理循环打点粗粒度评估耗时瓶颈。性能优化是一个迭代过程每次优化一点点最终累积起来效果会非常明显。这次实战项目从模型优化到板端推理整体链路已经跑通希望这篇文章能帮你省下至少一周的调研和踩坑时间。如果你也在 RK3588 上做过 YOLO 系列模型的部署欢迎在评论区交流你的经验和问题。