热更新要解决的核心矛盾
模型需要不断升级，但服务不能停。热更新就是在不中断服务的情况下，把正在运行的模型替换成新版本，让用户无感知地完成切换。对 AI 服务而言，这个需求比普通软件更迫切：大模型迭代频繁，每次停机升级都意味着用户请求被拒，损失的是真实流量和体验。一个面向大量用户的助手类产品，哪怕只停几分钟，累积的失败请求也可能是一个不小的数字。
为什么 AI 的热更新更难
普通服务换版本只是重启进程，AI 服务却要面对四类资源特性：模型加载慢，大模型加载到显存可能要几十秒甚至几分钟；显存吃紧，新旧两套同时存在时显存可能不够；长请求，一次生成可能要几十秒，中途切换会打断；状态难迁移，正在进行的对话上下文怎么处理。这四点是 AI 热更新区别于传统发布的关键。其中长请求和状态难迁移最棘手：一次生成可能跑几十秒，切换时机选不好，就会打断用户正在等待的回答。
三种切换策略
工程上常用三类策略。蓝绿部署：同时准备新旧两套环境，切流量过去，出问题再切回来。滚动更新：逐台替换，旧的一批下线、新的一批上线。金丝雀发布：先把少量流量切到新版本，观察没问题再全量。三者的差异可以用表对照。
| 策略 | 核心动作 | 出问题时的处理 |
|---|---|---|
| 蓝绿部署 | 新旧两套并存，一次性切流量 | 切回旧环境，回滚快 |
| 滚动更新 | 逐台替换实例 | 停止替换，回退已更新的实例 |
| 金丝雀发布 | 先切少量流量到新版 | 发现异常立即撤回新流量 |
选择哪种策略，取决于团队对回滚速度和资源成本的取舍：蓝绿回滚快但最占资源，滚动更新省资源但回滚要逐台处理，金丝雀发布适合风险较高的新模型。
四个配套动作
光有切换策略还不够，热更新需要四件事配合。预热：新模型先加载好、跑几个测试请求，再切流量。优雅下线：旧实例先停止接收新请求，等已有请求跑完再关。快速回滚：发现新版本有问题时能立刻切回旧版本。灰度验证：先切少量流量，确认效果和稳定性。缺了任何一环，热更新都可能变成"热事故"。举个例子：没有预热就把流量切过去，新模型还在加载，请求就会堆积超时；没有优雅下线，正在生成的长回答就会中断。
热更新做不到什么
热更新解决的是"不停机换模型"，但它无法确保新模型一定更好。如果新模型本身效果差或引入新问题，热更新只是把它更快地推上线。此外，热更新依赖新旧模型接口兼容：如果新版本的输入输出格式变了，切换时仍可能打断请求。它还无法解决显存不足的硬约束——新旧两套并存时，如果显存不够，只能先做模型量化或切分来腾空间，这些手段与热更新配合使用才有意义。所以热更新是一套组合动作，任何一个环节掉链子，都会让"不停机"的目标落空。
对普通用户意味着什么
你感受到的往往是：AI 服务的升级悄悄发生——没有停机公告，某天突然发现它变强了，或者回答风格变了。这背后就是热更新在起作用。理解这一点，能帮你判断"服务变了"和"服务坏了"的区别。热更新做得好的产品，升级往往悄无声息；做得不好，就会表现为卡顿、报错或回答中断。想了解新旧模型怎么对比，可以看什么是模型 A/B；想知道模型文件里装的是什么，可以看什么是模型权重文件；如果显存不够需要瘦身，可以对照什么是模型量化和什么是模型切分。
速查：热更新的四个配套动作
- 预热：新模型先加载好再切流量
- 优雅下线：旧实例跑完已有请求再关
- 快速回滚：出问题能立刻切回旧版
- 灰度验证：先切少量流量确认稳定
