Ultralytics RKNNBackend 详解在瑞芯微 NPU 上运行 YOLO 推理.rknn 模型【免费下载链接】ultralyticsUltralytics YOLO26, YOLO11, YOLOv8 — object detection, instance segmentation, semantic segmentation, image classification, pose estimation, object tracking项目地址: https://gitcode.com/GitHub_Trending/ul/ultralytics本文围绕 Ultralytics 仓库中 RKNNBackend 的 API 参考展开逐方法解读RKNNBackend的load_model与forward实现并结合 ultralytics/nn/backends/rknn.py、ultralytics/nn/backends/base.py 与 ultralytics/nn/autobackend.py 的源码说明.rknn模型如何在 RockchipRK3588、RK3566 等NPU 上完成加载、推理与元数据恢复以及 INT8 量化模型的坐标还原细节帮助你在 Rockchip 边缘设备上正确部署和调试 YOLO 推理链路。RKNNBackend 类概览RKNNBackend定义在 ultralytics/nn/backends/rknn.py 中类文档字符串对其职责的表述是Rockchip RKNN inference backend for Rockchip NPU hardware. Loads and runs inference with RKNN models (.rknn files) using the RKNN-Toolkit-Lite2 runtime. Only supported on Rockchip devices with NPU hardware (e.g., RK3588, RK3566).由此可以提炼出三条关键事实它只负责运行已导出的.rknn模型不负责模型转换转换由rknn-toolkit2在 PC 侧完成导出流程见 docs/en/integrations/rockchip-rknn.md运行依赖RKNN-Toolkit-Lite2运行时rknnlite.api.RKNNLite而非桌面端的rknn-toolkit2只能在带 NPU 的 Rockchip 设备上运行如 RK3588、RK3566在 x86 PC 上会直接抛异常。类结构上它继承自 BaseBackend后者是一个抽象基类统一约定了所有推理后端必须实现的两个方法load_model(weight)从权重文件或模型目录加载推理运行时forward(im)对输入张量执行一次前向推理。BaseBackend.__init__会初始化一组公共属性stride32、names、task、batch1、channels3、end2endFalse、metadata等并在构造末尾自动调用load_model(weight)因此只要AutoBackend能路由到RKNNBackend加载过程就会自动发生无需用户显式调用。运行环境前提Rockchip 设备检测load_model的第一步是环境自检rknn.py L32-L33if not is_rockchip(): raise OSError(RKNN inference is only supported on Rockchip devices.)is_rockchip()实现于 ultralytics/utils/checks.py L1140-L1156其判定逻辑是仅在Linux ARM64环境下尝试检测LINUX and ARM64读取设备树节点/proc/device-tree/compatible取最后一个逗号分隔的 SoC 标识去掉空字符后取-之前的主型号判断该主型号是否落在白名单RKNN_CHIPS内。白名单定义在 ultralytics/utils/init.py L84-L98RKNN_CHIPS frozenset( { rk3588, rk3576, rk3566, rk3568, rk3562, rv1103, rv1106, rv1103b, rv1106b, rk2118, rv1126b, } ) # Rockchip processors available for export也就是说RKNNBackend支持的设备覆盖 RK35 系列主流芯片以及 RV11 系列工业级芯片不在这份集合中的 Rockchip 芯片哪怕有 NPU会在设备检测阶段被拒绝这是一个硬性的能力边界。load_model模型定位、运行时初始化与元数据恢复通过设备检查后load_modelrknn.py L22-L52依次完成四步def load_model(self, weight: str | Path) - None: if not is_rockchip(): raise OSError(RKNN inference is only supported on Rockchip devices.) LOGGER.info(fLoading {weight} for RKNN inference...) check_requirements(rknn-toolkit-lite2) from rknnlite.api import RKNNLite w Path(weight) if not w.is_file(): w next(w.rglob(*.rknn)) self.model RKNNLite() ret self.model.load_rknn(str(w)) if ret ! 0: raise RuntimeError(fFailed to load RKNN model: {ret}) ret self.model.init_runtime() if ret ! 0: raise RuntimeError(fFailed to init RKNN runtime: {ret}) self.apply_metadata(self.read_metadata(w))1. 依赖检查与延迟导入。check_requirements(rknn-toolkit-lite2)会在运行时自动校验必要时安装rknn-toolkit-lite2包from rknnlite.api import RKNNLite是延迟导入保证未安装该包的 PC 环境导入 Ultralytics 本身不会失败。2. 权重路径解析文件即目录皆可。入参weight既可以是.rknn文件路径也可以是包含模型的目录。当传入的是目录非文件时next(w.rglob(*.rknn))会在目录树中递归找到第一个.rknn文件。这正好对接 Ultralytics 的导出产物约定RKNN 导出的命名约定是yolo26n_rknn_model/目录见 ultralytics/nn/autobackend.py L120 的格式表RKNN | *_rknn_model/目录内同时包含模型名-平台.rknn与导出时写入的metadata.yaml。3. 两步初始化并严格校验返回码。RKNN Lite 的load_rknn()解析模型与init_runtime()初始化目标硬件运行时各自返回状态码任何一步非零都会抛出带状态码的RuntimeError便于在设备上定位是“模型文件不合法”还是“NPU 运行时不可用”例如设备缺少 RKNN 驱动时后者会失败。4. 元数据恢复。最后调用self.apply_metadata(self.read_metadata(w))。由于.rknn是二进制格式BaseBackend.read_metadatabase.py L152-L192走的是旁路 sidecar 文件分支它在模型所在目录或其上级目录寻找metadata.yaml并解析。该文件由导出侧写入参见 ultralytics/utils/export/rknn.py L82-L84if metadata: YAML.save(output_dir / metadata.yaml, metadata)forward输入格式约束与 NPU 推理forwardrknn.py L54-L81的文档字符串明确了输入约定im (torch.Tensor): Input image tensor inBHWC format, normalized to [0, 1].方法体先做张量到运行时输入格式的转换h, w im.shape[1:3] im (im.cpu().numpy() * 255).astype(uint8) im im if isinstance(im, (list, tuple)) else [im] y self.model.inference(inputsim)要点BHWC uint8RKNN NPU 的推理输入是 HxWxC 的 8 位无符号整数[0,1]浮点张量乘以 255 后转为uint8这与 NCHW/FP32 的 PyTorch、ONNX 后端形成鲜明对比。AutoBackend中通过self.nhwc format in {coreml, saved_model, pb, edgetpu, rknn}autobackend.py L263标记了这一点预测管线的预处理会据此在送入后端前完成通道布局转换归一化由导出配置承担导出侧onnx2rknn固定写入了config {mean_values: [[0, 0, 0]], std_values: [[255, 255, 255]], target_platform: name}export/rknn.py L74即“除以 255”的归一化被烘焙进了 RKNN 模型本身所以推理端只需喂原始像素值即可两侧严格互补批量输入inputsim接受列表RKNNLite.inference可对列表中的多帧做批量推理批量能力取决于导出时的batch参数。INT8 量化模型的坐标还原forward中最值得关注的是一段针对 INT8 导出的后处理rknn.py L67-L81# INT8 exports use input-relative coordinates so a single per-tensor scale preserves class scores. if ( self.metadata.get(args, {}).get(quantize) 8 and self.task in {detect, segment, pose, obb} and not self.end2end ): kpt_start 4 len(self.names) # pose keypoints follow the box (4) and class-score (nc) channels for x in y: if x.ndim 3: x[:, [0, 2]] * w x[:, [1, 3]] * h if self.task pose: x[:, kpt_start::3] * w x[:, kpt_start 1 :: 3] * h这段逻辑的触发条件有三个且都来自导出时嵌入的元数据metadata.yaml→apply_metadata恢复为实例属性args.quantize 8模型是 INT8 量化导出的任务属于detect / segment / pose / obb这些任务的原始输出里包含坐标通道not self.end2end非端到端 NMS 模型。从源码结构看这与导出侧的限制一致——ultralytics/engine/exporter.py L681-L684 明确对rknn格式禁用end2end分支“This export format does not support end2end models”因此该条件在 RKNN 导出中实际恒为 True保留它是为了与BaseBackend的通用语义对齐。为什么需要这一步注释解释了原因INT8 导出采用“相对输入的坐标”input-relative coordinates这样单个 per-tensor 量化 scale 就不会破坏类别分数class scores。代价是 NPU 输出的框坐标是归一化到输入尺寸的比例值forward需要把它们乘回真实像素值x/y通道乘宽ww/h通道乘高h。对pose任务关键点紧跟在框4 通道与类别分数nc通道之后因此用kpt_start 4 len(self.names)定位起点再按每 3 个通道一组x, y, conf分别还原 x 与 y。这段还原逻辑与导出侧一一对应导出 INT8 图时ultralytics/engine/exporter.py L1096-L1104 会在 ONNX 图中插入_NormalizeCoords节点“Normalize coordinates by input size so RKNNs per-tensor INT8 scale preserves class scores”两者共同构成“导出端归一化、推理端反归一化”的闭环。AutoBackend 如何路由到 RKNNBackend用户在 Ultralytics 中从不直接实例化RKNNBackend入口是AutoBackendultralytics/nn/autobackend.py格式识别AutoBackend的_BACKEND_MAP将rknn映射到RKNNBackendautobackend.py L167文件命名约定为*_rknn_model/目录FP16 不支持fp16 format in {pt, torchscript, onnx, openvino, engine, triton}autobackend.py L215RKNN 不在其中设备端推理的精度由导出时的quantize决定设备回落非 PyTorch 系格式在 CUDA 不可用时会自动落回cpu设备对象autobackend.py L218-L224而 RKNN 的实际执行硬件由RKNNLite.init_runtime()在 NPU 侧完成device参数更多是管线层面的记账。与导出侧的衔接.rknn 目录是怎么来的虽然本文主体是推理后端但理解导出侧能完整解释后端的行为约定。导出函数onnx2rknnultralytics/utils/export/rknn.py L16-L84的要点目标平台通过name指定默认rk3588写入target_platform配置平台精度限制rv1103 / rv1106 / rv1103b / rv1106b这四个 INT8-only 平台不做量化会直接报错必须quantize8export/rknn.py L44-L48INT8 校准quantize8时必须有校准图像列表文件datasetbuild(do_quantizationTrue, dataset...)完成后导出模型名-平台.rknn并把元数据以metadata.yaml旁路写入同一目录export/rknn.py L80-L84——这正是后端read_metadata读取的文件INT8 仅检测任务ultralytics/engine/exporter.py L720-L725 规定 RKNN INT8 导出只支持detect任务其他任务请改用 FP16quantize16批次扩展rknn_batch_size在加载 batch-1 的 ONNX 后由 RKNN Toolkit 扩展所以export_rknn中会先截取self.im self.im[:1]exporter.py L1535。导出入口的完整命令示例含name、quantize参数参见 docs/en/integrations/rockchip-rknn.md。使用方式与仓库内的验证约束在 Rockchip 设备上只要把导出的yolo26n_rknn_model/目录拷贝到板端Ultralytics 的预测/验证入口即可直接使用例如from ultralytics import YOLO model YOLO(yolo26n_rknn_model/) # 目录中自动 rglob 定位 .rknn results model.predict(bus.jpg) # 推理走 RKNN NPU仓库自身也对 RKNN 运行环境做了硬性约束可在 ultralytics/utils/benchmarks.py L170-L173 看到if export_format rknn: assert not isinstance(model, YOLOWorld), YOLOWorldv2 RKNN exports not supported yet assert LINUX, RKNN only supported on Linux assert not is_rockchip(), RKNN Inference only supported on Rockchip devices这三条 assert 给出了三条适用前提YOLO-World v2 暂不支持 RKNN 导出仅 Linux且推理必须真的在 Rockchip 板卡上执行该 benchmark 路径特意排除 Rockchip 环境因为 PC 上既不能跑rknnlite也不应跑。适用范围与限制小结综合文档与源码RKNNBackend的能力边界可以归纳为维度事实依据运行硬件仅 Rockchip 带 NPU 设备白名单RKNN_CHIPSutils/init.py L84-L98运行系统仅 Linux ARM64 路径下才会尝试设备检测checks.py L1140-L1156依赖rknn-toolkit-lite2运行时rknn.py L36-L37输入格式BHWC、[0,1]归一化张量内部转 uint8 像素精度由导出决定FP16/INT8推理端不支持 FP16 开关autobackend.py L215元数据依赖导出目录内的metadata.yamlsidecarbase.py L187-L190INT8 后处理detect/segment/pose/obb 的坐标乘回像素值pose 关键点按kpt_start定位rknn.py L67-L81端到端 NMSRKNN 格式导出时自动禁用end2endexporter.py L681-L684如果你在 Rockchip 板端调试 RKNN 推理遇到问题排查顺序建议为先确认 SoC 是否在RKNN_CHIPS白名单内 → 再确认metadata.yaml与.rknn同目录否则task、names等元数据为空后处理会退化→ 最后关注init_runtime()的返回码以区分模型问题与 NPU 驱动/运行时问题。参考文档nn.backends.rknn API Reference本类由 ultralytics/nn/backends/rknn.py 自动生成。【免费下载链接】ultralyticsUltralytics YOLO26, YOLO11, YOLOv8 — object detection, instance segmentation, semantic segmentation, image classification, pose estimation, object tracking项目地址: https://gitcode.com/GitHub_Trending/ul/ultralytics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Ultralytics RKNNBackend 详解：在瑞芯微 NPU 上运行 YOLO 推理（.rknn 模型）
Ultralytics RKNNBackend 详解在瑞芯微 NPU 上运行 YOLO 推理.rknn 模型【免费下载链接】ultralyticsUltralytics YOLO26, YOLO11, YOLOv8 — object detection, instance segmentation, semantic segmentation, image classification, pose estimation, object tracking项目地址: https://gitcode.com/GitHub_Trending/ul/ultralytics本文围绕 Ultralytics 仓库中 RKNNBackend 的 API 参考展开逐方法解读RKNNBackend的load_model与forward实现并结合 ultralytics/nn/backends/rknn.py、ultralytics/nn/backends/base.py 与 ultralytics/nn/autobackend.py 的源码说明.rknn模型如何在 RockchipRK3588、RK3566 等NPU 上完成加载、推理与元数据恢复以及 INT8 量化模型的坐标还原细节帮助你在 Rockchip 边缘设备上正确部署和调试 YOLO 推理链路。RKNNBackend 类概览RKNNBackend定义在 ultralytics/nn/backends/rknn.py 中类文档字符串对其职责的表述是Rockchip RKNN inference backend for Rockchip NPU hardware. Loads and runs inference with RKNN models (.rknn files) using the RKNN-Toolkit-Lite2 runtime. Only supported on Rockchip devices with NPU hardware (e.g., RK3588, RK3566).由此可以提炼出三条关键事实它只负责运行已导出的.rknn模型不负责模型转换转换由rknn-toolkit2在 PC 侧完成导出流程见 docs/en/integrations/rockchip-rknn.md运行依赖RKNN-Toolkit-Lite2运行时rknnlite.api.RKNNLite而非桌面端的rknn-toolkit2只能在带 NPU 的 Rockchip 设备上运行如 RK3588、RK3566在 x86 PC 上会直接抛异常。类结构上它继承自 BaseBackend后者是一个抽象基类统一约定了所有推理后端必须实现的两个方法load_model(weight)从权重文件或模型目录加载推理运行时forward(im)对输入张量执行一次前向推理。BaseBackend.__init__会初始化一组公共属性stride32、names、task、batch1、channels3、end2endFalse、metadata等并在构造末尾自动调用load_model(weight)因此只要AutoBackend能路由到RKNNBackend加载过程就会自动发生无需用户显式调用。运行环境前提Rockchip 设备检测load_model的第一步是环境自检rknn.py L32-L33if not is_rockchip(): raise OSError(RKNN inference is only supported on Rockchip devices.)is_rockchip()实现于 ultralytics/utils/checks.py L1140-L1156其判定逻辑是仅在Linux ARM64环境下尝试检测LINUX and ARM64读取设备树节点/proc/device-tree/compatible取最后一个逗号分隔的 SoC 标识去掉空字符后取-之前的主型号判断该主型号是否落在白名单RKNN_CHIPS内。白名单定义在 ultralytics/utils/init.py L84-L98RKNN_CHIPS frozenset( { rk3588, rk3576, rk3566, rk3568, rk3562, rv1103, rv1106, rv1103b, rv1106b, rk2118, rv1126b, } ) # Rockchip processors available for export也就是说RKNNBackend支持的设备覆盖 RK35 系列主流芯片以及 RV11 系列工业级芯片不在这份集合中的 Rockchip 芯片哪怕有 NPU会在设备检测阶段被拒绝这是一个硬性的能力边界。load_model模型定位、运行时初始化与元数据恢复通过设备检查后load_modelrknn.py L22-L52依次完成四步def load_model(self, weight: str | Path) - None: if not is_rockchip(): raise OSError(RKNN inference is only supported on Rockchip devices.) LOGGER.info(fLoading {weight} for RKNN inference...) check_requirements(rknn-toolkit-lite2) from rknnlite.api import RKNNLite w Path(weight) if not w.is_file(): w next(w.rglob(*.rknn)) self.model RKNNLite() ret self.model.load_rknn(str(w)) if ret ! 0: raise RuntimeError(fFailed to load RKNN model: {ret}) ret self.model.init_runtime() if ret ! 0: raise RuntimeError(fFailed to init RKNN runtime: {ret}) self.apply_metadata(self.read_metadata(w))1. 依赖检查与延迟导入。check_requirements(rknn-toolkit-lite2)会在运行时自动校验必要时安装rknn-toolkit-lite2包from rknnlite.api import RKNNLite是延迟导入保证未安装该包的 PC 环境导入 Ultralytics 本身不会失败。2. 权重路径解析文件即目录皆可。入参weight既可以是.rknn文件路径也可以是包含模型的目录。当传入的是目录非文件时next(w.rglob(*.rknn))会在目录树中递归找到第一个.rknn文件。这正好对接 Ultralytics 的导出产物约定RKNN 导出的命名约定是yolo26n_rknn_model/目录见 ultralytics/nn/autobackend.py L120 的格式表RKNN | *_rknn_model/目录内同时包含模型名-平台.rknn与导出时写入的metadata.yaml。3. 两步初始化并严格校验返回码。RKNN Lite 的load_rknn()解析模型与init_runtime()初始化目标硬件运行时各自返回状态码任何一步非零都会抛出带状态码的RuntimeError便于在设备上定位是“模型文件不合法”还是“NPU 运行时不可用”例如设备缺少 RKNN 驱动时后者会失败。4. 元数据恢复。最后调用self.apply_metadata(self.read_metadata(w))。由于.rknn是二进制格式BaseBackend.read_metadatabase.py L152-L192走的是旁路 sidecar 文件分支它在模型所在目录或其上级目录寻找metadata.yaml并解析。该文件由导出侧写入参见 ultralytics/utils/export/rknn.py L82-L84if metadata: YAML.save(output_dir / metadata.yaml, metadata)forward输入格式约束与 NPU 推理forwardrknn.py L54-L81的文档字符串明确了输入约定im (torch.Tensor): Input image tensor inBHWC format, normalized to [0, 1].方法体先做张量到运行时输入格式的转换h, w im.shape[1:3] im (im.cpu().numpy() * 255).astype(uint8) im im if isinstance(im, (list, tuple)) else [im] y self.model.inference(inputsim)要点BHWC uint8RKNN NPU 的推理输入是 HxWxC 的 8 位无符号整数[0,1]浮点张量乘以 255 后转为uint8这与 NCHW/FP32 的 PyTorch、ONNX 后端形成鲜明对比。AutoBackend中通过self.nhwc format in {coreml, saved_model, pb, edgetpu, rknn}autobackend.py L263标记了这一点预测管线的预处理会据此在送入后端前完成通道布局转换归一化由导出配置承担导出侧onnx2rknn固定写入了config {mean_values: [[0, 0, 0]], std_values: [[255, 255, 255]], target_platform: name}export/rknn.py L74即“除以 255”的归一化被烘焙进了 RKNN 模型本身所以推理端只需喂原始像素值即可两侧严格互补批量输入inputsim接受列表RKNNLite.inference可对列表中的多帧做批量推理批量能力取决于导出时的batch参数。INT8 量化模型的坐标还原forward中最值得关注的是一段针对 INT8 导出的后处理rknn.py L67-L81# INT8 exports use input-relative coordinates so a single per-tensor scale preserves class scores. if ( self.metadata.get(args, {}).get(quantize) 8 and self.task in {detect, segment, pose, obb} and not self.end2end ): kpt_start 4 len(self.names) # pose keypoints follow the box (4) and class-score (nc) channels for x in y: if x.ndim 3: x[:, [0, 2]] * w x[:, [1, 3]] * h if self.task pose: x[:, kpt_start::3] * w x[:, kpt_start 1 :: 3] * h这段逻辑的触发条件有三个且都来自导出时嵌入的元数据metadata.yaml→apply_metadata恢复为实例属性args.quantize 8模型是 INT8 量化导出的任务属于detect / segment / pose / obb这些任务的原始输出里包含坐标通道not self.end2end非端到端 NMS 模型。从源码结构看这与导出侧的限制一致——ultralytics/engine/exporter.py L681-L684 明确对rknn格式禁用end2end分支“This export format does not support end2end models”因此该条件在 RKNN 导出中实际恒为 True保留它是为了与BaseBackend的通用语义对齐。为什么需要这一步注释解释了原因INT8 导出采用“相对输入的坐标”input-relative coordinates这样单个 per-tensor 量化 scale 就不会破坏类别分数class scores。代价是 NPU 输出的框坐标是归一化到输入尺寸的比例值forward需要把它们乘回真实像素值x/y通道乘宽ww/h通道乘高h。对pose任务关键点紧跟在框4 通道与类别分数nc通道之后因此用kpt_start 4 len(self.names)定位起点再按每 3 个通道一组x, y, conf分别还原 x 与 y。这段还原逻辑与导出侧一一对应导出 INT8 图时ultralytics/engine/exporter.py L1096-L1104 会在 ONNX 图中插入_NormalizeCoords节点“Normalize coordinates by input size so RKNNs per-tensor INT8 scale preserves class scores”两者共同构成“导出端归一化、推理端反归一化”的闭环。AutoBackend 如何路由到 RKNNBackend用户在 Ultralytics 中从不直接实例化RKNNBackend入口是AutoBackendultralytics/nn/autobackend.py格式识别AutoBackend的_BACKEND_MAP将rknn映射到RKNNBackendautobackend.py L167文件命名约定为*_rknn_model/目录FP16 不支持fp16 format in {pt, torchscript, onnx, openvino, engine, triton}autobackend.py L215RKNN 不在其中设备端推理的精度由导出时的quantize决定设备回落非 PyTorch 系格式在 CUDA 不可用时会自动落回cpu设备对象autobackend.py L218-L224而 RKNN 的实际执行硬件由RKNNLite.init_runtime()在 NPU 侧完成device参数更多是管线层面的记账。与导出侧的衔接.rknn 目录是怎么来的虽然本文主体是推理后端但理解导出侧能完整解释后端的行为约定。导出函数onnx2rknnultralytics/utils/export/rknn.py L16-L84的要点目标平台通过name指定默认rk3588写入target_platform配置平台精度限制rv1103 / rv1106 / rv1103b / rv1106b这四个 INT8-only 平台不做量化会直接报错必须quantize8export/rknn.py L44-L48INT8 校准quantize8时必须有校准图像列表文件datasetbuild(do_quantizationTrue, dataset...)完成后导出模型名-平台.rknn并把元数据以metadata.yaml旁路写入同一目录export/rknn.py L80-L84——这正是后端read_metadata读取的文件INT8 仅检测任务ultralytics/engine/exporter.py L720-L725 规定 RKNN INT8 导出只支持detect任务其他任务请改用 FP16quantize16批次扩展rknn_batch_size在加载 batch-1 的 ONNX 后由 RKNN Toolkit 扩展所以export_rknn中会先截取self.im self.im[:1]exporter.py L1535。导出入口的完整命令示例含name、quantize参数参见 docs/en/integrations/rockchip-rknn.md。使用方式与仓库内的验证约束在 Rockchip 设备上只要把导出的yolo26n_rknn_model/目录拷贝到板端Ultralytics 的预测/验证入口即可直接使用例如from ultralytics import YOLO model YOLO(yolo26n_rknn_model/) # 目录中自动 rglob 定位 .rknn results model.predict(bus.jpg) # 推理走 RKNN NPU仓库自身也对 RKNN 运行环境做了硬性约束可在 ultralytics/utils/benchmarks.py L170-L173 看到if export_format rknn: assert not isinstance(model, YOLOWorld), YOLOWorldv2 RKNN exports not supported yet assert LINUX, RKNN only supported on Linux assert not is_rockchip(), RKNN Inference only supported on Rockchip devices这三条 assert 给出了三条适用前提YOLO-World v2 暂不支持 RKNN 导出仅 Linux且推理必须真的在 Rockchip 板卡上执行该 benchmark 路径特意排除 Rockchip 环境因为 PC 上既不能跑rknnlite也不应跑。适用范围与限制小结综合文档与源码RKNNBackend的能力边界可以归纳为维度事实依据运行硬件仅 Rockchip 带 NPU 设备白名单RKNN_CHIPSutils/init.py L84-L98运行系统仅 Linux ARM64 路径下才会尝试设备检测checks.py L1140-L1156依赖rknn-toolkit-lite2运行时rknn.py L36-L37输入格式BHWC、[0,1]归一化张量内部转 uint8 像素精度由导出决定FP16/INT8推理端不支持 FP16 开关autobackend.py L215元数据依赖导出目录内的metadata.yamlsidecarbase.py L187-L190INT8 后处理detect/segment/pose/obb 的坐标乘回像素值pose 关键点按kpt_start定位rknn.py L67-L81端到端 NMSRKNN 格式导出时自动禁用end2endexporter.py L681-L684如果你在 Rockchip 板端调试 RKNN 推理遇到问题排查顺序建议为先确认 SoC 是否在RKNN_CHIPS白名单内 → 再确认metadata.yaml与.rknn同目录否则task、names等元数据为空后处理会退化→ 最后关注init_runtime()的返回码以区分模型问题与 NPU 驱动/运行时问题。参考文档nn.backends.rknn API Reference本类由 ultralytics/nn/backends/rknn.py 自动生成。【免费下载链接】ultralyticsUltralytics YOLO26, YOLO11, YOLOv8 — object detection, instance segmentation, semantic segmentation, image classification, pose estimation, object tracking项目地址: https://gitcode.com/GitHub_Trending/ul/ultralytics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考