2、TinyML基础回顾：微控制器上的机器学习、模型部署流程、资源约束（内存、算力、功耗）对健康评分的影响
TinyML 的核心命题，是在微控制器（MCU）这类极端受限的硬件上运行机器学习推理。要理解设备健康评分为何需要“从模型输出到业务指标”的映射，首先必须清楚模型在 MCU 上如何生存、如何被部署，以及内存、算力、功耗这三座大山如何从根本上塑造评分系统的设计边界。本章将系统回顾 TinyML 的技术底座，并重点剖析资源约束对健康评分架构的传导效应。
2.1 微控制器上的机器学习：为什么不是“缩小版”的 AI
微控制器与 PC 或云端服务器有着本质差异。一颗典型的 Arm Cortex-M4 MCU，主频通常在 80MHz 到 200MHz 之间，内置 RAM 可能只有 64KB 到 256KB，Flash 存储为 256KB 到 1MB。相比之下，一张入门级 GPU 拥有数千个计算核心和数 GB 显存。这种数量级的差距，决定了 TinyML 不是简单地把模型“变小”，而是要从算法、数据结构、数值精度、内存管理等多个维度重新设计。
在 MCU 上运行机器学习推理，通常采用 TensorFlow Lite for Microcontrollers（TFLite Micro）或 CMSIS-NN 等优化库。这些框架将模型编译为 C++ 静态数组，推理时使用预分配的内存池（arena），避免动态内存分配带来的碎片化和不确定性。模型权重通常量化为 int8 或 uint8 格式，以匹配 MCU 的整数运算单元。例如，一个用于振动信号分类的 1D CNN 模型，在 PC 上可能占用 5MB 的 float32 权重，经过 int8 量化后压缩至约 1.25MB，再经过剪枝可进一步降至 600KB 左右，才能勉强塞进一颗中端 MCU 的 Flash。
这种硬件约束对健康评分系统产生第一层影响：模型容量直接决定了评分的“分辨率”。如果 MCU 只能容纳一个参数量为 50K 的小型决策树或线性分类器，那么健康评分可能只能区分“正常/异常”两个粗粒度状态；而如果能够部署一个 300K 参数的 1D CNN，则可以输出 0-100 的连续健康分数，甚至给出故障类型的概率分布。因此，在设计健康评分方案时，必须首先回答：我们能在目标 MCU 上跑多大的模型？
2.2 模型部署流程：从训练到 MCU 的完整链路
一个 TinyML 模型的落地，需要经过五个关键阶段，每个阶段都会对最终的健康评分产生直接影响。
| 阶段 | 关键操作 | 对健康评分的影响 |
|---|---|---|
| ① 训练 | 在 PC/云端使用完整精度（float32）训练模型 | 模型精度上限在此确定，评分逻辑的“理想表现” |
| ② 压缩 | 量化（int8）、剪枝、权重共享、知识蒸馏 | 精度损失可能造成评分偏差，需校准阈值 |
| ③ 转换 | 转换为 TFLite Micro 格式，生成 C++ 数组 | 算子支持范围决定模型结构，影响评分函数形式 |
| ④ 部署 | 烧录到 MCU，配置内存池和推理调度 | 内存不足会导致推理失败，需降级评分策略 |
| ⑤ 推理与映射 | 传感器数据输入，模型输出原始结果，映射为健康分 | 映射函数设计决定最终业务可读性 |
在部署阶段，一个常见的工程陷阱是内存池大小设置不当。TFLite Micro 要求开发者预先分配一个足够大的内存缓冲区（例如 8KB 或 16KB），如果设置过小，模型初始化会直接失败。更隐蔽的问题是，某些算子（如 LSTM）在推理时会临时申请额外内存，导致峰值内存超出预期。因此，在部署前必须使用框架提供的内存分析工具（如 tflite::MicroInterpreter::arena_allocator() 的统计信息）来精确计算内存需求。
// 典型 TFLite Micro 部署代码片段
static uint8_t tensor_arena[10 * 1024]; // 10KB 内存池
const tflite::Model* model = tflite::GetModel(g_model);
tflite::MicroInterpreter interpreter(
model, resolver, tensor_arena, sizeof(tensor_arena));
TfLiteStatus init_status = interpreter.AllocateTensors();
if (init_status != kTfLiteOk) {
// 内存不足，需要增大 arena 或减小模型
return kHealthScoreUnavailable;
}2.3 资源约束的三重奏：内存、算力、功耗
内存、算力、功耗并非独立变量，它们相互耦合，共同构成健康评分系统的“不可能三角”。
内存约束：RAM 决定了模型中间激活值（activation）的存储空间，Flash 决定了权重和代码的存储空间。一个 1D CNN 模型，输入长度为 256 的振动信号，经过 3 层卷积后，中间特征图可能占用 20-40KB 的 RAM。如果 MCU 只有 64KB RAM，留给系统其他任务（传感器驱动、通信协议栈）的空间就非常紧张。这迫使健康评分系统采用流式处理而非批量处理：每次只缓存一小段窗口数据（如 64 个采样点），推理完成后立即释放内存。
算力约束：MCU 的 CPU 通常没有浮点单元（FPU），即使有，频率也有限。一次 int8 卷积运算可能需要数百微秒到数毫秒。假设一个健康评分模型每次推理需要 50ms，那么每秒最多只能执行 20 次推理。对于振动监测这类需要高频采样的场景（如 10kHz 采样率），不可能对每个采样点都做推理，只能采用滑动窗口 + 间隔推理策略：每采集 256 个点（约 25.6ms）做一次推理，然后休眠。
功耗约束：MCU 的功耗通常在 1mW 到 100mW 之间，具体取决于工作频率和外设状态。对于电池供电的设备（如无线传感器节点），功耗预算直接决定了设备寿命。假设一颗 500mAh 的纽扣电池，平均工作电流为 5mA，理论寿命约 100 小时。如果健康评分系统要求每 10 秒推理一次，每次推理消耗 20mA 电流持续 50ms，那么推理功耗占比仅为 0.01%，几乎可以忽略；但如果推理频率提高到每秒一次，功耗占比将升至 10%，显著缩短电池寿命。
这三重约束对健康评分映射的直接影响是：评分更新频率必须与推理频率匹配。如果模型每 10 秒才输出一次结果，那么健康评分就不应该设计成毫秒级实时变化的指标，而应该采用滑动平均或指数加权移动平均（EWMA）来平滑输出，避免评分剧烈抖动。同时，评分系统需要设计“降级模式”：当电池电量低或 CPU 负载过高时，自动降低推理频率，并相应调整评分的置信度。
2.4 案例拆解：振动监测设备健康评分的资源适配
我们以一个实际的工业电机振动监测项目为例，说明资源约束如何塑造健康评分方案。
背景与约束：某工厂需要在 20 台电机上部署无线振动传感器，每台电机配备一颗 STM32L4 系列 MCU（Cortex-M4 @ 80MHz，128KB RAM，1MB Flash），通过 BLE 将健康评分上报到网关。电池容量为 1000mAh，要求设备至少运行 6 个月。振动采样率为 4kHz，每个采样点 16 位。
初始方案与问题：团队最初计划部署一个在 PC 上训练好的 2D CNN 模型（输入为 128×128 的时频图），但发现模型转换后权重高达 800KB，超出 Flash 空间；且推理时需要 60KB 的中间激活内存，导致 RAM 不足。更严重的是，生成一张时频图需要采集 1 秒的振动数据（4000 个采样点），在 MCU 上做 FFT 和频谱图拼接需要约 200ms，功耗过高。
分析判断过程：团队重新审视了健康评分的业务目标——只需要区分“正常、轻微磨损、严重故障”三个等级，并给出一个 0-100 的置信度分数。于是决定放弃复杂的 2D CNN，改用 1D 时序特征 + 决策树集成模型。具体步骤如下：
- 特征压缩：不再使用完整时频图，而是提取 6 个统计特征（RMS、峰值因子、峭度、波形因子、脉冲因子、裕度因子），每个特征仅需 4 字节 float，总计 24 字节。
- 模型轻量化：使用 3 棵深度为 4 的决策树（总参数量约 1.2KB），通过 int8 量化后仅占 600 字节 Flash，推理时 RAM 占用不到 2KB。
- 推理调度：每 10 秒采集一次 256 点窗口（64ms），计算特征后执行推理（约 3ms），然后进入低功耗模式。平均工作电流从 15mA 降至 3mA。
- 评分映射：决策树输出三个类别的概率，通过加权公式映射为健康分：
score = 100 - (0.6 × P_fault + 0.3 × P_wear + 0.1 × P_normal)，其中 P_fault 为严重故障概率。
结果对比：部署后，模型 Flash 占用从 800KB 降至 1.2KB，RAM 占用从 60KB 降至 4KB，单次推理时间从 200ms 降至 3ms。电池寿命从预估的 2 个月延长至 8 个月，满足 6 个月的要求。健康评分与人工巡检结果的吻合率达到 87%，虽然低于原 2D CNN 在 PC 上的 94% 准确率，但在 MCU 约束下已经达到可接受水平。
风险与代价：简化模型对高频冲击信号的敏感度下降，早期点蚀故障的检出率降低了约 12%。团队通过增加一个简单的阈值检测器（当峭度 > 5 时直接触发告警）来弥补这一缺陷，代价是增加了约 200 字节的代码和 0.5ms 的额外计算。
经验复盘：在 TinyML 健康评分项目中，“先定资源预算，再选模型复杂度”是铁律。不要先追求模型精度，再试图压缩；而应该先测量 MCU 的空闲 RAM、Flash 和可接受的推理延迟，然后反推模型的最大参数量和算子类型。同时，评分映射函数的设计必须考虑模型输出的不确定性——当模型置信度低时，评分应趋向保守（如向 50 分靠拢），而不是给出极端值。
2.5 常见误区与总结复盘
在 TinyML 健康评分系统的设计中，以下误区需要特别警惕：
- 误区一：忽视量化校准。直接使用训练时的 float32 权重做 int8 量化，没有使用代表性数据集进行校准，导致评分输出偏移。正确做法是使用设备实际采集的传感器数据作为校准集，并验证量化前后评分分布的差异。
- 误区二：内存池“差不多就行”。随意设置 tensor arena 大小，导致推理时内存溢出或初始化失败。应使用框架提供的工具精确计算，并预留 10%-20% 的余量。
- 误区三：评分映射过于线性。直接将模型输出概率线性映射到 0-100 分，忽略了概率分布的非线性。例如，当模型输出 P_fault=0.4 时，实际故障风险可能已经很高，应使用 sigmoid 或分段函数进行非线性映射。
- 误区四：忽略功耗与评分的耦合。为了追求评分实时性而提高推理频率，导致电池快速耗尽，最终评分系统因断电而完全失效。应设计动态推理频率调节机制，根据剩余电量和设备状态自动调整。