去年我接手了一个户外智能摄像头的项目需求很“朴素”电池供电半年不换电还要能本地识别“人形入侵”并报警。当时团队第一反应是把视频传云端做识别但算完带宽和功耗账之后所有人都沉默了——4G网络下持续传输视频流的耗电和流量费比硬件本身还贵。也正是从那个项目开始我彻底把视线转向了端侧 AI。端侧 AI 这几年已经不只是“在手机上跑个小模型”的概念了。它代表了把推理能力从云端搬到设备端在本地完成数据采集、预处理、推理甚至决策闭环。它省的不只是流量和服务器成本更重要的是解决了实时性、隐私性和离线可用性这些云端方案永远绕不开的痛点。对做硬件、做嵌入式、做 IoT 的工程师来说端侧 AI 带来的不是“要不要跟风”的问题而是“晚一步可能就掉队”的压力。这篇文章不打算复述教科书概念我会结合自己实际做过的硬件部署项目重点拆解端侧 AI 硬件部署的核心逻辑再聊聊超低功耗端侧 AI 视觉模块怎么做电池供电最后分享一些模型落地时容易被坑的细节。无论你是刚接触端侧 AI 的产品经理还是已经在调模型跑板子的开发这篇应该都能给你一些参考。1. 端侧 AI 不是“云端的缩小版”它是另一套思维很多人理解端侧 AI第一反应是“把云端的模型压缩压缩塞进小盒子”。这个理解方向不能说错但它隐藏了一个致命假设——二者的优化目标和约束条件是一样的。实际上端侧 AI 从立项那一刻起就在回答一组完全不同的“元问题”。1.1 端侧推理的核心价值延迟、隐私、可靠性的三重解锁先说最直观的延迟。云端的完整链路是“采集 - 上传 - 排队 - 推理 - 回传”即便网络条件极好单次往返也要几十毫秒到几百毫秒。而端侧推理发生在数据产生的同一块硬件上从摄像头取帧到输出结果通常只需要几毫秒到几十毫秒而且这个延迟是确定的不受网络拥塞影响。对工业质检、自动驾驶、手势识别这类对实时性有硬性要求的场景端侧是唯一现实的选择。再说隐私。很多数据本身就“不该离开设备”。比如家庭摄像头拍摄的室内画面、智能音箱录到的语音、医疗设备采集的体征数据这些数据一旦上传云端哪怕服务器再“安全”在网阶段和存储阶段都存在被窃取或泄露的可能。端侧 AI 在本地完成特征提取和识别只把“结果是有人”或“心率异常”这类高层信息传出原始数据留在本地这从合规角度省去了大量数据出境申报和用户授权流程。最后是可靠性。云端的命脉是网络。断网、弱网、信号遮蔽都会让云端 AI 变“瞎”。而端侧 AI 在完全离线的状态下依然可以工作。我们在野外布控的非法捕捞监测设备就是依靠纯离线端侧模型完成渔船识别只在有网时回传报警消息和抓拍图片。这种“断网也能干活”的能力在工业巡检、油气田监控、边海防等领域价值远高于那些花哨的算法。1.2 云端与端侧的边界不是非此即彼而是三段式分工我不会把端侧 AI 吹成“万能解药”它有自己的边界。实践中的最优方案往往是端、边、云协同的三段式结构端侧负责低延迟、高频、隐私敏感的部分比如关键帧提取、简单事件检测、唤醒词识别。边缘侧如本地网关或小服务器负责中等算力需求比如多路视频结构化。云端负责大规模训练、复杂推理模型更新、历史数据挖掘和全局运营分析。端侧 AI 的“端”也不是特指某一种硬件。从几毫瓦的 MCU 到几十瓦的边缘盒子都可以算端侧。关键在于“数据在本地理清结果按需上云”。我见过有人非要在 8 位单片机上跑 YOLO结果效果惨不忍睹也见过有人在带 8TOPS NPU 的开发板上只做简单的关键点检测算力严重浪费。真正的端侧思维是搞清楚“这个场景到底需要在设备上做到什么程度”然后反推需要什么硬件、什么模型、什么功耗预算。2. 端侧 AI 硬件部署芯片选型不是算力越大越好端侧 AI 硬件部署的第一步永远是选主芯片。市面上的方案五花八门从带 NPU 的高算力 SoC如瑞芯微 RK3588、地平线 J5到 MCU轻量 NPU 的组合如 STM32N6、瑞萨 RA8再到纯 MCU 跑极简模型如 Cortex-M4/M7 上的 TensorFlow Lite Micro。选型的核心不是看谁算力高而是看谁能在你的功耗、成本、尺寸约束下跑得动你的模型。2.1 算力、内存与工具链三件事分开看很多人选芯片只看“TOPS”这个数字这其实是行业内最大的误导。TOPS 是理论峰值算力是在最优算子、最优数据布局下才可能达到的数值实际部署乘以 30% 到 50% 就是很了不起的了。更关键的是不同芯片的 TOPS 定义还不同有些是 INT8有些是 INT4甚至还有稀疏化加成完全没有可比性。我认为选型时要分开看三个维度算力TOPS / GOPS决定模型推理的理论上限。按经验每 1 TOPS 大约能支撑 1 路 1080p30fps 视频的轻量目标检测实际还要看算子的优化程度。内存带宽和内存容量NPU 不算复杂可内存不够或者带宽不足照样跑不动大模型。内存带宽决定了每帧数据喂给 NPU 的速度模型变大后带宽不足会导致推理时间急剧拉长模型容量则像“仓库”塞不进 3MB 以上的模型硬件规格再高也白搭。工具链与算子支持芯片公司配套的转换工具、量化工具、推理运行时是否成熟决定你从 PyTorch 模型到板子上跑通所需的团队人力和时间。我见过某芯片的 NPU 算子支持列表只有寥寥几个一个常见的转置卷积都跑不了最后只能把模型结构改得面目全非。2.2 不同量级硬件方案定位对比用我最近接触的几类方案做一张实际选型对比方案层级代表芯片算力范围内存典型功耗适合场景MCU 极简方案STM32L4、RP2040几十到几百 GOPS几十到几百 KB SRAM几 mW 到几十 mW关键词唤醒、简单振动分类、低帧率存在检测MCUNPU 中等方案STM32N6、瑞萨 RA8D11-2 TOPS几 MB 内部 SRAM 外部 PSRAM100 mW 以内摄像头前端的物体分类、人脸存在检测、单目标计数高性能 SoC 方案RK3588、Jetson Orin Nano、地平线 J53-100 TOPS2-16 GB LPDDR1-10 W多路视频结构化、复杂姿态识别、大模型本地推理All-in-One 视觉模组君正 T41、星宸 SSC338Q、爱芯 AX6200.5-3 TOPS128 MB DDR0.3-1.5 W整板电池摄像头、门锁、巡检记录仪这四档不是递进关系而是“够用就好”的关系。我在做电池摄像头时曾纠结要不要上 RK3588能有很强的本地算力但电池供电场景下光 SoC 的待机漏电流就足以让续航目标泡汤最后还是选了带 0.5 TOPS NPU 的视觉专用 SoC配合 ARM Cortex-A7 跑 Linux实现了 50 mW 左右的待机功耗和满功耗 600 mW 的推理功耗才最终把“半年续航”的指标做了下来。2.3 不要忽视“外设”带来的功耗黑洞芯片本身功耗只是端侧 AI 硬件部署的起点真正的功耗往往在外设上。摄像头传感器的点屏、闪光灯、补光的 LED、4G 模块的发射峰值、甚至是板子上的降压芯片的静态电流每一项都可能比 NPU 本身更费电。我做第一个低功耗视觉模块时测出来整机待机电流 12mA以为 CPU 进入 sleep 就万事大吉了。后来逐步排查发现一颗 LDO 因为压差太大静态功耗就有 8mA供电回路里的分压电阻和 LED 指示灯又吃掉了 2mA。把这些细节处理完之后整机待机电流才真正压到 0.8mA。选芯片的时候一定要把“外设供电可关断”作为硬性指标每个外设都要能独立控制电源通路。3. 超低功耗端侧 AI 视觉模块实战电池供电的端点 AI 是怎么炼成的“超低功耗端侧 AI 视觉模块”这个词近两年越来越热本质上就是想在电池供电的约束下把图像采集和 AI 分析都做到设备端。难点不在于“能跑 AI”而在于“大部分时间几乎不耗电瞬间启动、瞬间算完、再瞬间关掉”。这件事对硬件和软件都是极大的考验。3.1 典型场景的功耗预算怎么算常见的电池供电视觉场景包括智能门锁带猫眼识别、野外红外相机、智能电表读数相机、宠物喂食器、工业仪表盘拍照巡检。这些场景有共性平时在“极低功耗监听”状态出现事件时“快速唤醒并完成推理”。以我的项目为例电池容量 18000mAh目标续航 6 个月。估算流程如下每天触发事件(如人形出现)约 30 次每次事件完整流程唤醒 抓图 推理 可选回传 平均 1.2 秒期间平均电流 350mA每天事件总耗电 30 × 1.2 秒 × 350mA 12600 mA·s 3.5 mAh每天待机 24 小时待机电流目标 0.5mA耗电 0.5 × 24 12 mAh每天总耗电约 15.5 mAh18000mAh 理论可用约 1161 天考虑电池低温衰减和自放电实际打 6 折约 696 天远超 6 个月目标。这就是超低功耗端侧 AI 视觉模块的典型预算逻辑待机电流决定了续航下限事件功耗决定了可用天数。如果待机电流降到不了 1mA 以下这项目基本没法用电池做。3.2 硬件层面一整套“事件驱动”电源管理设计电池供电的端点 AI 硬件和插电设备最大的不同是每个元器件都要能“睡觉”而且要睡得够死。我总结了几条硬性设计准则用一颗独立 RTC 或超低功耗 MCU 作为常开电源域负责定时唤醒和外部事件监听。主 SoC 完全断电而不是睡眠。电源树上每个模块都要有独立的负载开关MOS摄像头、SD 卡、4G 模组、NPU 的电源分别可控。谁不干活就把谁切掉。注意“启动瞬间的电流尖峰”。摄像头 sensor 上电瞬间电流尖峰可能高达平均功耗的 5-10 倍这对电源设计和电池选型都有冲击要加软启或大电容缓冲。低功耗不等于低性能。唤醒后要在几百毫秒内完成从断电状态到系统就绪因此启动选择要有快速加载能力尽量选支持从 SPI NOR Flash 快速启动的芯片避免 Linux 从 SD 卡启动那 1-2 秒的大电流消耗。3.3 软件层面模型量化和事件驱动的推理策略功耗不只是硬件的事软件策略对续航的影响同样巨大。我们的做法可以归纳为“三级事件驱动”第一级用 PIR人体红外或微波雷达作为硬件级触发器检测到运动才给主系统发出唤醒信号。这是最省电的因为 PIR 模块待机功耗在几十微安级别。第二级主系统唤醒后先跑一个超轻量级模型比如 MobileNetV2 的 1/8 版本或者 SSD-Lite判断画面里是否存在“可疑目标”。如果只是风吹草动或者小动物直接关机关灯不唤醒高算力 NPU。第三级只有第二级确认是目标时再上高精度模型精细识别并把关键帧存盘或回传。这样的层级把“高功耗的 AI 推理”限制在了少量关键帧上而不是每帧都跑。实测下来一个 0.5 TOPS 的 NPU 跑轻量检测INT8 量化后单帧延迟约 30ms功耗约 500mW但每秒只跑 1-2 帧平均下来功耗就只有峰值功耗的 1/20。这比一味追求“每次唤醒尽量跑满帧率”要省电得多。模型侧的关键是量化。现在主流 NPU 都支持 INT8 量化有些新芯片甚至支持 INT4。量化不是简单地所谓“转成 int8”而是要准备校准集、做逐通道缩放、甚至要做混合精度量化来解决敏感层的掉点。我通常的做法是用 5000 到 10000 张覆盖各个光照和角度条件的真实场景图做校准而不是用训练集的子集这样出来的量化模型在不同现场环境下的泛化能力更好。3.4 野外实测中的功耗数据项目结束后我们拿整机做了连续 72 小时的功耗记录选取 3 个典型时刻做样本节选工作状态平均电流持续时间说明深度待机RTC监听主SoC断电0.55 mA无事件12V电池经DCDC后实际功耗唤醒后抓图轻量推理340 mA0.8 秒摄像头NPU工作高精度识别4G回传780 mA2.5 秒NPU全速4G发射峰值连续事件场景30秒内被反复触发210 mA持续处理器长开电源管理频繁切换最终折算实际续航约 8 个月比预算还多了一个多月。核心原因就是我们用事件驱动设计把大部分时间都维持在“深度待机”状态而不是让系统在“满速但空闲”的状态下空转。这一点对于所有超低功耗端侧 AI 视觉模块都通用系统“睡着了”才是最低功耗而不是“快速跑起来但没活干”。4. 模型从 PC 到板子的最后一公里部署细节与踩坑记录硬件和系统都调好了模型在 PC 上跑得飞起可一上板子就“老大爷散步”这是端侧 AI 项目中最常见的落差。最后一公里的部署通常决定了项目成败。这里分享几个我亲身踩过的坑。4.1 推理框架的选型逻辑端侧部署先选运行框架。常见的选项包括TFLite Micro适合 MCU 级内存占用极小但算子支持少。TensorFlow LiteTFLite适合手机和 Linux 板卡成熟稳定算子覆盖广但部分传统模型结构不兼容。ONNX Runtime中间表示兼容性强适合在 CPU、某些 GPU 上直接用。芯片厂商自带的推理框架如 RockX、HBDK、EIQ性能最高但绑定特定硬件迁移成本高。我的建议是除非有特殊兼容性需求否则在量产项目中直接用芯片厂商的 SDK而不是上来先用通用框架。厂商的算子库、驱动、内存分配器和底层硬件调度都是深度绑定的通用框架跑出来的效率通常只有原生 SDK 的 60%-80%。如果一定要通用框架起手也要早早验证关键算子尤其是检测头部分的卷积、上采样、NMS在板子上的表现。4.2 算子转换的兼容性陷阱从 PyTorch 导出的 ONNX 模型往往包含一些“纸面合法实际不支持”的算子。我这几年遇到最多的三类动态尺寸的输入或输出。很多模型在导出时保留了动态 batch 或动态 H/W而 NPU 通常要求静态 shape。解法是在导出时固定输入尺寸或者在部署代码里做 Padding。非对称 padding 和 dilated convolution。别看这两个在 PC 上都是“常规操作”不少 NPU 的硬件加速单元就是不支持。遇到这种情况要么把算子替换成等效的组合比如非对称 padding 换成裁切要么拆成多个算子让 CPU 兜底。后处理中的非规则逻辑。NMS、TopK、矩阵取反这些有 if-else 逻辑的算子在 NPU 上极难实现。实践中我会把后处理剥离开让 NPU 只负责张量运算后处理用 CPU 上的一两百行 C 代码搞定。虽然损失一点延迟但换来的是模型的“可部署性”这笔账很划算。4.3 一个实用的端侧 AI 硬件部署流程我把经过多次迭代验证的部署流程写在这里尽量确保工程团队拿到就能用起点在 PC 上用 PyTorch 或 TensorFlow 训练模型达到目标 mAP 或准确率但不要盲目追求大模型要在精度和速度之间留余量。转换用 ONNX 导出模型再转成芯片厂商的模型格式通常是 .rknn、.nb、.kmodel 等。转换过程中打开“模型优化”可以自动做算子融合。量化校准准备 1000 张以上现场图片做校准集执行 INT8 量化。先用厂商默认设置跑一遍看准确率掉点再用混合精度针对敏感层微调。硬件在环仿真先在板子上跑单张图用硬件计时器测延迟和内存峰值。如果延迟超标最有效的优化选项是缩小输入分辨率、减帧率、剪掉不必要的通道、换轻量化骨干网络。功耗标定分别测“待机”“推理”“回传”三态功耗核对总预算。压力测试连续运行 72 小时监控内存泄漏、定期唤醒失败、温度过冲等。我曾经就遇到过板子在 60°C 下 NPU 频率自动拉低导致推理超时的问题这类“热降频”问题必须在样机阶段就测出来。4.4 实测中值得单独说的小技巧对于摄像头前端的图像预处理缩放、格式转换、去畸变不要全在 CPU 上做。优先用芯片自带 ISP 和硬件缩放模块NPU 直接消费 YUV 或 RGB 数据能省下不少 CPU 算力和功耗。推理时用“帧间去重”如果连续几帧画面内容几乎一致比如固定摄像头就跳过 AI 推理直接用上一次结果。这可以在纯软件层面节省 30% 的无效推理功耗。多线程流水线设计。抓图、预处理、推理、后处理做四级流水线而不是串行执行。这样每帧延迟不变但吞吐可以提升 2-3 倍。5. 端侧 AI 的未来方向从“近场识别”到“场景自适应的轻量决策”最后想聊聊端侧 AI 往前看会是什么样。因为我自己做的项目跨度比较大从 MCU 到边缘盒子都有我观察到几个趋势很明确。第一个趋势是模型“更轻、更快、更准”的螺旋上升。曾经跑不动的 YOLOv4今天在 0.5 TOPS 的芯片上也能量化部署而新出的更高效的 Backbone 和检测头正不断把同样精度的模型体积继续往下压。未来端侧视觉模块会向着“1-2 TOPS 内跑出接近当年云端效果”的方向演进而 0.1 TOPS 级别的 MCU 上也会跑起越来越多的高精度事件分类器。第二个趋势是“多模态”在端侧落地。视觉之外语音、震动、温湿度、雷达等多源传感器数据可以在端侧融合做更靠谱的场景理解和决策。比如电池摄像头可以同时用 PIR 的“有没有人”和麦克风的“有没有异常响声”来自动调节检测灵敏度既降低误报又进一步省电。第三个趋势是“自适应端侧更新”。模型不会永远一套走天下。未来芯片上的 NPU 会支持更多的在线学习策略比如利用设备端积累的新样本在低功耗的状态下做增量更新。目前受限于内存和算力这还比较难但已经有芯片公司开始试探了。到时候端侧 AI 就从“部署到设备就不管了”进化成“在设备上持续进化”这对设备商和用户的价值都是指数级的。个人在几年实践中最大的体会是端侧 AI 技术上永远没有“一步到位”更多的是在一个个实时性、隐私性、功耗、成本的约束下做权衡。如果你正在做类似项目我会建议你从需求反推硬件而不是从参数表里挑“看起来最强”的芯片。多花一天在功耗预算和工具链验证上比之后返工一个月省太多事。别的不多说了如果你的团队正在选型或者部署中遇到了卡点欢迎交流。