先说一个我自己踩过的坑前年做一个工业视觉检测方案产品经理拍板用的是“普通摄像头边缘盒子”的老套路。等一测功耗整套系统最高到12W客户要求压到5W以内怎么都下不来。后面仔细分析才发现真正吃掉功耗的既不是CPU也不是NPU而是图像数据从传感器搬到DDR、再从DDR搬进算子的这一路。一趟1080P60fps的原始图像每秒数据量就超过100MB这个搬运成本比计算本身高出不止一个数量级。那段时间我一直在看传感器端计算in-sensor computing的资料越看越觉得这条路径才是解决“边缘功耗墙”的真正钥匙而不是继续堆算力。这篇文章我打算把传感器端计算这件事拆开讲清楚它到底解决什么问题、主流的技术路径有哪些、像素级计算和近感计算的核心原理怎么理解、工程化落地时最容易踩的坑是什么以及怎么判断一个场景到底适不适合上传感器端计算。不管你是做低功耗IoT设备的还是做视觉检测、穿戴式医疗的这篇文章都值得花十分钟看完。1. 数据搬运的惊人成本感算一体到底在解决什么1.1 算力不是瓶颈带宽才是很多人一谈到边缘AI第一反应就是“算力不够”。但如果你把功耗账本摊开看会发现一个不太符合直觉的结论在大多数视觉边缘场景里幻觉中的“算力不够”根本不存在真正压垮系统的是数据搬运的带宽和能耗。我给你算一笔简单的账。以一颗1600万像素的传感器为例RAW格式12bit输出一帧就是1600万×12bit 192Mbit ≈ 24MB如果跑30fps每秒大概产生720MB数据。这些数据要从像素阵列读出经过MIPI或LVDS接口传到SoC先写进DDR再从DDR读出来送进NPU做卷积。这一趟下来每个bit平均要花几十皮焦的能量算下来光是搬运功耗就是好几瓦。与之对应的是一个MAC运算乘加运算在先进工艺下能耗大概只有零点几到几个皮焦。换句话说搬一个数据所花的能量足够做几十次甚至上百次计算了。这就是业界经常引用的“数据搬运能耗远大于计算能耗”的真正含义。只要你还坚持“传感器只管采、处理器只管算”的传统架构那这套架构的物理极限就在传输链路上CPU再快、NPU再强都救不了功耗。1.2 传感器端计算把“算”往数据源头推传感器端计算的思路完全反过来既然搬运数据那么贵那就干脆别搬了直接在传感器这层把数据“消化”掉一部分只输出真正有用的结果——比如一个缺陷坐标、一个人脸框、一个动作标签、一对异常波形脉冲。数据从720MB/s变成了几百字节每秒后面所有环节的带宽、存储、功耗压力全都缓解了。这个思路最典型的一个代表是事件相机event camera。事件相机不算传统意义上的感算一体芯片但它做的就是“传感器端判断”每个像素自己判断亮度变化是否超过阈值只有变化足够大的时候才输出一个事件静态画面完全不输出。这样拍出来的数据天然就是稀疏的后续算法不需要对整帧图像做处理只需要处理稀疏事件流。我用过一款事件相机做高速旋转机械的振动监测原本要300fps的帧率才能捕捉到的异常事件流只要几毫秒就能触发一个“变化量超限”信号数据量大概只有传统方案的百分之一。真正的传感器端计算in-sensor computing走得更远它不只是“判断要不要输出”而是直接在像素阵列内部完成卷积、池化、特征提取等计算直接输出高层语义特征。所以你理解的传感器端计算本质上是把“感知”和“计算”这两个原本分离的环节融合在一起从物理层面绕开数据搬运这座大山。2. 感内、近感、事件驱动传感器端计算的三条主流技术路线传感器端计算的叫法很多容易混。按计算发生的位置和数据流形态我习惯把它分成三条路线感内计算in-sensor computing、近感计算near-sensor computing和事件驱动感知event-driven sensing。这三条路线不是同一件事但它们经常被放在一起讨论选型的时候要特别注意区分。2.1 感内计算in-sensor computing在像素里做算术感内计算指的是计算直接发生在像素阵列内部通常是在模拟域完成。像素不再是单纯的“光电转换器”而是变成了一个能执行乘加运算的模拟计算单元。比如把卷积核的权重映射到多个光电二极管上让光电流直接做加权求和最后读出来的就不是“像素灰度值”而是“卷积特征图”。这条路线的核心优点是极致的能效比。因为是模拟域处理不用做AD转换、不用从阵列读出大数据量计算能耗可以压缩到极低。我在一份研究数据里看到模拟域像素级卷积的能效可以达到TOps/W量级比传统数字处理器高出两个数量级。但代价也很明显精度受限、灵活性差、对工艺偏差非常敏感。模拟计算的误差来源太多了后面第四章我会详细讲。2.2 近感计算near-sensor computing传感器旁边放个专用核近感计算是把一个数字处理核和传感器封装在一起或者直接集成在同一个芯片上缩短数据搬运的物理距离。计算还是数字域精度和灵活性都保留得很好但节约的主要是“片间传输”的能量片内像素到处理核的模拟数据仍然要读出和转换。典型的商业案例是索尼IMX500它把DSP和SRAM集成在CMOS图像传感器芯片上可以在传感器内部跑一个轻量CNN输出对象检测、语义分割的结果。IMX500输出的不是处理后的特征图而是“检测到了什么、在哪个位置”也就是说它已经把“结果”给了后端后端不需要再做大计算量推理。这类方案非常适合安防摄像头、智能门锁这些对实时性和功耗都有要求的场景。2.3 事件驱动感知event-driven sensing从源头只输出“变化”事件相机是这条路线最出名的代表。它不是“算”出来的而是从物理层面改变了数据产生的方式没有变化就不产生数据有变化才输出微秒级的稀疏事件流。它的数据完全是异步的时间分辨率极高动态范围极好在高速运动、高对比度场景下比传统帧相机优势大得多。拿它和感内计算比较事件相机更像是“前端数据触发的传感器”感内计算则是“在传感器内部做完整计算”。事件相机适合做运动信息提取、高速追踪、视觉SLAM感内计算适合做静态目标的特征提取、识别分类。两者可以搭配使用。2.4 三条路线的关键参数对比路线计算位置数据输出能效比灵活性代表方案/产品感内计算像素阵列内模拟域特征图/判断结果极高TOps/W量级低算子固定或受限学术原型、产业预研芯片近感计算传感器同封装/同芯片数字域语义结果/特征高中高可跑轻量CNN索尼IMX500等事件驱动像素级变化检测稀疏异步事件流高数据量大减中需专用算法动态视觉传感器选型的第一步是先搞清楚自己说的“传感器端计算”到底是哪一条路线因为它们对算法、硬件、工具链的要求差别非常大。如果只是想在功耗上“省一点”近感计算的成熟度最高如果想在极致功耗和极致数据压缩上做文章才需要考虑感内计算或事件驱动方案。3. 把卷积“写进”像素感内计算的关键原理拆解3.1 光电流加权求和矩阵运算的模拟实现感内计算最核心的一个操作其实是把卷积运算映射到像素阵列的物理过程上。传统CMOS图像传感器的像素只做一件事把光照强度转成电压或电流。而感算一体的像素会在像素内部或像素之间构建加权网络。怎么理解呢想象一个小的卷积核是3×3的九个权重你把这九个权重分别映射到九条光电流通道上每个通道的电流会按照权重被放大或衰减然后再汇到一条线上相加。这个“加权相加”的过程在物理上就是一个最原始的乘加运算。关键是这个过程中没有任何数字电路参与也不需要把像素值一个个读出来再做乘加。光照射到像素上光电流本身就在源源不断地产生加权求和的过程是实时的、并行的、几乎零额外能耗的。这就是为什么模拟域感内计算能效比高到夸张的原因。3.2 电荷域和时间域计算比电压域更稳定的路径不过电压域的加权求和有一个老问题像素输出电压摆幅小动态范围有限容易受噪声干扰。所以很多新的感内计算研究倾向于做电荷域计算或时间域计算。电荷域计算的做法是把像素的光电二极管在曝光期间收集到的电荷通过控制浮置扩散节点的开关时序按权重分配到不同的存储电容里。因为电荷的累加是物理过程不需要额外的运算电路精度和鲁棒性都比电压域好一些。时间域计算更巧妙它把“模拟量”转化成了“时间量”。比如让一个像素的输出信号去控制一个比较器翻转的时间点光照越强翻转越快而“翻转的时间”用数字计数器来记录。这样把计算变成对时间戳的加减操作规避了模拟电压精度差的问题又保留了低功耗的优势。我自己看这一块的时候有个体会模拟域计算的演进方向本质上是在“精度”和“能耗”之间寻找一个工程上可行的平衡点电荷域和时间域是绕开模拟精度瓶颈的两个关键手段。3.3 忆阻器和RRAM交叉阵列把权重存储进传感器感内计算的另一个大方向是引入非易失存储器件比如RRAM或PCM把神经网络的权重直接“烧”在传感器芯片上。RRAM阵列本身就具备两个特性一是能存储权重不同阻态代表不同权重二是能通过基尔霍夫定律做矩阵向量乘电流自然相加。把它和光电探测阵列叠在一起就实现了一颗芯片上同时完成“感知→存储→计算”的完整链路。用生活化的类比传统架构里传感器是“眼睛”存储器是“记事本”处理器是“算盘”三者各干各的数据每次都要在三个器官之间来回倒。感算一体用RRAM做的方案相当于把“记事本”和“算盘”直接装在了“眼睛”里看到什么、查到什么、算到什么全都原地完成只有最终的结论才传达给你。这个方向非常有前景但目前大部分还停留在实验室阶段离量产有距离。看论文和宣传资料的时候需要特别注意区分“研究了什么”和“量产了什么”。3.4 一个具体例子像素内做卷积到底怎么做我给你一个更具体的操作级理解。假设你想在传感器端对图像做一个3×3的卷积核那么曝光期间像素阵列的某个邻域内就会有九个光电二极管同时感光。如果你希望在读出时直接得到卷积结果最直接的做法是把这九个像素的光电流按照卷积核的权重分别接到不同增益的放大器上再把放大器输出汇总到一根总线上。更聪明一点的做法是分时复用分三次曝光第一次用正权重曝光积分第二次用负权重曝光积分第三次做归一化。最后读出的电压差就是卷积输出。这个过程不需要AD转换也不需要把九个数一一读到外面天然就是并行的每颗像素都在为最终的卷积结果贡献自己的一份力量。但这也会带来一个问题像素面积大了不少填充因子下降感光效率降低。所以感内计算芯片的分辨率往往做不高目前公开的研究多数是几百到一千分之一分辨率级别比如64×64、128×128很少看到VGA以上的。这个限制决定了它更适合“任务简单、数据越少越好”的场景而不是高清拍照。4. 精度、温度、一致性感算一体方案工程化的三座大山实话说感算一体在论文里很美好但到量产落地阶段有三座山真不好翻。我看了不少项目也参与过外部的方案评估发现问题往往不出在“能不能算”而出在“算得稳不稳定”。这三座山是模拟计算的精度、温度漂移、以及量产一致性。4.1 模拟域计算的精度天花板模拟域计算的精度天然受限于信号链路上的噪声源。像素的暗电流噪声——光照为零的时候像素本身也会因为热激发产生暗电流。这个暗电流大小、温度升高时呈指数增加直接叠加到光电流上。加权求和时暗电流也被加权了如果权重很大暗电流的波动就会被放大最终在卷积结果里形成明显的噪声。还有工艺偏差同一颗芯片上不同像素的晶体管阈值电压、电容值、增益都可能有百分之几到百分之十几的偏差。数字电路里这些偏差可以靠设计修正模拟域里这些偏差直接变成了计算误差。要让模拟域卷积精度达到8bit也就是相当于256个灰度等级的分辨率这在实际芯片里已经非常吃力。很多研究论文其实按4bit以下的“有效精度”在跑。所以你在评估一个感算一体芯片时不要看它宣传“神经网络精度达到95%”那是可能加了很多纠偏、重训练的计算出来的结果要问清楚的是在典型工况、不调参的情况下实际任务的精度掉了多少。4.2 温度漂移室外场景最大的拦路虎第二个坑是温度。感算一体把计算和感知做在一起传感器本身就会发热而环境温度的变化更是逃不掉。传统数字芯片对温度相对不敏感但模拟域计算不一样MOS管的阈值电压、迁移率都会随温度漂移电容的漏电流、暗电流更是温度敏感参数。实测下来同一个感算芯片在25度和65度环境下卷积输出幅值可能差20%以上。这对室外安防、工业现场这些宽温域场景几乎是致命的。所以如果评估一个感算方案用在户外高温和低温环境下的精度衰减数据一定要拿到还要问清楚有没有片上温度补偿电路。我见过好几份方案书能在室温下演示得很完美但一到夏天设备外壳温度上到60度检测率就明显下滑。4.3 量产一致性与校准成本第三座山是量产一致性。模拟电路的工艺偏差决定了每一颗芯片的响应曲线都略有不同。数字芯片出厂时可以统一烧录同一个固件但模拟感算芯片出厂时可能需要逐颗校准——给标准光照、测标准输出、烧录校准系数。一颗两颗没问题但到了百万片级别的量产逐颗校准的时间和成本都是绕不开的问题。换句话说传感器端计算目前更适合“工艺成熟、出货量可控”的场景比如医疗耗材、工业探头这类单价值高、产量不是最大的行业。如果是消费电子那种百万套起订、对成本极其敏感的行业校准摊销成本可能会劝退很多人。4.4 算法侧的补偿手段好消息是并不全是硬件的活儿算法侧可以做一部分补偿。比较常见的做法是重训练把硬件引入的非理想因素噪声、漂移、失配建模成一个可微的“硬件效应层”插在网络结构里用真实硬件的噪声分布去训练网络。这样训练出来的模型在面对硬件真实工况时鲁棒性会好很多。我见过有人把图像传感器的噪声模型和量化噪声一起引入训练最后在低照度下的检测精度提升了十几个百分点。所以工程化的思路不是“等硬件完美了再上应用”而是“硬件算法协同设计”硬件负责把能耗和延迟降下来算法负责在容忍硬件非理想的前提下把精度拉回可接受范围。5. 评估一份感算一体方案我先看这五个维度这些年我陆续接触过一些传感器端计算的方案评估有芯片公司的参考设计也有外包团队的项目提案还看过好几个研究原型。被各种漂亮参数“骗过”几次之后我总结了一套自己的评估框架。如果你也要评估感算一体方案我建议按这五个维度逐项过一遍。5.1 功耗口径标的到底是裸片还是全系统第一件事就是把功耗口径对齐。有的方案PPT上写“超低功耗0.1mW”结果一问这只是像素阵列的功耗没有包括AD转换、参考电压生成、时钟、IO驱动这些外围电路。全系统一算可能跳到几毫瓦甚至几十毫瓦完全不是一个量级。所以看到功耗数字第一反应应该问一句这功耗包括哪些模块是常开的功耗还是休眠唤醒的平均功耗5.2 有效精度实际任务的指标而不是模型精度第二看有效精度。方案方可能会给你一个很高的模型精度指标比如“MNIST识别99.2%”“VOC检测mAP 80%”但这个精度是在标准数据集上用理想的软件模型跑出来的而不是在真实硬件上测出来的。你要追问的是在你们这芯片上实际跑一个业务场景的数据集准确率、召回率是多少跟你们芯片输出精度相比软件模型的精度掉几个点如果调了模型结构来适配硬件那新模型跟原始模型比又掉了多少我有个很简单的判断方法拉着方案方一起拿你们自己的真实数据在对方的开发板上跑一个最小验证集几十张图哪怕只有一百张就行看看输出的结果和标注的差距有多大。这比看十页PPT都管用。5.3 数据流匹配度你的算法能否映射到它的算子第三看数据流匹配度。不同感算芯片支持的算子集差异极大有的只能跑固定3×3卷积核有的只能做边缘检测模板有的支持可编程的tiny CNN。你要看看自己的业务算法是不是能拆成对方算子集的组合。如果业务算法里需要一个5×5空洞卷积、一个softmax、一个NMS非极大值抑制而这些算子芯片上都没有那这个“感算一体”对你来说就是无效的只能当普通低功耗传感器用。我建议把这部分做成一张算子映射表一条一条核。5.4 工具链成熟度没有SDK和编译器的硬件都是半成品第四看工具链。传感器端计算芯片不像GPU那样有非常成熟的CUDA生态很多还停留在“给一堆寄存器手册”的状态。如果没有一个能用的SDK、编译器或者至少是Python前端工具你把算法模型做到芯片上会非常痛苦。我面试过一堆标称“AI芯片”的团队最后发现连神经网络模型转换工具都要自己写这种产品化程度基本不值得投入。一个衡量标准上手时间。拿到开发板后你团队最快几天能跑通第一个demo如果超过两周还没有进展说明工具链成熟度太低后续产品化的风险会很高。5.5 成本与供应链NRE、良率、量级一个都不能少最后看成本账。定制感算芯片的前期NRE非回收工程投入非常高流一次片从几十万美元到上百万美元不等这还不包括封装、测试、校准的后续成本。如果方案方不是推现成的标准产品而是需要你定制那要好好算一笔账预估出货量是多少如果出货量只有几千片平摊下来每颗芯片的NRE成本可能比芯片本身贵几十倍那这个方案在商业上就不成立。5.6 一张快速评估打分表评估维度问什么问题理想答案功耗口径整系统功耗还是裸片功耗全系统、带动态场景数值有效精度真实业务数据下掉多少点给出实测值允许复现数据流匹配我的算子能否映射到芯片映射表完整、缺失少工具链上手跑通demo要多久三天以内成本芯片单价/NRE/校准成本与出货量匹配且合理6. 实战选型哪些场景值得用传感器端计算哪些是伪需求看完了原理和评估维度最后一个很现实的问题是我做的场景到底要不要上传感器端计算这东西不是万能的很多场景上了反而是给自己找麻烦。我结合自己的项目经验给几个判断框架和正反例子。6.1 值得上的场景高数据率、低特征维度、低功耗预算判断一个场景适不适合传感器端计算三个条件最好同时满足原始数据量很大但最终要提取的信息维度很少、系统功耗预算极低容不下一个主控一直全速跑、任务模式相对稳定不需要频繁迭代算法。典型的正向例子是工业质检的缺陷检测分选。产品在产线上高速流过需要以极快的速度判断“这个工件正不正常”。传统方案是高速相机拍完把图像传到工控机工控机跑检测算法整条链路延迟大、功耗高、设备贵。如果传感器端能做缺陷预判只把疑似缺陷的局部区域或一个异常标签传到后端产线速度可以大幅提升后端设备的算力要求也会降低很多。另一个正向例子是穿戴式心电图/脑电监测。原始波形数据连续产生一天下来就是GB级的数据量但医生真正关心的只是少数几个异常事件。在传感器端做信号质量评估和异常检测只把异常段压包上传云端压力、功耗、流量都降下来了。这已经是成熟产品里会用到近感计算的典型场景。智能门锁和安防摄像头的低功耗唤醒场景也适合平时传感器端只检测“有没有人/有没有移动”一旦确认有人出现再把摄像头调到全分辨率模式或者上传告警。这样待机功耗可以压到微安级别电池续航从几天拉到几个月体验差距巨大。6.2 不适合上的场景大模型、高精度多类感知、快速迭代反过来有几类场景我建议慎上。第一类是需要跑大模型的场景。传感器端计算芯片的算力和存储容量都极其有限基本跑不了几十MB的模型。如果你要做的是通用物体检测、上百种分类、语义理解那还是老老实实用边缘盒子或云端方案。硬把模型塞进传感器端芯片最后只能牺牲精度效果远不如在处理器上跑一个剪枝后的模型。第二类是环境极端、需要极高可靠性的场景。我之前提到温度漂移问题如果在高温、低温、剧烈振动、强电磁干扰的环境下运行模拟域计算的稳定性很难保证。军工、航天这种对可靠性极为苛刻的场景现阶段宁可多耗点电也要保证计算的确定性不要用过渡方案去堵枪眼。第三类是算法迭代非常快的场景。今天做行人检测明天要加异常行为识别后天又要换模型结构。如果每次都靠重新流片或重新烧录权重来适配硬件改版周期会拖慢产品迭代速度。这种情况更适合用近感计算里可编程程度较高的方案或者干脆把推理任务放到后端。6.3 我自己的选型决策清单到现在为止我评估一个项目要不要上传感器端计算会按顺序问五个问题当前系统的瓶颈真的是带宽或功耗吗如果不是根本不需要走到感算这一步。业务模型在“极简网络”下能做到可接受的精度吗先用软件仿真把一个很小的CNN剪到几百KB以内测一下精度如果低于业务线就不推。使用场景的温度和光线环境可控吗如果户外大温差、强光直射先把方案方的温漂数据要过来看。有没有靠谱的工具链支持没有工具链的硬件只能当实验室玩具。这个项目的生命周期有多长如果一年后大概率要换技术路线那传感器端计算的定制投入不一定回本。6.4 一个实际案例把“高速瓶盖缺陷检测”从12W压到3.5W最后分享一个我真实参与过的项目。产线上做瓶盖外观缺陷检测每分钟检测600个瓶盖原来用的方案是30fps工业相机工控机整机功耗12W左右产线上一条线要放三套对车间散热和电费压力都很大。后来我和一个小团队合作把算法换成了一个极轻量的CNN——输入灰度图分辨率压到64×64三个卷积层加一个池化加两个全连接模型大小只有40KB。配合近感计算芯片在传感器端完成推理只输出“有缺陷/无缺陷”和缺陷类别后端只接一个单片机做分选控制。实测结果是整机功耗降到了3.5W检测速率提升了大概20%因为省掉了图像传输和预处理的时间。这个项目让我实打实体会到传感器端计算不是在理论上“节能”而是在产品形态上能带来质的改变。前提是你要把原有的算法模型做一次彻底的“瘦身”并且接受它在精度上比大模型低几个点的代价。我现在的态度是传感器端计算不是用来替代通用AI平台的它是一个非常锋利的手术刀专门切“高数据率、低特征维度、超低功耗”这一类场景。用对了能帮你在产品功耗和实时性上建立别人追不上的优势。用错了你会被它的灵活性差、工具链不成熟和校准成本拖进泥潭。把适用边界摸清楚比追着新概念跑更重要。