聊到“可重构低功耗AI芯片”和“智能门锁”,很多人第一反应是:门锁而已,需要这么高级的芯片吗?前阵子我看了某家可重构计算芯片团队的负责人欧阳的分享,主题正好就是围绕这块展开的。他的观点挺有意思——智能门锁正在从“一把锁”变成“一个全天候待机的边缘AI终端”,而可重构低功耗AI芯片,恰恰是平衡算力、功耗和成本的一个很务实的答案。这篇文章我就顺着这个方向,把可重构低功耗AI芯片为什么适合智能门锁、落地时要关注哪些指标、真实项目里会遇到哪些坑,一块儿拆开聊透。
适合读这篇文章的人,我大概圈一下:做智能硬件或门锁产品经理、负责端侧AI方案的算法工程师、做芯片选型和BOM成本控制的硬件负责人,还有对边缘计算芯片架构感兴趣的开发者。如果你正被“电池不够用、识别太慢、算法老要改”这几个问题折磨,那这篇文章大概率能帮你打开思路。
1. 先搞清楚三件事:可重构、低功耗、AI芯片分别解决什么问题
1.1 可重构架构的核心思想
可重构计算,简单说就是芯片内部的运算单元和数据通路不是固定死的,而是可以在运行前甚至运行中被重新配置。传统芯片设计里,ASIC(专用集成电路)把算法固化成硬件,效率最高但改不了;CPU/GPU走通用指令集,灵活但能效比吃亏。可重构架构把这两者的优势做了一次折中:把计算阵列做成很多个小单元,通过配置信息把单元连接成适合当前算法的数据流结构。
用乐高来类比会比较直观。CPU像一套已经拼好的成品玩具,玩法固定、拆了重拼很费劲;ASIC像一块定制雕刻的实木模型,好看好用但想改造型等于重做;可重构芯片就是那箱子乐高积木,图纸变了可以拆开按新图纸重拼。在芯片层面,这个“重拼”就是改变数据在计算单元之间的流动路径和每个单元执行的操作类型,整个过程由配套的编译器把算法自动映射成硬件配置流。
在智能门锁这种产品上,可重构的意义非常实际:算法版本会迭代,人脸模型会升级,甚至今天做的是人脸识别,明天可能要加上手势识别或宠物检测。如果芯片算法锁死,每次升级都要改板子,这对量产产品来说是很痛苦的。
1.2 低功耗不是“省电”两个字那么简单
低功耗这三个字,听上去谁都会说,但真正落地到芯片设计里,是一整套组合拳:工艺制程选择、多电压域设计、动态电压频率调节、时钟门控、数据稀疏跳过,以及针对神经网络计算特性的存算优化。把这些手段组合起来,才能做到“该算的时候快,不该算的时候几乎不耗电”。
对智能门锁来说,功耗维度比手机严苛得多。手机可以一天一充甚至一天几充,门锁不能,用户期望是“装上电池至少用一年,最好两三年不用管”。这决定了芯片在待机状态下的功耗必须压到极低水平,而唤醒后又要能瞬间跑到足够高的性能完成识别任务,不能等用户站在门前转半天圈。
欧阳在分享里特意提到一点:低功耗设计的关键不只是峰值功耗低,而是“功耗与场景匹配”——系统知道当前在做什么,就能把芯片调到对应的工作状态,整体平均功耗才能降下来。这句话说起来容易,做起来需要芯片和软件深度配合。
1.3 智能门锁为什么需要专属AI芯片
前几年很多门锁用的是主控MCU跑算法,或者干脆把数据传到云端识别。MCU方案遇到稍大一点的神经网络就捉襟见肘,人脸识别延迟高、耗电大,体验很一般。云端方案在隐私和断网场景上又有硬伤——门口没网或网不好,锁就变傻了,谁都不敢用。
所以行业逐步往“端侧AI”迁移,也就是在门锁内部完成识别。但端侧部署对芯片提出了三个具体要求:算力要够(跑得动人脸网络)、功耗要低(电池撑得住)、成本要可控(门锁走量但毛利压力大)。这三者互相拉扯,传统方案很难同时满足,这就给可重构低功耗AI芯片留出了空间——它可以在专用和通用之间找到一个效率比较高的平衡点。
2. 智能门锁场景下的功耗预算和算力需求拆解
2.1 智能门锁的真实工作负载长什么样
很多人以为门锁的AI负载就是把一张人脸图片丢进神经网络跑一下,测个延迟就完事了。真做产品你会发现,整个工作负载是分阶段、分场景的,而且不同阶段的功耗和性能要求完全不一样。
门锁的工作循环大致是:待机 → 事件唤醒 → 感知采集 → 前处理 → 推理识别 → 执行动作 → 回到待机。待机阶段可能长达几十个小时,功耗要按微安级别算;而唤醒识别阶段只有几百毫秒,功耗可以放宽到百毫瓦甚至瓦级。这种“极长低功耗待机 + 极短高性能突发”的负载特征,决定了芯片不能以一个固定频率工作,必须有非常深的低功耗状态和多档性能档位。
另外,门锁面临的环境条件也更复杂:户外低温电池掉电快、阳光直射屏幕/镜头有反光、老人小孩脸部特征变化大、戴帽子口罩遮挡多。这些都会影响识别算法,进而对芯片的预留算力和动态范围提出要求。
2.2 功耗预算怎么算:待机、唤醒、识别三个阶段
我一个做门锁的硬件朋友给过一个比较典型的预算模型,我拿来说下大致思路。
假设整锁用4节五号碱性电池,总能量大约在2400mAh×4×1.5V≈14.4Wh,但碱性电池根本不能把能量全放干净。考虑到可用系数通常按60%算,实际可用能量大概是8.6Wh。如果目标续航一年,平均功耗就得控制在8.6Wh÷8760h≈1mW以下。
继续拆:待机部分(MCU休眠、触摸芯片待机、通信模块待机)大概占0.3-0.5mW;AI芯片待机功耗理想情况应该在几十微瓦量级;剩下的预算要给唤醒后的人脸识别。假设每天开门10次,每次从唤醒到识别完成消耗的能量是50mJ(约0.014mWh),一年3650次也才约50mWh,摊到全年平均不到0.006mW。这么一算就明白,续航的大头其实不在识别过程,而在待机,所以降低待机功耗的价值远大于压低识别峰值功耗。
这个预算模型告诉我们一个很反直觉的结论:选AI芯片时,峰值算力不用追太高,够用就行,但待机功耗和唤醒速度是硬指标。识别慢半秒,用户可能还能忍;待机电流多几十微安,续航直接掉几个月,产品口碑就没了。
2.3 参数对照:人脸识别、指纹、猫眼的算力需求
不同门锁形态对AI芯片的需求差异很大,我整理了一个参考表:
| 门锁功能 | 典型算法 | 算力参考 | 时延要求 | 峰值功耗参考 |
|---|---|---|---|---|
| 指纹识别 | 小型CNN/传统特征 | 0.1-0.5 TOPS | <300ms | 30-100mW |
| 人脸识别(近红外) | MobileNet类/自研轻量网络 | 0.5-1.5 TOPS | <500ms | 300mW-1W |
| 人脸识别(RGB+深度) | 多模态融合网络 | 1-4 TOPS | <600ms | 1-2W |
| 猫眼/视频监控 | 实时检测/编码 | 1-2 TOPS | 实时性要求高 | 0.5-1.5W |
注意,TOPS只是参考,实际部署时更关键的是“有效算力利用率”。同样标称1TOPS的芯片,有的跑你那个网络能用到60%,有的只能用到20%。可重构芯片的一个好处是计算阵列能按网络结构定制数据通路,利用率通常能做到比通用NPU高,这对功耗和成本都是实打实的帮助。
3. 可重构低功耗AI芯片在门锁里的落地路径
3.1 芯片和算法怎么配合:从网络到配置流
很多人会问:可重构芯片的“重构”到底是怎么发生的?落地的时候算法工程师要做什么额外工作?
实际流程大概是这样:算法工程师训练好模型后,把网络结构交给配套工具链;工具链会把网络层(卷积、池化、全连接等)翻译成计算阵列可执行的配置流,同时生成调度信息,告诉芯片每个计算单元在哪个时间片做什么操作、数据从哪来、结果送到哪去。这个过程在概念上很像FPGA的综合布局布线,但它是面向AI计算阵列的更高层级映射,自动化程度也更高。
对用芯片的人来说,这个过程基本是“编译器干活,工程师把关”。比传统MCU开发多的一个环节是:你要理解你的网络结构里有哪些算子跑在计算阵列上、哪些跑在CPU上,有时候为了效率还得动手改网络结构,比如把某些不规则的算子改造成更规整的形式,让硬件利用率更高。欧阳团队在做门锁项目时也是这么干的——先跑通,再根据硬件反馈调网络结构,最后把IO耗时也优化掉。
3.2 针对门锁场景的优化策略
门锁场景有一个特别适合可重构架构的特点:工作负载相对固定,就那么几个识别网络来回用。可重构架构可以在每次开门时把网络重新配置到计算阵列上,完全按当前任务定制硬件行为。
具体优化可以做几个层面。
算子层的优化,比如卷积用直接映射还是Winograd、乘加运算的并行度设置多大,这些在传统芯片上由硬件决定,在可重构芯片上则可以通过配置去适应不同大小和通道数的卷积层。数据层的优化更关键:人脸图像输入后,前处理往往涉及均值减除、归一化、缩放等操作,这些是可以和卷积层融合的,融合之后数据不用反复在DDR和计算单元之间搬运,省下的时间比单纯算得快还明显。低功耗层面的优化则是动态关闭不用的计算单元、根据帧率动态调整时钟频率,以及在没有检测到人体时把整个AI流水线深度睡眠。
3.3 为什么这类方案比纯固定NPU更吃香
固定NPU(神经网络处理单元)的设计思路是把常见算子硬件化,跑网络时按固定调度执行,优点是开发简单、生态成熟。但它在碎片化的边缘AI场景里有点“水土不服”:算子一更新或者网络结构一变,硬件利用率可能断崖式下跌。
可重构芯片相当于给硬件加了一层“软件定义能力”,算法演进时不用换芯片。对智能门锁这种产品迭代快、型号多的品类来说,这能省下不小的研发成本——同一个芯片方案可以覆盖从低端指纹锁到高端人脸锁的产品线,只需要改算法和配置就行。
当然,可重构也有代价:编译器门槛比通用NPU高,工具链成熟度参差不齐,而且调度做得不好,实际性能可能还不如固定NPU。这里面的取舍,需要根据团队自身能力来判断,并不是说可重构方案一定优于NPU方案。
4. 实际项目中的经验:选型、调优、排查
4.1 芯片选型时一定要追问的五个指标
如果你真的要选一颗可重构低功耗AI芯片做门锁,我建议就别只看TOPS和工艺制程了,下面这几个问题一定要问清楚。
第一,待机功耗到底怎么测的?有些芯片标称“待机功耗XX微安”,但那是只保CPU休眠、AI阵列完全断电的状态,实际产品里外设供电和唤醒源还在耗电。要让原厂拿出整机参考设计的实测数据,别只信芯片单体的数据手册。
第二,唤醒到开始推理的时间是多少?门锁场景里,人走到门前到识别完成的总时延用户预期在1秒左右,其中传感器唤醒、IR补光灯稳定都需要时间,芯片端的启动和识别时间必须压到500ms以内才有得玩。
第三,工具链到底支持哪些算子?这是最容易踩的坑。很多主控说支持PyTorch模型,实际转换工具只支持有限算子,碰到不支持的算子就自动跑CPU回退,性能和功耗直接崩盘。选型时必须把自己要用的网络结构先跑一遍工具链,确认无回退且效率可接受。
第四,工作温度范围和电源稳定性。门锁在北方冬天要零下二十度能开机,电池低温下电压会跌落,芯片必须有足够宽的电源工作范围和温度适应性,最好选有户外产品量产经验的方案。
第五,原厂FAE支持力度和路线图。这点新人最容易忽略。可重构芯片的开发门槛不低,原厂能不能在关键阶段提供深度支持,直接决定项目能不能按时交付。选一个没有量产经验的方案,风险不是“多花点时间”,而是“卡在某个技术细节上出不来”。
4.2 调优过程中我踩过的几个坑
这里分享几个真实项目里比较有共性的坑,都是拿时间和功耗换来的教训。
第一个坑是低估了数据搬运的功耗。很多团队的优化只盯着计算阵列的MAC利用率,把算力优化得很漂亮,但没注意算子之间以及CPU和AI阵列之间的数据交互。跑起来以后发现,功耗里有将近一半是数据搬运和访存开销。解决办法是把相邻算子做融合、把中间结果尽量留在片上SRAM,而不是动不动就往DDR里写。这一点在可重构架构上尤其重要,因为配置流本身就是一种“搬数据”的机制。
第二个坑是活体检测引入的额外资源开销。人脸锁基本都要做活体检测防照片攻击,不管是基于近红外图像还是基于可见光图像,多路输入都意味着神经网络要处理更多数据。有些项目前期只按单模型评估算力,后来才发现活体检测模型加上去之后,识别时延和功耗涨了将近一倍。建议一开始就把活体检测、ISP前处理、人脸检测、人脸识别这几个模块统一放进资源规划里。
第三个坑是OTA升级对存储资源的挤压。可重构方案虽然算法可升级,但升级需要预留存储空间来放新配置流和模型参数。门锁主控Flash本来就是精打细算的,曾遇到过为了省Flash压缩配置流导致启动变慢的情况。选方案时最好预留30%以上的配置存储余量,顺便把差分升级机制也做进去。
4.3 常见问题速查与排查思路
| 问题现象 | 可能原因 | 排查思路 |
|---|---|---|
| 待机功耗偏高 | 芯片没有进入深度睡眠;外设供电没关干净 | 逐个外设测量电流;检查唤醒源配置是否意外拉高了唤醒频率 |
| 低温下识别失败率升高 | 电池电压跌落导致芯片降频;IR LED亮度不足 | 实测-20℃电池内阻与压降;给芯片和传感器预留电压余量 |
| 识别时延突然变长 | 后台OTA或日志任务占用了CPU/总线;网络退化到CPU回退 | 检查工具链log是否出现算子fallback;高峰期打点分析调度 |
| 唤醒后卡在启动阶段 | 配置流加载过慢;Flash读取速率低 | 改用XIP或预加载方式;压缩配置流长度 |
| 电池电量消耗非线性 | 低温下电池可用容量下降;频繁误唤醒 | 增加人体感应前置判断;校验唤醒阈值和休眠策略 |
| 多路图像处理时内存溢出 | 网络融合后中间张量过大 | 改流水线为分块推理;调整张量生命周期复用策略 |
这些都是可以边开发边积累的经验,建议团队在项目启动前就建一个类似的问题台账,把每个问题出现时的现象、根因、解决动作记录下来,后面做派生型号时会省很多事。
5. 写在最后:一条值得长期关注的技术路线
聊了这么多,我自己最大的体会是:可重构低功耗AI芯片的技术讨论,本质上是在回答一个问题——边缘AI芯片到底应该在“专用”和“通用”之间站在哪个位置?智能门锁这个品类很有意思,它规模大、负载相对固定、功耗约束严苛,而且用户对时延和隐私的要求又很高,刚好把可重构架构的特点都发挥了出来。
根据个人经验,如果你正在做类似的电池供电边缘AI产品,选型时不要被“高TOPS”带偏,多花时间在“待机功耗、工具链成熟度、算法演进空间”这三件事上,比什么都重要。另外,有机会的话一定找原厂要一份他们实际的“网络到配置流”的真实案例分析,而不是只听理论宣传。纸上谈兵的东西,到了酷暑或严寒的户外环境里,往往第一个崩。
我自己做边缘AI项目这几年,最深的感受是:硬件选型从来不是单比参数,而是比“与你的场景的匹配程度”。可重构低功耗AI芯片给智能门锁带来的不是某一项指标的碾压,而是一整套关于“如何在有限电量里算得又快又省”的系统思路。这个思路,放到智能猫眼、智能门铃、便携穿戴设备上,同样适用。后面我还会再写一篇专门讲可重构编译器的算子映射细节,感兴趣的话可以持续关注。