尧图网页设计 
1. 单块NPU的算力底牌6.6 TOPS到底能跑几个模型先回答大家最关心的一个问题RK3588 的 NPU 只有区区 6.6 TOPSINT8 峰值算力把人员入侵、烟火检测、垃圾分类三个模型塞进去会不会直接跑不动说实话我第一次接到这个需求时心里也打了个问号但实测下来这块 NPU 的调度弹性比想象中强。先看硬件账。RK3588 的 NPU 由三核组成单核算力 2.2 TOPS三核合计 6.6 TOPS严格来说是 6.6 TOPS INT8FP16 会折半到 3.3 TOPS 左右。这个数字放在 2025 年的大模型时代确实不够看但我们要跑的是边缘端轻量级检测任务YOLOv5s 的单帧 INT8 算力需求大约在 5~8 GOPS 量级视输入分辨率而定意味着理论上每秒能处理的帧数天花板非常高。问题的关键不在总算力而在于如何让三核干活不互相打架。我手上这套方案的模型配置是这样的人员入侵用 YOLOv5s输入分辨率 640×640烟火检测用 YOLOv8nnano 版本分辨率同样是 640×640垃圾分类用 MobileNetV3-Small 或轻量级 ShuffleNetV2输入 224×224。三个模型单帧推理耗时在板端实测分别是YOLOv5s 约 12~18msYOLOv8n 约 8~12msMobileNetV3 约 3~5ms。听起来每帧加起来才 30ms 左右理论上能跑到 30fps但这是分时复用的情况。如果要求三路视频同时处理且每路都要实时输出结果就得认真考虑并发调度策略了。这里要泼一盆冷水并发跑多个模型时NPU 的实际吞吐不会线性叠加。原因是 NPU 的任务分配器Dispatcher和内存带宽会成为瓶颈尤其是多路 RTSP 视频流同时拉流、解码、预处理时CPU 侧的压力往往比 NPU 更大。所以我的优化思路不是盲目追求并发跑满而是做算力预算——明确每个任务占用的 NPU 时间片和内存带宽再按需分配。注意6.6 TOPS 是理论峰值实际能利用的有效算力大约在 60%~70%。在做算力评估时预留 30% 的冗余是底线否则遇到复杂场景比如夜间烟火检测、密集人群容易掉帧。2. 模型选型与剪枝三个任务如何共用“一份”算力预算既然要在一颗 NPU 上同时跑三个模型模型选型就必须从“单个模型精度最高”转向“整体系统吞吐最优”。这里分享我踩过坑之后总结的三个选型原则基本可以覆盖同类多任务边缘 AI 项目的需求。2.1 检测类任务YOLO 家族怎么挑精度和速度的平衡点人员入侵和烟火检测都属于目标检测任务很多人的第一反应是直接上 YOLOv8m 甚至 YOLOv8l但在 6.6 TOPS 的算力约束下大模型一发子弹都别想打出去。我实测过 YOLOv8m 在 RK3588 NPU 上的 INT8 推理单帧 640×640 大概要 35~45ms如果两路视频同时跑就接近满载了更别说第三个分类模型还要分一杯羹。最终的方案是人员入侵用 YOLOv5s烟火检测用 YOLOv8n。选择依据很直接——算力和精度的平衡点。YOLOv5s 在 COCO 数据集上的 mAP 约 37.2val在人员检测这种大目标场景下足够用而且 RKNN-Toolkit2 对 YOLOv5 系列的算子支持最成熟量化后掉点最少。YOLOv8n 的 mAP 略低于 YOLOv5s但模型体积只有 YOLOv5s 的 1/3对烟火这种特征相对明显的目标火焰高亮、烟雾纹理来说nano 版本完全够用。模型选型时还要考虑一个容易忽略的维度目标尺寸分布。烟火检测的对象通常是大面积、区域性目标COCO 预训练权重里缺乏类似的样本所以我不建议直接拿官方权重硬上而是用自建的烟火数据集做迁移学习只微调最后几层。人员入侵则相反目标形态相对固定直接用公开的人体检测权重微调即可。2.2 分类任务MobileNetV3 还是轻量 YOLOv5n垃圾分类本质上是图像分类任务输入的是检测框裁剪出来的垃圾图片。刚开始我图省事直接用了 YOLOv5n 的检测头去做分类结果发现两个问题一是检测和分类的标签体系冲突二是 YOLO 系模型在分类任务上的效率不如专用分类网络。后来换成了 MobileNetV3-Small尺寸 224×224分类数按实际垃圾类别设置。MobileNetV3 在 RKNN-Toolkit2 中的支持度相当好量化后精度损失可以控制在 1% 以内单帧推理仅需 3~5ms。如果追求更低延迟还可以考虑 ShuffleNetV2它在 ARM CPU 上的推理速度极快但在 NPU 上的算子融合效果不如 MobileNetV3 稳定。这里有个小坑要提醒RK3588 的 NPU 对 Depthwise 卷积和 SESqueeze-and-Excitation模块的支持不如 GPU 平台的 TensorRT 那么成熟。MobileNetV3 里包含 SE 模块在 RKNN 转换时部分算子会回退到 CPU 执行导致实际耗时比理论预期高。解决办法有两个一是在训练时对 SE 模块做 Channel Pruning 或直接移除精度损失可接受二是用 RKNN 的 1.6.0 版本以上的优化算子库实测对 SE 模块的支持有明显改进。三个模型组合起来的算力预算大约如下模型任务输入分辨率INT8 单帧耗时占 NPU 算力YOLOv5s人员入侵640×64012~18ms约 45%YOLOv8n烟火检测640×6408~12ms约 25%MobileNetV3-Small垃圾分类224×2243~5ms约 10%表格里的占比是按三核 NPU 的全部算力来算的实际跑起来还要考虑前处理、后处理、内存拷贝的耗时。个人建议将 NPU 占用率控制在 70% 以内剩余算力留给系统调度和突发流量。2.3 量化与蒸馏INT8 量化是这个项目成败的隐形胜负手这是整个项目最容易被忽视的环节也是最容易翻车的环节。RK3588 的 NPU 原生支持 INT8 量化推理但直接把 PyTorch 的 FP32 模型转成 RKNN 格式后用精度掉得让你怀疑人生。正确的做法是第一使用 RKNN-Toolkit2 自带的量化工具做混合量化而不是粗暴地全 INT8。我的做法是先用典型的业务场景图片包含白天、黑夜、逆光、雨天等工况构建校准数据集数量不需要太多200~500 张足够。校准数据集的质量直接决定量化效果宁可用真实的低照度监控截图也不要用互联网高清图片。第二对于烟火焰检测模型建议做QAT量化感知训练。我这里率先体验了一把 PyTorch 的 QAT 流程在训练时插入 FakeQuantize 节点模拟 INT8 量化的精度损失训练完成后导出 ONNX 再转 RKNN。实测经过 QAT 的 YOLOv8n 在烟火场景上的 mAP 比后训练量化PTQ高出 2~3 个百分点这个差距在远距离小火焰检测上尤为明显。第三逐层检查量化敏感度。RKNN-Toolkit2 提供了逐层精度分析的接口可以输出每一层在量化前后的输出误差。通常 Detect 层的输出对量化最敏感如果发现某个层误差过大可以在转换时将该层强制保留为 FP16。我在部署垃圾分类模型时就遇到了这个问题——主干网络量化后精度几乎不掉但最后的全连接层误差偏大强制设为 FP16 后问题解决。说到这顺便提一句部署流程的时间分配。三个模型从训练到板载部署我大概用了两周半训练和微调用了 5 天转 ONNX 和 RKNN 用了 4 天量化校准和精度比对占了 3 天剩下的时间全花在板端调试和写业务代码上。很多人以为模型训练是重头戏实际上在边缘 NPU 项目里模型转换和量化调试才是真正的大坑建议从第一天就并行推进。3. 并发调度架构三核 NPU 的三种工作模式怎么选RK3588 的 NPU 虽然物理上有三个核心但对我们开发者来说它更像一个可编程的“算力池”。选对调度模式直接决定了你的三个模型是“和平共处”还是“互相挤兑”。这一节我把三种工作模式逐一拆解并给出我的最终选择。3.1 单核串行最稳但最亏的方案NK 3588 的 NPU 驱动支持将任务简单分配给单个核心多个模型在时间片上串行执行。这种方式的优点是实现简单——你把三个模型分别加载然后按顺序调用 rknn_run 即可互不干扰代码量最少。缺点是算力利用率极低。假设三路视频流同时到达每个视频流各自要跑检测和分类串行模式下总时延就是三者相加更糟糕的是内存带宽在模型切换时会频繁刷新缓存实际吞吐可能只有理论值的 40%。对于 6.6 TOPS 这种本就不富裕的算力而言这个方案只适合低并发场景比如单路视频流的 Demo 演示。3.2 三核并行手工分配算力系统复杂度直线上升NPU 驱动支持将模型指定到某个物理核心上运行于是很多人的第一反应是三个模型——三核——完美映射。烟 RK3588 NPU多模型并发部署实践：从算力预算到INT8量化
1. 单块NPU的算力底牌6.6 TOPS到底能跑几个模型先回答大家最关心的一个问题RK3588 的 NPU 只有区区 6.6 TOPSINT8 峰值算力把人员入侵、烟火检测、垃圾分类三个模型塞进去会不会直接跑不动说实话我第一次接到这个需求时心里也打了个问号但实测下来这块 NPU 的调度弹性比想象中强。先看硬件账。RK3588 的 NPU 由三核组成单核算力 2.2 TOPS三核合计 6.6 TOPS严格来说是 6.6 TOPS INT8FP16 会折半到 3.3 TOPS 左右。这个数字放在 2025 年的大模型时代确实不够看但我们要跑的是边缘端轻量级检测任务YOLOv5s 的单帧 INT8 算力需求大约在 5~8 GOPS 量级视输入分辨率而定意味着理论上每秒能处理的帧数天花板非常高。问题的关键不在总算力而在于如何让三核干活不互相打架。我手上这套方案的模型配置是这样的人员入侵用 YOLOv5s输入分辨率 640×640烟火检测用 YOLOv8nnano 版本分辨率同样是 640×640垃圾分类用 MobileNetV3-Small 或轻量级 ShuffleNetV2输入 224×224。三个模型单帧推理耗时在板端实测分别是YOLOv5s 约 12~18msYOLOv8n 约 8~12msMobileNetV3 约 3~5ms。听起来每帧加起来才 30ms 左右理论上能跑到 30fps但这是分时复用的情况。如果要求三路视频同时处理且每路都要实时输出结果就得认真考虑并发调度策略了。这里要泼一盆冷水并发跑多个模型时NPU 的实际吞吐不会线性叠加。原因是 NPU 的任务分配器Dispatcher和内存带宽会成为瓶颈尤其是多路 RTSP 视频流同时拉流、解码、预处理时CPU 侧的压力往往比 NPU 更大。所以我的优化思路不是盲目追求并发跑满而是做算力预算——明确每个任务占用的 NPU 时间片和内存带宽再按需分配。注意6.6 TOPS 是理论峰值实际能利用的有效算力大约在 60%~70%。在做算力评估时预留 30% 的冗余是底线否则遇到复杂场景比如夜间烟火检测、密集人群容易掉帧。2. 模型选型与剪枝三个任务如何共用“一份”算力预算既然要在一颗 NPU 上同时跑三个模型模型选型就必须从“单个模型精度最高”转向“整体系统吞吐最优”。这里分享我踩过坑之后总结的三个选型原则基本可以覆盖同类多任务边缘 AI 项目的需求。2.1 检测类任务YOLO 家族怎么挑精度和速度的平衡点人员入侵和烟火检测都属于目标检测任务很多人的第一反应是直接上 YOLOv8m 甚至 YOLOv8l但在 6.6 TOPS 的算力约束下大模型一发子弹都别想打出去。我实测过 YOLOv8m 在 RK3588 NPU 上的 INT8 推理单帧 640×640 大概要 35~45ms如果两路视频同时跑就接近满载了更别说第三个分类模型还要分一杯羹。最终的方案是人员入侵用 YOLOv5s烟火检测用 YOLOv8n。选择依据很直接——算力和精度的平衡点。YOLOv5s 在 COCO 数据集上的 mAP 约 37.2val在人员检测这种大目标场景下足够用而且 RKNN-Toolkit2 对 YOLOv5 系列的算子支持最成熟量化后掉点最少。YOLOv8n 的 mAP 略低于 YOLOv5s但模型体积只有 YOLOv5s 的 1/3对烟火这种特征相对明显的目标火焰高亮、烟雾纹理来说nano 版本完全够用。模型选型时还要考虑一个容易忽略的维度目标尺寸分布。烟火检测的对象通常是大面积、区域性目标COCO 预训练权重里缺乏类似的样本所以我不建议直接拿官方权重硬上而是用自建的烟火数据集做迁移学习只微调最后几层。人员入侵则相反目标形态相对固定直接用公开的人体检测权重微调即可。2.2 分类任务MobileNetV3 还是轻量 YOLOv5n垃圾分类本质上是图像分类任务输入的是检测框裁剪出来的垃圾图片。刚开始我图省事直接用了 YOLOv5n 的检测头去做分类结果发现两个问题一是检测和分类的标签体系冲突二是 YOLO 系模型在分类任务上的效率不如专用分类网络。后来换成了 MobileNetV3-Small尺寸 224×224分类数按实际垃圾类别设置。MobileNetV3 在 RKNN-Toolkit2 中的支持度相当好量化后精度损失可以控制在 1% 以内单帧推理仅需 3~5ms。如果追求更低延迟还可以考虑 ShuffleNetV2它在 ARM CPU 上的推理速度极快但在 NPU 上的算子融合效果不如 MobileNetV3 稳定。这里有个小坑要提醒RK3588 的 NPU 对 Depthwise 卷积和 SESqueeze-and-Excitation模块的支持不如 GPU 平台的 TensorRT 那么成熟。MobileNetV3 里包含 SE 模块在 RKNN 转换时部分算子会回退到 CPU 执行导致实际耗时比理论预期高。解决办法有两个一是在训练时对 SE 模块做 Channel Pruning 或直接移除精度损失可接受二是用 RKNN 的 1.6.0 版本以上的优化算子库实测对 SE 模块的支持有明显改进。三个模型组合起来的算力预算大约如下模型任务输入分辨率INT8 单帧耗时占 NPU 算力YOLOv5s人员入侵640×64012~18ms约 45%YOLOv8n烟火检测640×6408~12ms约 25%MobileNetV3-Small垃圾分类224×2243~5ms约 10%表格里的占比是按三核 NPU 的全部算力来算的实际跑起来还要考虑前处理、后处理、内存拷贝的耗时。个人建议将 NPU 占用率控制在 70% 以内剩余算力留给系统调度和突发流量。2.3 量化与蒸馏INT8 量化是这个项目成败的隐形胜负手这是整个项目最容易被忽视的环节也是最容易翻车的环节。RK3588 的 NPU 原生支持 INT8 量化推理但直接把 PyTorch 的 FP32 模型转成 RKNN 格式后用精度掉得让你怀疑人生。正确的做法是第一使用 RKNN-Toolkit2 自带的量化工具做混合量化而不是粗暴地全 INT8。我的做法是先用典型的业务场景图片包含白天、黑夜、逆光、雨天等工况构建校准数据集数量不需要太多200~500 张足够。校准数据集的质量直接决定量化效果宁可用真实的低照度监控截图也不要用互联网高清图片。第二对于烟火焰检测模型建议做QAT量化感知训练。我这里率先体验了一把 PyTorch 的 QAT 流程在训练时插入 FakeQuantize 节点模拟 INT8 量化的精度损失训练完成后导出 ONNX 再转 RKNN。实测经过 QAT 的 YOLOv8n 在烟火场景上的 mAP 比后训练量化PTQ高出 2~3 个百分点这个差距在远距离小火焰检测上尤为明显。第三逐层检查量化敏感度。RKNN-Toolkit2 提供了逐层精度分析的接口可以输出每一层在量化前后的输出误差。通常 Detect 层的输出对量化最敏感如果发现某个层误差过大可以在转换时将该层强制保留为 FP16。我在部署垃圾分类模型时就遇到了这个问题——主干网络量化后精度几乎不掉但最后的全连接层误差偏大强制设为 FP16 后问题解决。说到这顺便提一句部署流程的时间分配。三个模型从训练到板载部署我大概用了两周半训练和微调用了 5 天转 ONNX 和 RKNN 用了 4 天量化校准和精度比对占了 3 天剩下的时间全花在板端调试和写业务代码上。很多人以为模型训练是重头戏实际上在边缘 NPU 项目里模型转换和量化调试才是真正的大坑建议从第一天就并行推进。3. 并发调度架构三核 NPU 的三种工作模式怎么选RK3588 的 NPU 虽然物理上有三个核心但对我们开发者来说它更像一个可编程的“算力池”。选对调度模式直接决定了你的三个模型是“和平共处”还是“互相挤兑”。这一节我把三种工作模式逐一拆解并给出我的最终选择。3.1 单核串行最稳但最亏的方案NK 3588 的 NPU 驱动支持将任务简单分配给单个核心多个模型在时间片上串行执行。这种方式的优点是实现简单——你把三个模型分别加载然后按顺序调用 rknn_run 即可互不干扰代码量最少。缺点是算力利用率极低。假设三路视频流同时到达每个视频流各自要跑检测和分类串行模式下总时延就是三者相加更糟糕的是内存带宽在模型切换时会频繁刷新缓存实际吞吐可能只有理论值的 40%。对于 6.6 TOPS 这种本就不富裕的算力而言这个方案只适合低并发场景比如单路视频流的 Demo 演示。3.2 三核并行手工分配算力系统复杂度直线上升NPU 驱动支持将模型指定到某个物理核心上运行于是很多人的第一反应是三个模型——三核——完美映射。烟