低功耗AI芯片之争：从TOPS/W到端侧落地的实战选型指南

低功耗AI芯片这几年的热度，可以说是被终端设备一路“逼”出来的。我第一次认真研究这个方向，是在一个带屏智能音箱的预研项目里：语音识别、人脸识别和轻量姿态估计都要尽量在本地跑，可整机待机功耗本来就紧张，分给AI加速部分的预算更是抠了又抠。那时候我就发现，所谓低功耗AI芯片的“明争暗斗”，表面上是各家在发布会PPT上比算力、比精度、比价格，私下里拼的其实是同一件事——在每一毫瓦电能里，到底能完成多少有效的AI推理。这篇文章会从指标、技术、市场和落地应用四个维度展开，我也会把过去在端侧项目里踩过的坑整理出来。无论你是正在做嵌入式AI选型，还是单纯对端侧智能方向好奇，这篇内容应该能帮你把思路理顺。

1. 算力的真实账单：低功耗AI芯片到底在“抢”哪笔账

1.1 为什么越来越多AI计算正在从云端往终端搬

过去几年，AI推理的主流思路是“上传云端，集中处理”。云端有GPU、有海量算力，理论上什么模型都能扛。但真实产品一旦涉及实时反馈，问题马上出现：首先是端到端时延，一个数据包从设备上传、排队、推理、返回，往返几十毫秒甚至几百毫秒，对于人脸开锁、跌倒检测这类场景太慢了；其次是隐私，麦克风、摄像头数据总要传到别人服务器上，合规和用户信任都会打折扣；第三是带宽和成本，视频监控若每路都回传原始码流，流量费用会直接拖垮预算。

所以行业开始把AI推理“下沉”到设备本地，至少要做一个前置过滤层。比如智能音箱先说“你好”，本地先完成唤醒词检测，确认后才上传云端做复杂语义理解；智能摄像头本地先框出人形和运动区域，再决定要不要上报。这些前置AI计算往往要7x24小时待命，普通CPU跑不动，即便跑得动，电池也扛不住。低功耗AI芯片的需求由此迅速放大：它不能再指望大风扇和大散热片，它必须在很小的功率预算内完成推理，同时留出足够算力给应用层。

我见过不少团队对端侧AI的误解：以为把模型压缩塞进固件就是端侧化了，结果整机待机功耗翻了倍，产品没上市就被续航测试刷下来。端侧AI是典型的“预算思维”，整个设备就是一个功耗池，AI模块只是里面的住户之一，住户之间还要抢名额。

1.2 TOPS和TOPS/W：看指标之前先搞清计算粒度

大家看低功耗AI芯片，首先会看到TOPS这个单位。TOPS是Tera Operations Per Second的缩写，代表每秒钟可以做多少万亿次整数运算。比如某款芯片标称8 TOPS，相当于每秒可执行8万亿次特定整数操作。这里的“特定”很关键，通常指INT8精度下的乘加计算，有些芯片会用INT4甚至稀疏模式来堆指标，不同精度之间的数字直接拿来比，意义不大。

真正和有参考价值的是TOPS/W，也就是能效比。以INT8计算为例，主流端侧芯片的能效范围大致在3到15 TOPS/W之间，少数设计极致的芯片能在特定负载上摸到20 TOPS/W以上。但这里的水分同样不小：TOPS/W是按峰值算力除以峰值功耗算出来的，实际跑模型时MAC阵列不可能一直满载，所以有效能效往往要打五折甚至更低。

我把不同精度的典型能效列成一张简表，方便有个直观感受：

这张表想说明的是：精度切到INT8，最直接的好处是内存占用和带宽需求降到四分之一，这也决定了端侧是否装得下某个模型。而低功耗之争的核心，其实是“单位功率下能做多少有效计算”，不是单纯的“多少T”。

1.3 广告峰值和有效算力之间的水分是哪里来的

标称算力很难直接和设备上的真实体验画等号。芯片手册里的TOPS，通常是在最优算子组合、最优数据排布、满负荷流水线下测出来的，相当于“赛车在专属赛道的单圈记录”。但实际模型里有卷积、池化、归一化、激活、矩阵乘法、内存搬运，各种算子的形状和依赖关系千变万化，MAC阵列没法每一拍都打满。

我做模拟项目X时的体验就很典型：当时一块标称6 TOPS的端侧板子，拿来做某个目标检测模型，持续吞吐量只能到2.5 TOPS上下；后来重写了数据排布，把特征图重新分块，增加了片上缓存复用，才勉强拉到4 TOPS左右。差的这40%，不是芯片本身性能打了折，而是硬件潜力没被软件层充分榨出来。

所以说，低功耗AI芯片绝不是单一硬件能搞定的事。一个真正低功耗的方案，必须在模型、编译器、运行时、驱动、算子库和硬件架构之间做好协同，哪一层拖后腿，整瓦功耗都会明显变难看。这一点，也是理解整个“明争暗斗”的关键前提。

2. 省电是一场三层协作：模型瘦身、编译优化与硬件巧劲

2.1 先从模型做减法：量化、剪枝和蒸馏不是万能的

低功耗AI的设计，第一刀通常落在模型本身。最常见的省电手段是量化，把一个32位浮点权重压缩成8位甚至4位整数。内存占用直接变为原来的四分之一甚至八分之一，片上SRAM能放下更多参数，DRAM访问大幅减少，推理功耗自然降下来。此外，整数乘加单元在芯片上比浮点单元更省面积、更省功耗，INT8在端侧已成为标配。

但量化不是免费的。一个模型里不同层对量化误差的敏感度差别巨大，比如BatchNorm之后的激活分布、Softmax和LayerNorm，直接切INT4很容易掉点。成熟做法是混合精度量化：大部分卷积层用INT8，少数敏感层退回FP16，或单独用更高比特位宽。校准数据集也很讲究，若只用普通图片做校准，一旦上线遇到暗光、大逆光、运动模糊这类边缘分布，推理精度可能突然崩。所以量化这件事，一定要在项目早期就纳进模型迭代流程，而不是等模型固定后一刀切。

剪枝和蒸馏同样常见。剪枝是把权重接近零的连接或通道去掉；如果硬件支持稀疏加速，跳过零值计算就等于直接省电。知识蒸馏则是用一个大模型做教师，训练出一个更小的学生模型，在相同精度目标下减少参数量。合理使用这些方法，能让很多原以为端侧跑不动的模型变得可行。不过要注意，模型减小并不等于推理时延一定下降，有些结构在硬件上会产生内存碎片，导致内存带宽反而增加。

2.2 编译器干了很多大家看不见的“脏活”

真正决定低功耗上限的，不只模型大小，还有算子落地方式。一个最典型的优化是算子融合：比如把卷积、BatchNorm、ReLU融合成一个算子，逐层计算完直接写回片上缓存，不再把中间结果反复落到DRAM。数据搬移是端侧推理的主要能耗来源，减少一次大张量写回，节省的可能比省几次计算还多。

内存排布同样重要。芯片常用Tiling策略，把输入特征图切成小块，逐块送入片上SRAM，让局部数据反复复用，从而减少对外部DRAM的反复读写。我见过同一个模型，在工具链里只是调整了通道排布和切块大小，推理时延精进近30%，功耗也低了20%以上。可以说，同样一块芯片，在不同编译器版本、不同开发者的优化水平下，测出来的能效差距能差出代际。

所以看低功耗AI芯片时，不能只看它算力强不强，要看软件栈是否成熟。模型转换器能不能覆盖常见算子、算子在端侧的实现是否高效、是否有性能分析工具帮助定位瓶颈，这些因素可能比峰值TOPS更能决定真实功耗。

2.3 芯片微架构的巧劲：专用阵列、电压缩放和存算一体

硬件层也一直在做各种“省电特技”。第一是专用MAC阵列，把矩阵乘加变成硬连线操作，省掉通用CPU里指令调度、分支预测等大量开销；第二是电压频率调节，因为功耗和电压的平方成正比，在保证实时性的前提下尽量压低电压和频率，能换取明显功耗节省；第三是更激进的近阈值电路设计，在接近晶体管阈值的电压下工作，能效可以大大提升，但工艺一致性、时序收敛难度也跟着陡增。

近年来讨论很多的还有存算一体技术。传统架构里，权重需要从存储单元搬到计算单元，搬动过程本身就很耗电；存算一体会把乘加计算直接放进存储阵列中完成，数据移动距离大幅缩短，能效可以提升一个量级。但代价是灵活性受限、精度控制更难，目前更多用于特定场景的专用加速器，并不适合所有通用模型。

这一层面的竞争，某种程度上比制程提升更有决定性。它说明低功耗AI芯片已经没有标准答案，不同厂商在不同计算精度、稀疏方案、片上存储配比之间做出的取舍，都会影响最终产品体验。这也是后面要讨论的“路线分歧”的根源。

3. 战场上的路线分歧：集成、专用和云边协同的三种打牌方式

3.1 大厂自研路线：把NPU嵌进主SoC

如今头部的手机和穿戴设备方案，基本都选择在主SoC里集成NPU或AI加速单元。集成路线的最大好处是共享内存和缓存体系，CPU、GPU、NPU之间能够快速协同，整体延迟最低，且功耗调度的弹性更大。手机里既要跑拍照增强，又要跑语音助手，还要跑系统级AI调度，集成NPU可以复用整套工具链，一次开发多场景受益。

但集成路线也有明显问题：为了兼容SoC整体的面积、功耗和成本预算，NPU往往不能做到极致低功耗。它的峰值算力上去了，可待机时的漏电功耗、处于不同电源域切换时的唤醒开销，都是整个系统的隐形成本。而且这类芯片更多为“手机发热可控”设计，放到只有一节纽扣电池的传感器上并不合适。所以大厂集成NPU的本质，是在通用性和性能之间做平衡。

在宣传口径上，这一路线也最容易形成“明争”：大家都说自己的端侧AI能力能跑多大模型、首token多快、电池多耐用，但这些指标很难用统一基准横向衡量。一个模型跑得动，往往意味着做了不少定制优化，不代表同生态内的其他模型都跑得动。

3.2 创业团队走垂直化：在极度受限场景里抠毫瓦

另一类选手是从垂直场景切入的芯片公司，专攻语音唤醒、极低功耗视觉检测、TWS耳机降噪、门锁人脸识别等方向。他们没有大厂那种平台包袱，可以把整个芯片设计成“只为一件事服务”。比如只做唤醒词检测的芯片，可以把麦克风、DSP、超小NPU、电源管理封装在一起，在待机状态下做到毫瓦级甚至几十微瓦级，这是通用SoC很难达到的。

这类方案的生意模式也比较多样：有卖模块的，有卖Turnkey方案芯片的，也有只授权IP给大客户的。它们的挑战在于生态太窄。通用AI框架的模型不能直接跑，需要厂商提供的模型压缩工具和算子库配合，若产品想换成非主流的模型结构，几乎等于重新定制。因此垂直方案更适合量足够大、形态足够固定的应用，比如门锁、耳机、智能传感器，而不是随时换玩法的原型机。

在“暗斗”层面，创业团队最怕的其实不是大厂的产品参数更好，而是大厂把通用芯片的功耗做下来之后，垂直芯片的“省电优势”被追上。所以很多垂直方案会不断往传感器融合、模型定制和参考设计方向延伸，从“卖芯片”变成“卖整套低功耗AI能力”。

3.3 云厂商入场：边缘AI芯片成为云体系的前沿哨所

云厂商也在积极布局边缘AI芯片，毕竟摄像头、智能网关、边缘服务器都是云端流量入口。这类芯片通常更看重视频编解码、网络接入和AI推理的结合，常见做法是本地先做目标检测和结构化，只上传关键帧或告警信息。它们会和云平台工具深度绑定，模型训练、部署、监控可以在云端统一管理，对开发者很友好。

但从开发者角度看，这类方案的锁定量也更强。一旦使用某套边缘AI工具链，算子集、设备管理、调度接口都形成习惯，未来切换到别的芯片，成本会很高。所以云厂商和独立芯片厂商的争执，表面是比芯片参数，背后实际是“谁是开发者入口”的争夺。

3.4 真正决定归属权的是工具链和生态

回看这些年行业里的合作、竞争和合作破裂，会发现硬件参数的差距往往在半年内就被拉平，真正形成护城河的是软件工具链。一个芯片能把PyTorch模型顺滑转换、能稳定复现训练精度、能提供热点定位和量化调试工具，开发者的开发周期可以缩短好几周；反之，哪怕芯片能效再高，每次模型改动都要绕过算子库里一堆不支持的算子，项目就会困在适配泥潭里。

所以评估低功耗AI芯片时，我认为应该拿“从PyTorch模型到端侧跑通”这个完整过程来衡量。转换是否自动、量化校准是否顺手、运行时观测是否方便，决定了一款芯片是活在PPT里，还是能真正落到量产产品中。这种竞争短期看起来很温和，用户体验却能感受得非常直接。

4. 实测取舍：唤醒、识别和多模态场景下的功耗台账

4.1 语音唤醒的毫瓦级账本：不能只看唤醒率

语音唤醒是低功耗AI芯片最经典的主战场。一个智能音箱整机待机功耗通常有几瓦，但其中纯AI唤醒的预算要压缩到几十毫瓦级，否则用户会相遇“没唤醒几次就没电了”。这里涉及信号链每一个环节：麦克风偏置和放大电路、音频编解码器、活动检测、特征提取，最后才是轻量神经网络识别。

实际项目中最容易忽略的是音频前端。麦克风偏置电路和ADC必须一直供电，这部分功耗往往和唤醒网络本身差不多甚至更高。有些芯片会把VAD（语音活动检测）放在一个极低功耗的DSP核上，平时只有这个核在工作，检测到疑似语音后再唤醒专用NPU，形成两级唤醒机制。这种分层调度非常有意思，相当于把“就寝/待命/全力冲刺”三种状态拆给不同硬件去执行。

我也在某个项目里吃过亏：只拿安静房间里的唤醒率做测试，指标很好，一到商场、公交和电视噪音下，误唤醒和漏唤醒双双飙升。把检测阈值调低，唤醒率上来了，误唤醒又把功耗拉高。最后只能用双阈值方案，第一级粗筛在DSP完成，第二级精判在NPU完成，功耗和体验才算稳住。

4.2 摄像头视觉识别：突发功耗和持续功耗是两码事

智能摄像头、可视门铃这类设备，往往采用“低功耗触发+突发推理”的工作模式。平时系统处于深度睡眠，只有热释电红外或雷达检测到人靠近后，主控和AI加速器被唤醒，开始跑人脸检测、人形框选等推理，完成后再次回到睡眠。对这类设备来说，真正决定续航的不是峰值算力，而是“每秒/每分钟有多少时间在跑，跑一个周期下来平均电流是多少”。

我做过一次电流曲线测量：某双电池门铃方案，在待机阶段平均电流约300微安，而一旦触发跑到满负荷，电流会瞬间拉到800毫安甚至更高。虽然单次推理只有不到两秒，但每隔几分钟触发一次，平均功耗就会被线性抬高。所以评估低功耗AI芯片时，一定要测“唤醒进栈-推理-回栈”全过程的电流波形，重点关注唤醒回栈时间、关断漏电和稳压器静态功耗，这类指标在宣传册上几乎不会写。

连续视频流应用就更有意思了。若做24小时持续识别，芯片的功耗预算通常卡在几百毫瓦到1瓦之间。开发者常常用帧率控制和ROI裁剪来交换功耗：设定“无人时降到2fps，有人时升到15fps”，把检测和跟踪的开销动态调整，这种策略对NPU的快速启动和低功耗空闲能力要求很高。

4.3 端侧大模型与多模态：瓶颈已从算力变成内存带宽

最近一年，端侧大语言模型逐渐成为新卖点。但这类应用的功耗特性，和前两类完全不同。LLM推理时每个token生成都要反复读取模型全部权重，计算量通常不是最核心的瓶颈，DRAM带宽和存储容量才是。一个参数为1.3B的模型，INT4量化后权重大约700MB，若芯片内存带宽只有20GB/s，每读取一遍权重就要35毫秒，期间功耗几乎恒定地由DRAM访问主导。

这时候，单纯堆MAC阵列效率意义不大，更要紧的是低比特量化、权重压缩、KV缓存管理和按需卸载。有些新芯片已经在架构里增加了“上下文调度”概念，暂时不用的层可以留在外部存储，只有激活的模块进入片上SRAM，等于用软件层调度换取内存带宽的释放。从实测看，这类优化能把端侧LLM的功耗从动辄七八瓦压到两三瓦，但依然很难进入耳机这类极低功耗设备。

这张表是我做几个模拟项目时沉淀下来的经验，不一定覆盖所有产品，但方向足够准。

5. 选型避坑实录：从标称TOPS到持续功耗的落差

5.1 用持续负载把真实能效逼出来

很多开发者的习惯是先看芯片手册里的TOPS和TOPS/W，再决定是否立项，这种习惯很容易踩坑。我自己的做法是，拿到开发板后先拿最接近真实业务的模型跑一轮“持续负载测试”，循环推理15到30分钟，同时记录功耗和温度。标称数据往往在25度、短时测试下测得，板子真正跑热后会降频，热节流后的性能曲线才能代表量产机状态。

测试时还需要特别注意推理框架的缓存策略。有些芯片会把同一份输入重复推理，模型权重全部留在片上缓存，导致“缓存友好”的假象，换成随机输入后性能立刻跌两三个档位。所以测试的输入数据要避免同一张图反复跑，合理做法是准备一个包含上百张样本的数据集，循环投喂。

5.2 量化工具链比硬件参数更需要验货

低功耗AI芯片普遍依赖低比特量化，因此量化工具链的成熟度，直接决定了项目的成败。评估时不要只看它支持几种模型格式，最好的办法是把一个包含多种算子的代表性模型（如带注意力机制的分割网络或检测网络）喂进去，看转换是否顺畅、精度掉多少、调试是否方便。

真实项目中经常出现这种情况：某个层在INT8下完全正常，切到INT4后直接输出一片噪声；甚至同样在INT8下，不同版本的编译器对同一算子生成的代码效率差异巨大。如果厂商提供的量化工具能支持逐层混合精度、能输出每个节点的数值范围报表、能定位到异常激活层，调试效率会提高一个量级。

还有一点，校准数据的选择不能偷懒。很多人直接拿训练集里随机选几百张图片做校准，遇到部署环境光照、老化、遮挡变化时，精度往往不稳定。更稳妥的是专门收集一批覆盖极端情况的校准数据，尽量贴近线上真实分布。

5.3 别忘了芯片生命周期和开发工具支持周期

低功耗AI芯片的选型，还要看产品生命周期和维护承诺。嵌入式产品通常要卖好几年，而芯片厂商的产品线更新很快，工具链大版本升级、算子行为变化、知识产权许可到期，都会让老产品变成“维护地狱”。签合同前至少问清楚：这款芯片是否还在持续更新编译器和运行时？目标生命周期多长？原厂还能支持几年？

我在某个项目中吃过这方面亏：原型阶段用的一款芯片在功能上完全胜任，结果正式量产前，原厂宣布产品线重组，部分工具弃用，整个软件栈要迁移到另一套体系。那次的迁移成本远超预期，也让我后来选型时把“厂商技术路线稳定性”提到了和“芯片能效”同等重要的位置。

也可以参考下面这张选型判断维度表，是我后来一直沿用的：

5.4 别让“极致低功耗”打乱产品迭代节奏

最后一条经验，低功耗芯片不是越省越好，而是在“满足功能、算力余量、功耗预算和开发成本”之间找到平衡点。自主做极致省电的专用ASIC，能效最优，但一动功能就要改版，周期长、风险高；买通用芯片，开发灵活，但待机功耗和成本都难降下来。小批量、快速迭代的产品，更值得先选通用NPU方案，用软件层优化换取低功耗；只有到了产品形态稳定、出货量足够大的阶段，再谈定制芯片或专用Turnkey方案。

我倾向于把低功耗AI芯片选型看作“项目风险决策”，不是单纯的技术指标对比。芯片背后的工具链稳定性、参考设计完整性、原厂支持响应速度，往往比纸面多出的2 TOPS/W更能影响项目能否准时量产。

最后再分享一点个人体会：我在实际做端侧项目时，已经把工作习惯从“先看芯片参数”改成了“先把模型放进开发板跑三天”。低功耗不是一个绝对值，而是和你的模型结构、运行工况、环境温度紧紧耦合在一起的系统指标。评测时多看一眼持续功耗曲线，多测一轮噪声环境，多跑一次量化前后对比，比盯着发布会上那个刷新了纪录的TOPS/W数字更重要。低功耗AI芯片的明争暗斗还会持续很多年，但最终能留在牌桌上的，一定是那些能帮开发者把“每瓦有效任务完成量”真正做上去的选手。