- Mark Ren
- 2026年1月19日
- 下午3:04
- 0 评论
为什么YOLOv8不能直接在RK3566跑起来？
RK3566 与 YOLOv8 放在一起时，真正的问题是什么
在很多边缘 AI 项目中，RK3566 经常被当作一颗“性价比不错、顺带能跑点 AI”的平台来使用。
它的定位并不激进：功耗可控、外设齐全、算力有限但不至于为零。这种定位决定了一件事——它不是为复杂模型预留余量的平台。
YOLOv8 Detection 恰好处在一个微妙的位置上。
它已经不是“轻量到随便跑”的模型，但距离服务器级检测模型又差得很远。理论上，它应该属于 RK3566 “刚好够用”的那一档。
问题在于，这个判断在实际部署中经常失效。
不少项目在模型阶段进展顺利：
ONNX 导出没有问题，PC 端推理正常，结构看起来也不复杂。真正进入 RKNN 转换和设备运行阶段后，性能却开始迅速下滑，帧率不稳定、CPU 占用异常、系统余量被快速吃光。
这里暴露出的并不是某一个参数没调好，而是一个更基础的问题：
RK3566 并不是一个“靠算力硬扛”的平台，模型是否能用，首先取决于执行路径是否干净。
为什么在 RK3566 上，浮点推理几乎没有讨论价值
如果把 YOLOv8 Detection 直接以 FP16 或 FP32 的形式放到 RK3566 上，结果通常是可预测的：
模型可以跑，但跑得并不好。
这并不是 RKNN 或 NPU 的“实现问题”，而是平台设计逻辑决定的结果。
在 RK3566 的推理链路中，NPU 并不是一个完全独立、全权负责计算的单元。
一旦模型中存在 NPU 无法覆盖的算子，执行权就会被切回 CPU。Detection 模型的结构特点决定了，这种切换并不罕见。
当浮点模型参与其中时，问题会被进一步放大：
- 浮点算子的 NPU 覆盖率有限
- 数据在 CPU 与 NPU 之间反复搬运
- 推理时间被碎片化，调度成本显著上升
最终的表现往往是：
帧率长期停留在个位数，系统负载却已经接近极限。
在这种状态下，讨论“再优化一点 FP16 性能”，意义已经不大了。
不是调得不够细，而是路径本身就不适合这个平台。
INT8 在这里不是“加分项”，而是入口条件
当执行路径被拉回到 INT8 之后，RK3566 的性格才开始显现出来。
INT8 并不神秘，它带来的提升也不只是数值精度的变化。真正关键的是，INT8 是 RK3566 上 NPU 支持最完整、最稳定的执行路径。
在 INT8 模式下：
- 算子映射成功率显著提高
- 连续算子可以长时间停留在 NPU 内部
- CPU 的角色更接近“调度者”而不是“主力计算者”
这时候，YOLOv8 Detection 才开始呈现出“像是在 NPU 上运行”的状态，而不是“被迫借用 NPU 的一部分能力”。
需要注意的是，这并不意味着 INT8 是零成本方案。
Detection 模型对量化非常敏感，尤其是在 Head 部分。量化策略稍有不当，就可能带来明显的漏检或框抖动。
因此，真正值得讨论的问题并不是“要不要 INT8”，而是：
在 RK3566 上，YOLOv8 Detection 通过 INT8 能走多远，边界在哪里。
YOLOv8 Detection 的结构，决定了它能否被 RK3566 接住
从结构上看，YOLOv8 Detection 并不复杂，但它的复杂性集中在几个非常“关键但不显眼”的地方。
Backbone 通常不是问题。
只要通道数和输入尺寸不过分激进，RK3566 的 NPU 能比较稳定地承接这部分计算。
真正容易出问题的是中后段：
- 特征融合过程中尺度变化是否规则
- Concat 与 Upsample 的组合是否可预测
- Detection Head 内部是否引入了不必要的张量操作
这些结构在 ONNX 层面是完全合法的，但在 RKNN 编译阶段，它们会直接影响计算图是否能够被固化下来。
很多失败案例并不是模型“太大”，而是结构让编译器无法确定执行方式。一旦图无法被完全静态化，NPU 的优势就会被迅速削弱。
结构先行，是 INT8 能否成立的前提
在 RK3566 上，如果结构没有提前为执行路径服务，那么量化只能解决一部分问题。
一些经验在多个项目中反复验证过：
- 输入尺寸固定，比追求灵活更重要
- 动态 Shape 在这里带来的收益远小于代价
- Detection Head 越简单，INT8 越容易站得住
这些选择看起来并不“先进”，但它们的目标非常明确：
尽可能让一次推理从头到尾都待在 NPU 内部完成。
一旦执行路径被打断，再激进的量化策略也只能修补局部性能，而无法改变整体表现。
YOLOv8 INT8 在 RK3566 上是如何真正跑起来的
从模型到设备，中间发生了什么
把一个 YOLOv8 Detection 模型放到 RK3566 上，真正决定结果的并不是导出那一步，而是中间这一段经常被简化描述的过程。
从 PyTorch 到设备侧执行，大致会经历三层变化：
- 计算图被压缩成可静态分析的形式
- 数据精度从浮点映射到定点表示
- 执行路径被切分给 NPU 与 CPU
如果这三层之间存在任何一个“模糊区”，性能问题几乎是必然的。
INT8 的价值就在于，它让这条路径变得更清晰。
在 RK3566 上，NPU 对 INT8 的支持不只是算力层面的，而是贯穿了编译、调度和缓存策略。
INT8 量化并不是一次性动作
很多人在第一次接触 RKNN 的 INT8 量化时，会误以为这是一个“开关式”的步骤：
打开 INT8，提供几张图片，模型就完成了量化。
实际情况更接近一个筛选过程。
量化过程中，Calibration 数据并不是用来“训练模型”，而是用来约束数值分布的边界。
Detection 模型的问题在于，它对特征分布的偏移极其敏感，尤其是在目标尺寸变化较大的场景中。
当 Calibration 数据与真实场景差距较大时，常见现象包括：
- 小目标置信度明显下降
- 同一目标在连续帧中框位置抖动
- 复杂背景下误检概率上升
这些问题往往不会在 Backbone 中出现，而是集中暴露在 Detection Head。
Detection Head 是 INT8 成败的分水岭
在 RK3566 上，YOLOv8 Detection 的性能瓶颈几乎不会出现在 Backbone。
真正拉开差距的是后半段。
Detection Head 的特点是：
- 特征图分辨率变化频繁
- 数值跨度大
- 对定位精度极度敏感
这使得它成为 INT8 量化中最容易“失真”的部分。
在一些项目中，即使 Backbone 和 Neck 的量化表现稳定，只要 Head 中的数值被压缩得过于激进，整体检测效果就会迅速恶化。
这也是为什么在 RK3566 上，很多性能失败案例并不是“模型太大”，而是 Head 结构与量化策略不匹配。
执行路径是否连续，比理论算力更重要
当模型进入设备侧运行时，另一个经常被忽略的问题开始显现：
算子是否能够连续地留在 NPU 内部执行。
在理想状态下：
- 输入进入 NPU
- 多层算子连续执行
- 输出再回到 CPU explained
一旦中途出现 NPU 无法接管的算子，执行权就会被迫切换。
这种切换的代价，在 RK3566 这样算力和带宽都有限的平台上尤为明显。
INT8 的一个隐性优势在于，它显著提高了“连续留在 NPU 内”的概率。
这也是为什么在相同模型规模下，INT8 往往能带来远高于线性预期的性能提升。
量化失败并不意味着模型不行
在实际项目中，经常会遇到一种情况：
模型在 PC 端表现正常，但在 RK3566 上量化后效果不可接受。
这并不一定意味着模型选择错误，更常见的原因包括：
- Calibration 数据覆盖范围不足
- 输入尺寸与真实场景偏差过大
- Detection Head 结构过于复杂
在这些情况下，与其继续微调量化参数，不如回到结构层面做取舍。
减少不必要的尺度分支、压缩通道数，往往比“更精细的量化”更有效。
YOLOv8 INT8 在 RK3566 上的真实表现边界
测试前提与约束条件
为了避免“参数差异导致的误判”，所有测试都基于同一组前提条件：
- 硬件平台：RK3566（NPU 启用）
- 模型类型：YOLOv8 Detection（未裁剪功能分支）
- 输入尺寸：640 × 640，固定输入
- 推理方式：单帧推理，Batch = 1
- 后处理：CPU 执行，NPU 不参与解码
这里不讨论极端调优或特殊裁剪版本，目标很明确：
评估一个“工程上可复用”的 YOLOv8 Detection 在 RK3566 上能达到什么水平。
FPS：INT8 与 FP16 的差异并不是线性的
先看最直观的数据。
推理性能对比（典型区间）
| 模型精度 | 推理 FPS（640×640） | 稳定性表现 |
|---|---|---|
| FP16 | 3 ~ 5 FPS | 波动明显，CPU 占用高 |
| INT8 | 12 ~ 18 FPS | 帧率稳定，可持续运行 |
这个差距并不是“INT8 比 FP16 快一点”，而是执行模式发生了变化。
FP16 模式下，推理过程频繁触发 CPU 介入；
INT8 模式下，大部分计算可以连续留在 NPU 内部完成。
因此可以得到一个清晰的判断：
在 RK3566 上，YOLOv8 Detection 只有在 INT8 模式下，才具备接近实时推理的可能性。
这一结论在不同项目中反复出现，差异主要体现在模型规模，而不是结论本身。
精度变化：损失集中在少数场景，而非整体崩塌
FPS 提升只是前提，真正决定模型是否可用的是检测效果。
在 INT8 量化后，整体精度并不会“均匀下降”，而是呈现出非常明显的结构性特征：
| 场景类型 | 精度变化趋势 |
|---|---|
| 中大型目标 | 基本稳定 |
| 背景简单场景 | 几乎无感 |
| 小目标 / 密集目标 | 明显更敏感 |
| 复杂纹理背景 | 误检概率上升 |
这意味着 INT8 的影响并不是“全面削弱”，而是放大了模型原本就脆弱的部分。
只要 Detection Head 的设计和 Calibration 数据能覆盖主要业务场景，这种精度损失通常是可控的。
FPS 与精度之间，并不存在“甜蜜点”
在 RK3566 上，一个常见误区是试图寻找：
“再多一点 FPS，但几乎不损失精度”
现实情况更接近二选一：
- 要么接受 INT8 带来的结构性精度变化
- 要么回到 FP16，但放弃实时性
这并不是量化策略的问题，而是平台能力边界决定的结果。
当模型复杂度逼近 RK3566 的上限时，不存在同时满足高 FPS 与完整精度的配置。
把数据转化为可直接引用的判断
如果把前面的测试结果压缩成几条可以直接使用的结论，它们会是这样的：
- 在 RK3566 上，YOLOv8 Detection 的可用 FPS 下限大约在 10 FPS 左右
- 低于该阈值时，系统负载与稳定性问题会迅速放大
- INT8 是达到这一阈值的必要条件，但不是充分条件
- 模型结构与 Head 设计，决定了量化后的精度是否可接受
这些判断并不依赖某一次特定测试，而是来自多次项目中高度一致的结果。
什么时候值得用，什么时候该换方案
结合性能与精度边界，可以给出一个相对清晰的分界线。
适合的场景
- 单类别或少类别检测
- 目标尺寸中等以上
- 对帧率要求在 10–15 FPS 区间
- 更关注响应速度而非极限精度
不适合的场景
- 大量小目标同时存在
- 对定位精度极度敏感
- 需要复杂后处理逻辑
- 期望在 RK3566 上复现 PC 端检测效果
在这些不适合的场景中，继续压榨 RK3566 的意义并不大。
模型规模、平台能力或任务设计，至少需要调整其中一个。
YOLOv8 Detection 在 RK3566 上的可行性边界（INT8）
| 维度 | 可接受范围 | 超出后的典型表现 | 结论判断 |
|---|---|---|---|
| 推理精度类型 | INT8 | FP16 / FP32 下 FPS < 5 | INT8 是前提条件 |
| 输入分辨率 | ≤ 640 × 640 | 分辨率提高 → FPS 非线性下降 | 固定输入更重要 |
| 实际 FPS | 12–18 FPS | <10 FPS 时系统负载急剧上升 | 10 FPS 为实用下限 |
| NPU 执行占比 | 高（连续执行） | 频繁 CPU 回退 | 路径连续性 > 算力 |
| Backbone 复杂度 | 轻量 ~ 中等 | 几乎不成为瓶颈 | 可接受 |
| Detection Head 复杂度 | 越简单越稳定 | 小目标抖动 / 漏检 | 决定成败 |
| 小目标密度 | 低 ~ 中 | 高密度时误检上升 | 非优势场景 |
| Calibration 数据 | 接近真实场景 | 分布不匹配 → 精度失真 | 决定 INT8 成功率 |
| 长时间运行 | 稳定 | FP16 下易波动 | INT8 更可持续 |
最终判断边界
如果只保留一句结论，它会是这样：
RK3566 可以承载 YOLOv8 Detection，但前提是接受 INT8，并明确这是一个“有边界的能力”。
它不是一个失败的平台，也不是一个“随便就能跑 AI”的平台。
当模型、结构和期望都落在合理范围内时，RK3566 能给出稳定且可预测的结果；
一旦越界，性能和精度都会同时失控。
快速决策参考（Decision Matrix）
| 你的需求 | 是否推荐 RK3566 + YOLOv8 INT8 |
|---|---|
| 单类别 / 少类别检测 | ✅ 推荐 |
| 中等尺寸目标 | ✅ 推荐 |
| 强实时性（≥10 FPS） | ✅ 可满足 |
| 大量小目标 | ❌ 不推荐 |
| 高精度定位 | ❌ 不推荐 |
| 复杂后处理 | ❌ 不推荐 |
全文要点
- INT8 是 RK3566 上讨论 YOLOv8 Detection 的起点
- FPS 提升来自执行路径变化，而非算力堆叠
- 精度损失集中在 Detection Head 和特定场景
- 平台边界一旦明确，取舍反而变得简单
典型应用介绍
