做嵌入式开发这几年头一次感觉“算力”这个词跟自己关系这么密切。早两年同行聊天出口多半是主频多少、内存多大、I2C/SPI/UART/串口走什么协议今年不一样聚会话题变成了“板子上的NPU能跑多大模型”“INT8能到多少TOPS”“工具链顺不顺手”。变化的核心就是端侧AI这颗棋子真正落到了嵌入式设备上AI不再只是云端大厂的事情。第一期“嵌入式周报”我把最近这段时间在端侧AI算力、内核、开源生态三条线上看到的变化和实操经验整理出来。先给自己做个归档也想给打算从传统嵌入式转向AI方向的朋友一份参考。看完这篇文章你会搞清楚算力单位怎么读、一张训练好的模型怎么跑进开发板、Linux内核在底层做了哪些提速以及一套能直接上手的嵌入式Linux开发环境怎么搭。1. 端侧AI的“算力翻身仗”到底在打什么1.1 为什么不把AI全塞进云端先说一个大多数人会问的问题既然云端有强大算力、有现成大模型API为什么还要在设备端跑AI我拿一个实际项目举例。生产线上装一台工业相机做外观质检要求每秒处理30帧画面发现缺陷后在几毫秒内给出信号、触发机械臂剔除。如果走云端推理画面要先压缩上传服务器排队计算结果再传回来。一次往返至少几十毫秒碰上网络抖动直接飙到几百毫秒产线的节拍根本等不起。更不用说每台相机24小时开着视频流带宽成本足够再买几台设备。端侧AI解决的正是这几个痛点低延迟推理在设备本地完成隐私安全视频画面不出设备离线可用断网不影响功能功耗可控相比持续上行传输反而省电。所以说端侧AI不是来抢云端饭碗的而是分工不同——云端负责训练大模型和跑重负载端侧负责把轻量模型以实时、低成本的方式跑起来。这个分工其实也给嵌入式工程师打开了一条新路以前我们管传感器、管电机现在还得管神经网络。1.2 先看懂算力单位TOPS与INT8/FP16的分野端侧AI绕不开“算力”两个字而算力这个词在芯片圈经常被拿来宣传不搞清楚单位很容易被参数带偏。TOPS全称Tera Operations Per Second每秒万亿次操作。一块标称6 TOPS的NPU意思是它理想状态下每秒能完成6×10的12次方次运算。至于一次神经网络卷积里的乘加运算MAC通常算两次操作一个是乘、一个是加。所以你看到模型的计算量单位是GMACs时想估算帧率可以用一个很粗略的公式帧率估算值FPS ≈ 有效TOPS × 1000 ÷模型GMACs × 2举个例子YOLOv5s输入640×640大约7.9 GMACs。在6 TOPS的NPU上理论峰值约为6000 ÷ 15.8 ≈ 380帧每秒。看这个数字很夸张对吧实际上你根本跑不到这个值。NPU利用率、数据搬运、预处理、后处理、DDR带宽都会吃掉性能真实部署通常只有理论值的10%到30%。这里还要聊清楚精度类型的差异。同样一颗芯片FP32、FP16、INT8三种数据格式下的算力往往相差很大精度类型位宽相对算力成本典型用途FP6464位最低科学计算、数值仿真FP3232位较低训练、高精度推理FP1616位较高端侧训练、大模型推理INT88位最高端侧推理主力INT44位最高超低功耗推理需谨慎校准所以看到“某芯片INT8算力12 TOPSFP16算力只有6 TOPS”别觉得是缩水这是正常的硬件设计取舍。INT8单位面积能塞进更多计算单元功耗也低特别适合嵌入式场景。端侧部署绝大多数模型目标就是量化成INT8甚至INT4。还有一点容易被忽略算力高不等于跑得快。NPU计算完每一层结果都要写回显存/DDR下一层再读出来。内存带宽不够计算单元再多也只能空转。就像水龙头开得再大下水道不够粗水照样漫出来。1.3 国产端侧芯片算力一览这几年国产端侧AI芯片的迭代速度确实快。早期主流开发板上的NPU普遍只有0.5到1 TOPS跑个垃圾分类模型都费劲现在入门级开发板6 TOPS起步边缘计算盒子30 TOPS以上的选择也多了。列举几个市面上讨论度比较高的芯片型号CPUNPU算力工具链典型定位瑞芯微 RK35884×A76 4×A556 TOPSRKNN-Toolkit2通用开发板、AI盒子地平线 旭日X34×A535 TOPSOpenExplorer智能摄像头、机器人算能 SG2300X8×A5532 TOPSTPU-MLIR边缘AI服务器、复杂模型爱芯 AX650N4×A5323.6 TOPSPulsar视觉Transformer、大模型注意看这些芯片的CPU配置清一色Arm架构这正是嵌入式工程师最熟悉的地盘。NPU算力翻倍只是上半场下半场比的是谁的工具链能把模型转换、量化、调试、部署整条链路做得更顺。这方面各家的策略不太一样有的倾向兼容ONNX做一键转换有的绑定自家模型库和SDK。我的经验是先用手头芯片的官方工具链省下的时间远比纠结“哪个框架更通用”值钱。2. 从一张训练好的模型到设备上跑起来端侧AI部署实战2.1 部署第一步永远是把模型“变小”训练好的模型默认是FP32格式参数多、计算量大。一块几GB显存的云端GPU跑起来没什么感觉放到开发板上就是灾难——算力不够、内存带宽不够、模型文件太大。所以部署的第一步本质上是“压缩”。最常见手段是量化。把FP32权重压缩成INT8模型体积缩小到原来的四分之一左右推理速度提升数倍代价是精度有轻微下降。现在主流方案有两种PTQ训练后量化直接拿训练好的模型用一批校准图片统计每层激活值的分布算出缩放因子QAT量化感知训练在训练过程中就模拟量化误差精度损失更小但需要重新训练模型、门槛更高。校准集这个概念值得多说一句。做PTQ时你需要准备几十到几百张有代表性的图片让模型“跑”一遍统计激活分布。校准图越贴近真实使用场景量化效果越好。比如你的摄像头装在户外检测车辆校准集却拿室内静物图量化后精度很可能崩盘。我见过不少人栽在这个细节上。另外不是所有层都能无脑压成INT8。像Softmax、Sigmoid这类激活函数输出范围集中映射到INT8后信息损失特别大。部分模型需要采用混合精度策略敏感层保留FP16普通卷积层走INT8。许多工具链已经支持指定层精度实际用的时候要关注一下手册。2.2 以RK3588为例YOLOv5检测模型的完整转换流程纸上谈兵没意思直接走一遍完整部署流程。我用RK3588开发板做例子理由很简单板子便宜、教程多、RKNN工具链相对成熟踩坑的时候搜得到答案。第一步准备转换环境。RKNN-Toolkit2支持在x86主机上用Python环境运行官方推荐用conda创建虚拟环境Python版本按文档来然后安装rknn-toolkit2的whl包。板端运行推理用的是rknn-toolkit-lite2体积更小不带模型转换能力。第二步拿到ONNX格式模型。用ultralytics的YOLOv5导出命令一般是yolo export modelyolov5s.pt formatonnx imgsz640导出后可以先用Netron看一下模型结构顺便确认输入输出的名字和shape后面转换脚本里要对应上。第三步写转换脚本。核心代码只有几行from rknn.api import RKNN rknn RKNN() rknn.config(mean_values[[0,0,0]], std_values[[255,255,255]], target_platformrk3588) rknn.load_onnx(modelyolov5s.onnx) rknn.build(do_quantizationTrue, datasetcalibration.txt) rknn.export_rknn(yolov5s.rknn)这里的calibration.txt是一份纯文本文件每行一个校准图片的绝对路径。rknn.build会读取这些图片自动完成INT8量化。如果没有校准集也可以跳过量化直接转FP16模型精度更高但推理速度慢不少。第四步把rknn模型拷贝到开发板用rknn-toolkit-lite2推理from rknnlite.api import RKNNLite rknn RKNNLite() rknn.load_rknn(yolov5s.rknn) rknn.init_runtime() img load_image(test.jpg) # 预处理缩放、归一化、转NHWC out rknn.inference(inputs[img])注意几个细节RKNN模型的输入格式一般是NHWC而不是NCHW图像通道顺序是RGB还是BGR要和转换脚本里的mean/std对齐inference默认走NPU如果模型里有些算子NPU不支持会自动跑到CPU上但你最好在日志里确认一下以免性能悄悄打折扣。2.3 帧率上不去NPU调优的几条土办法模型转换成功只是第一步真正让用户满意的是稳定帧率。很多时候帧率上不去瓶颈根本不在NPU而是被周边环节拖死了。第一个坑是图像预处理。OpenCV的resize默认走CPU如果每帧图像是1920×1080要缩到640×640一次resize就是几毫秒连续跑还会占用CPU时间片。解决办法是用开发板自带的硬件加速单元比如RK3588的RGA模块可以做硬件缩放或者用双核A77核心单独开线程跑预处理别让预处理和NPU推理挤在同一根线上。第二个坑是数据拷贝。摄像头取到的帧在内存里NPU要的是连续内存块。每次推理前做一次copy看似开销不大帧数一高差距就出来了。偏好方案是直接用支持DMA的零拷贝接口或者至少在初始化时分配好输入输出缓冲区避免推理循环里反复malloc/free。第三个坑是模型输入分辨率。检测小目标需要大分辨率输入但640×640和416×416的计算量差近一倍。业务场景不敏感的话优先降分辨率帧率提升立竿见影。第四个坑是发热降频。开发板散热差时NPU跑满几分钟后温度飙到80摄氏度以上频率自动往下掉帧率肉眼可见地变低。这不是玄学是实打实的工程问题。测性能时至少跑20分钟以上再看平均帧率别拿冷机上电前30秒的数据写进汇报。我把这个过程总结成一句话调优顺序应该是先看数据通路再看算子分布最后才是抠NPU利用率。3. 内核与嵌入式系统底层底座正在加速3.1 Linux 6.x主线带来的实时性变化“Linux不适合硬实时”是老黄历了但这句话曾经确实有道理。早期Linux内核调度延迟大、中断响应不确定用在工业控制上让人提心吊胆。PREEMPT_RT补丁项目折腾了十几年前些年一直是外部补丁各家厂商自己编内核今年才开始正式融入Linux主线。这个信号对嵌入式行业意义挺大意味着后续商业发行版会默认带上实时能力不用再折腾第三方内核。普通人怎么感知这个变化跑一个cyclictest工具就能看出来。它统计线程唤醒延迟的分布最好的时候能在几十微秒级别稳定运行。对运动控制来说控制周期从1毫秒降到几百微秒抖动再小一点机械臂轨迹就平滑得多。我做过一个视觉定位配合运动控制的设备控制层以前靠单独一颗MCU跑实时逻辑主机Linux只负责交互和视觉。内核实时性上来以后一部分简单控制逻辑可以挪进Linux侧系统架构简单一大截。要注意合入主线不等于默认开启。你需要在编译内核时打开CONFIG_PREEMPT_RT选项同时注意驱动代码里有没有关抢占的临界区。把RT补丁当万能药的人容易翻车实时性优化是软硬件协同的事情。3.2 异构多核与RTOS实时任务和非实时任务怎么共存嵌入式设备越来越复杂常常面临一个矛盾视觉AI需要Linux生态电机控制需要硬实时。用两块板子当然能解决问题但成本、体积、线缆都上去了。于是异构多核方案成了主流选择。常见架构是单颗SoC上同时集成Cortex-A核和Cortex-M核A核跑Linux负责视觉业务、网络、文件系统M核跑RTOS负责电机控制、IO采集、安全逻辑。两边的通信走OpenAMP框架底层基于RPMsg本质是共享内存加中断通知。我打个比方Linux侧像项目经理负责对外沟通、复杂计算RTOS侧像车间技师只关心每个动作在规定时间内完成。两者通过一张长纸条共享内存传递指令按一下铃中断告诉对方新消息到了。开发时要特别注意内存隔离。A核的Linux驱动如果有bug可能直接踩到M核的代码段轻则通信异常重则实时任务崩掉。所以异构方案的启动顺序、内存分配、中断注册都要提前规划别指望默认配置直接能用。市面上RT-Thread Smart、Zephyr、FreeRTOS都提供了对应的OpenAMP适配层上手路径比从前顺畅多了。3.3 内核源码阅读路线与调试工具“嵌入式内核源码”这个词让我想到很多新手的学习误区。上来就翻driver目录翻三天觉得枯燥就放弃了。我的建议是换条路线先看启动流程。从init/main.c里的start_kernel函数开始你会发现内核初始化的节奏非常清晰关中断、设置页表、初始化调度器、创建init进程。把这条链路走一遍之后你会发现“内核是怎么启动的”不再玄乎后面看驱动、看设备树都会顺手很多。调试工具方面我推荐VSCode加clangd插件做源码阅读配合QEMU在主机上模拟运行Arm架构内核再用gdb-multiarch打断点。命令大致是qemu-system-aarch64 -M virt -cpu cortex-a53 -kernel Image -append consolettyAMA0 -nographic -s在gdb里target remote localhost:1234就能连上去调试。不需要真机就能单步跟踪启动流程对理解内核的帮助是巨大的。内核阅读不需要全部精读而是带着问题看代码。比如“设备树怎么描述一个串口”“调度器如何选下一个任务”“DMA缓冲区怎么映射”。一个模块一个模块地吃透比笼统地“通读内核”有用得多。4. 开源生态全线提速工具链、开发环境与学习路径4.1 推理框架混战选型对照开源社区里的端侧推理框架越来越多这是个好现象但也带来了选择困难。我整理了一张对照表方便你按需求选型框架硬件适配量化支持上手难度适用场景RKNN-Toolkit2瑞芯微芯片INT4/INT8/FP16低RK系列开发板首选NCNN不限CPU优化好INT8/FP16中通用CPU推理移动端MNN不限支持GPUINT8/FP16中淘系生态通用性能好ONNX Runtime不限INT8/FP16中跨平台、生态大OpenCV DNN不限有限低跑通Demo、效果验证选型建议分三步先看芯片厂商官方工具链踩坑有人问官方工具链实在搞不定的算子再考虑通用框架 CPU/GPU兜底最后别盲目追新框架社区活跃度、文档完整度比版本号重要得多。4.2 用VSCode搭一套嵌入式Linux开发环境嵌入式Linux开发过去总跟复杂的IDE绑定命令行、交叉编译、烧录每一步都劝退新人。现在我用VSCode解决绝大多数开发需求轻量、免费、远程开发体验好。基本思路是让开发板当远程服务器主机上用VSCode的Remote-SSH连上去操作。具体步骤开发板开启SSH保证主机能连上。VSCode安装Remote - SSH、C/C、CMake Tools三个扩展。在开发板上安装交叉编译工具链比如aarch64-linux-gnu-gcc。用CMake组织项目一个最简单的CMakeLists.txt是这样的cmake_minimum_required(VERSION 3.16) project(edge_demo C CXX) set(CMAKE_CXX_STANDARD 17) find_package(OpenCV REQUIRED) add_executable(demo main.cpp) target_link_libraries(demo ${OpenCV_LIBS})本地写好代码Remote-SSH同步到板端直接编译运行。这套流程最大的优势是代码编辑在主机编译运行在板端路径统一、依赖隔离不用每次编译完再来回拷贝文件。踩过的坑有两个一是板端glibc版本太老主机的交叉编译器版本太高编出来的二进制跑不起来二是OpenCV交叉编译依赖特别碎建议直接刷带OpenCV的固件或者用包管理器预装版本省得自己编一天。4.3 给想入行或转方向的工程师的建议这段时间后台私信里不少人问嵌入式学习路线我结合这几年的经验给一份保守但稳的路线第一步把C语言基础打牢。指针、结构体、内存管理、编译链接过程这些不扎实后面全都会还债。第二步学Arm体系结构和裸机开发。寄存器、中断、GPIO、定时器知道程序怎么跟硬件打交道。第三步进Linux。文件系统、进程线程、驱动模型、设备树这部分是嵌入式Linux工程师的护城河。第四步学RTOS。RT-Thread、FreeRTOS选一个把任务调度、信号量、消息队列搞明白理解实时系统跟通用操作系统的区别。第五步再碰端侧AI。量化、推理框架、NPU部署这是现在增量最大的方向。面试这块嵌入式岗位虽然被戏称要背“八股文”但面试官其实最关注项目深度。比起简历堆了五个项目不如把一个项目从头到尾讲透需求怎么来的、硬件怎么选、通信协议为什么用I2C而不是SPI、线程和中断的优先级怎么安排、出过什么问题怎么排查、性能瓶颈在哪。任何项目只要能讲清这几个问题基本不会低于平均水平。5. 常见问题与排查技巧实录5.1 模型转换失败的典型原因模型转换工具报错绝大多数是下面几个原因算子不支持。模型里有工具链没适配的算子日志一般会直接指出来。处理方法换等价的算子组合或者在对应层回退到CPU/GPU执行。ONNX opset版本不匹配。导出模型时opset选太高旧框架解析不了。降一档重导通常能解决。动态shape问题。端侧推理普遍要求固定输入尺寸模型里如果用了动态维度转换前先fixed住。校准集图片路径错误或格式不对。这个错很低级但很多人第一次都栽在这日志提示不明显。5.2 板端推理性能异常的排查顺序部署后帧率远低于预期按下面顺序排查比乱试高效看NPU占用率。占用率太低说明模型没真正跑满可能是算子被打散到CPU了。看CPU占用。CPU满了多半是预处理和后处理在抢资源检查有没有用硬件加速。看温度。跑一段时间后降频需要加强散热或降低功耗。看内存带宽。数据拷贝太频繁会拖慢整体速度尽量用零拷贝接口。看单帧耗时分布。把preprocess、inference、postprocess三段分别计时往往一眼就看出问题在哪。5.3 Linux启动挂起的快速定位板子启动卡住先看串口日志通常是串口线的问题导致什么信息都看不到。日志停在“Starting kernel”附近多半是设备树问题停在根文件系统挂载多半是initramfs配置不对或者根分区路径写错。这个状态用JTAG也能调但串口日志是最快路径。5.4 常见问题速查表现象可能原因排查手段转换时算子报错模型含有不支持的算子查看日志关键词替换算子量化后精度下降明显校准集不贴合场景换成真实场景图片重新量化帧率远低于标称算力NPU/CPU资源分配不合理分阶段计时定位瓶颈板子运行一段时间变慢散热不足导致降频测温度加强散热交叉编译的二进制跑不起来glibc版本不匹配查看ldd输出调整编译器版本6. 第一期的几点个人体会做端侧AI部署这一年多最大的感受是“算力翻身仗”的本质不是参数好看而是工程化能力落地。一块芯片标称几十TOPS真正能拿出来用的可能只有零头差距就在工具链、驱动、SDK、文档这些看似不起眼的环节上。选平台的时候我宁愿选算力稍低但生态成熟的也不选参数漂亮但教程都凑不齐的板子。另一个体会是别贪多。端侧AI涉及的东西太杂模型、算法、硬件、驱动、系统各占一块一天学一点很容易在信息里迷路。我的做法是锁定一个开发板、一个经典模型、一个真实场景从采购到部署完整跑通一遍。这个过程比看一百篇教程都有用因为你会亲自踩到那些文档里从来不写的坑。这一期先聊到这里。下期打算用一套具体的RT-Thread加边缘AI的组合做例子把实时任务和神经网络推理怎么在一个系统里协作跑通讲细一些。想跟进的朋友可以先把手里吃灰的RK3588板子翻出来照着第二节的流程跑一遍YOLOv5跑通了咱们下期就有共同语言了。 
长河君 · 2026/9/26 10:53:59 · 阅读 1.2k 端侧AI实战：从NPU算力到嵌入式Linux部署全解析
做嵌入式开发这几年头一次感觉“算力”这个词跟自己关系这么密切。早两年同行聊天出口多半是主频多少、内存多大、I2C/SPI/UART/串口走什么协议今年不一样聚会话题变成了“板子上的NPU能跑多大模型”“INT8能到多少TOPS”“工具链顺不顺手”。变化的核心就是端侧AI这颗棋子真正落到了嵌入式设备上AI不再只是云端大厂的事情。第一期“嵌入式周报”我把最近这段时间在端侧AI算力、内核、开源生态三条线上看到的变化和实操经验整理出来。先给自己做个归档也想给打算从传统嵌入式转向AI方向的朋友一份参考。看完这篇文章你会搞清楚算力单位怎么读、一张训练好的模型怎么跑进开发板、Linux内核在底层做了哪些提速以及一套能直接上手的嵌入式Linux开发环境怎么搭。1. 端侧AI的“算力翻身仗”到底在打什么1.1 为什么不把AI全塞进云端先说一个大多数人会问的问题既然云端有强大算力、有现成大模型API为什么还要在设备端跑AI我拿一个实际项目举例。生产线上装一台工业相机做外观质检要求每秒处理30帧画面发现缺陷后在几毫秒内给出信号、触发机械臂剔除。如果走云端推理画面要先压缩上传服务器排队计算结果再传回来。一次往返至少几十毫秒碰上网络抖动直接飙到几百毫秒产线的节拍根本等不起。更不用说每台相机24小时开着视频流带宽成本足够再买几台设备。端侧AI解决的正是这几个痛点低延迟推理在设备本地完成隐私安全视频画面不出设备离线可用断网不影响功能功耗可控相比持续上行传输反而省电。所以说端侧AI不是来抢云端饭碗的而是分工不同——云端负责训练大模型和跑重负载端侧负责把轻量模型以实时、低成本的方式跑起来。这个分工其实也给嵌入式工程师打开了一条新路以前我们管传感器、管电机现在还得管神经网络。1.2 先看懂算力单位TOPS与INT8/FP16的分野端侧AI绕不开“算力”两个字而算力这个词在芯片圈经常被拿来宣传不搞清楚单位很容易被参数带偏。TOPS全称Tera Operations Per Second每秒万亿次操作。一块标称6 TOPS的NPU意思是它理想状态下每秒能完成6×10的12次方次运算。至于一次神经网络卷积里的乘加运算MAC通常算两次操作一个是乘、一个是加。所以你看到模型的计算量单位是GMACs时想估算帧率可以用一个很粗略的公式帧率估算值FPS ≈ 有效TOPS × 1000 ÷模型GMACs × 2举个例子YOLOv5s输入640×640大约7.9 GMACs。在6 TOPS的NPU上理论峰值约为6000 ÷ 15.8 ≈ 380帧每秒。看这个数字很夸张对吧实际上你根本跑不到这个值。NPU利用率、数据搬运、预处理、后处理、DDR带宽都会吃掉性能真实部署通常只有理论值的10%到30%。这里还要聊清楚精度类型的差异。同样一颗芯片FP32、FP16、INT8三种数据格式下的算力往往相差很大精度类型位宽相对算力成本典型用途FP6464位最低科学计算、数值仿真FP3232位较低训练、高精度推理FP1616位较高端侧训练、大模型推理INT88位最高端侧推理主力INT44位最高超低功耗推理需谨慎校准所以看到“某芯片INT8算力12 TOPSFP16算力只有6 TOPS”别觉得是缩水这是正常的硬件设计取舍。INT8单位面积能塞进更多计算单元功耗也低特别适合嵌入式场景。端侧部署绝大多数模型目标就是量化成INT8甚至INT4。还有一点容易被忽略算力高不等于跑得快。NPU计算完每一层结果都要写回显存/DDR下一层再读出来。内存带宽不够计算单元再多也只能空转。就像水龙头开得再大下水道不够粗水照样漫出来。1.3 国产端侧芯片算力一览这几年国产端侧AI芯片的迭代速度确实快。早期主流开发板上的NPU普遍只有0.5到1 TOPS跑个垃圾分类模型都费劲现在入门级开发板6 TOPS起步边缘计算盒子30 TOPS以上的选择也多了。列举几个市面上讨论度比较高的芯片型号CPUNPU算力工具链典型定位瑞芯微 RK35884×A76 4×A556 TOPSRKNN-Toolkit2通用开发板、AI盒子地平线 旭日X34×A535 TOPSOpenExplorer智能摄像头、机器人算能 SG2300X8×A5532 TOPSTPU-MLIR边缘AI服务器、复杂模型爱芯 AX650N4×A5323.6 TOPSPulsar视觉Transformer、大模型注意看这些芯片的CPU配置清一色Arm架构这正是嵌入式工程师最熟悉的地盘。NPU算力翻倍只是上半场下半场比的是谁的工具链能把模型转换、量化、调试、部署整条链路做得更顺。这方面各家的策略不太一样有的倾向兼容ONNX做一键转换有的绑定自家模型库和SDK。我的经验是先用手头芯片的官方工具链省下的时间远比纠结“哪个框架更通用”值钱。2. 从一张训练好的模型到设备上跑起来端侧AI部署实战2.1 部署第一步永远是把模型“变小”训练好的模型默认是FP32格式参数多、计算量大。一块几GB显存的云端GPU跑起来没什么感觉放到开发板上就是灾难——算力不够、内存带宽不够、模型文件太大。所以部署的第一步本质上是“压缩”。最常见手段是量化。把FP32权重压缩成INT8模型体积缩小到原来的四分之一左右推理速度提升数倍代价是精度有轻微下降。现在主流方案有两种PTQ训练后量化直接拿训练好的模型用一批校准图片统计每层激活值的分布算出缩放因子QAT量化感知训练在训练过程中就模拟量化误差精度损失更小但需要重新训练模型、门槛更高。校准集这个概念值得多说一句。做PTQ时你需要准备几十到几百张有代表性的图片让模型“跑”一遍统计激活分布。校准图越贴近真实使用场景量化效果越好。比如你的摄像头装在户外检测车辆校准集却拿室内静物图量化后精度很可能崩盘。我见过不少人栽在这个细节上。另外不是所有层都能无脑压成INT8。像Softmax、Sigmoid这类激活函数输出范围集中映射到INT8后信息损失特别大。部分模型需要采用混合精度策略敏感层保留FP16普通卷积层走INT8。许多工具链已经支持指定层精度实际用的时候要关注一下手册。2.2 以RK3588为例YOLOv5检测模型的完整转换流程纸上谈兵没意思直接走一遍完整部署流程。我用RK3588开发板做例子理由很简单板子便宜、教程多、RKNN工具链相对成熟踩坑的时候搜得到答案。第一步准备转换环境。RKNN-Toolkit2支持在x86主机上用Python环境运行官方推荐用conda创建虚拟环境Python版本按文档来然后安装rknn-toolkit2的whl包。板端运行推理用的是rknn-toolkit-lite2体积更小不带模型转换能力。第二步拿到ONNX格式模型。用ultralytics的YOLOv5导出命令一般是yolo export modelyolov5s.pt formatonnx imgsz640导出后可以先用Netron看一下模型结构顺便确认输入输出的名字和shape后面转换脚本里要对应上。第三步写转换脚本。核心代码只有几行from rknn.api import RKNN rknn RKNN() rknn.config(mean_values[[0,0,0]], std_values[[255,255,255]], target_platformrk3588) rknn.load_onnx(modelyolov5s.onnx) rknn.build(do_quantizationTrue, datasetcalibration.txt) rknn.export_rknn(yolov5s.rknn)这里的calibration.txt是一份纯文本文件每行一个校准图片的绝对路径。rknn.build会读取这些图片自动完成INT8量化。如果没有校准集也可以跳过量化直接转FP16模型精度更高但推理速度慢不少。第四步把rknn模型拷贝到开发板用rknn-toolkit-lite2推理from rknnlite.api import RKNNLite rknn RKNNLite() rknn.load_rknn(yolov5s.rknn) rknn.init_runtime() img load_image(test.jpg) # 预处理缩放、归一化、转NHWC out rknn.inference(inputs[img])注意几个细节RKNN模型的输入格式一般是NHWC而不是NCHW图像通道顺序是RGB还是BGR要和转换脚本里的mean/std对齐inference默认走NPU如果模型里有些算子NPU不支持会自动跑到CPU上但你最好在日志里确认一下以免性能悄悄打折扣。2.3 帧率上不去NPU调优的几条土办法模型转换成功只是第一步真正让用户满意的是稳定帧率。很多时候帧率上不去瓶颈根本不在NPU而是被周边环节拖死了。第一个坑是图像预处理。OpenCV的resize默认走CPU如果每帧图像是1920×1080要缩到640×640一次resize就是几毫秒连续跑还会占用CPU时间片。解决办法是用开发板自带的硬件加速单元比如RK3588的RGA模块可以做硬件缩放或者用双核A77核心单独开线程跑预处理别让预处理和NPU推理挤在同一根线上。第二个坑是数据拷贝。摄像头取到的帧在内存里NPU要的是连续内存块。每次推理前做一次copy看似开销不大帧数一高差距就出来了。偏好方案是直接用支持DMA的零拷贝接口或者至少在初始化时分配好输入输出缓冲区避免推理循环里反复malloc/free。第三个坑是模型输入分辨率。检测小目标需要大分辨率输入但640×640和416×416的计算量差近一倍。业务场景不敏感的话优先降分辨率帧率提升立竿见影。第四个坑是发热降频。开发板散热差时NPU跑满几分钟后温度飙到80摄氏度以上频率自动往下掉帧率肉眼可见地变低。这不是玄学是实打实的工程问题。测性能时至少跑20分钟以上再看平均帧率别拿冷机上电前30秒的数据写进汇报。我把这个过程总结成一句话调优顺序应该是先看数据通路再看算子分布最后才是抠NPU利用率。3. 内核与嵌入式系统底层底座正在加速3.1 Linux 6.x主线带来的实时性变化“Linux不适合硬实时”是老黄历了但这句话曾经确实有道理。早期Linux内核调度延迟大、中断响应不确定用在工业控制上让人提心吊胆。PREEMPT_RT补丁项目折腾了十几年前些年一直是外部补丁各家厂商自己编内核今年才开始正式融入Linux主线。这个信号对嵌入式行业意义挺大意味着后续商业发行版会默认带上实时能力不用再折腾第三方内核。普通人怎么感知这个变化跑一个cyclictest工具就能看出来。它统计线程唤醒延迟的分布最好的时候能在几十微秒级别稳定运行。对运动控制来说控制周期从1毫秒降到几百微秒抖动再小一点机械臂轨迹就平滑得多。我做过一个视觉定位配合运动控制的设备控制层以前靠单独一颗MCU跑实时逻辑主机Linux只负责交互和视觉。内核实时性上来以后一部分简单控制逻辑可以挪进Linux侧系统架构简单一大截。要注意合入主线不等于默认开启。你需要在编译内核时打开CONFIG_PREEMPT_RT选项同时注意驱动代码里有没有关抢占的临界区。把RT补丁当万能药的人容易翻车实时性优化是软硬件协同的事情。3.2 异构多核与RTOS实时任务和非实时任务怎么共存嵌入式设备越来越复杂常常面临一个矛盾视觉AI需要Linux生态电机控制需要硬实时。用两块板子当然能解决问题但成本、体积、线缆都上去了。于是异构多核方案成了主流选择。常见架构是单颗SoC上同时集成Cortex-A核和Cortex-M核A核跑Linux负责视觉业务、网络、文件系统M核跑RTOS负责电机控制、IO采集、安全逻辑。两边的通信走OpenAMP框架底层基于RPMsg本质是共享内存加中断通知。我打个比方Linux侧像项目经理负责对外沟通、复杂计算RTOS侧像车间技师只关心每个动作在规定时间内完成。两者通过一张长纸条共享内存传递指令按一下铃中断告诉对方新消息到了。开发时要特别注意内存隔离。A核的Linux驱动如果有bug可能直接踩到M核的代码段轻则通信异常重则实时任务崩掉。所以异构方案的启动顺序、内存分配、中断注册都要提前规划别指望默认配置直接能用。市面上RT-Thread Smart、Zephyr、FreeRTOS都提供了对应的OpenAMP适配层上手路径比从前顺畅多了。3.3 内核源码阅读路线与调试工具“嵌入式内核源码”这个词让我想到很多新手的学习误区。上来就翻driver目录翻三天觉得枯燥就放弃了。我的建议是换条路线先看启动流程。从init/main.c里的start_kernel函数开始你会发现内核初始化的节奏非常清晰关中断、设置页表、初始化调度器、创建init进程。把这条链路走一遍之后你会发现“内核是怎么启动的”不再玄乎后面看驱动、看设备树都会顺手很多。调试工具方面我推荐VSCode加clangd插件做源码阅读配合QEMU在主机上模拟运行Arm架构内核再用gdb-multiarch打断点。命令大致是qemu-system-aarch64 -M virt -cpu cortex-a53 -kernel Image -append consolettyAMA0 -nographic -s在gdb里target remote localhost:1234就能连上去调试。不需要真机就能单步跟踪启动流程对理解内核的帮助是巨大的。内核阅读不需要全部精读而是带着问题看代码。比如“设备树怎么描述一个串口”“调度器如何选下一个任务”“DMA缓冲区怎么映射”。一个模块一个模块地吃透比笼统地“通读内核”有用得多。4. 开源生态全线提速工具链、开发环境与学习路径4.1 推理框架混战选型对照开源社区里的端侧推理框架越来越多这是个好现象但也带来了选择困难。我整理了一张对照表方便你按需求选型框架硬件适配量化支持上手难度适用场景RKNN-Toolkit2瑞芯微芯片INT4/INT8/FP16低RK系列开发板首选NCNN不限CPU优化好INT8/FP16中通用CPU推理移动端MNN不限支持GPUINT8/FP16中淘系生态通用性能好ONNX Runtime不限INT8/FP16中跨平台、生态大OpenCV DNN不限有限低跑通Demo、效果验证选型建议分三步先看芯片厂商官方工具链踩坑有人问官方工具链实在搞不定的算子再考虑通用框架 CPU/GPU兜底最后别盲目追新框架社区活跃度、文档完整度比版本号重要得多。4.2 用VSCode搭一套嵌入式Linux开发环境嵌入式Linux开发过去总跟复杂的IDE绑定命令行、交叉编译、烧录每一步都劝退新人。现在我用VSCode解决绝大多数开发需求轻量、免费、远程开发体验好。基本思路是让开发板当远程服务器主机上用VSCode的Remote-SSH连上去操作。具体步骤开发板开启SSH保证主机能连上。VSCode安装Remote - SSH、C/C、CMake Tools三个扩展。在开发板上安装交叉编译工具链比如aarch64-linux-gnu-gcc。用CMake组织项目一个最简单的CMakeLists.txt是这样的cmake_minimum_required(VERSION 3.16) project(edge_demo C CXX) set(CMAKE_CXX_STANDARD 17) find_package(OpenCV REQUIRED) add_executable(demo main.cpp) target_link_libraries(demo ${OpenCV_LIBS})本地写好代码Remote-SSH同步到板端直接编译运行。这套流程最大的优势是代码编辑在主机编译运行在板端路径统一、依赖隔离不用每次编译完再来回拷贝文件。踩过的坑有两个一是板端glibc版本太老主机的交叉编译器版本太高编出来的二进制跑不起来二是OpenCV交叉编译依赖特别碎建议直接刷带OpenCV的固件或者用包管理器预装版本省得自己编一天。4.3 给想入行或转方向的工程师的建议这段时间后台私信里不少人问嵌入式学习路线我结合这几年的经验给一份保守但稳的路线第一步把C语言基础打牢。指针、结构体、内存管理、编译链接过程这些不扎实后面全都会还债。第二步学Arm体系结构和裸机开发。寄存器、中断、GPIO、定时器知道程序怎么跟硬件打交道。第三步进Linux。文件系统、进程线程、驱动模型、设备树这部分是嵌入式Linux工程师的护城河。第四步学RTOS。RT-Thread、FreeRTOS选一个把任务调度、信号量、消息队列搞明白理解实时系统跟通用操作系统的区别。第五步再碰端侧AI。量化、推理框架、NPU部署这是现在增量最大的方向。面试这块嵌入式岗位虽然被戏称要背“八股文”但面试官其实最关注项目深度。比起简历堆了五个项目不如把一个项目从头到尾讲透需求怎么来的、硬件怎么选、通信协议为什么用I2C而不是SPI、线程和中断的优先级怎么安排、出过什么问题怎么排查、性能瓶颈在哪。任何项目只要能讲清这几个问题基本不会低于平均水平。5. 常见问题与排查技巧实录5.1 模型转换失败的典型原因模型转换工具报错绝大多数是下面几个原因算子不支持。模型里有工具链没适配的算子日志一般会直接指出来。处理方法换等价的算子组合或者在对应层回退到CPU/GPU执行。ONNX opset版本不匹配。导出模型时opset选太高旧框架解析不了。降一档重导通常能解决。动态shape问题。端侧推理普遍要求固定输入尺寸模型里如果用了动态维度转换前先fixed住。校准集图片路径错误或格式不对。这个错很低级但很多人第一次都栽在这日志提示不明显。5.2 板端推理性能异常的排查顺序部署后帧率远低于预期按下面顺序排查比乱试高效看NPU占用率。占用率太低说明模型没真正跑满可能是算子被打散到CPU了。看CPU占用。CPU满了多半是预处理和后处理在抢资源检查有没有用硬件加速。看温度。跑一段时间后降频需要加强散热或降低功耗。看内存带宽。数据拷贝太频繁会拖慢整体速度尽量用零拷贝接口。看单帧耗时分布。把preprocess、inference、postprocess三段分别计时往往一眼就看出问题在哪。5.3 Linux启动挂起的快速定位板子启动卡住先看串口日志通常是串口线的问题导致什么信息都看不到。日志停在“Starting kernel”附近多半是设备树问题停在根文件系统挂载多半是initramfs配置不对或者根分区路径写错。这个状态用JTAG也能调但串口日志是最快路径。5.4 常见问题速查表现象可能原因排查手段转换时算子报错模型含有不支持的算子查看日志关键词替换算子量化后精度下降明显校准集不贴合场景换成真实场景图片重新量化帧率远低于标称算力NPU/CPU资源分配不合理分阶段计时定位瓶颈板子运行一段时间变慢散热不足导致降频测温度加强散热交叉编译的二进制跑不起来glibc版本不匹配查看ldd输出调整编译器版本6. 第一期的几点个人体会做端侧AI部署这一年多最大的感受是“算力翻身仗”的本质不是参数好看而是工程化能力落地。一块芯片标称几十TOPS真正能拿出来用的可能只有零头差距就在工具链、驱动、SDK、文档这些看似不起眼的环节上。选平台的时候我宁愿选算力稍低但生态成熟的也不选参数漂亮但教程都凑不齐的板子。另一个体会是别贪多。端侧AI涉及的东西太杂模型、算法、硬件、驱动、系统各占一块一天学一点很容易在信息里迷路。我的做法是锁定一个开发板、一个经典模型、一个真实场景从采购到部署完整跑通一遍。这个过程比看一百篇教程都有用因为你会亲自踩到那些文档里从来不写的坑。这一期先聊到这里。下期打算用一套具体的RT-Thread加边缘AI的组合做例子把实时任务和神经网络推理怎么在一个系统里协作跑通讲细一些。想跟进的朋友可以先把手里吃灰的RK3588板子翻出来照着第二节的流程跑一遍YOLOv5跑通了咱们下期就有共同语言了。