边缘计算AI更新要有灰度和回滚

端侧模型更新一旦出错，现场通常没有太多容错时间。边缘计算里的 AI 更新，不能只看“能不能推上去”，还要看“推错了能不能退回来”。

模型灰度发布的目的，是把风险分散到少量节点上先观察。先给一小部分边缘设备加载新版本，可以在不影响全网的情况下检查精度、时延和资源占用是否变化。问题在于，灰度样本如果只覆盖了网络好、环境稳的设备，真正高风险的现场可能根本没参与测试。边缘计算里的灰度，只有覆盖不同硬件批次、不同场景和不同供电条件，才算真正有意义。

回滚标志位则决定出错后能否快速恢复。新模型上线后，应先处于试运行状态，只有连续通过健康检查、关键样本回归和本地告警门限，才能把标志位写成正式。如果设备在写标志时突然掉电，状态就可能卡在半升级。双版本存储可以缓解这个问题，但也要防止旧版本被覆盖得太早。回滚标志还要和端侧校验包绑定，避免模型回去了，配置阈值却还停留在新版本。

灰度指标要同时看精度和资源。新模型可能识别更准，却把推理时间、内存峰值或温度推高；在低端节点上，这种资源变化会比精度变化更早造成故障。灰度期间应记录低置信比例、误报率、平均时延、最坏时延和回滚次数，并按设备型号分组分析。若只汇总全网平均，少数高风险现场会被淹没。

回滚也不能只回模型文件。预处理参数、量化尺度、阈值配置和后处理逻辑都可能与模型版本绑定；如果只把模型切回旧版本，配置仍停留在新版本，输出会出现难以定位的偏差。更可靠的做法，是让模型包、配置包和校验清单作为一个原子版本进入 A/B 槽，试运行失败时整套回退。

更稳妥的做法，是把在线热更新和失效保护分开。热更新负责提高迭代速度，失效保护负责在新模型异常时立即切回旧版本并限制输出动作。样本漂移监控应持续跟着上线版本跑，观察是否出现误报升高或延迟变长。若出现问题，应优先判断是模型本身失配，还是现场数据分布已经变了。

更新窗口也要受控。设备正在执行关键任务时，不应直接替换模型；否则一次加载抖动或缓存重建就可能影响实时输出。可以先把新模型下载到备用槽，在低负载窗口完成校验和预热，再切换推理入口。若切换后首批结果异常，应自动回退，并保留新旧模型对同一输入的差异摘要，便于定位问题。

灰度还要防止版本碎片长期存在。少量节点试运行是必要的，但如果多个版本长期混跑，中心平台很难解释不同节点的输出差异。应给灰度设置明确的观察周期、晋级条件和回退条件；超过周期仍无法确认的新版本，应暂停扩散，而不是让现场设备各自停在不同阶段。

端侧更新还要处理离线节点。离线设备可能错过多个版本，重新上线时不能直接跨越所有中间状态；升级服务应先检查兼容窗口，必要时按阶段补齐运行时和模型包。否则回滚链会断，现场只剩无法解释的版本组合。

因此，更新策略不是能不能发，而是发出去后有没有退路。边缘计算上的 AI 更新，灰度是前门，回滚是后门，两者都得通。