157、TinyML模型训练最佳实践：联邦学习

157 TinyML模型训练最佳实践：联邦学习

上周调试一个智能门锁的唤醒词模型，客户反馈说用户数据不能出设备，但模型又需要持续优化。我盯着示波器上跳动的I2C信号，突然意识到——这不就是联邦学习最典型的落地场景吗？数据主权和模型迭代之间的矛盾，在嵌入式端比云端尖锐十倍。

从一次失败的聚合说起

先讲个真实翻车案例。去年给一批温湿度传感器做联邦学习，每个节点采集本地数据训练小模型，服务器端做参数聚合。第一轮聚合后，模型准确率从82%直接掉到53%。排查了三天，发现是某个节点的传感器坏了，持续输出异常值，本地模型学了一堆噪声，聚合时把整个模型带偏了。

这个教训让我明白：联邦学习在TinyML场景下，数据异构性不是理论问题，是工程灾难。云端联邦学习可以容忍10%-20%的异常节点，嵌入式端只要有一个节点出问题，整个模型就崩。

联邦学习在MCU上的三个核心约束

1. 通信开销是命门

Wi-Fi模块发一次模型参数，耗电够MCU跑100次推理。我见过最极端的方案——用LoRa传模型梯度，一次同步要等45秒。解决方案是梯度压缩：只传Top-K梯度，或者用量化感知训练把32位浮点压到8位整型。实测在STM32F4上，8位量化后通信量减少75%，精度损失不到1%。

2. 本地训练不能太贪心

别想着在MCU上跑完整训练流程。我踩过的坑：在ESP32上跑ResNet-18的联