TinyML模型训练最佳实践:自动化MLOps昨晚调试一块STM32U5的板子,发现部署上去的模型推理结果全乱套了。翻看训练日志,才发现训练脚本里有个随机种子没固定,每次跑出来的权重都不一样。这种问题在TinyML里太常见了——模型小,但坑一点不少。从一次“模型漂移”说起上周有个项目,传感器采集的数据在开发板上跑得好好的,换到另一批硬件上就崩了。查了两天,发现是训练时用的数据增强参数和实际部署环境不匹配。更糟的是,训练脚本是同事半年前写的,没人记得当时用了哪些预处理步骤。这就是TinyML的典型困境:模型小到可以在MCU上跑,但训练流程的复杂度一点没减。MLOps在云端大模型里已经成熟了,但在嵌入式领域,很多人还在“手工炼丹”。数据版本控制:别让数据成为黑箱我见过最离谱的情况:一个团队用同一个数据集训练了三个月,结果发现数据被多次覆盖,不同版本的标签还不一致。在TinyML里,数据量本来就少,每一份样本都珍贵。DVC(Data Version Control)是个好工具,但别把它当Git用。我习惯在项目根目录建一个data/文件夹,里面按日期和版本号命名子目录:data/ ├── 2024-01-15_v1.0/ │ ├── raw/ │ ├── processed/ │ └── metadata.yaml └── 2024-02-20_v2.0/ └── ...每个版
161、TinyML模型训练最佳实践:自动化MLOps
TinyML模型训练最佳实践:自动化MLOps昨晚调试一块STM32U5的板子,发现部署上去的模型推理结果全乱套了。翻看训练日志,才发现训练脚本里有个随机种子没固定,每次跑出来的权重都不一样。这种问题在TinyML里太常见了——模型小,但坑一点不少。从一次“模型漂移”说起上周有个项目,传感器采集的数据在开发板上跑得好好的,换到另一批硬件上就崩了。查了两天,发现是训练时用的数据增强参数和实际部署环境不匹配。更糟的是,训练脚本是同事半年前写的,没人记得当时用了哪些预处理步骤。这就是TinyML的典型困境:模型小到可以在MCU上跑,但训练流程的复杂度一点没减。MLOps在云端大模型里已经成熟了,但在嵌入式领域,很多人还在“手工炼丹”。数据版本控制:别让数据成为黑箱我见过最离谱的情况:一个团队用同一个数据集训练了三个月,结果发现数据被多次覆盖,不同版本的标签还不一致。在TinyML里,数据量本来就少,每一份样本都珍贵。DVC(Data Version Control)是个好工具,但别把它当Git用。我习惯在项目根目录建一个data/文件夹,里面按日期和版本号命名子目录:data/ ├── 2024-01-15_v1.0/ │ ├── raw/ │ ├── processed/ │ └── metadata.yaml └── 2024-02-20_v2.0/ └── ...每个版