模型迭代越来越快，推理服务却不能跟着频繁重启：一次重启意味着所有进行中的请求被掐断、缓存清空、冷启动的几分钟服务降级。热更新的目标是：用户无感知，请求不中断，新版本平滑接管。

一、权重热加载：在进程内换掉模型

最轻量的方案是在同一个推理进程内热加载新权重：先把新权重加载到显存的空闲区域，校验通过后再原子切换指针，旧权重的显存随后释放。这种方式切换速度最快，但约束也最多：要求新旧模型结构完全一致，只是权重不同，且切换瞬间需要双倍显存，至少是权重部分的双倍。工程上要注意两点：加载过程不能阻塞正在服务的请求，一般用后台线程分块加载；切换点要选在请求边界，不能在一次解码中途换权重，否则会出现一句话前半段一个模型、后半段另一个模型的诡异输出。

二、双实例切换：蓝绿部署的推理版

更通用的方案是蓝绿部署：拉起一组加载了新模型的新实例，通过健康检查确认就绪后，把流量逐步切过去，旧实例排空后下线。优点是新旧模型可以是完全不同的结构，比如架构升级，隔离性好，出问题回滚就是切流量的事。代价是切换期间需要双倍资源。流量切换建议用加权路由逐步放量，而不是一次性全切，给监控留出反应时间。

三、流量排空：别杀掉正在说话的请求

无论哪种方案，排空都是热更新成败的关键。标准流程：先把实例从服务发现里摘掉，不再接收新请求；然后等待进行中的请求自然结束，设一个上限超时，比如最长等待几分钟；超时后还剩的长尾请求做优雅中断并返回可重试的错误码。排空期间要密切看两个指标：剩余进行中请求数是否在下降，以及新实例的错误率是否正常。

四、版本一致性校验：确保线上跑的真是你想的那个版本

热更新最危险的故障不是失败，而是静默跑错版本：流量切过去了，但某台实例还在跑旧权重。防范手段有三层：每个模型版本打唯一的版本指纹，即权重哈希，实例启动或热加载后上报指纹，网关按指纹做流量路由和监控；发布系统在切流量前全量核对各实例指纹，不一致的实例不参与接流量；监控大盘上同时看各版本实例数和各版本请求占比，两者对不上立刻告警。

热更新做得好，模型迭代就从深夜停机发布变成白天随时可发的日常操作。