嵌入式AI升级为何翻车？模型怎么回滚？

模型升级不像替换一份普通资源，因为它同时改动推理图、预处理和判定阈值。嵌入式AI若没有把版本依赖和回滚状态写清，一次在线更新就可能让设备保持可启动却不可用。

升级翻车首先出在格式兼容被低估。模型文件、运行时库、算子插件、量化参数和后处理脚本必须匹配，少任何一项都可能让推理结果偏掉。比如新模型使用了旧固件不支持的算子，系统可能在加载时失败；更隐蔽的是加载成功但回退到 CPU，导致控制周期超时。若前处理的归一化均值、输入尺寸或颜色顺序随模型变化，却没有跟模型一起发布，输出分数会系统性偏移，现场看起来像精度突然坏掉。

因此，模型包需要带完整清单，而不是只放一个二进制。清单至少应描述输入输出张量、量化尺度、需要的运行时版本、后处理阈值和校验哈希；设备升级前要先做能力检查，确认固件支持这些约束。嵌入式AI设备如果允许模型和固件独立升级，还要规定最低兼容版本，避免旧固件加载新模型后进入半可用状态。

回滚机制则要把模型当成可启动组件管理。单槽覆盖写入风险很高，掉电或下载中断会让旧模型被破坏，新模型又不完整；即使文件完整，新模型首次运行也可能因内存峰值、延迟超限或误检率过高而不适合现场。A/B 模型槽可以把下载、校验、试运行和提交分开：新模型先写入备用槽，校验通过后标为试运行，只有连续通过健康检查和关键场景验证后才切换为正式槽。

试运行判据不能只看能否加载。设备应记录推理耗时、异常返回、低置信比例和关键动作触发率，如果这些指标偏离旧模型基线，就自动回到上一槽。回滚标志位要掉电可恢复，并且与模型包签名、版本号和配置参数一起绑定，不能让攻击者或误操作把设备回退到有漏洞的旧模型。必要时，模型配置也应跟随槽位保存，避免模型回滚了而阈值仍停留在新版本。

灰度策略还要贴近设备差异。同一型号在不同传感器批次、安装角度和现场网络条件下，升级风险并不相同；若只按在线率随机抽样，首批灰度可能刚好避开高风险工况。更合理的做法，是按硬件版本、固件版本、场景类型和历史误报率分层放量，并在每层设置独立暂停条件。这样发现问题时可以收缩到具体群组，而不是全量回退。

验证升级流程时，应主动在下载、校验、首次加载、首次推理和提交成功前后断电，确认每个断点都能解释当前状态。很多方案只测网络正常时的升级，忽略了弱网、存储写满、证书过期和运行时能力不足这些更常见的失败路径。还应模拟配置包先到、模型包后到的乱序情况，防止版本依赖被拆散，并确认失败日志不会覆盖回滚状态。只有失败路径能被旧模型接管，在线更新才不会把现场设备变成不可诊断状态。

所以，模型升级的核心不是把文件传过去，而是让设备始终知道哪一套模型可信。把兼容清单和双槽回滚做实，嵌入式AI才敢持续迭代。