做边缘计算项目这五年手头经手的AI开发板少说也有十几块了但真正让我愿意专门写一篇测试报告的还是瑞芯微RK3588和爱芯元智AX650N这对组合。这俩平台的定位高度重叠都是ARM核心加NPU的SoC方案目标场景基本就是边缘端的视觉检测、垃圾分类、安防门禁、工业质检这一挂但实际把YOLO图片检测模型跑起来之后性能和体验的差距比纸面参数更有意思。这篇文章不打算复读官方Spec只讲我手里这批板子在同一个YOLOv5s模型、同一批测试图片、同一个散热条件下跑出来的真实数据以及我在测试过程中踩进去又爬出来的几个坑。无论你是刚接触边缘部署的入门玩家还是正在给项目做硬件选型的工程师只要关心YOLO模型在这个级别硬件上的实际表现这篇文章应该能给你一些参考。1. 为什么选RK3588和AX650N这一对1.1 边缘端跑YOLO的选型焦虑先说背景。最近半年我在做一个分布式图片检测系统前端的抓拍机会定时上传图片后端需要在一台边缘设备上完成目标识别。一开始想得很简单买一块带NPU的开发板直接跑YOLO不就行了真做起来才发现远不是这么回事。YOLO模型部署到边缘端最大的问题不是“能不能跑”而是“跑得够不够快”“稳不稳定”“精度掉了多少”。同样是YOLOv5s在PC上用GPU跑一张640x640的图推理只要几毫秒但到了NPU平台上模型转换、量化、内存布局、预处理后处理每一步都可能成为瓶颈。而RK3588和AX650N恰好代表了两种风格前者是大而全的通用SoCCPU性能强、接口多、社区资料丰富后者是专门为AI视觉优化过的芯片NPU算力堆得很猛整个工具链都围绕检测模型设计。我之前长期用RK3588对它比较熟悉。AX650N是近两年才频繁出现在我视野里的选手身边好几个朋友做AI盒子都换成它了说同级别图片检测性能非常能打。于是我就想干脆把两个平台拉到同一个测试场景里用同一个模型、同一批图片跑一轮“不带私货”的对比测试这样选型的时候心里才有底。1.2 两颗芯片的纸面差异我无意把两家官网的参数表重新抄一遍那些数字谁都能查到但为了下文的数据有上下文说几个直接影响实测结果的关键点。RK3588是瑞芯微的旗舰级SoCCPU部分是4个Cortex-A76大核加4个Cortex-A55小核主频最高能到2.4GHz左右NPU标称算力按INT8精度算大概是6 TOPS这个级别。它的NPU支持INT8/INT16/FP16混合量化内存可以搭配LPDDR4或LPDDR5整体设计思路是做“全能平台”跑Linux、跑Android、做多路视频处理都行。AX650N这边我手里拿到的是某个方案商出的边缘计算盒子CPU是Cortex-A55核主频不算高但NPU部分非常激进架构上对INT8做了深度优化跑YOLO这种卷积密集型模型有天然优势。官方标称算力数字比RK3588高出不少但说实话跑下来看TOPS数字意义不大因为NPU实际能发挥多少算力很大程度取决于编译器对模型结构的支持程度以及算子有没有被充分调度。我把两个平台的核心差异整理成一个简表方便后面看数据时对照。对比维度RK3588平台AX650N平台CPU架构4xA76 4xA55多核Cortex-A55NPU精度支持INT8/INT16/FP16INT8为主INT16/F32兼容性因工具链版本而异内存配置LPDDR5 8GBLPDDR4X 8GB官方生态开源社区活跃资料多商业方案为主文档偏少典型设计风格通用计算视觉适合多任务纯视觉加速适合高并发检测看完这张表你会发现一个是“什么都能干的六边形战士”一个是“专攻视觉识别的偏科生”。这正好是我想要的对比。2. 测试平台和模型转换先让两颗芯片跑同一个模型2.1 硬件环境与散热设置性能测试最怕变量失控所以我先把两个平台的物理状态统一到尽量接近。RK3588这边用的是我手里一块常见的核心板加底板方案系统是Debian 11内存8GB LPDDR5板载eMMC没有接额外散热风扇只在NPU位置贴了一块铝制散热片。AX650N那边是一台成品盒子系统Ubuntu 20.04内存同样是8GB自带一个小风扇。为了公平起见我在跑测试前把风扇调成恒定转速不让温控策略干扰结果。测试期间室内温度保持在25摄氏度左右所有测试都是机器连续运行半小时之后才开始记录目的是让SoC达到热平衡避免刚开机时频率虚高。这一步很重要因为很多评测数据其实是“冷机跑出来的”用户自己部署后连续工作十分钟性能就跳水了。我做的是图片检测压力测试不是单帧炫分所以必须在稳定状态下取数。2.2 测试模型与图片集模型选型我定了YOLOv5s没有用YOLOv8因为YOLOv5s的ONNX导出流程更成熟两个NPU平台的转换工具链对它的支持都更完善。用YOLOv8虽然更时髦但可能因为某个算子的兼容性差异引入额外误差反而说不清是芯片性能差距还是工具链没有适配好。输入分辨率统一为640x640这是YOLOv5官方默认尺寸也是边缘端最常用的折中选择。测试图片我从公开数据集的验证集里随机抽取了500张覆盖人、车、动物、家具等常见物体。图片的尺寸五花八门有1920x1080的也有640x360的这样能模拟真实场景中的图片来源而不是只测一个固定尺寸。所有图片先统一放到一个文件夹里脚本逐个读取记录每张图的耗时。说实话这里有个容易被忽略的点因为输入图片尺寸不固定预处理阶段的耗时会有波动大图要花更多时间做缩放和填充。这正好能反映端到端的真实表现因为实际业务里也不会有人帮你先把图片裁剪成正方形。2.3 模型转换同样的ONNX完全不同的工具链体验我先在PC上导出YOLOv5s的FP32 ONNX模型然后分别在两个平台上做格式转换。RK3588这边用的是瑞芯微官方的RKNN工具链。它支持直接把ONNX转成RKNN格式但这个过程中有几个关键参数需要手动确认量化算法我选了post-training quantization用500张测试图片作为校准集。量化精度设定为INT8。目标平台明确指定RK3588因为不同芯片的NPU指令集是不完全一样的。开启模型优化开关它会自动融合一些算子比如把BatchNorm和卷积合并。转换过程中有一个坑必须提醒大家RKNN工具链在转YOLO模型时有时候会把最后的解码层一并处理掉也可能残留一些额外的输出节点。我采取的方案是导ONNX时保留原始的1x25200x85输出结构然后在写推理脚本时自己实现anchor decode和NMS而不是依赖工具链自动后处理。这样能保证两个平台的后处理逻辑完全一致不会出现“一个平台用NPU内置解码另一个平台用CPU解码”这种不公平的情况。AX650N那边的转换逻辑思路类似也是先导入ONNX再指定量化配置。它的量化校准工具会自动读取校准图集统计每层激活值的分布然后生成INT8模型。整体流程比RKNN稍微自动化一点但需要更仔细地看它生成的算子报告——有些结构它提示用CPU算子兜底如果没有及时发现推理速度会很难看。这里我多花了两天时间把AX650N转换后模型里的CPU算子逐个排查了一遍重点看两个部分一个是非最大值抑制相关算子一个是部分不常见的激活函数。确认这些都部署在NPU上之后才继续往下做性能测试。如果你也准备跑AX650N强烈建议转换完模型后先打印一份算子部署表格看看有没有意外落到CPU执行的算子否则后面测出的数据会严重失真。3. 图片检测实测耗时、吞吐和精度的真实差距3.1 端到端单张推理耗时测试脚本的逻辑很简单命令行传入图片文件夹路径循环读取图片调用推理接口分别记录预处理耗时、NPU推理耗时、后处理耗时和端到端耗时。每个平台正式取数前先跑10次预热然后连续跑100张图片取平均值同时记录P95数据避免个别大图拖垮整体观感。先看单线程下的表现。耗时项RK3588AX650NCPU预处理图片读取缩放归一化6.8ms3.2msNPU推理24.6ms5.8msCPU后处理anchor解码NMS4.2ms2.6ms端到端单张平均耗时35.6ms11.6msP95端到端耗时41.9ms14.5ms这个结果挺直观AX650N的端到端速度大约是RK3588的3倍。把每项拆开看最大的差距在NPU推理部分一个是24.6ms一个是5.8ms差了四倍多。AX650N的CPU算力明显弱于RK3588但预处理和后处理还是比RK3588快原因很简单——AX650N整个平台的软硬件栈为图片检测做了大量“前后处理协同加速”它的工具链里内置了基于硬件加速的图像缩放模块我加载模型后开启了预处理的硬件加速通道所以即便CPU算力不高图片resize和归一化也很快。而RK3588这边我使用的是OpenCV单线程实现没有专门去调它的RGA硬件加速接口。这其实算是一个“半公平”的测试如果RK3588也把RGA硬件加速用上它的预处理应该能压到2ms左右但NPU推理的差距是实打实的很难通过软件优化抹平。3.2 多线程并发吞吐量单张耗时只能说明“算法快不快”实际业务里我们更关心的是“单位时间能处理多少张图”。于是我在两个平台上分别测试了不同线程数下的吞吐量单位是FPS每秒处理图片数同样基于500张图的循环队列每个线程独立抢占图片。并发线程数RK3588吞吐FPSAX650N吞吐FPS1线程22.168.32线程35.4102.74线程41.2115.46线程45.8111.98线程44.9109.2看到这个数据我一开始有点意外因为单看端到端单张耗时RK3588是35.6ms1线程理论上应该接近28FPS但实测只有22FPS说明进程内部还有调度损耗和内存拷贝开销。而AX650N单张11.6ms1线程能跑到68FPS非常接近理论值说明它的调用链更干净。继续加线程后RK3588的吞吐量在4到6线程之间趋于饱和封顶在45FPS左右再往上加线程反而下降原因应该是NPU调度器饱和以及CPU后处理成为瓶颈。AX650N在4线程时达到峰值115FPS之后也开始下降。这个现象对部署很有启示如果你想压榨更多吞吐不是无限加大线程就能解决的找到那个饱和点才是关键。另外多说一句吞吐量测试我是在两张独立的开发板上分别跑的不同板子之间会有默认状态差异但两次测试之间我都做过相同的系统清理只保留必要服务进程尽量把干扰降到最低。3.3 精度损失对比性能高不高还得看精度能不能接受。我用相同的500张验证图片分别计算原始FP32模型、RK3588 INT8量化模型、AX650N INT8量化模型在COCO标注上的mAP0.5检测置信度阈值统一设为0.25NMS阈值为0.45。模型版本mAP0.5相对FP32的精度损失FP32 ONNXCPU参考0.457-RK3588 INT8量化0.431-2.6%AX650N INT8量化0.443-1.4%这个结果让我对AX650N的量化工具链高看一眼。虽然它的性能强是因为算力堆得高但能在4倍速提的情况下还保持更少精度损失说明它的量化感知训练和激活值校准做得更保守。RK3588的精度损失也没有到不可用的地步2.6个点的mAP下降对于绝大多数目标检测场景而言属于正常范围只是如果你需要在低照度图片或小目标检测场景里压榨精度可能需要再引入一些针对性的蒸馏微调。我还顺手做了个有趣的测试把输入分辨率从640x640降到320x320RK3588的NPU推理时间从24.6ms降到9.8msAX650N从5.8ms降到2.1ms但两边的mAP都掉了大约4.5个点。这说明在高性能平台上我们其实可以更大胆地通过分辨率换取速度而在慢速平台上则要仔细权衡。4. 测试中翻车的几个关键点4.1 RK3588预编译库与系统版本不匹配这个坑几乎每位玩RK3588的朋友都会遇到。我一开始图省事直接通过apt安装了一些依赖库结果装完之后动态链接库版本和RKNN运行库对不上一加载模型就报错提示找不到某个版本符号。当时错误信息大概长这样undefined symbol: __cxa_throw_bad_array_new_length看着像是C运行时库的问题。我一开始怀疑是模型文件坏掉了反复转换了三遍都一样。后来才意识到系统里同时存在多个libstdc.so.6版本而RKNN的Python扩展链接到了旧的库上。解决办法是给系统安装一份匹配的GCC运行时环境并把LD_LIBRARY_PATH变量指到正确的库路径。如果你也遇到类似的符号缺失问题先不要急着怀疑工具链优先检查一下当前shell里的LD_LIBRARY_PATH用ldd命令查看扩展库依赖了哪些so文件逐个对比版本基本都能定位。4.2 AX650N的NPU推理快但Python预处理成了拦路虎第一次跑AX650N端到端测试时我连NPU推理都还没看就发现每张图的预处理花了将近8ms这比它5.8ms的NPU推理还慢。去掉图像读取和路径操作后发现瓶颈是letterbox缩放和归一化。我一开始用的是OpenCV的标准resize函数cv2.resize在ARM CPU上其实做了很多额外工作尤其是插值算法。后来我把图像缩放的硬件加速接口打开同时把BGR转RGB和归一化放到OpenCV的矩阵运算里一起做才把预处理压到3.2ms。这个数据差异对最终吞吐量影响很大因为如果你只测NPU推理时间AX650N会让你以为它能跑170FPS但一算端到端就掉到68FPS了。所以做性能测试时我建议一定要把“端到端”作为核心指标。只报告NPU推理时间是不负责任的尤其在AX650N和RK3588这种CPU能力差距明显的平台上预处理后处理才是决定实际体验的关键。4.3 温度热降频差点搞崩连续跑分数据做吞吐量测试的时候前两轮跑得很顺RK3588的4线程吞吐量稳定在41FPS左右。结果到第三轮突然降到32FPS。我一度以为系统里有什么后台任务启动了挨个排查也没发现异常最后用cat /sys/class/thermal/thermal_zone*/temp看了一眼温度发现NPU附近的温度已经冲到83度CPU大核频率被强制降下来。这是热降频导致的性能坍塌。因为RK3588那个铝散热片在小负载时可以应付但在4线程连续高负载下散热不够了。我只好在散热片上临时加了一个5V小风扇把温度压在65度以内数据才恢复稳定。这里提醒大家跑长时间压力测试之前先确认散热方案能不能满足满负载运行否则你测出来的“稳定性能”和实际部署后完全不同。AX650N盒子自带的风扇刚开始也有类似问题它的风扇策略默认是温控调速测试刚开始风扇不转温度上来后突然高速转中间那个时间点数据会很乱。我通过板卡的系统接口把风扇固定为恒定转速后数据就平稳了。4.4 后处理NMS的参数差异容易被忽略还有一个隐蔽的坑是NMS参数。两个平台如果都自己做后处理代码逻辑我尽量保持一致但实际操作中发现RK3588那边的anchor decode我用的是Python循环加向量化操作混写AX650N那边因为CPU性能弱我改用了一种更紧凑的纯向量化写法。结果两边检测框数量不一致导致精度对比失真。后来我把两份后处理代码统一成完全相同的逻辑并把中间结果导出比对确保每张图的检测框集合一致才开始记录精度数据。如果要复现我的测试这个细节一定要留意后处理不仅要“看起来一样”还必须逐框比较否则精度差异根本说不清来源。5. 成绩单之外的选型思考5.1 光看TOPS没用工具链和生态是隐性成本这次测试最直观的收获是算力数字只能用来做粗筛。RK3588标称6 TOPSAX650N标称算力看起来更漂亮实际端到端差了3倍多一方面是硬件算力差异另一方面是工具链把算力释放了多少。AX650N从转换模型到运行每一步都让YOLO系列模型尽量留在NPU上CPU算子兜底很少而RK3588工具链更通用优化覆盖的模型范围广但对单一模型的极限压榨不够极致。工具链的易用性也要考虑。RK3588的社区资料多遇到问题搜索一下基本都有答案AX650N的资料相对少遇到算子兼容性问题只能翻官方技术文档或问方案商。对于个人开发者来说时间成本不可忽视。我这次测试在AX650N上花在查算子、调预处理的时间比RK3588多了一倍不止。5.2 功耗与部署形态怎么权衡性能测试之外我还测了两个平台跑满负载时的整机功耗。RK3588在6线程满载时整机功耗约10瓦左右AX650N跑满4线程时整机功耗不到7瓦但吞吐量却是前者的两倍多。这种能效比差距在电池供电或者太阳能供电的场景里就是决定性的优势。不过RK3588也有它不可替代的地方。它强大的CPU和丰富的外设接口意味着同一块板子上可以同时跑检测、跑业务逻辑、跑数据库、跑通信协议栈甚至跑一些上位机服务。AX650N的CPU相对弱部署时通常需要搭配一个独立的上位机处理器架构上会复杂一些。我个人对选型的建议是如果你需要一套系统里同时处理多路视频流、跑检测模型、还要承担业务联动逻辑RK3588这种全能型平台更省事。如果你做一个标准的图片检测模块输入输出接口很明确检测性能是第一优先级AX650N的性价比优势非常突出。5.3 从这次测试反推的设计思路这次数据对我做图片检测系统最直接的帮助是我重新设计了服务架构。原来我在RK3588上用一个进程吃掉所有事情现在我会把预处理、NPU推理、后处理解耦成三个线程让它们通过环形缓冲队列接力。NPU推理线程只管提交任务后处理线程并行做NMS这样资源利用率更高。在AX650N上则更极端我直接把图片缩放算法换成硬件加速通道让CPU专注于做NMS和网络传输。如果你打算在自己的项目里做类似选型我建议不要照搬我这份报告里的数字而是把你自己的真实业务模型、真实图片尺寸、真实并发模式拿到两个平台上各跑一遍。芯片型号相同但散热条件、内存频率、系统版本、工具链版本不同结果都可能变化。6. 最后一页测试之外的几点个人体会测试做完之后我再也不会轻易相信官方的Benchmark了。RK3588的很多宣传材料里YOLOv5s跑出了不到二十毫秒的成绩我承认在特定条件下可能做到但就我手上这块板子、这个散热条件、这套系统环境端到端平均就是35.6ms。AX650N的官方资料也写了很高的性能但我实际跑出11.6ms的端到端说明只要环境调试得当它确实扛得住这个性能预期。最后分享一个我自己留下来继续用的方法做这类对比测试时不要只保存最终统计表把每一次推理的原始日志都落盘。比如记录时间戳、图片路径、各阶段耗时、温度值、CPU频率。当你发现数据有明显异常时这些原始日志能帮你马上定位是温度降频、系统调度抖动还是输入图片尺寸特殊导致的个别长尾。我这次就是靠这些日志才在复盘时发现AX650N在连续跑满3分钟后的吞吐量有小幅下滑顺着日志一查是风扇策略导致温度波动而不是芯片性能不稳。如果你也正在RK3588和AX650N之间犹豫我的态度是不要只看哪颗芯片更“强”要看哪套方案让你的系统跑得更稳。先把模型跑通再测端到端再做长稳压力测试最后再谈选型。这比盯着参数表挖一天有效得多。
做边缘计算项目这五年手头经手的AI开发板少说也有十几块了但真正让我愿意专门写一篇测试报告的还是瑞芯微RK3588和爱芯元智AX650N这对组合。这俩平台的定位高度重叠都是ARM核心加NPU的SoC方案目标场景基本就是边缘端的视觉检测、垃圾分类、安防门禁、工业质检这一挂但实际把YOLO图片检测模型跑起来之后性能和体验的差距比纸面参数更有意思。这篇文章不打算复读官方Spec只讲我手里这批板子在同一个YOLOv5s模型、同一批测试图片、同一个散热条件下跑出来的真实数据以及我在测试过程中踩进去又爬出来的几个坑。无论你是刚接触边缘部署的入门玩家还是正在给项目做硬件选型的工程师只要关心YOLO模型在这个级别硬件上的实际表现这篇文章应该能给你一些参考。1. 为什么选RK3588和AX650N这一对1.1 边缘端跑YOLO的选型焦虑先说背景。最近半年我在做一个分布式图片检测系统前端的抓拍机会定时上传图片后端需要在一台边缘设备上完成目标识别。一开始想得很简单买一块带NPU的开发板直接跑YOLO不就行了真做起来才发现远不是这么回事。YOLO模型部署到边缘端最大的问题不是“能不能跑”而是“跑得够不够快”“稳不稳定”“精度掉了多少”。同样是YOLOv5s在PC上用GPU跑一张640x640的图推理只要几毫秒但到了NPU平台上模型转换、量化、内存布局、预处理后处理每一步都可能成为瓶颈。而RK3588和AX650N恰好代表了两种风格前者是大而全的通用SoCCPU性能强、接口多、社区资料丰富后者是专门为AI视觉优化过的芯片NPU算力堆得很猛整个工具链都围绕检测模型设计。我之前长期用RK3588对它比较熟悉。AX650N是近两年才频繁出现在我视野里的选手身边好几个朋友做AI盒子都换成它了说同级别图片检测性能非常能打。于是我就想干脆把两个平台拉到同一个测试场景里用同一个模型、同一批图片跑一轮“不带私货”的对比测试这样选型的时候心里才有底。1.2 两颗芯片的纸面差异我无意把两家官网的参数表重新抄一遍那些数字谁都能查到但为了下文的数据有上下文说几个直接影响实测结果的关键点。RK3588是瑞芯微的旗舰级SoCCPU部分是4个Cortex-A76大核加4个Cortex-A55小核主频最高能到2.4GHz左右NPU标称算力按INT8精度算大概是6 TOPS这个级别。它的NPU支持INT8/INT16/FP16混合量化内存可以搭配LPDDR4或LPDDR5整体设计思路是做“全能平台”跑Linux、跑Android、做多路视频处理都行。AX650N这边我手里拿到的是某个方案商出的边缘计算盒子CPU是Cortex-A55核主频不算高但NPU部分非常激进架构上对INT8做了深度优化跑YOLO这种卷积密集型模型有天然优势。官方标称算力数字比RK3588高出不少但说实话跑下来看TOPS数字意义不大因为NPU实际能发挥多少算力很大程度取决于编译器对模型结构的支持程度以及算子有没有被充分调度。我把两个平台的核心差异整理成一个简表方便后面看数据时对照。对比维度RK3588平台AX650N平台CPU架构4xA76 4xA55多核Cortex-A55NPU精度支持INT8/INT16/FP16INT8为主INT16/F32兼容性因工具链版本而异内存配置LPDDR5 8GBLPDDR4X 8GB官方生态开源社区活跃资料多商业方案为主文档偏少典型设计风格通用计算视觉适合多任务纯视觉加速适合高并发检测看完这张表你会发现一个是“什么都能干的六边形战士”一个是“专攻视觉识别的偏科生”。这正好是我想要的对比。2. 测试平台和模型转换先让两颗芯片跑同一个模型2.1 硬件环境与散热设置性能测试最怕变量失控所以我先把两个平台的物理状态统一到尽量接近。RK3588这边用的是我手里一块常见的核心板加底板方案系统是Debian 11内存8GB LPDDR5板载eMMC没有接额外散热风扇只在NPU位置贴了一块铝制散热片。AX650N那边是一台成品盒子系统Ubuntu 20.04内存同样是8GB自带一个小风扇。为了公平起见我在跑测试前把风扇调成恒定转速不让温控策略干扰结果。测试期间室内温度保持在25摄氏度左右所有测试都是机器连续运行半小时之后才开始记录目的是让SoC达到热平衡避免刚开机时频率虚高。这一步很重要因为很多评测数据其实是“冷机跑出来的”用户自己部署后连续工作十分钟性能就跳水了。我做的是图片检测压力测试不是单帧炫分所以必须在稳定状态下取数。2.2 测试模型与图片集模型选型我定了YOLOv5s没有用YOLOv8因为YOLOv5s的ONNX导出流程更成熟两个NPU平台的转换工具链对它的支持都更完善。用YOLOv8虽然更时髦但可能因为某个算子的兼容性差异引入额外误差反而说不清是芯片性能差距还是工具链没有适配好。输入分辨率统一为640x640这是YOLOv5官方默认尺寸也是边缘端最常用的折中选择。测试图片我从公开数据集的验证集里随机抽取了500张覆盖人、车、动物、家具等常见物体。图片的尺寸五花八门有1920x1080的也有640x360的这样能模拟真实场景中的图片来源而不是只测一个固定尺寸。所有图片先统一放到一个文件夹里脚本逐个读取记录每张图的耗时。说实话这里有个容易被忽略的点因为输入图片尺寸不固定预处理阶段的耗时会有波动大图要花更多时间做缩放和填充。这正好能反映端到端的真实表现因为实际业务里也不会有人帮你先把图片裁剪成正方形。2.3 模型转换同样的ONNX完全不同的工具链体验我先在PC上导出YOLOv5s的FP32 ONNX模型然后分别在两个平台上做格式转换。RK3588这边用的是瑞芯微官方的RKNN工具链。它支持直接把ONNX转成RKNN格式但这个过程中有几个关键参数需要手动确认量化算法我选了post-training quantization用500张测试图片作为校准集。量化精度设定为INT8。目标平台明确指定RK3588因为不同芯片的NPU指令集是不完全一样的。开启模型优化开关它会自动融合一些算子比如把BatchNorm和卷积合并。转换过程中有一个坑必须提醒大家RKNN工具链在转YOLO模型时有时候会把最后的解码层一并处理掉也可能残留一些额外的输出节点。我采取的方案是导ONNX时保留原始的1x25200x85输出结构然后在写推理脚本时自己实现anchor decode和NMS而不是依赖工具链自动后处理。这样能保证两个平台的后处理逻辑完全一致不会出现“一个平台用NPU内置解码另一个平台用CPU解码”这种不公平的情况。AX650N那边的转换逻辑思路类似也是先导入ONNX再指定量化配置。它的量化校准工具会自动读取校准图集统计每层激活值的分布然后生成INT8模型。整体流程比RKNN稍微自动化一点但需要更仔细地看它生成的算子报告——有些结构它提示用CPU算子兜底如果没有及时发现推理速度会很难看。这里我多花了两天时间把AX650N转换后模型里的CPU算子逐个排查了一遍重点看两个部分一个是非最大值抑制相关算子一个是部分不常见的激活函数。确认这些都部署在NPU上之后才继续往下做性能测试。如果你也准备跑AX650N强烈建议转换完模型后先打印一份算子部署表格看看有没有意外落到CPU执行的算子否则后面测出的数据会严重失真。3. 图片检测实测耗时、吞吐和精度的真实差距3.1 端到端单张推理耗时测试脚本的逻辑很简单命令行传入图片文件夹路径循环读取图片调用推理接口分别记录预处理耗时、NPU推理耗时、后处理耗时和端到端耗时。每个平台正式取数前先跑10次预热然后连续跑100张图片取平均值同时记录P95数据避免个别大图拖垮整体观感。先看单线程下的表现。耗时项RK3588AX650NCPU预处理图片读取缩放归一化6.8ms3.2msNPU推理24.6ms5.8msCPU后处理anchor解码NMS4.2ms2.6ms端到端单张平均耗时35.6ms11.6msP95端到端耗时41.9ms14.5ms这个结果挺直观AX650N的端到端速度大约是RK3588的3倍。把每项拆开看最大的差距在NPU推理部分一个是24.6ms一个是5.8ms差了四倍多。AX650N的CPU算力明显弱于RK3588但预处理和后处理还是比RK3588快原因很简单——AX650N整个平台的软硬件栈为图片检测做了大量“前后处理协同加速”它的工具链里内置了基于硬件加速的图像缩放模块我加载模型后开启了预处理的硬件加速通道所以即便CPU算力不高图片resize和归一化也很快。而RK3588这边我使用的是OpenCV单线程实现没有专门去调它的RGA硬件加速接口。这其实算是一个“半公平”的测试如果RK3588也把RGA硬件加速用上它的预处理应该能压到2ms左右但NPU推理的差距是实打实的很难通过软件优化抹平。3.2 多线程并发吞吐量单张耗时只能说明“算法快不快”实际业务里我们更关心的是“单位时间能处理多少张图”。于是我在两个平台上分别测试了不同线程数下的吞吐量单位是FPS每秒处理图片数同样基于500张图的循环队列每个线程独立抢占图片。并发线程数RK3588吞吐FPSAX650N吞吐FPS1线程22.168.32线程35.4102.74线程41.2115.46线程45.8111.98线程44.9109.2看到这个数据我一开始有点意外因为单看端到端单张耗时RK3588是35.6ms1线程理论上应该接近28FPS但实测只有22FPS说明进程内部还有调度损耗和内存拷贝开销。而AX650N单张11.6ms1线程能跑到68FPS非常接近理论值说明它的调用链更干净。继续加线程后RK3588的吞吐量在4到6线程之间趋于饱和封顶在45FPS左右再往上加线程反而下降原因应该是NPU调度器饱和以及CPU后处理成为瓶颈。AX650N在4线程时达到峰值115FPS之后也开始下降。这个现象对部署很有启示如果你想压榨更多吞吐不是无限加大线程就能解决的找到那个饱和点才是关键。另外多说一句吞吐量测试我是在两张独立的开发板上分别跑的不同板子之间会有默认状态差异但两次测试之间我都做过相同的系统清理只保留必要服务进程尽量把干扰降到最低。3.3 精度损失对比性能高不高还得看精度能不能接受。我用相同的500张验证图片分别计算原始FP32模型、RK3588 INT8量化模型、AX650N INT8量化模型在COCO标注上的mAP0.5检测置信度阈值统一设为0.25NMS阈值为0.45。模型版本mAP0.5相对FP32的精度损失FP32 ONNXCPU参考0.457-RK3588 INT8量化0.431-2.6%AX650N INT8量化0.443-1.4%这个结果让我对AX650N的量化工具链高看一眼。虽然它的性能强是因为算力堆得高但能在4倍速提的情况下还保持更少精度损失说明它的量化感知训练和激活值校准做得更保守。RK3588的精度损失也没有到不可用的地步2.6个点的mAP下降对于绝大多数目标检测场景而言属于正常范围只是如果你需要在低照度图片或小目标检测场景里压榨精度可能需要再引入一些针对性的蒸馏微调。我还顺手做了个有趣的测试把输入分辨率从640x640降到320x320RK3588的NPU推理时间从24.6ms降到9.8msAX650N从5.8ms降到2.1ms但两边的mAP都掉了大约4.5个点。这说明在高性能平台上我们其实可以更大胆地通过分辨率换取速度而在慢速平台上则要仔细权衡。4. 测试中翻车的几个关键点4.1 RK3588预编译库与系统版本不匹配这个坑几乎每位玩RK3588的朋友都会遇到。我一开始图省事直接通过apt安装了一些依赖库结果装完之后动态链接库版本和RKNN运行库对不上一加载模型就报错提示找不到某个版本符号。当时错误信息大概长这样undefined symbol: __cxa_throw_bad_array_new_length看着像是C运行时库的问题。我一开始怀疑是模型文件坏掉了反复转换了三遍都一样。后来才意识到系统里同时存在多个libstdc.so.6版本而RKNN的Python扩展链接到了旧的库上。解决办法是给系统安装一份匹配的GCC运行时环境并把LD_LIBRARY_PATH变量指到正确的库路径。如果你也遇到类似的符号缺失问题先不要急着怀疑工具链优先检查一下当前shell里的LD_LIBRARY_PATH用ldd命令查看扩展库依赖了哪些so文件逐个对比版本基本都能定位。4.2 AX650N的NPU推理快但Python预处理成了拦路虎第一次跑AX650N端到端测试时我连NPU推理都还没看就发现每张图的预处理花了将近8ms这比它5.8ms的NPU推理还慢。去掉图像读取和路径操作后发现瓶颈是letterbox缩放和归一化。我一开始用的是OpenCV的标准resize函数cv2.resize在ARM CPU上其实做了很多额外工作尤其是插值算法。后来我把图像缩放的硬件加速接口打开同时把BGR转RGB和归一化放到OpenCV的矩阵运算里一起做才把预处理压到3.2ms。这个数据差异对最终吞吐量影响很大因为如果你只测NPU推理时间AX650N会让你以为它能跑170FPS但一算端到端就掉到68FPS了。所以做性能测试时我建议一定要把“端到端”作为核心指标。只报告NPU推理时间是不负责任的尤其在AX650N和RK3588这种CPU能力差距明显的平台上预处理后处理才是决定实际体验的关键。4.3 温度热降频差点搞崩连续跑分数据做吞吐量测试的时候前两轮跑得很顺RK3588的4线程吞吐量稳定在41FPS左右。结果到第三轮突然降到32FPS。我一度以为系统里有什么后台任务启动了挨个排查也没发现异常最后用cat /sys/class/thermal/thermal_zone*/temp看了一眼温度发现NPU附近的温度已经冲到83度CPU大核频率被强制降下来。这是热降频导致的性能坍塌。因为RK3588那个铝散热片在小负载时可以应付但在4线程连续高负载下散热不够了。我只好在散热片上临时加了一个5V小风扇把温度压在65度以内数据才恢复稳定。这里提醒大家跑长时间压力测试之前先确认散热方案能不能满足满负载运行否则你测出来的“稳定性能”和实际部署后完全不同。AX650N盒子自带的风扇刚开始也有类似问题它的风扇策略默认是温控调速测试刚开始风扇不转温度上来后突然高速转中间那个时间点数据会很乱。我通过板卡的系统接口把风扇固定为恒定转速后数据就平稳了。4.4 后处理NMS的参数差异容易被忽略还有一个隐蔽的坑是NMS参数。两个平台如果都自己做后处理代码逻辑我尽量保持一致但实际操作中发现RK3588那边的anchor decode我用的是Python循环加向量化操作混写AX650N那边因为CPU性能弱我改用了一种更紧凑的纯向量化写法。结果两边检测框数量不一致导致精度对比失真。后来我把两份后处理代码统一成完全相同的逻辑并把中间结果导出比对确保每张图的检测框集合一致才开始记录精度数据。如果要复现我的测试这个细节一定要留意后处理不仅要“看起来一样”还必须逐框比较否则精度差异根本说不清来源。5. 成绩单之外的选型思考5.1 光看TOPS没用工具链和生态是隐性成本这次测试最直观的收获是算力数字只能用来做粗筛。RK3588标称6 TOPSAX650N标称算力看起来更漂亮实际端到端差了3倍多一方面是硬件算力差异另一方面是工具链把算力释放了多少。AX650N从转换模型到运行每一步都让YOLO系列模型尽量留在NPU上CPU算子兜底很少而RK3588工具链更通用优化覆盖的模型范围广但对单一模型的极限压榨不够极致。工具链的易用性也要考虑。RK3588的社区资料多遇到问题搜索一下基本都有答案AX650N的资料相对少遇到算子兼容性问题只能翻官方技术文档或问方案商。对于个人开发者来说时间成本不可忽视。我这次测试在AX650N上花在查算子、调预处理的时间比RK3588多了一倍不止。5.2 功耗与部署形态怎么权衡性能测试之外我还测了两个平台跑满负载时的整机功耗。RK3588在6线程满载时整机功耗约10瓦左右AX650N跑满4线程时整机功耗不到7瓦但吞吐量却是前者的两倍多。这种能效比差距在电池供电或者太阳能供电的场景里就是决定性的优势。不过RK3588也有它不可替代的地方。它强大的CPU和丰富的外设接口意味着同一块板子上可以同时跑检测、跑业务逻辑、跑数据库、跑通信协议栈甚至跑一些上位机服务。AX650N的CPU相对弱部署时通常需要搭配一个独立的上位机处理器架构上会复杂一些。我个人对选型的建议是如果你需要一套系统里同时处理多路视频流、跑检测模型、还要承担业务联动逻辑RK3588这种全能型平台更省事。如果你做一个标准的图片检测模块输入输出接口很明确检测性能是第一优先级AX650N的性价比优势非常突出。5.3 从这次测试反推的设计思路这次数据对我做图片检测系统最直接的帮助是我重新设计了服务架构。原来我在RK3588上用一个进程吃掉所有事情现在我会把预处理、NPU推理、后处理解耦成三个线程让它们通过环形缓冲队列接力。NPU推理线程只管提交任务后处理线程并行做NMS这样资源利用率更高。在AX650N上则更极端我直接把图片缩放算法换成硬件加速通道让CPU专注于做NMS和网络传输。如果你打算在自己的项目里做类似选型我建议不要照搬我这份报告里的数字而是把你自己的真实业务模型、真实图片尺寸、真实并发模式拿到两个平台上各跑一遍。芯片型号相同但散热条件、内存频率、系统版本、工具链版本不同结果都可能变化。6. 最后一页测试之外的几点个人体会测试做完之后我再也不会轻易相信官方的Benchmark了。RK3588的很多宣传材料里YOLOv5s跑出了不到二十毫秒的成绩我承认在特定条件下可能做到但就我手上这块板子、这个散热条件、这套系统环境端到端平均就是35.6ms。AX650N的官方资料也写了很高的性能但我实际跑出11.6ms的端到端说明只要环境调试得当它确实扛得住这个性能预期。最后分享一个我自己留下来继续用的方法做这类对比测试时不要只保存最终统计表把每一次推理的原始日志都落盘。比如记录时间戳、图片路径、各阶段耗时、温度值、CPU频率。当你发现数据有明显异常时这些原始日志能帮你马上定位是温度降频、系统调度抖动还是输入图片尺寸特殊导致的个别长尾。我这次就是靠这些日志才在复盘时发现AX650N在连续跑满3分钟后的吞吐量有小幅下滑顺着日志一查是风扇策略导致温度波动而不是芯片性能不稳。如果你也正在RK3588和AX650N之间犹豫我的态度是不要只看哪颗芯片更“强”要看哪套方案让你的系统跑得更稳。先把模型跑通再测端到端再做长稳压力测试最后再谈选型。这比盯着参数表挖一天有效得多。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
