1. 项目概述为什么家电非得自己“长脑子”做家电的端侧 AI这两年其实到了一个很有意思的节点。前几年大家提智能家居第一个想到的是“连上 Wi-Fi、手机 App 能控制、云端能联动”整套架构是以“联网”为核心的。但真正把设备铺到用户家里之后你会发现很多场景下用户根本不关心你的设备是不是接了云他们只关心三件事响应快不快、好不好用、有没有隐私泄露的风险。我参与的这个项目标题很直白Bringing Cost-Effective, On-Device AI to Home Appliances翻译过来就是“把高性价比的端侧 AI 带到家电产品中”。核心目标不是做一台概念性的智能冰箱而是实打实地在中低端家电主控板上跑起语音唤醒、行为识别、异常检测这些 AI 能力让设备在不依赖云端的条件下自己就能完成大部分智能决策。为什么强调“端侧”而不是“云端”用个最直白的类比云端 AI 像是你打电话求助远方的专家专家再厉害电话线断了你也只能干瞪眼。端侧 AI 则是在家门口蹲一个保安虽然水平不一定顶尖但随叫随到、反应迅速、而且你家里的事他门儿清不会到处去说。对于家电这种对延迟、稳定性、隐私都极其敏感的场景端侧的优势是压倒性的。这篇博文我会把整个项目从方案选型、模型压缩、硬件适配到系统集成的完整链路拆开来讲适合正在做 IoT 智能硬件、嵌入式 AI 落地或者对“如何在资源受限设备上跑机器学习模型”感兴趣的开发者。里面涉及的所有参数、选型思路、踩坑记录都是我实际跑过验证过的不是从文档里抄来的概念。2. 整体设计与思路拆解别急着上大模型先想清楚场景2.1 家电 AI 的核心矛盾资源限制与体验要求的博弈做家电端侧 AI 的第一课就是认清现实。家里那台用了五年的洗衣机主控芯片可能还是一颗主频几百兆赫兹的 MCU内存以 KB 为单位Flash 存储按 MB 算。就算用户愿意多花两百块升级硬件整机的 BOM 成本压力也会让产品经理皱眉头。所以项目启动的第一件事不是选模型而是做减法哪些 AI 能力是用户真正需要的哪些是伪需求以我们做的这款产品为例为避免商业信息具体品类模糊处理但大体是厨房电器真正有用户价值的场景就三个语音控制比如“定时十五分钟”“调到小火”、异常状态识别比如干烧、溢锅、门没关严、能效模式自动切换。这三个场景有一个共同点它们都需要设备对本地环境做出即时反应而且都不能接受“等一下我帮你问一下云端”这种体验延迟。语音指令等三秒再执行用户早就上手去按键了干烧等云端识别再报警黄花菜都凉了。2.2 方案选型从“能用”到“够用”的三个硬性指标选型阶段我给整个方案定下了三个硬性指标这三点一直到量产都没有动摇过。第一是响应延迟。从用户发出指令到设备执行动作端到端延迟必须控制在 500 毫秒以内。这是人体能感知到的“即时响应”临界值超过这个时长用户就会觉得“卡”。拆解下来音频采集约 20ms唤醒词检测约 100ms指令识别约 150ms控制指令下发约 50ms还要留出系统调度的余量每段都得精打细算。第二是离线可用。设备在断网状态下所有 AI 能力必须照常工作。这不仅是体验问题更是可靠性问题——想象一下用户家里 Wi-Fi 不稳定冰箱突然不会调节温度了他大概率不会觉得是网络问题只会觉得“这智能产品真垃圾”。第三是误触率与漏报率的平衡。以语音唤醒为例唤醒词识别率要做到 95% 以上同时误唤醒率要低于每 24 小时 1 次。这个指标看着简单实际调起来非常痛苦后面我会专门讲这个坑。2.3 架构设计的三个模块感知、推理、决策整体架构上我们把系统拆成三个模块感知模块麦克风阵列、温湿度/接近等传感器、推理模块端侧 AI 推理引擎 轻量模型、决策模块基于推理结果触发设备控制逻辑。三个模块之间用消息队列解耦这样即使推理模块偶发故障基础的控制功能仍然可用——这一点很重要家电产品绝不能因为 AI 功能崩溃就变成一块砖。这里多说一句为什么不用现成的“AI 语音芯片”。市面上确实有集成了语音识别能力的专用芯片开发简单但问题在于可定制性太差你只能用它预设好的唤醒词、指令集和交互逻辑想做场景联动或定制行为识别非常困难。我们项目的目标是探索“通用的端侧 AI 能力底座”所以选择了“通用主控 NPU 加速单元”的路线把模型的灵活性和硬件的效率都握在自己手里。3. 硬件平台选型与搭建把每一分算力都花在刀刃上3.1 主控芯片的选择MCU、Linux SoC 还是带 NPU 的 SoC很多第一次做端侧 AI 的开发者会陷入一个误区觉得算力越强越好恨不得直接在设备里塞一块 GPU。但家电产品的算力选择本质是“够用就行”的工程问题不是“跑分越高越好”的性能竞赛。我们对比过三条技术路线第一类是纯 MCU 方案比如 STM32、ESP32 这类。优点是成本极低几块钱到十几块钱、功耗低、启动快但痛点也很明显内存和 Flash 太小跑不了像样的神经网络。虽然像 TensorFlow Lite Micro 这类框架能在 MCU 上跑一些极小模型但功能十分受限做关键词唤醒勉强可以做复杂一点的意图理解就非常吃力。第二类是入门级 Linux SoC比如全志、晶晨的某些型号。能跑 Linux意味着可以用完整的 TensorFlow Lite、ONNX Runtime 等推理框架模型生态一下子打开了。但这类芯片普遍没有专用的 NPU神经网络加速单元纯靠 CPU 跑推理遇到稍大的模型就会出现明显卡顿而且功耗和发热也会让家电厂商皱眉头。第三类就是我们现在采用的带 NPU 的中端 SoC。以瑞芯微 RK3588 为代表CPU 算力够用NPU 提供 6 TOPS 左右的整数运算能力跑我们选型的轻量模型绰绰有余。最关键的是这类芯片的典型功耗可以控制在 5W 以内被动散热就能搞定不需要加风扇对家电的噪音、可靠性都是很大的优势。最终选择在 RK3588 平台上做原型验证是因为它的 NPU 工具链相对成熟支持的模型算子也比较全遇到问题的时容易找到解决方案。3.2 音频传感模组关键的信号链别在这里省钱做语音相关功能麦克风阵列是绕不开的。我们早期原型机用过单麦克风方案结果唤醒率在厨房噪音环境下直线下降到 60% 左右完全不可用。后来换了双麦克风线性阵列 波束成形算法在同样的噪音环境下唤醒率回到了 95% 以上。这里要补一个核心知识麦克风阵列的波束成形Beamforming本质上是一个信号处理技术通过多个麦克风的相位差对特定方向的声音进行增强对其他方向的噪音进行抑制。在厨房这种有排风扇、抽油烟机、水流声的复杂环境中没有波束成形语音识别的准确率基本无法保证。但从单麦升级到双麦BOM 成本增加的绝对值并不多收益却是指数级的这钱花得非常值。具体的音频信号链是双麦克风采集 → 前端信号处理去混响、降噪、波束成形→ 唤醒词检测持续监听→ 指令识别唤醒后单次触发。整个链路用了一块独立的音频 DSP 芯片来做前端处理主控 NPU 只在唤醒后介入指令识别这样既保证了持续监听的功耗不会太高又能保证识别准确率。整套系统的待机监听功耗可以控制在 0.8W 以内对家电设备来说完全是可接受的。3.3 硬件调试中的三个小问题电源纹波、地环路与喇叭干扰硬件原型的调试过程永远比想象中曲折说三个很有代表性的问题。第一个是电源纹波导致唤醒率下降。我们的第一版原型机唤醒率在实验室测试时是正常的但装进产品外壳后突然下降。排查了整整两天最后发现是电源模组在满负载时的纹波过大峰值超过 80mV干扰了音频编解码器的参考电压。解决办法是给音频供电增加一级 LC 滤波并在 ADC 的 VREF 脚上加了一个 10uF 的钽电容。纹波降到了 20mV 以下唤醒率恢复正常。这个案例告诉我们数字电路和模拟电路共用一个电源平面时一定要在布局阶段就做隔离。第二个是地环路导致的交流声。麦克风阵列和主控板之间用排线连接在实验室用 USB 供电时一切正常但接上产品原来的开关电源后音频里出现了明显的 50Hz/100Hz 交流声。这是因为开关电源的初级地和次级地之间通过 Y 电容耦合了共模干扰在接地环路中形成了回路电流。解决方法是重新规划了单点接地将音频信号的参考地单独引到电源地切断了环路。这个问题在开发阶段不容易暴露往往要到整机组装阶段才会出现建议大家在做第一版 PCB 时就把接地规划想清楚。第三个是喇叭干扰麦克风。厨房电器通常有蜂鸣器或语音播报喇叭而喇叭启动瞬间的电流冲击会通过空间辐射耦合到麦克风信号线上造成误唤醒。我们后面在扬声器驱动输出端加了软启动电路同时把麦克风引线改成了屏蔽线并且尽量远离喇叭走线问题就消失了。这类问题很难通过软件完全消除必须在结构设计阶段就考虑电磁兼容。4. 模型选型、压缩与蒸馏从“大而全”到“小而精”的实战之路4.1 模型选型三个场景三种思路针对前文确定的三个核心场景我们分别选了三类不同的模型方案思路差异很大放在一起看比较有意思。语音指令识别选用的是基于卷积网络的轻量级语音意图模型。这里没有上 Transformer 结构原因很粗暴在同样精度下Transformer 的模型参数量和计算量比 CNN 高出数倍在端侧 NPU 上跑一次推理的时间会超过 100ms挤压其他环节的延时预算。我们参考了 Google 的 Speech Commands 数据集的分类思路把指令集收敛到 15 个固定指令如“启动”“停止”“定时十五分钟”“加大火力”等用一个 5 层卷积 全连接的小网络参数量约 380K38 万在 RK3588 NPU 上 INT8 推理耗时约 12ms精度达到 97.2%。异常状态识别用的是基于时序信号的轻量级异常检测模型。以干烧检测为例本质上是识别温度传感器和功率传感器的时间序列特征。我们选用了一个带有注意力机制的小型时序模型输入长度为 50 个时间步每步 4 个特征同时用传统阈值法做并联冗余。这里要说明一下AI 模型做异常检测最怕的是“没见过的场景”产生误判而传统算法对已知场景的判断非常稳定。我们让两者做投票只有两种算法都判定为“异常”系统才触发报警。这个设计把误报率从纯 AI 方案的千分之三降到了万分之三以下极大地减少了对用户的打扰。能效模式自动切换则完全是基于规则的“伪 AI”——我们采集了历史运行数据用聚类算法离线分析出用户的使用习惯然后在端侧部署一套简单的决策树模型来做档位切换。为什么不用在线学习因为家电设备的使用场景相对规律离线训练的模型完全够用没有必要引入在线学习的复杂性和不确定性。做端侧 AI 的一点心得是不是所有问题都需要深度学习传统机器学习甚至决策规则只要能解决问题就是好方案。4.2 模型压缩实战量化、剪枝与知识蒸馏的组合拳选好模型后最核心的工作就是压缩这一步直接决定了模型能不能跑进目标硬件。我们的目标是把模型压缩到原来的 1/4 以下同时精度损失不超过 1.5 个百分点。整个流程分三步走。第一步是训练后量化PTQ最简单也最立竿见影。把 FP32 模型转成 INT8 模型体积直接减少 75%。在 RK3588 的 NPU 上支持 INT8/INT16 混合精度推理。我们先用 NPU 配套的量化工具做了一版 PTQ精度从 97.2% 降到了 94.8%损失了 2.4 个百分点超出了预算。分析误差来源后发现主要是部分激活值分布范围过大量化分辨率不够。于是第二步上场量化感知训练QAT。在训练过程中就模拟量化误差让模型参数主动去适应低精度表达。这一步做完INT8 模型的精度回到了 96.5%损失收窄到了 0.7 个百分比。代价是训练时间多了大概 30%但这对一次性成本来说完全可以接受。第三步是微结构化剪枝。我们把影响精度的那些通道Channel剪掉 20% 的冗余参数再用 QAT 训练恢复精度最终参数量从 380K 降到了约 290KINT8 体积只有约 300KB推理速度反而更快了因为计算量减少精度还能维持在 96.1%——已经非常接近原始 FP32 模型了。这里有个重要的经验剪枝和量化一定要交替进行不要一次性剪枝到位再量化。我们试过先剪枝 40%、再量化结果精度崩到 89%根本救不回来。正确做法是“剪一小步 → 量化训练恢复 → 再剪一小步 → 再恢复”每次剪枝幅度控制在 5%~10%这样精度曲线会非常平滑。4.3 模型部署中的算子兼容性文档里不会写清楚的坑模型在 PC 上跑得好好的一部署到设备上就报错这是所有端侧 AI 开发者的噩梦。我们遇到的第一个问题就是算子不支持。在 PyTorch 里顺手用的某些操作比如动态形状Dynamic Shape、某些高级索引操作在 RKNN 工具链里根本不被支持。排查方法也很暴力写一个脚本把模型的所有算子遍历一遍逐一映射到工具链支持的算子清单上不支持的算子就要么重写要么换实现方式。第二个问题是激活函数的精度差异。同一个 Mish 激活函数在 CPU 上用的是高精度浮点近似在 NPU 上可能用查找表LUT的方式实现两边计算出来的结果会有细微差异。这个差异在多层的累积下会导致模型的输出分布略有偏移。所以建议在量化校准的时候一定要用真机上的 NPU 推理输出作为参考而不是用 PC 上的模拟结果。我们当时就吃过这个亏——用 PC 闪寸模拟校准出来的量化参数在真机上精度掉了 1.8%改用真机推理校准后恢复正常。5. 系统集成与稳定性保障把 AI 能力“焊接”进产品里5.1 推理引擎选型为什么要自研轻量级推理框架模型压缩完成后下一步就是把它跑起来。目前成熟的端侧推理框架有好几个选择比如 TensorFlow Lite、ONNX Runtime、ncnn、MNN 等但在我们场景下都略有不爽TensorFlow Lite 在 MCU 类场景支持好但在 RK3588 这类 Linux SoC 上对 NPU 的适配反而不如专用的 RKNN 顺手ONNX Runtime 的算子覆盖全面但体积较大内存占用偏高ncnn 在手机端优化很好但嵌入到家电主控API 风格和内存管理方式跟我们的业务耦合度不够高。最终我们选择基于 RKNN SDK 做了一层非常轻量的封装自研了一个“推理服务模块”暴露给上层应用的是一个极其简单的接口输入音频特征或传感器数据输出分类结果或置信度向量。这个封装的意义不在于“重新发明轮子”而在于统一了上下层的交互协议——上层业务逻辑不用关心底层是 NPU 还是 CPU也不用关心模型什么时候被加载、什么时候被卸载。5.2 资源受限下的内存管理模型常驻缓冲区复用这里有个具体的工程问题RK3588 虽然有 8GB 内存但家电主控不可能把所有内存都分给你的 AI 模块整个系统还跑着实时控制、网络通信、人机交互等一堆任务。我们的做法是给推理服务分配一块固定大小的内存池所有中间张量的内存都从池中申请和释放禁止在推理过程中动态 malloc。一次性把内存池初始化好能避免内存碎片化也能避免底层 NPU 驱动在动态内存分配时出现不可预测的延迟。音频采集这边的处理是双缓冲区交替写入。一块缓冲区在采集数据时另一块缓冲区在推理两块交替中间用信号量做同步。这样麦克风的数据流不会因为推理耗时而出现丢帧。实测下来300ms 的数据缓冲量足够覆盖推理峰值耗时不会出现音频断层。5.3 系统稳定性看门狗、掉电保护与灰度升级家电产品的运行环境远比手机恶劣——电网波动、静电干扰、高温高湿什么都有可能发生。AI 模块作为一个相对复杂的软件子系统最怕的就是“卡死”或者“异常挂起”。我们的方案是多级看门狗硬件看门狗监控主控系统软件看门狗监控推理服务一旦推理服务超过 5 秒没有响应系统自动重启推理模块而不需要重启整个设备。因为推理服务是独立的进程重启后可以快速恢复状态期间设备的基础功能——比如加热、搅拌、定时——完全不受影响。还有一个容易被忽略的点是掉电保护。洗衣机正在跑 AI 能效分析时突然断电下次开机不能因为 AI 状态机还没恢复就罢工。我们的做法是把 AI 模块的持久化状态比如当前是否在异常监测模式、学习到的用户习惯参数存到 Flash 的固定分区每次状态变更时立即写入启动时读取恢复。注意写入策略上不能太频繁否则 Flash 寿命会很快耗尽——我们用“脏标记 定期合并”的方式来缓解把写入频率控制在分钟级而不是秒级。OTA 升级这块也有值得分享的。端侧模型不像 App 能随时更新升级模型时如果网络中断可能导致设备“半新半旧”新的模型文件已经覆盖了旧的但模型版本号与下层的算子库不匹配推理直接崩溃。我们的方案是双分区 A/B 升级模型文件先写到备用分区校验通过后再切换启动指针。整个升级包只有几百 KB通过产品自己的 Wi-Fi 模块在后台静默完成用户无感知。6. 实测数据与效果对比用数据说服产品经理和老板6.1 三种运行模式下的性能测试整个系统联调完成后我们做了一轮详细的性能测试分别在三种状态下记录关键指标待机监听模式、语音交互模式、连续异常监测模式。待机监听模式下的功耗约为 0.85W包含双麦克风阵列、音频 DSP、主控低功耗状态。这个数字对家电产品很关键因为家电在非工作状态下的待机功耗直接关系到能效等级评定。语音交互模式下从用户说出唤醒词到设备执行指令的平均响应时间为 280msP95 为 410ms完全落在 500ms 的目标范围内。连续异常监测模式下推理模块的 CPU 占用率约 22%、NPU 占用率约 35%内存占用约 120MB含模型常驻和缓冲区系统整体还有大量的余量可供其他业务模块使用。6.2 与纯云端方案的成本对比很多人在立项时都会问一个问题云端方案这么成熟为什么还要花大力气做端侧我们算过一笔账还是很有说服力的。云端语音交互方案每台设备需要额外的 4G 或 Wi-Fi 模组的算力支持、云端服务费、持续的流量费哪怕每个月只有几十 MB。以一台设备生命周期 5 年计算每台设备的云端服务费用累计约 30~50 元这还没算云端开发、运维、以及网络波动导致的客服投诉成本。而端侧方案的边际成本几乎为零——硬件成本增加主要集中在芯片升级和麦克风阵列约 15~20 元软件成本是一次性的可以摊薄到产品生命周期里。对于年出货量在百万级的家电产品这笔账算下来非常可观。6.3 用户反馈与效果迭代产品放出小批量试产机后我们收集了首批用户的反馈。语音控制功能的使用率比预想中高很多有 68% 的用户一周内至少使用过一次语音指令这说明“能用”和“好用”之间存在巨大的体验鸿沟——很多用户之前不用语音控制不是不喜欢而是之前的方案太卡、识别太差。用户吐槽最多的一个点反而是我们一开始没太重视的语音反馈的响应语太机械。系统播报“好的已为您设置定时十五分钟”用户觉得像在跟机器人说话。后来我们在端侧加了一个轻量级的语气变体库根据用户指令的类型随机选择不同的应答模板比如“行嘞十五分钟以后关”“好嘞小火定时开始”虽然只是很小的交互细节但用户满意度提升非常明显。这就是做实际产品和做 Demo 的最大区别Demo 看功能产品看细节。7. 常见问题与排查技巧实录整个项目踩过的坑不少这里挑几个最典型的整理成速查表方便后续做类似项目的朋友快速定位问题。问题现象可能原因排查思路与解决办法唤醒率在装壳后骤降电源纹波过大干扰音频参考电压给音频供电加 LC 滤波检查模拟地与数字地布局偶尔出现误唤醒扬声器启动瞬间的电磁耦合扬声器驱动加软启动麦克风走线改屏蔽线并远离喇叭模型部署后精度下降明显量化校准集与实际场景分布不一致采集真实场景数据作为量化校准集并在真机上验证NPU 推理时间波动大内存碎片化或 NPU 任务优先级被抢占用固定内存池替代动态 malloc设置实时线程优先级异常检测偶尔漏报温度传感器数据噪声偏大传感器数据先做滑动平均滤波再做时序模型推理升级后模型无法加载版本不匹配或文件校验失败A/B 分区升级校验文件哈希后再切换启动指针设备长时间运行后 AI 功能无响应推理服务线程卡死软件看门狗自动重启推理模块基础功能不受影响指令识别混淆“大火”与“小火”音频特征在低频段特征区分度不足增加倒谱均值归一化CMN预处理补充更多近场训例按我个人的经验这里最容易踩的坑其实是前两个——硬件问题比软件问题更难排查。软件问题有日志、有调用栈可以一步步调试硬件问题往往是“时好时坏、换了环境就复现不了”。所以我在做每一个新功能之前都会先确保硬件平台的信号完整性和电源完整性没有隐患这能省下后面大量的排障时间。8. 最终的心得体会项目从立项到试产前后大概花了 8 个月。这中间经历了模型精度怎么调都不达标的焦躁期也经历了深夜在实验室用示波器抓波纹的“电工时刻”但整体走下来最深的体会是做端侧 AI 和做互联网 AI 完全是两种思维方式。互联网 AI 讲究“数据越多越好、模型越大越好”算力不够就堆显卡效果不好就换更大的模型。但端侧 AI 讲究的是“在绝对有限的资源下设计出够用且稳定的方案”。你必须在功能、成本、功耗、延迟、隐私、可靠性这些互相矛盾的目标之间找到一个微妙的平衡点。这个能力不是看几篇论文就能学会的必须在实际项目中反复打磨。最后再分享一个小技巧在做模型压缩和硬件适配时一定要从第一天就把“真机验证”作为核心的开发流程千万不要在 PC 上把一切调试好了再移植到设备上。PC 上一切正常到了真机上出现各种莫名其妙的问题几乎是端侧 AI 开发的常态。只有尽早让模型在真实硬件上跑起来后续的迭代才会是顺畅的。这个项目的很多方法论我觉得放到其他家电品类——空调、冰箱、厨电、小家电——也是通用的。只要明确了场景、圈定了资源边界、搭好了一套稳定的端侧推理底座后续往不同产品线复制速度会快很多。