TinyML模型部署最佳实践：日志与监控去年夏天，我在一个电池供电的振动监测节点上栽了个大跟头。设备部署在化工厂的管道上，三天后运维反馈说“设备没死，但数据全是零”。我远程连上去一看，模型推理正常，传感器读数正常，但输出结果被一个悄无声息的数值溢出给吞掉了——模型输出的softmax概率在特定工况下会略大于1.0，而我的后处理代码直接做了个if (prob 0.5)的判断，没做钳位。这个bug在实验室跑了两个月都没复现，因为实验室的振动台永远给不出那种极端工况。从那以后，我养成了一个习惯：任何部署到现场的TinyML设备，日志和监控系统必须在一开始就设计好，而不是等出问题了再补。嵌入式资源有限，但恰恰因为资源有限，你才更需要知道那点资源到底用在了哪里。日志系统的“瘦身”哲学MCU上的日志和服务器上的日志完全是两码事。你不能指望一个只有64KB Flash、8KB RAM的Cortex-M0芯片跑什么ELK栈。但反过来，你也不能因为资源紧张就只留一个printf——现场设备一旦封箱，串口线就拔掉了，你printf给谁看？我现在的做法是分层日志，按严重程度和存储介质分开处理：#define LOG_LEVEL_NONE 0 #define LOG_LEVEL_ERROR 1 #define LOG_LEVEL_WARN 2 #define LOG_LEVEL_INFO 3 #define LOG_LEVEL_DEB
TinyML模型部署最佳实践：日志与监控去年夏天，我在一个电池供电的振动监测节点上栽了个大跟头。设备部署在化工厂的管道上，三天后运维反馈说“设备没死，但数据全是零”。我远程连上去一看，模型推理正常，传感器读数正常，但输出结果被一个悄无声息的数值溢出给吞掉了——模型输出的softmax概率在特定工况下会略大于1.0，而我的后处理代码直接做了个if (prob 0.5)的判断，没做钳位。这个bug在实验室跑了两个月都没复现，因为实验室的振动台永远给不出那种极端工况。从那以后，我养成了一个习惯：任何部署到现场的TinyML设备，日志和监控系统必须在一开始就设计好，而不是等出问题了再补。嵌入式资源有限，但恰恰因为资源有限，你才更需要知道那点资源到底用在了哪里。日志系统的“瘦身”哲学MCU上的日志和服务器上的日志完全是两码事。你不能指望一个只有64KB Flash、8KB RAM的Cortex-M0芯片跑什么ELK栈。但反过来，你也不能因为资源紧张就只留一个printf——现场设备一旦封箱，串口线就拔掉了，你printf给谁看？我现在的做法是分层日志，按严重程度和存储介质分开处理：#define LOG_LEVEL_NONE 0 #define LOG_LEVEL_ERROR 1 #define LOG_LEVEL_WARN 2 #define LOG_LEVEL_INFO 3 #define LOG_LEVEL_DEB
)
