3.6 端侧AI与自适应采样
3.6.1 端侧AI：TinyML概述与部署工具
从“只传不判”到“边感边判”
工业车间里部署了一百台振动传感器，每周例行巡检时总能发现三台机器的轴承已经磨损到需要更换。问题是，这些轴承在失效前一周，其振动频谱中出现了一个特定的“前兆”模式——早期故障特征隐藏在噪声里，固定阈值触发器根本捕捉不到。传统的做法是把所有振动数据上传到云端分析，但这台传感器每秒采集数千个加速度数据点，一百台传感器光带宽费用就不菲，而且云端就算分析出来，延迟也赶不上紧急停机。
更好的做法是：让传感器节点自己学会识别这个频率模式，只有“看起来像轴承故障”的片段才上传。数据量大幅降低，响应延迟从秒级降到采样周期级别。这就是TinyML在感知层要解决的问题——把机器学习推理引擎塞进一块只有几十KB RAM的微控制器里，让它能自己“看懂”传感器数据。
什么是TinyML
TinyML是“微型机器学习”（Tiny Machine Learning）的简称。它并不是一个新的算法体系，而是一套专门在资源极度受限的微控制器（MCU，Microcontroller Unit）上部署和运行机器学习模型的工程技术。典型的目标硬件是ARM Cortex-M系列（M0/M3/M4/M7）、RISC-V核，乃至8位单片机。这些芯片的SRAM通常只有几十到几百KB，Flash不超过几MB，运行频率在几十到几百MHz之间。
放到物联网感知层来看，TinyML让传感器节点不仅会“测”，而且会“算”和“判断”。它把端侧智能直接嵌入到最靠近物理世界的最后一厘米。智能传感器正是“将传感器与微处理器集成为一体，具有环境感知、数据处理、智能控制与数据通信功能的智能数据终端设备”。TinyML恰恰给这个“微处理器”注入了更强的数据处理能力——不再只是跑固定逻辑或阈值比较，而是能根据历史数据模式完成分类、回归或异常判定。对照第1章讨论的AIoT架构，这里对应的是“采集”环节的智能化：不是先把数据全传到云端再说，而是采集的同时就能做初步判决。
为什么需要端侧AI
原因可以从三个维度来理解。
带宽与成本。 感知层往往是物联网系统的数据瓶颈。一个中等规模的工厂可能有数千个传感器节点，如果每个节点每隔几秒上传一条完整的原始数据包，汇聚层的无线网关和云存储很快就会不堪重负。TinyML让节点在本地完成特征提取和初步判决，只上传有业务价值的“事件”或“摘要”。在典型的无线传感器网络场景中，这意味着电池寿命延长和传输费用下降，具体压缩比例取决于信号稀疏度和模型能力。
延迟与可靠性。 很多保护性动作要求毫秒级响应——比如质检相机发现产品缺陷后立即触发剔除机构。等数据传到云端、完成推理、再下发指令，往返延迟通常超过100ms，产线已经运行了十几件产品。端侧推理可以把响应延迟降到采样周期级别，而且不依赖于网络连接质量。即使在断网情况下，本地节点依然能独立运行。这种“云侧训练、边缘推理、端侧响应”的分工模式在实践中已被大量采用。
功耗与隐私。 传统的AI模型在GPU或云端服务器上运行，功耗通常在数十瓦到数百瓦之间。TinyML模型的推理功耗通常在毫瓦级别，能够靠电池运行数月甚至数年。同时，原始数据可以不上传，这在用户隐私场景下很有价值——例如在智能楼宇中检测人员活动状态时，在本地完成姿态判断，只上传“有人/无人”的布尔值，不把视频帧流送到远处，也避免了触碰数据合规红线。
核心技术：量化与剪枝
把训练好的神经网络模型塞进一块只有几十KB内存的MCU上，不是简单的“复制粘贴”。主流深度学习框架（TensorFlow、PyTorch）导出的模型通常是32位浮点（float32）权重和激活值。一个含 10 万个 float32 参数的模型，权重即占约 400KB Flash（100K 参数 × 4 字节），对只有几十 KB 内存级别的 MCU 而言相当可观。需要做两件事情：量化和剪枝。
量化（Quantization）是最核心的压缩手段。它把32位浮点数映射到8位整数甚至1位二值值。8位量化（int8）后的模型体积显著缩小，推理速度明显提高，在大多数分类和回归任务中精度损失可以控制在工程可接受范围内。更激进的策略包括混合精度（部分层保持float16，部分层降到int8）和训练时模拟量化（Quantization-Aware Training, QAT），后者能让量化后的模型精度更接近浮点基线。
剪枝（Pruning）则把模型中不重要的连接或神经元直接移除。训练完成后，权重绝对值接近0的神经元对最终输出贡献极小，可以安全砍掉。结构化的剪枝可以删掉整层或通道，非结构化剪枝则只去掉单个连接。剪枝后模型体积缩小，计算量下降，通常需要再微调几个epoch来恢复精度。
下面这张图展示了TinyML从训练到部署的完整流程，这是工程中需要面对的标准生命线。
实测验证闭环：PTQ、QAT 与硬件验收
量化不能只比较模型文件大小。训练后量化（PTQ, Post-Training Quantization）在训练完成后用代表性校准数据估计数值范围，成本低，适合先建立INT8基线；若精度损失或异常样本退化不可接受，再采用量化感知训练（QAT, Quantization-Aware Training）在训练中模拟量化误差。FP16、INT8甚至INT4是否更快，取决于目标NPU/MCU、算子支持、内存带宽和运行时；位宽降低并不自动等于端到端加速。
代表性校准集必须覆盖真实设备、工况、环境和异常，而不是只抽取训练集中的理想样本。预处理、量化参数和模型应作为同一发布单元。转换后依次检查：
- 模型和固件能否加载，算子是否回退到慢速路径；
- 全量验证集及关键子群的准确率、召回率和误报率；
- 推理时延的P50/P95、峰值RAM/Flash、冷启动和持续运行热稳定性；
- 单次推理和单位时间能耗；
- 断电、模型损坏、OTA失败时能否回滚。
主流部署工具链
目前工程中应用最广泛的TinyML工具链有两个。
| 工具链 | 开源/商业 | 典型适用目标 | 核心优势 | 主要代价 |
|---|---|---|---|---|
| TensorFlow Lite for Microcontrollers (TFLM) | 开源 | ARM Cortex-M全系列、ESP32、RISC-V等 | 平台通用性最高，灵活配置，社区活跃 | 手动调优工作量大，需自行集成驱动 |
| STM32Cube.AI | 商业 | STM32系列MCU (M4/M7/M55) | 自动化程度高，与STM32CubeMX深度整合，硬件加速 | 平台锁定，跨厂商迁移困难 |
TensorFlow Lite for Microcontrollers (TFLM)。这是Google TensorFlow团队维护的开源推理引擎，专门针对MCU场景做了内存优化。官方文档中列举了ARM Cortex-M0/M3/M4/M7、ESP32等作为验证硬件。TFLM的核心是把模型解释器的代码量压缩到几十KB级别，不依赖操作系统，纯C++实现，可以直接在裸机或FreeRTOS上运行。工作流程是：用TensorFlow/Keras训练模型→通过TFLite Converter做量化和转换→导出为C字节数组→嵌入到MCU工程中。TFLM的灵活性最高，适合对内核兼容性要求高的项目，但配置工作相对繁琐。
STM32Cube.AI。这是意法半导体的商业工具，深度绑定STM32系列MCU。它读取Keras、ONNX或TensorFlow Lite模型，自动生成针对Cortex-M核优化的C语言推理代码，并且能调用STM32内部的硬件加速器（如M4和M7的DSP扩展、M55的Helium向量扩展）。在STM32CubeMX集成开发环境中，AI模型可以作为一个外设直接配置，和UART、I2C等硬件驱动并列在同一份工程文件里。对于没有足够模型优化经验的团队，Cube.AI的自动化程度更高，但代价是平台锁定到STM32生态。
两条路径的选型取决于项目约束：如果使用非STM32芯片，或者需要最大自由度进行实验，TFLM是更通用的选择；如果团队已经有STM32硬件选型，且希望快速交付原型，STM32Cube.AI能省去大量手动调优工作。
工程权衡与部署陷阱
TinyML不是万灵药。它的适用边界很明确——如果任务需要理解复杂的上下文（比如多轮对话或图像语义分割），MCU的算力和内存远远不够。这类需要语言理解的任务，目前的折中做法是把小语言模型（SLM，Small Language Model）下沉到边缘网关：30亿参数量级以下的模型经量化后已能在网关级硬件上运行，支撑设备手册问答、告警摘要、工单初筛这类运维场景；不过它需要数GB级内存和瓦级功耗，属于网关侧而非传感器节点的能力，与TinyML不在一个量级上。但如果只是做二分类、少量关键词识别（唤醒词、几个控制命令）、简单的异常检测或振动模式匹配，TinyML完全胜任，而且成本远低于在云上跑大模型。
部署时需要注意的几个常见工程陷阱：
- 量化后的模型精度必须在实际硬件上重新验证。仿真器的浮点行为可能和真芯片存在差异，尤其是涉及到浮点精度损失在边缘激活值上的累积效应。一个在PC上通过验证的量化模型，烧录到MCU上后可能出现误报率飙升。
- 预处理配置必须与训练完全一致。输入数据的归一化参数、滑动窗口大小、降采样比例这些细节，在固件烧录后几乎无法修改。预处理逻辑应该在代码设计阶段就与模型打包在一起，而不是写在固件外层的配置文件中。
- 模型更新机制需要提前规划。如果现场设备已经部署了上千台，采用OTA方式更新固件是比较实用的做法。这需要芯片支持安全的Flash擦写和回滚保护，且模型文件不能超过Flash可用空间。
例子：在Cortex-M4上部署关键词识别模型
在一颗ARM Cortex-M4内核、配备典型SRAM和Flash大小的MCU上部署一个关键词识别模型（识别“开启”、“关闭”、“停止”等三到五个命令）。训练好的全精度模型采用常见轻量级网络结构。经过int8量化和适度剪枝后，模型体积压缩到微控制器Flash可容纳的范围内，推理时所需SRAM（包括模型权重和中间激活值）也远低于典型可用RAM。整个推理过程的功耗（包含传感器采集和MCU运算）低到可以支持电池供电下的长期运行。这个场景展示了TinyML如何在资源受限的传感器节点上实现“听懂”指令，完全不需要把音频流上传云端。
TinyML正在把感知层的“末梢神经”从单纯的传感器变成一个个有基本判断力的微型大脑。下一节讨论另一种降低上行数据量的工程策略——自适应采样。两者互补：TinyML管理的是“是否动”和“为什么动”，自适应采样管理的是“多久动一次”。两者结合后，一个边缘节点可以做到只在有意义的相关事件发生时，才以需要的精度去感知和上报。
3.6.2 自适应采样：动态调整数据采集频率
固定频率采样在工程中有一个根本矛盾：平稳时段投入的采样和带宽资源大部分浪费了，而异常发生时又嫌采集节奏太慢，关键信息偏偏落在采样间隔的缝隙里。自适应采样（Adaptive Sampling）让传感器根据数据的“有趣程度”动态调整采集与上报频率——平稳时省电省带宽，异常时自动加速。它不要求每个节点都跑 TinyML 模型，但和端侧 AI 的思路同出一脉：在感知层做决策，减少无效传输。
三种基本策略
事件驱动采样（Event-driven Sampling）：传感器平时处在低功耗休眠状态，只保留一个极低功耗的唤醒电路检测预定义事件。和普通中断唤醒的区别在于，判定前增加了基础逻辑——比如加速度计仅在连续检测到多次超过阈值的振动后，才判定为“疑似机械故障”，然后启动高速采样。休眠期功耗可降至极低水平（微安级示意值），但对缓慢演变的故障几乎无反应，容易漏报。
变化率采样（Deadband Sampling）：传感器持续监测物理量的变化率，当变化率落在预设死区内时大幅降低采样频率，超过死区时恢复全速甚至加速。具体实现中，传感器维护一个滑动窗口，计算当前值与窗口均值的偏差：偏差小于死区则跳过下一个采样；超过死区则立即补采并延长观察窗口。死区宽度的设定依赖离线数据分析，过宽会丢失缓慢变化，过窄则节省不了多少射频能耗。
预测模型采样（Predictive Model Sampling）：部署一个轻量级自回归模型（如 AR(1)）或浅层决策树，根据最近若干采样点预测下一时刻值。若预测残差小，说明环境处于稳态，降低采样频率；残差突然放大，说明发生了模型未覆盖的新情况，立即进入高采样模式。这种方式用预测误差衡量“数据的新颖程度”，能捕捉到固定阈值和变化率都难以识别的早期前兆，但需要投入模型训练和部署流程。
混合策略状态机
实际工程中很少只用单一策略，更常见的是将事件驱动、变化率判据和预测模型打包成一个有限状态机——状态间的切换由模型预测误差的连续放大来驱动。以下是一个振动传感器的三状态切换逻辑（图 3-12）。稳态低功率状态下，传感器以较长间隔采样，仅做简单的频段能量计算和模型预测；一旦模型误差连续放大到基线阈值的数倍以上，立即切换到加速监听模式，以更高频率采样但不做上传；如果多轮残差持续高于阈值，确认故障发生，将累积的原始波形上传。上传完成后复位到稳态。三类转移条件均为示意值，实际工程中需根据振动信号的频率范围和噪声底噪重新标定。稳态下射频完全关闭，只有 MCU 以低时钟运行模型预测；基线阈值需根据离线数据标定，通常取正常工况最大残差的一个倍数范围。
例子：振动传感器自适应采样
考虑一个场景：工业旋转机械上部署的无线振动传感器，电池容量要求维护周期不低于某一期望值。正常工况振动幅值稳定；轴承早期磨损时高频噪声出现但幅值增量微小，固定阈值触发器完全无法感知，而自适应采样的预测模型在误差连续放大时就能察觉到变化。全年绝大多数时间传感器停留在稳态低功率状态，电池寿命较固定高频采样方案显著延长，能满足维护周期要求。更重要的是，模型误差的连续放大可靠地捕捉了从稳定到故障的过渡窗口——这与 3.6.1 节 TinyML 识别振动前兆的设计思路一脉相承，只不过这里用更简单的统计模型替代了神经网络。
工程实现：混合策略伪代码
以下是一个基于变化率与 AR(1) 模型的混合策略实现骨架。其中采样间隔、死区、误差阈值均为示意值，实际部署需根据信号特征和电池容量重新标定。predict_next_value 在实际产品中可以替换为 3.6.1 节提到的 TinyML 模型。
#define WINDOW_SIZE 10 // 示意窗口大小
#define DEADBAND 0.5f // 变化率死区（示意值）
#define MODEL_ERROR_THRESH 2.0f // 预测残差阈值（示意值）
#define HIGH_FREQ_INTERVAL_MS 1000
#define LOW_FREQ_INTERVAL_MS 10000
static float sample_window[WINDOW_SIZE];
static int window_index = 0;
static int consecutive_model_error = 0;
static int current_interval = LOW_FREQ_INTERVAL_MS;
float compute_rate_of_change() {
float sum = 0;
for (int i = 0; i < WINDOW_SIZE; i++) sum += sample_window[i];
float mean = sum / WINDOW_SIZE;
return fabs(sample_window[(window_index - 1 + WINDOW_SIZE) % WINDOW_SIZE] - mean);
}
float predict_next_value() {
// AR(1)模型：直接用最近一次采样值（示意）
return sample_window[(window_index - 1 + WINDOW_SIZE) % WINDOW_SIZE];
}
void sample_and_decide() {
float current = read_adc();
float rate = compute_rate_of_change();
float residual = fabs(current - predict_next_value());
sample_window[window_index] = current;
window_index = (window_index + 1) % WINDOW_SIZE;
if (rate > DEADBAND || residual > MODEL_ERROR_THRESH) {
consecutive_model_error++;
if (consecutive_model_error >= 2 && current_interval != HIGH_FREQ_INTERVAL_MS) {
current_interval = HIGH_FREQ_INTERVAL_MS;
trigger_high_frequency_mode();
}
} else {
consecutive_model_error = 0;
if (current_interval != LOW_FREQ_INTERVAL_MS) {
current_interval = LOW_FREQ_INTERVAL_MS;
trigger_low_frequency_mode();
}
}
if (consecutive_model_error >= 5) {
upload_buffer_to_edge();
consecutive_model_error = 0;
}
}工程权衡：延迟、能耗与漏报率
选择采样策略需要在几个矛盾指标之间取舍。表3-4为定性对比，具体量级因硬件和工况差异很大。
表3-4 自适应采样策略定性对比
| 指标 | 事件驱动 | 变化率 | 预测模型 | 混合策略 |
|---|---|---|---|---|
| 响应延迟 | 极低（中断级） | 中等（依赖死区） | 较高（需累积误差） | 可调 |
| 能耗节省 | 极高 | 中高 | 高（射频休眠收益抵消计算开销） | 较高 |
| 漏报率 | 高（缓慢变化） | 中等 | 低 | 低 |
| 实现复杂度 | 低 | 低 | 高（需模型训练） | 中高 |
从工程覆盖角度看，混合策略兼顾了不同场景的需求：关键路径用“事件驱动+变化率”保证低延迟，次要路径用“预测模型”捕捉缓慢变化信号，从而最大化电池寿命。一个容易被忽视的工程细节：深度休眠唤醒后的初次采样可能存在 ADC 稳定误差，应做丢弃处理；变化率窗口大小需根据信号特征频率设定——对于工频振动，窗口取完整周期样本数可覆盖一个周期；预测模型初次部署时应运行在“全速采样+模型学习”模式，积累足够样本后才进入自适应阶段。平台侧应为每个设备维护一个“采样频率轨迹”字段，便于事后分析降采样时段的数据完整性，也可配合第 5 章的历史数据归档策略进行离线模型校准。