前阵子一个做智能水表的朋友找到我说他们准备给产品加AI让我帮忙看看方案。我问他具体想做什么他说想预测哪户漏水。说实话这种需求在物联网开发里太典型了一说加AI大家第一反应是上深度学习、上大模型可真到落地的时候很多环节用简单的时间序列分析加上几条规则就搞定了真正需要模型的地方反而藏在更具体的细节里。AI在物联网开发中的应用这几年已经从一个概念变成开发者躲不开的工程问题。我完整趟过从硬件端到云端的几个项目之后发现很多问题的关键不是模型多先进而是怎么判断“这个环节该不该用AI、用哪一种AI、部署在哪里”。这篇文章不打算讲那种宏观概念我想结合自己踩过的坑把AI在物联网开发里真正会碰到的工程问题从头到尾理一遍。不管你是做嵌入式、写物联网平台还是准备转AIoT的算法工程师应该都能找到能直接用的东西。1. 物联网开发里的AI到底解决的是哪几类问题在动手写代码之前我习惯先做一道分类题。一个物联网系统从物理世界采集数据经过传输和处理再反馈回物理世界AI能发挥作用的环节其实就三类感知、决策、交互。这个分类不是学术定义是从项目评审的实战里洗出来的因为不同类别直接决定了你选什么模型、把模型放哪以及需要什么样的硬件资源。1.1 数据侧的感知与清洗先说感知。别以为感知就是装个传感器读数值真实场景里的数据质量往往差到让你怀疑人生。传感器会出现零漂、温漂车间里的电机一启动附近另一路振动信号就被带上高频噪声防水终端进水后数据会出现一整段异常平直线。传统的低通滤波、中值滤波能处理掉一部分规则噪声但碰到那种“看起来像真实故障、实际上是环境干扰”的样本固定参数的滤波器非常容易误判——要么把有效信号滤掉要么把干扰当故障报出来。这种情况下AI可以作为第二道校验。我在一个水泵健康监测项目里先用了孤立森林对采集到的振动数据做无监督异常检测目的是把明显偏离历史分布的片段标出来再人工确认是真实故障还是传感器异常。选孤立森林不选深度自编码器原因很简单它没有训练阶段复杂的调参需求特征少C也容易移植。这里我要强调一点如果你们的运维工程师已经有多年经验能用3σ原则或控制图解释清楚的数据模式优先用那些统计方法AI模型只在传统方法解释不了时才上。不要为了在汇报里多一个“AI”字把简单问题复杂化。1.2 决策侧的预测与控制决策侧是目前AI在物联网中价值最直接的部分。典型的任务包括设备剩余寿命预测、基于历史能耗的优化调度、冷链运输中制冷机组启停策略、城市路灯按人流量自动调光。这些任务的共同特点是有明确的输入历史数据、状态量有可量化的输出一个数值或一个类别适合用监督学习来做。但说句得罪人的实话物联网决策侧能拿到的标注数据通常少得可怜。故障样本可能只占总样本的千分之几这时候模型结构的复杂程度反而不是关键怎么处理类别不平衡、怎么定义损失权重才是决定上线效果的因素。我在热泵故障预测里试过XGBoost和随机森林最终效果差不多但随机森林的推理代码更容易在边缘网关上部署。如果数据量再少一些我甚至会先用逻辑回归或者朴素贝叶斯建一个基线模型把评估流程跑通再考虑要不要升级。这算是一个非常重要的工程习惯先用最简单的模型打通链路再优化准确率。1.3 交互侧的人机自然沟通交互侧是最近两年才爆发起来的。以前的物联网交互基本是手机App里一堆开关和滑块或者智能音箱上的固定命令词。现在有了大模型设备能听懂“帮我看看车库的温度为什么这么高”甚至能和用户多轮对话。这类功能对算力、内存和通信带宽的要求都比较高绝大多数项目会把自然语言理解放在云端或边缘服务器。我也做过一个尝试在本地网关部署一个小参数模型处理固定的离线指令比如断网时识别“打开客厅灯”在线时再调用云端大模型做复杂意图识别。这个混合方案兼顾了离线可用和智能程度但部署成本确实不低涉及到量化、推理框架适配和内存优化。如果只是做个演示完全可以把交互全部放云端如果产品要考虑弱网环境这块就得提前规划。问题类型典型输入常用方案推荐部署位置感知与清洗原始传感器序列滤波异常检测孤立森林/自编码器设备端/边缘端决策与预测历史时序工况状态随机森林/XGBoost/1D CNN边缘端/云端交互理解语音/文字指令LLM/小参数NLP模型云端为主边缘为辅这个表并不是绝对规则它的作用是让团队在评审需求时快速对齐我们现在讨论的到底属于哪一类资源该怎么倾斜。2. 端侧推理模型选型从MCU到边缘网关怎么权衡2.1 为什么不能把云端模型直接搬上MCU在聊选型之前先讲一个最常见的错误有些团队算法部分在服务器上跑通了直接想把它挪到设备端结果发现根本塞不进去。一个普通的MobileNetV1图像分类模型FP32权重在4.9MB左右而一颗常见的Cortex-M0 MCU内存只有几十KB到一两百KB光权重就差了两个数量级。更有甚者很多MCU内核根本没有浮点运算单元跑一次卷积可能耗时几秒根本谈不上实时。所以模型能放在哪一层先要由硬件资源决定。我的习惯是先统计三件事可用内存、Flash空间、单次推理的时间预算。比如一个电表箱里的监测设备MCU内存只有192KBFlash 1MB要求2秒内完成预测并上报那深度学习模型基本不用考虑直接用C语言的决策树或箱型判断更现实而一台工厂边缘网关如果用的是RK3588或者Jetson平台内存8GB以上那就能跑较大的CNN甚至能跑微型Transformer。2.2 压缩“三件套”量化、剪枝、蒸馏如果确认算法必须上深度学习但设备端资源紧张第一件事不是换模型结构而是做压缩。压缩路线我常用的有三条。量化把FP32的权重和激活值变成INT8甚至INT4就像把一张高清照片保存成网页用的小尺寸图。推理速度通常能提升2到4倍模型体积缩小75%左右精度损失一般在1%到3%。这里有个细节——量化不是拿训练完的模型直接转就完事跑量化校准的时候需要一个能代表真实分布的校准集否则如果校准数据太“干净”放到现场遇到噪声分布差异大的数据INT8模型的输出可能偏差很大。剪枝把模型里影响不大的连接或通道删掉。直观理解是删掉一篇文章的冗余段落保留核心信息。剪枝手法有结构化剪枝和非结构化剪枝前者对硬件更友好后者能压体积但不好加速。物联网端侧推理我推荐结构化剪枝因为它切掉的是整个卷积核或通道在普通推理引擎里能真正跑得快。蒸馏用一个大模型当“老师”教一个小模型当“学生”。学生模型保留老师的大部分能力但体积小得多。这个方案适合云端已经有一个效果不错的模型现在要把它搬到边缘的场景。三条路线经常组合使用。我记得在一个图像分类项目里一个6MB的ResNet18模型先用蒸馏变成3.2MB的小模型再INT8量化到0.8MB推理速度从200多毫秒降到35毫秒基本不影响业务精度。2.3 硬件和推理框架怎么配部署平台内存规模推荐推理框架适用模型规模Cortex-M系列MCU几十KB~几百KBTFLite Micro、STM32Cube.AI极小CNN/决策树/规则ESP32-S3等AIoT芯片512KB~8MBESP-DL、TFLite MicroMobileNet等小型CNN边缘Linux网关RK3588等4GB以上ONNX Runtime、RKNNCNN、Transformer等Jetson系列4GB以上TensorRT中大型模型/检测模型这里想说明一点选框架不只看算力还要看工程团队熟悉度。我们在一个项目里即使TensorRT性能最好但团队没人用过后来还是选了RKNN因为技术支持资料多、踩坑成本小。工具链的成熟度有时候比纸面性能更重要。3. 一个设备故障预测功能的完整实现链路这一部分进入实操。我拿一个旋转机械轴承异常检测项目当例子把从传感器到边缘网关的所有步骤展开。这是物联网AI里非常经典的任务既有时间序列处理又有明确的失效模式很适合作为学习样板。3.1 场景定义与数据采集设计先说目标通过加速度传感器采集轴承振动信号提前几小时到几天预警轴承异常减少非计划停机。采集端放在轴承座附近用ADXL345加速度计采样率定在12kHz每次采样1秒也就是每段序列12000个点然后每隔10秒上传一次特征值到边缘网关。这里有个设计依据轴承故障特征频率通常在几千赫兹以内12kHz满足奈奎斯特定理再高了数据量翻倍对存储和带宽都不划算。标签怎么打这是物联网AI里最容易翻车的地方。我们参照维修工单记录把每次实际更换轴承的时间往前推48小时这段时间内的样本标为“即将故障”其余标为“正常”。还要注意单台设备的振动基线会随负载变化所以我们在标签里额外记录转速和负载系数后续模型可以按工况分组训练。一开始没有这套标注逻辑的时候我们拿到的标签乱七八糟训练出的模型上线后误报率惨不忍睹。3.2 特征提取与数据集构建原始12000点数据直接喂给模型在小样本场景并不可靠。我们提取时域和频域两组特征时域RMS、峰峰值、方差、峭度、波峰因子。峭度对冲击类故障比较敏感波峰因子能反映信号是否有短时大幅值。频域对每一段信号做FFT把0到6kHz频带切成若干个频段计算每个频段的能量占比。代码用Python实现import numpy as np from scipy.fft import rfft, rfftfreq def extract_features(signal, fs12000): feat {} feat[rms] np.sqrt(np.mean(signal**2)) feat[peak] np.max(np.abs(signal)) feat[variance] np.var(signal) feat[kurtosis] ((signal - feat[rms])**4).mean() / ((feat[variance]**2) 1e-12) feat[crest] feat[peak] / (feat[rms] 1e-12) spectrum np.abs(rfft(signal)) freqs rfftfreq(len(signal), 1/fs) for i, (lo, hi) in enumerate([(0, 1000), (1000, 2000), (2000, 3000), (3000, 6000)]): mask (freqs lo) (freqs hi) feat[fband_{i}] np.sum(spectrum[mask]) / (np.sum(spectrum) 1e-12) return feat这段代码是实际用的简化版注意峭度计算里的数值稳定性加了1e-12防止除零。数据不平衡问题也要重视。正常样本可能有10万条故障样本只有几百条。简单的做法是在训练前做SMOTE过采样或者给少数类更大的损失权重。实测下来对于随机森林SMOTE带来的提升并不明显反而是把正负样本比例控制在1:5到1:10更稳定。3.3 模型选择与训练我们用的随机森林原因有三个特征量不大十几个维度随机森林不易过拟合而且在边缘网关上转换成C代码比深度学习模型简单得多。如果你手上样本足够比如有几万条以上也可以试试1D CNN本质是对原始信号做局部模式学习省去特征工程但代价是调参和部署成本直线上升。训练关键代码如下from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import train_test_split from sklearn.metrics import classification_report X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42, stratifyy ) model RandomForestClassifier( n_estimators200, max_depth12, class_weightbalanced, random_state42 ) model.fit(X_train, y_train) print(classification_report(y_test, model.predict(X_test)))评估时不要只看准确率。因为故障样本占比小哪怕全预测为“正常”也能有99%准确率。要严格看召回率漏报率和误报率两个指标。我们在项目里的目标是“即将故障”的召回率不低于90%误报率不超过每台设备每天1次。3.4 部署到边缘网关的坑模型在服务器上验证通过后用m2cgen或ONNX转成C代码放进边缘网关程序里。听起来顺畅但真正上线第一周误报率直接超标。后来查出来是模型冷启动问题设备端新安装的传感器前几天的振动基线和训练数据使用的旧传感器有差异温漂也改变了特征分布。解决办法是在部署后加一个为期一周的“自适应校准期”系统先用前几天的数据重新计算特征归一化参数再把标准化后的特征送入模型。这个经验救了我好几次任何传感器模型真正部署时都要给数据分布漂移留缓冲不要相信模型在测试集上的漂亮指标就能直接复用到现场。4. 云边协同AI模型不是部署完就算完事4.1 端边云三层分工在物联网项目的架构上我习惯把AI能力拆成三层。设备端这层只做必须的本地实时处理比如工业协议栈里的紧急停车判断、门锁的本地人脸特征比对。边缘网关是中间层运行大多数推理模型响应延迟尽量控制在几十毫秒到几百毫秒。云端负责重型计算和迭代训练比如处理所有设备上传的数据、训练新模型、定期做数据报表。为什么这么拆主要考量是延迟、带宽和可靠性。如果每次判断都要把数据传到云端再等结果网络抖动一下设备就断判断如果所有模型都在设备端跑硬件成本又压不下来。边缘网关的作用相当于把云端的部分思考能力下沉到离设备最近的地方既保留离线能力又比MCU算力强很多。4.2 模型更新与OTA迭代模型部署上线不是终点而是另一套迭代流程的起点。我们一般在云端训练好新模型然后以差分包形式推送到边缘网关。推送机制要兼顾安全和灰度具体我习惯这样做先在一台边缘网关上加载新模型用真实流量跑24小时对比新旧模型的输出分布和误报率。如果差异在可接受范围内开放到10%设备做灰度持续观测3到7天。确认稳定后再全量推送。同时保留上一版本模型文件支持一键回滚。这个过程很容易被忽略的是“回滚”能力。很多团队推了新模型后旧的直接删掉一旦新模型在某种工况下崩溃想恢复都没有底包。正确做法是至少保留最近两个版本的模型文件并配置好回滚脚本。指标说明触发回滚阈值每日误报率每台设备每天预计次数超过旧版本2倍推理耗时P95边缘网关上的预测延迟超过500ms内存使用率模型加载后的常驻内存超过可用内存80%4.3 数据回流与持续学习所有AI模型在物联网场景里都会面对模型漂移因为设备老化、季节变化、生产线的工艺调整都会改变数据分布。所以部署之后要持续回流数据。我参与的项目会在边缘网关保存推理结果、原始特征和人工确认标签每周批量回传到云端云端把新样本并入训练集再生成下一版模型。要特别注意一点回流数据必须做脱敏和合规检查。比如采集的是工厂设备运行数据里面可能包含生产节拍、工艺参数这些对工厂来说是商业机密。在回传之前先和设备方签订数据使用协议技术侧尽量做匿名化和特征级脱敏只回传模型训练需要的统计特征不要回传原始波形。这不是流程繁琐而是项目能长期做下去的前提。5. AI辅助物联网开发本身代码生成、调试与测试5.1 用LLM生成嵌入式代码的实际效果和限制最近两三年开发者的编码方式已经被大模型改变。我在物联网开发中使用LLM最频繁的场景是生成协议封装、驱动读取代码和配置文件模板。比如让LLM写一个通过MQTT上报JSON数据的C语言封装它生成的基础结构基本能直接用能省不少时间。但LLM在嵌入式代码上有明显的“一本正经编造”问题。之前让它生成一个模拟I2C读取某颗温湿度传感器的驱动它给出了寄存器地址和读取时序看着像模像样但对照芯片手册发现地址完全是错的。这类错误编译器不会报错只有实机测试才会暴露。所以我现在坚持一个原则LLM生成的所有寄存器地址、引脚定义、时序参数必须对照手册人工核对函数框架可以信任但硬件相关常量绝不盲信。提示词怎么写给足上下文。不要只写“生成STM32读取ADC代码”而是明确“使用STM32F407HAL库ADC1通道3要开启DMA采集返回12位原始值并以数组形式存储”。上下文越具体生成结果的可用率越高。5.2 LLM在日志和协议解析上的应用物联网设备一多日志解析就成了一件头疼事。不同厂商的设备日志格式完全不同甚至同一型号不同固件版本的报错字段都不一致。传统做法是写正则表达式去匹配但新增一种设备就要写一版规则。我在一个充电桩远程运维项目里尝试用LLM来做日志归一化和异常分级效果不错。把原始日志文字和少量示例输进去让模型输出结构化的故障类别、严重级别和建议处理方式比手写正则的覆盖率高很多。不过用LLM处理日志有两条红线。第一不要直接把真实日志扔到公有云API上涉及用户信息和商业数据一旦泄露很麻烦。可以部署本地小模型或者先做字段脱敏再处理。第二要有清晰的降级方案大模型偶尔会把“普通提示”看成“故障”所以故障告警还是要走规则引擎兜底LLM只负责打标签和辅助分派不直接触发停机动作。5.3 Agent与开发工作流再进一步就是把LLM封装成Agent和代码仓库、编译工具、测试框架打通。我用LangChain4j搭过一个团队内部的工具链开发者描述一个需求Agent去检索代码库、修改相关模块、编译并跑单元测试最后把结果汇总回来。这相当于一个大模型实习生能节省不少重复劳动。但Agent在物联网开发里要谨慎。嵌入式编译链的交叉工具非常容易因为环境变量不对而失败Agent很难自己判断问题出在代码还是环境。我的建议是别让Agent直接向主分支提交代码而是让它生成补丁和测试结果由人工确认后合入。自动化越深出问题时的排查成本越高这个度要控制好。6. 想少踩坑建议按这个顺序落地6.1 从数据量最成熟的项目切入如果你所在团队刚刚开始做AIoT别选那种要从采集层开始建设的项目。最理想的切入点是已经有至少一年历史数据、并且数据质量还行的场景比如设备历史告警、生产能耗记录、温室环境监测。有了数据模型验证能在几天内跑通团队也容易建立信心。反过来如果是一边设计硬件一边做算法任何一个环节出问题都很难定位。6.2 先做预测和异常检测再碰控制闭环控制类AI比如自动调节设备参数意味着AI出错会造成实际物理后果责任边界和设备安全都得重新评估。我们内部有个不成文的规定新场景第一版只做预测和建议也就是“告诉运维人员该检修了”不做自动断电、自动调参。等技术团队在模型可靠性、回滚机制和权限管理上成熟后再逐步放宽控制权限。6.3 效果评估与故障恢复机制最后不管做什么AIoT项目在立项时就要定义清楚可量化的评估指标。我在项目里常用这几个准确率、召回率、误报率、推理延迟、内存占用、模型更新回滚时间。其中回滚时间是很容易被忽略的一项——没有回滚机制所谓人工智能上线就变成“人工智障”兜底。回到开头那个智能水表的朋友我最后给他的建议是先不要上任何模型。先把过去一年的用水数据按户整理出来用简单的季节性分解看哪些户在凌晨持续小流量这大概率能覆盖他80%的需求。等这个规则版本跑稳了再根据反馈样本决定要不要用异常检测模型去覆盖剩余的长尾场景。我自己做了几年物联网项目最大的感受是AI在物联网开发里不是一个炫技的标签而是解决数据、决策和交互问题的一组工具。真正靠谱的落地往往是从一个很小的、能解释清楚的模型开始的。如果你正打算入坑先从一路传感器、一个月的干净数据和一个随机森林开始跑通了再谈更复杂的架构。