1. 低功耗视频这条赛道为什么值得单独拿出来聊低功耗视频这个词外行听起来像是两个不太搭界的词拼在一起。视频意味着大带宽、高算力、持续运行低功耗意味着省电、长续航、小体积这两件事天然矛盾。但恰恰是这种矛盾撑起了一个非常具体的市场电池供电的摄像头、门铃、行车记录仪、运动相机、宠物看护器、户外监控设备。这些设备有一个共同特征——它们不能一直插着电但又必须持续地看、持续地录、持续地判断。我最早接触这类方案是在做一款电池门铃的时候。当时选型的第一反应是找一颗通用MCU加一颗WiFi模组再配一个图像传感器觉得这样最灵活。结果实测下来待机功耗压不下去唤醒一次要几百毫秒用户按下门铃到手机弹出画面中间能等三四秒。这个体验在消费级产品里基本等于判死刑。后来才意识到低功耗视频不是把通用芯片拼起来就能做好的事它需要一颗从一开始就为这个场景设计的芯片——在待机时几乎不耗电在事件触发时能瞬间唤醒、快速出图、快速编码、快速送出去。合肥君正这家公司就是在这个缝隙里扎下去的。它的产品线围绕低功耗视频和边缘智能展开核心思路是把图像处理、视频编码、轻量级AI推理和低功耗管理集成到一颗SoC里让设备在大部分时间里处于极低功耗的监听状态只在真正需要的时候才全速运转。这个思路听起来简单但工程实现上有一堆坑唤醒延迟怎么压、内存怎么省、编码器怎么在低码率下保住画质、AI模型怎么塞进有限的算力和内存里。这些问题的答案决定了产品能不能落地。这篇文章不打算写成公司宣传稿而是想从技术选型和工程实践的角度把低功耗视频加边缘AI这条路线拆开讲。适合正在做电池类视觉产品的硬件工程师、嵌入式开发者也适合想了解这类芯片到底难在哪里的产品经理。我会尽量把原理、参数、踩坑经验都摊开说能抄作业的地方直接给方案。2. 低功耗视频芯片的核心矛盾待机功耗与唤醒速度的拉锯2.1 为什么待机功耗是这类产品的生死线先算一笔账。一颗常见的18650锂电池容量大约2600mAh标称电压3.7V总能量约9.6Wh。如果设备待机功耗是1mW理论上能撑9600小时也就是400天。如果待机功耗是10mW就只剩40天。如果待机功耗是50mW不到8天。而消费级电池摄像头通常要求至少3到6个月的续航这意味着整机待机功耗必须控制在1mW到3mW这个量级。这个数字有多苛刻很多通用WiFi模组光是维持网络连接的待机功耗就在20mW以上还没算主控和传感器。所以低功耗视频方案的第一条铁律是不能一直保持网络连接也不能一直让主控全速运行。正确的做法是分层管理——最底层是一个极低功耗的监听电路可能只消耗几十微瓦负责检测是否有事件触发触发之后才唤醒主控和通信模块快速完成采集、编码、上传然后重新回到深度休眠。合肥君正的方案里这个分层管理是硬件级别的。芯片内部有独立的低功耗域可以在主域断电的情况下维持RTC、部分SRAM和唤醒逻辑。PIR传感器或者音频检测模块的输出直接接到唤醒引脚上从触发到主控开始执行代码延迟可以压到毫秒级。这个设计的关键在于唤醒逻辑不能依赖软件轮询必须是硬件中断驱动否则光是轮询本身就会把功耗吃光。2.2 唤醒速度为什么比待机功耗更难做待机功耗可以靠工艺和电源域划分来优化但唤醒速度是一个系统性问题。设备被唤醒之后需要完成一系列动作传感器上电并稳定、时钟恢复、PLL锁定、DDR初始化、图像信号处理器配置、编码器配置、网络重连、鉴权、传输。每一步都有延迟加起来很容易超过一秒。我实测过一些方案从PIR触发到手机收到第一帧画面快的能到800毫秒慢的要三秒以上。对于门铃这类场景用户按下去之后如果超过一秒才看到画面就会觉得卡。对于行车记录仪碰撞触发后如果唤醒太慢可能错过关键的前几秒画面。君正在这方面做的优化我理解主要有几个层面。一是把一些初始化工作提前做好比如在深度休眠时保留部分时钟和电源状态唤醒后不需要从头初始化。二是把图像采集和编码的流水线做得很短传感器出图之后直接进编码器中间不经过多余的内存拷贝。三是网络重连做了快速通道保存连接上下文唤醒后直接恢复而不是重新握手。这些优化单独看都不神奇但叠在一起就能把端到端延迟压到可接受的范围。注意唤醒速度的测试不能只看芯片手册上的数字一定要在整机状态下测。传感器上电稳定时间、电源纹波、天线匹配这些因素都会让实际延迟比理论值差很多。2.3 编码器在低码率下的画质取舍低功耗视频还有一个容易被忽略的点编码。电池设备通常走WiFi或蜂窝网络带宽有限码率必须压得很低。但码率一低画质就崩尤其是运动场景和低照度场景。这时候编码器的质量就体现出来了。君正的芯片一般支持H.264和H.265部分型号支持智能编码也就是根据画面内容动态调整码率。比如画面静止时大幅降低码率有运动时再提上去。这个策略对电池设备特别有用因为大部分时间画面是静止的省下来的码率和功耗都很可观。但智能编码有个坑如果场景检测做得不好运动物体刚出现的那几帧可能被压得很糊等码率提上来已经错过了。所以调参的时候我一般会把运动检测的灵敏度调高一点宁可多花一点码率也要保证关键帧的清晰度。另外低照度下的降噪和编码要配合好降噪太狠会抹掉细节降噪不够则编码器会把噪声也编进去反而更费码率。3. 边缘AI塞进低功耗芯片到底难在哪3.1 算力、内存、功耗的不可能三角把AI推理放到设备端好处很明显不用把原始视频全传上去省带宽、省功耗、响应快、隐私也好。但难点在于低功耗芯片的算力通常只有零点几TOPS到几TOPS内存可能只有几十MB功耗预算可能只有几百毫瓦。在这个约束下跑AI模型就像在小户型里塞下一整套家具每一寸空间都要算计。君正的思路是只做轻量级推理比如人形检测、人脸检测、移动侦测、宠物识别这类任务。这些任务的模型可以做到几百KB到几MB算力需求在几十到几百MOPS。芯片里通常会有专门的NPU或者DSP来加速而不是用CPU硬跑。用CPU跑不是不行但功耗会高一个数量级而且会拖慢整个流水线。我见过一些团队一开始想在一颗低功耗芯片上跑通用目标检测结果发现帧率只有一两帧功耗还超标。后来退回到只做人形检测把模型量化到int8输入分辨率降到128x128才勉强跑通。这个教训是边缘AI在低功耗场景下不要追求通用性要针对具体任务做极致优化。3.2 模型量化与剪枝的实际操作模型量化是必做的。把float32的权重转成int8模型大小直接降到四分之一推理速度通常能提升两到四倍功耗也明显下降。但量化会带来精度损失尤其是对小目标和低对比度场景。我的经验是量化之后一定要用真实场景的数据做校准不能只用公开数据集。校准集要覆盖白天、夜晚、逆光、雨雾这些实际会遇到的情况否则模型在实验室里看着没问题一到现场就漏检。剪枝是另一个手段。把模型中贡献小的通道或层去掉能进一步压缩模型。但剪枝之后通常需要重新训练或者微调否则精度掉得厉害。对于嵌入式团队来说如果缺乏训练能力可以考虑用现成的轻量级骨干网络比如MobileNet系列或者ShuffleNet系列这些网络本身就是为移动端设计的量化友好剪枝空间也大。还有一个容易被忽略的点是输入预处理。摄像头出来的图像通常是RGB或者Bayer格式而模型可能需要YUV或者灰度图。这个转换如果放在CPU上做会消耗不少算力。君正的芯片通常支持硬件级的格式转换和缩放直接输出模型需要的输入格式省掉这一步的开销。3.3 推理结果怎么和视频编码协同边缘AI的推理结果不是孤立的它要和视频编码、传输策略联动。比如人形检测到有人才把视频码率提上去并开始上传没人的时候只传低码率的缩略图或者干脆不传。这个联动逻辑如果设计得好能大幅省电省流量。但联动也有坑。如果检测和编码是两套独立的流水线可能会出现检测到人但编码器还没切到高码率的情况导致关键画面被压糊。所以最好让检测结果直接控制编码器的参数中间延迟越小越好。另外检测的帧率不一定要和编码帧率一样可以检测跑低帧率编码跑高帧率这样既省算力又不丢画面。提示推理和编码共用内存带宽的时候要注意优先级。如果推理把带宽占满了编码器可能会丢帧。一般建议给编码器更高的内存优先级推理可以适当降帧。4. 从芯片到产品那些手册上不会写的工程细节4.1 电源树设计决定了一半的成败低功耗视频产品的电源树比普通嵌入式产品复杂得多。因为芯片内部有多个电源域每个域的电压和上电时序都有要求。如果电源树设计得不好轻则功耗超标重则芯片根本起不来。我踩过的一个坑是DCDC和LDO的选型。DCDC效率高但纹波大可能干扰图像传感器和射频。LDO纹波小但效率低压差大的时候发热严重。正确的做法是混合使用主电源用DCDC做一级降压然后对噪声敏感的模块用LDO做二级稳压。另外每个电源域的上电时序要严格按照手册来该先上的先上该后上的后上否则可能出现闩锁或者初始化失败。还有一个细节是休眠时的电源管理。芯片进入深度休眠后哪些电源域要保留哪些要关掉这个要在硬件设计阶段就规划好。如果保留的域太多待机功耗下不来如果关得太多唤醒之后重新初始化的时间又太长。这个平衡点需要根据具体产品的续航要求和响应要求来定。4.2 传感器选型和驱动适配的坑图像传感器的选型不能只看分辨率和帧率。低功耗场景下要重点关注几个参数休眠电流、唤醒时间、低照度性能、以及是否支持硬件级的运动检测。有些传感器支持在休眠状态下做低分辨率的运动检测检测到变化才唤醒主控。这个功能如果用好可以省掉外置PIR降低成本和体积。但不同传感器的这个功能实现差异很大有的灵敏度不够有的误报率高需要实际测试。驱动适配也是个大工程。传感器的寄存器配置通常有几百个不同厂家的传感器配置方式还不一样。君正的SDK一般会提供常见传感器的驱动但如果你选的传感器不在列表里就需要自己移植。移植的时候要注意时钟配置、MIPI时序、曝光增益控制这些细节任何一个不对出图就是黑的或者花的。4.3 网络传输的省电策略网络传输是功耗大户。WiFi模组在发送时的峰值电流可能达到几百毫安如果传输策略设计得不好电池很快就被抽干。我的做法是尽量批量传输而不是来一帧传一帧。比如攒够一秒的视频再一起传这样WiFi模组可以更长时间处于休眠状态。另外传输的时候要尽量用低带宽模式比如802.11b或者低速率模式虽然传输时间长一点但峰值电流低总体功耗可能更省。还有一个策略是本地缓存加按需上传。设备本地存一段视频只有检测到事件才上传关键片段平时只上传心跳和缩略图。这个策略对云存储成本也更友好。注意WiFi模组的省电模式要和路由器的beacon间隔配合。如果路由器beacon间隔太长模组休眠时间可以更长但唤醒延迟会增加。这个参数需要根据实际网络环境调。5. 实测数据与调优经验把功耗从毫瓦级再往下压5.1 功耗拆解每一毫瓦都要找到出处做低功耗优化第一步是精确测量。不能只看整机电流要把各个模块的功耗拆开。我的做法是在电源树的每个分支上串一个采样电阻用高精度电流探头或者功耗分析仪分别测。测的时候要覆盖所有状态深度休眠、监听、唤醒中、采集、编码、传输。实测下来一个典型的电池摄像头深度休眠应该在几十微安到几百微安监听状态在1mW以内唤醒后的峰值可能到几百毫瓦但持续时间要尽量短。如果深度休眠超过1mA就要查是哪个模块没关干净。常见的问题包括LDO的静态电流太大、传感器的休眠配置不对、GPIO上拉电阻一直在耗电、DDR没有进入自刷新模式。5.2 唤醒延迟的逐段优化唤醒延迟的优化要把整个链路拆开测。从PIR触发开始到主控开始执行第一条指令这是硬件唤醒时间从执行指令到传感器出第一帧这是传感器初始化时间从出图到编码完成这是编码时间从编码完成到数据发出这是网络时间。每一段都要单独测找到瓶颈。我遇到过的一个瓶颈是DDR初始化。有些方案为了省电休眠时把DDR完全断电唤醒后重新初始化要几十毫秒。后来改成DDR进入自刷新模式虽然休眠功耗高了一点但唤醒时间缩短了一大半整体体验反而更好。这个取舍要看产品对响应速度的要求。另一个瓶颈是网络重连。如果每次唤醒都重新扫描、关联、鉴权、获取IP可能要一两秒。优化方法是保存连接上下文唤醒后直接恢复。但这个功能需要WiFi模组和协议栈支持不是所有方案都能做。5.3 温度对功耗和性能的影响低温环境下电池内阻增大实际可用容量下降同时芯片的漏电流也会变化。高温环境下漏电流增大待机功耗会上升。这些因素在实验室常温下测不出来但到了实际使用场景就会暴露。我的经验是在-10度到50度这个范围里至少要做三个温度点的功耗测试低温、常温、高温。如果产品要出口到寒冷地区还要测-20度甚至-30度。测试的时候要注意电池本身的特性也会随温度变化最好用程控电源模拟电池而不是直接用电池测。6. 这条路线接下来还能怎么走低功耗视频加边缘AI这个方向远没有到天花板。从技术上看还有几个明显的演进空间。一是模型和硬件的协同设计。现在的做法通常是先有芯片再想办法把模型塞进去。未来如果能在芯片设计阶段就考虑目标模型的算子特性定制一些专用加速单元效率还能再上一个台阶。二是多模态融合。现在主要是视觉未来可以加上音频、雷达、甚至环境光传感器用多模态信息做更准确的触发和判断减少误报进一步省电。三是端云协同的进一步细化。哪些推理放端侧哪些放云侧这个划分不是固定的。随着端侧算力提升和模型压缩技术进步会有更多任务从云侧移到端侧响应更快隐私也更好。从产品角度看电池类视觉设备的形态还在不断分化。除了门铃和摄像头还有宠物项圈、车载监控、农业监测、工业巡检这些场景每个场景对功耗、算力、成本的要求都不一样。芯片方案要做的是在这些差异化需求里找到最大公约数同时保留足够的灵活性。我在实际项目里的体会是低功耗视频这个事没有一招鲜的解决方案。每一毫瓦的节省、每一毫秒的延迟优化都是靠一个个细节抠出来的。选对芯片只是起点真正的功夫在电源设计、驱动适配、参数调优、场景测试这些脏活累活里。君正这类厂商的价值在于把最难的底层做扎实了让做产品的人能把精力放在场景和体验上。这个分工对整个行业来说都是好事。
