做边缘AI这几年我最大的感受不是算法难而是“找方向”难。你打开一个硬件社区左边是Jetson用户晒自动驾驶demo右边是Arduino玩家在聊传感器采数中间还夹着一堆RKNN、TFLite、OpenVINO的报错帖。想做个视觉检测项目光选型就能耗掉你好几周。这门技术不是没有教程而是教程太散。芯片厂只讲自己的芯片框架文档只讲自己的框架算法论文只讲自己的模型。没人把“硬件—算法—部署”这三层放在一张图里给你讲清楚。这篇就是这个定位做一张边缘AI的技术地图。上篇先拆硬件和算法这两块下篇我再补软件、场景和项目落地。如果你正准备入门边缘AI或者已经在项目上但总觉得知识是零散的这篇文章值得你看完。我会尽量用做过项目的人的口吻把那些只有踩过坑才懂的东西一并讲了。1. 边缘AI的“选择困难症”逼你先画一张自己的地图1.1 为什么边缘AI听起来简单做起来却一团乱麻边缘AI的定义一句话能说清把人工智能推理放到靠近数据源头的设备上完成而不是把数据全传回云端。但定义好背落地头疼。问题出在两个层面。第一硬件层面从几块钱的MCU到几千块的边缘服务器中间隔着几十倍的性能和几百倍的价差第二软件层面每家芯片都有自己的工具链和运行时一个模型在不同平台上要做的转换操作几乎不通用。这造成了一个结果边缘AI技术社区看起来热闹但任何一个人问“我该用什么组合起步”得到的答案都不太一样。我见过不少项目卡死在第一阶段。有个朋友做养殖场牲畜计数听说边缘AI能省掉云端费用买了两块不同品牌的开发板结果一块板子只支持INT8量化另一块NPU的驱动在Windows上怎么都装不上。两周过去卷积神经网络还没跑起来一次推理。所以我不建议你一开始就陷入评测几十块板子的细节里而是先花两小时把地图理清楚。地图上不画具体产品而是画“维度”和“边界”。1.2 这张地图的核心是三根坐标轴算力、功耗、时延与成本我把边缘AI的选型问题压缩成三根坐标轴。第一根轴是算力。单位最常见的是TOPS也就是每秒万亿次整数运算。它决定了你跑的网络能有多大、多深也直接决定了你能用什么样的算法。第二根轴是功耗。边缘设备的共同特点是不能像服务器那样大功率散热很多场景是电池供电或被动散热功耗上限直接锁死了硬件选择。一个戴在身上的跌倒检测设备时延可以放到300毫秒但功耗必须压到几十毫瓦用电池撑一周。第三根轴是时延和成本我把它们放一起是因为在工程心里它们都是甲方预算的一部分从摄像头采集到算法输出结果整个链路要多快单套方案硬件多少钱、维护要多少人。一个好的边缘项目本质是在这三根轴之间找到一个业务能接受的点。比如持续工作的产线视觉检测功耗不用太省但时延要求100毫秒以内而一个农业巡检机器人时延可以放宽到秒级但整机成本和续航必须严格可控。1.3 这篇地图先圈三个重点区域这张地图我打算分三块讲。上篇先讲硬件层和算法层这是所有边缘AI项目的底座最后我会带一带部署链路因为不聊部署光讲硬件和算法就像拿了地图却不会看坐标。除此之外还有一个区域必须标注经典算法。边缘设备上不只是深度学习很多后处理、调度、规划问题依然靠传统数据结构算法在解决这一点经常被人忽略。标题里写“地图设计”我想强调的是读这篇文章的时候你脑子里应该慢慢建立起一条链路从应用落在哪个坐标区间到对应哪类硬件再到需要什么算法最后判断能不能顺利转换部署。拥有这条链路之后任何新芯片、新模型出现在你面前你都可以快速判断它是否有用。2. 硬件这一层从MCU到边缘服务器算力/功耗/实时性怎么取舍2.1 面向边缘AI的硬件光谱先分三档先给硬件光谱排个序。最底下是MCU比如STM32、ESP32-S3价格在几块到几十块之间功耗是毫瓦级。它们处理能力弱但胜在便宜、稳定、启动快适合跑唤醒词检测、振动分析这样的小任务也就是TinyML领域。顺便回应一个经常出现的疑问VB6.0能不能编程嵌入式硬件答案是基本不能。VB6.0是Windows桌面时代的开发工具和嵌入式开发完全是两个世界。MCU开发基本是C/C偏AI一点可以用MicroPython或者是TensorFlow Lite Micro这类轻量级运行时。再往上是带NPU的AI MPU或者带GPU/SIMD指令的应用处理器代表有瑞芯微RK3588、树莓派加AI加速棒、NVIDIA Jetson入门卡。这里的价格从几百到几千功耗从几瓦到十几瓦能跑的模型明显大了一截比如YOLOv8n检测、MobileNet分类、语音识别等等。最上面一类其实是边缘服务器或者说工业PC用x86 CPU加独立显卡来跑推理有时也加一块FPGA做特定逻辑加速。这类设备经常放在机房边缘和工厂产线旁功耗几十瓦起优点是x86生态成熟CUDA/TensorRT体系好用很多传统软件工程师用起来没有门槛。为了好对比我整理了一个常用对照表注意功耗是整板典型值不是芯片峰值档位代表硬件价格区间典型功耗适合的任务MCUSTM32、ESP32-S3几块~几十块毫瓦~1瓦唤醒词、传感器分类、异常振动AI MPURK3588、树莓派5Coral几百~两三千3~15瓦实时目标检测、OCR、人数统计边缘盒/小服务器Jetson Orin、Intel N100GPU两千~上万15~100瓦多路视频分析、大模型端侧推理这三档之间没有严格分界线但把它们列成一个光谱你的应用坐标就大概有着落了。实际项目里还要算上摄像头、显示、通信模块的功耗经常会出现“硬件标称可用整机一算超预算”的情况。2.2 TOPS、MACs、INT8……芯片参数到底该怎么读芯片算力是一个重灾区PPT上的数字和真实跑出来的数字经常差两三倍。首先TOPS是峰值算力峰值的意思是所有乘法器满负荷运转、数据刚好全部喂得上的时候才能达到。真实场景里瓶颈往往在内存带宽不在算力。比如一块号称50TOPS的芯片如果内存带宽只有20GB/s卷积里的每个输出像素都要反复读特征图性能会大打折扣。另外要注意精度标注。很多边缘NPU标的是INT8算力FP16算力直接砍半甚至更低。部署在端侧的时候如果模型对精度敏感需要混合精度那么标称TOPS基本要打七折以上来看。MACs是乘加次数是看模型计算量的单位用来估算“这个模型在这个硬件上大概能跑多快”。经验算法是一条网络的总MACs除以芯片可实现的有效算力再乘一个效率系数得到单次推理时延。效率系数看芯片架构NPU能不能吃满通常在0.2到0.4之间已经算优化得不错。我之前用一块NPU跑过分类网络发现实际吞吐只有宣传峰值的大约四分之一到三分之一。这不是厂商故意坑人是TOPS本来就只是“发动机排量”不是“实际车速”。所以比较硬件时别只看谁TOPS大要看运行你目标模型的真实帧率和功耗这个只有动手测才能知道。2.3 拿到板卡后的“硬件调通”到底调些什么好多新手第一次拿到开发板第一步不是跑AI而是被环境问题卡住。我列几个真实场景用Keil给MCU下载程序报pack install硬件错误最后发现是工具链版本和芯片Pack不匹配在Windows上接USB设备提示无法验证驱动数字签名处理思路是看设备管理器里具体报错再换厂商专用驱动或调整驱动签名策略别一上来就认为板子坏了。请记住一个原则先确认工具链和驱动能正常运行再碰算法。我把这个过程叫硬件调通通常分四步供电和串口调试能不能通下载/烧录有没有问题外设引脚是否正常工作推理框架自带的跑通Demo能不能出结果。很多人最开始的错误是跳过这一步直接拿自己的模型去转换部署最后分不清是硬件问题还是模型问题。另外提醒一下边缘终端很多是Linux系统跟Windows驱动打交道只是调试环节的一小部分。真正量产部署时我建议大家把Linux基础命令和系统服务搞熟边缘AI不是只写两行Python就能搞定的事。3. 算法这一层什么模型能真正活在边缘设备里3.1 边缘算法世界的两派传统机器学习与轻量化深度学习算法地图上先分两个方向。一类是传统机器学习随机森林、SVM、kNN以及各种统计方法。它们在MCU上依然有价值因为占用资源少可解释性比神经网络强。比如做电机振动异常检测提取一些时域特征扔给一棵决策树几百KB内存就能跑这类方案在工业里非常常见开发周期短、验证容易。另一类就是深度学习。边缘深度学习不是把你电脑上那套大模型直接搬过去而是要用专为边缘设计的轻量级网络。图像分类可以看MobileNet系列、EfficientNet-Lite也可以关注MaxViT-V2-nano这样同时带卷积和注意力机制的轻量混合结构目标检测主流是YOLO家族的小尺寸版本比如YOLOv8n语音和振动时序任务则常用TCN、CRNN或带残差结构的一维卷积网络。这些网络有一个共同点计算量和参数量都控制在比较小的范围同时结构上尽量规整。规整很重要因为NPU对层级的支持程度差异很大结构越规整转换部署时遇到算子不兼容的概率就越低。3.2 模型压缩三板斧剪枝、量化、蒸馏要把一个原本在服务器上很健康的大模型变成“能活在边缘设备”的样子业内主要用三板斧。剪枝就是把神经网络里不太重要的连接或通道删掉。有些权重接近零删掉对精度影响不大。结构剪枝比非结构剪枝更有实用价值因为它能把瘦身后的网络直接转成规整模型喂给NPU。我见过用粒子群算法、甚至NSGA-II这类多目标进化算法来搜索剪枝比例的效果确实有但我个人的体会是别一上来就搞复杂优化器先在几个固定比例之间做网格测试多数项目已经能拿到可接受的精度和速度。量化就是把FP32的权重和激活值改成INT8甚至更低精度表示。一个FP32的ResNet50大约98MB转成INT8大约25MB体积降到四分之一在多数边缘芯片上的推理速度能提升两到四倍。代价是精度可能会有轻微损失所以不是说所有层都必须量化逐层混合精度也是常用手段。蒸馏是让一个小模型去学习一个大模型的输出分布相当于师傅带徒弟。在边缘场景里通常先在服务器上训练一个精度很高的教师模型再用教师的输出监督一个小的学生模型。最后的结果就是边缘设备上跑的学生模型精度尽量接近大模型体积却小得多。这三招经常叠加使用先蒸馏出一个结构较小的模型再剪枝最后量化。每一步都要在验证集上观测精度损失。不要把精度指标逼到极限留出一点余量给量化噪声和边缘数据分布变化。3.3 经典算法和数据结构的“第二春”别把边端当弱化版PC边缘AI项目里不只有神经网络传统算法同样处处可见。拿目标检测来说模型输出一堆候选框之后要做一个NMS非极大值抑制从逻辑上看就是一种典型的贪心选择不断挑置信度最高的框然后抑制掉和它重合度过高的其他框。做路径规划时A*这类启发式搜索会派上用场。在资源受限的MCU上做排序也经常成为一道坎。经常有人问“在嵌入式里用什么排序好”我可以肯定地说不要手写冒泡排序哪怕是在只有几百KB内存的MCU上。排序库已经非常成熟C标准库的qsort、C的std::sort在绝大多数场景下都比你手写一个值快。真正需要考虑专门排序算法的场景是数据量特别大且内存紧张或者数据分布有特殊规律这时候计数排序、桶排序这些线性方法才值得研究。这里想说的核心是边缘终端的资源确实少但这不意味着你要把算法水平倒退到数据结构课作业的程度。反而因为资源少空间复杂度更敏感才应该把复杂度分析做得更细用更聪明的数据结构。比如在MCU上做时间序列缓存用环形缓冲区比频繁malloc安全得多做特征索引时用简单的哈希表和位图比线性扫描省电得多。这些经典数据结构才是边缘工程师的日常朋友。另外要提一个前沿点3D高斯泼溅3DGS重建出的场景模型已经开始出现在对实时渲染有要求的边缘产品里比如AR眼镜和机器人仿真。这给边缘硬件带来了很大压力因为3DGS的渲染需要大量算子和足够带宽。这不是让你现在就上手而是想说算法地图一直有新的区域在扩展地图思维比背具体模型更有用。4. 硬件与算法之间的部署链路算子、量化、工具链才是真正的分水岭很多能把硬件和算法都说得头头是道的人一上手部署还是会卡壳。因为硬件和算法之间有一条很容易被忽略的部署链路这条链路决定了项目成败也决定了同一块板子的实际生产力。4.1 从训练环境到边缘设备模型要走过一条典型流水线假设你在PyTorch里训练好了一个目标检测模型想部署到一块端侧NPU上。典型流程是模型导出成ONNX再用芯片厂商提供的转换工具把ONNX转成芯片自己的格式同时做图优化和量化。之后生成的模型文件交给芯片配套的运行时库去调用运行时再跟驱动和NPU硬件打交道。每一步都存在变量。导出时动态batch、动态分辨率很大概率会让转换工具拒绝工作转ONNX时一些自定义算子缺少实现量化时某些敏感层精度掉得厉害到了运行时你还可能发现内存申请失败、输入格式没对齐之类的问题。所以在做边缘AI项目时部署链路的复杂度往往超过模型训练本身。我心里的比例大约是训练占两成部署攻坚占八成。这也是为什么网上越搜越乱因为每个人卡住的环节都可能不一样。有人卡在导出有人卡在量化有人卡在内存优化看起来都是“部署报错”根因却完全不同。4.2 算子不兼容为什么比精度不足更常见很多人在服务器上模型精度跑到了95%可一到边缘设备上要么转换失败要么性能差得离谱。真正的拦路虎往往是算子支持度。NPU不像CPU那样可以通用执行任何指令它相当于一条流水线工厂只擅长加工卷积、池化、激活、矩阵乘这类“标准件”。一旦模型里出现了复杂的自定义层、动态形状、或者过于冷门的激活函数NPU的编译器就会罢工或者把这些算子甩给CPU去跑。大量使用算子对硬件性能的挑战说的就是这个事——算子越杂硬件越难优化性能碎片越严重。应对办法有两个方向。第一在模型设计阶段就考虑部署约束尽量用目标平台已经支持且优化良好的算子组合比如用深度可分离卷积结构用ReLU代替某些过于复杂又收益有限的激活。第二备份计划是让不支持的算子走CPU回退但如果这部分算子占比过高整体时延会很难看。我建议在项目最开始就把关键算子过一遍目标平台的支持表这比后续不断返工有效率得多。4.3 推理运行时怎么选没有“通吃”的框架如果说算子支持度决定了“能不能跑”那推理运行时决定的是“跑起来顺不顺”。现在边缘仓库里最常看到的推理运行时大概有这几种TFLite和TFLite Micro适合MCU和Linux小设备ONNX Runtime生态好适合服务端和部分边缘算力较强的设备TensorRT只能在NVIDIA平台用优化很强OpenVINO面向Intel系列RKNN是瑞芯微NPU专用还有NCNN、Tengine这类开源框架在一些国产芯片上被广泛适配。我的选型思路很简单优先用芯片官方主推的运行时。芯片厂商对自家工具链的优化和支持最到位社区资料也多。有人不喜欢受厂商锁定但边缘AI领域每家硬件都在做私有加速开源运行时在通用性上更好在特定硬件上却未必比专用运行时快。我的做法是主力功能用官方工具链跑通并验证之后如果确需跨平台再评估开源运行时。4.4 性能调优先用profile说话别靠感觉碰到模型跑得慢不要急着怀疑硬件算力不够。先用芯片配套的profile工具把每一层算子的耗时拉出来看。有时候问题出在数据前处理上图片解码、缩放、通道转换可能比推理本身还慢有时候是内存拷贝太多反复在CPU与NPU之间传数据有时候是整个链路上某个算子被放到了CPU成了瓶颈。调优的方向按投入产出比排序先把前处理和后处理合并到同一调度里减少CPU与NPU之间的同步等待检查输入分辨率很多任务没必要跑在1080p缩小到640甚至更小时延可能直接降一半最后才考虑用模型压缩手段。记住边缘AI的性能是一个系统指标不单是推理引擎的指标。把profile跑明白能省下大量无效优化时间。5. 按图索骥新手上路边缘AI的务实检查清单5.1 先锁业务约束再选硬件这一条可能已经被说烂了但我还是要强调任何边缘AI项目第一步都是锁约束条件而不是选芯片。你要回答的问题只有几个整个系统最高功耗是多少电池供电还是电源供电对环境温度有要求吗有没有风扇位推理时延上限是多少最多能接受多少钱的硬件成本需要24小时连续工作吗把这些硬性条件写下来到硬件光谱上一对照能选的平台基本就缩小到一个很窄的范围了。比如要求整板功耗低于5瓦且要实现实时人形检测那MCU大概率不够AI MPU是合理区间如果没有功耗限制只要求稳定和生态成熟x86边缘盒子可能是最容易上手的。我在这一节里见过最可惜的项目就是硬件工程师把板子堆得很强整机功耗却超了客户指标最后整个散热和电池方案推翻重来。硬件工程师的成长之路很多时候就是在这些约束条件里做权衡而不是单纯追求性能参数。5.2 找一份现成端到端Demo先把链路跑通选定硬件之后我强烈建议你找一份“端到端的推理Demo”也就是板子上已经有一个可运行的模型示例。为什么不是直接跑自己的模型因为Demo跑通意味着工具链、驱动、NPU运行时、前处理流水线都被验证过了你拿到的是一个已知可用的环境。在这个基准上再把你的数据集和模型慢慢引进来问题会更容易定位。很多人上来就编译自己训练环境里的代码报错几百行心态直接崩了。先跑通官方Demo花不了两个小时但能帮你排除掉大量环境层面的问题。我自己做项目时一定会保留一个能跑的官方Demo作为“环境恢复锚点”万一折腾坏了还能回来。5.3 关键算子和精度预留量决策前必须做的纸面预检在花大价钱购买开发板、投入几周时间训练之前先做一次“纸面预检”。把你计划使用的模型每一层算子列出来去目标平台的算子支持文档里逐个检查。特别注意这些点有没有动态形状或动态batch有没有转置卷积之外的奇怪上采样操作有没有自定义激活函数损失函数层是否只在训练时用到推理时会被错误带上。同时给你的精度目标留出余量。我的经验是如果在服务器上的验证集精度是98%放到边缘量化部署之后掉到92%到95%都是正常的。如果业务最低可接受精度是95%那服务器端至少要练到98%以上再谈部署否则后面会因为量化掉点而无休止地调优。5.4 上线前必须测的三组数据最后正式上线前不要只看Demo跑通。我建议你测三组数据第一组是端到端时延从传感器数据输入到结果输出包含I/O、预处理、推理、后处理全链路。不要只测推理引擎的单次时延那会给你一种“很快”的假象。第二组是功耗曲线连续跑几个小时看稳定功耗和峰值功耗。注意很多板卡启动时功耗比稳态高很多如果系统是电池供电这会影响容量设计。第三组是稳定性连续运行48小时以上观察内存会不会缓慢增长、NPU是否偶发死锁、跑几天后是否需要重启。边缘设备很多时候没人值守稳定性上的一个坑可能比精度不足更致命。把这些数据记录下来再回头对照5.1里写下的约束条件看是否满足。不能满足就回到地图上重新调整坐标或换平台。这个过程听起来繁琐但能避免项目做到一半才发现根本性选型错误。另外补充一个细节边缘AI的测评不是跑一次两次就行的一定要采集真实场景的数据而不是只在作者给的测试集上自嗨。光照变化、遮挡、网络波动在真实环境里都会发生算法必须要经过这些环境噪音的考验。我见过太多Demo漂亮但一进现场就失灵的项目根源都在测试环境太理想。做硬件和算法这件事说穿了就是不断在地图上修正自己的位置。我这里讲的硬件光谱、算法流派、部署链路都是这些年做嵌入式边缘AI项目时一点点摔出来的。地图有了下一步就看你愿不愿意花时间把每条路都走一遍。下篇我再接着拆软件、场景和应用落地到时候见。