端侧设备的模型更新机制：怎么升级才不影响在跑的业务

端侧设备上跑的模型需要更新，但设备同时在处理业务。直接停服替换的方式在现场通常不可行。可行的更新机制要解决三件事：怎么传、怎么切、出问题怎么退。三件事的设计方式决定了更新的影响范围。

分发要支持分批与断点

更新包的分发受现场网络条件限制。厂区与中心之间的带宽有限，设备可能处在不稳定网络中，分发过程需要能容忍中断。

可行的做法是分批推进。先选择少量设备作为试验批，观察一段时间确认无异常，再逐步扩大范围。分批的粒度可以按厂区、按设备型号或按业务重要程度划分。

断点续传同样必要。分发中断后从已完成的进度继续，而不是重新开始。对于体积较大的模型文件，这一点直接影响更新窗口的长短。

分发还应当支持暂停。发现异常时可以立即停止，尚未更新的设备不受影响。没有暂停能力的机制，一旦开始就只能等它跑完。

切换要尽量不中断任务

模型替换的方式决定了业务受影响的程度。常见做法有三种。

一是停机切换，简单直接，但要求有可用的停机窗口。对连续性要求不高的场景，这仍然是成本最低的方式。

二是双份部署，新旧模型同时存在，通过切换引用生效。切换过程是秒级的，业务中断可以忽略，代价是占用双份存储与内存。

三是在处理边界切换。等当前任务处理完成后再加载新模型，新任务使用新版本。这种方式对业务无感，但实现复杂度较高。

选择哪种方式取决于业务连续性要求与设备资源，而不是一律追求最平滑的方案。

回退要能远程完成

更新之后发现问题，回退路径必须可用。回退要求与更新本身相同：不需要人到现场，不需要重新配置。

实现回退的前提是旧版本仍然保留。这要求存储空间提前规划，而不是在更新时覆盖旧版本。配置与模型分开管理，回退模型时配置不受影响。

回退的触发条件也需要事先约定。什么情况下判定为异常、由谁决定回退、回退后如何验证，这些内容应当写进操作流程，而不是等到问题时临时判断。

回退动作要留下记录，包括时间、范围与原因，供后续分析更新策略是否需要调整。