推理服务的灰度与模型热更新：不停机的模型迭代

模型迭代的独有难题：不止是「换个代码」

传统服务的发布是「换个代码」——模型服务的发布是「换个大脑」，多了三个独有难题。难题一：状态在内存里。推理服务的 KV Cache、会话状态在内存中——切换进程 = 所有进行中的会话中断（用户聊到一半的服务重启——体验断裂）。难题二：流式响应的完整性。长回答的流式输出进行中切换——输出被截断。难题三：新旧模型的并存在所难免。灰度验证要求新旧模型同时服务（A/B 对比）——两个几十 GB 的模型同时占显存——显存的账要重新算。四种发布模式对应这些难题的不同解法。

模式一：蓝绿切换与排空（drain）——最稳的基线

蓝绿切换：新旧两组推理副本（蓝=现行、绿=新模型），流量整体切到绿、蓝排空退役。排空（drain）机制是关键工程：切换时停止向蓝副本派发新请求、但已接受的请求继续处理完（进行中的流式输出完整结束）——排空完成（队列清零）后蓝副本才下线。实现：网关层的摘流（健康检查摘除——本库惊群篇的摘流纪律）+ 推理引擎的 graceful shutdown（等活跃请求完成）。蓝绿的成本：双倍的显存与算力（新旧同时在线）——对大模型服务是昂贵的切换（两张 8 卡机同时在线）。适用：大版本更新、需要快速回滚的发布（蓝副本保留，回滚就是切回流量）。

模式二：流量灰度——按比例与按用户的渐进

灰度发布：新旧模型按比例同时服务（5% → 20% → 50% → 100%）——渐进验证而非一次性切换。灰度的维度选择：按比例随机（统计意义上的 A/B）、按用户分桶（同一用户始终同一版本——体验一致性）、按请求特征（特定场景的流量走新模型——定向灰度）。灰度的观测：新旧版本的核心指标对比（回答质量的人工抽评、延迟与吞吐、错误率、以及业务的下游指标——灰度不只是技术验证，是产品验证）。灰度的显存成本：新旧并存同样占双倍显存——灰度期用小流量的新副本（新模型 1 个副本承接 5% 流量——显存的增量可控）。模式与蓝绿的组合：灰度验证通过后，最终仍以蓝绿完成全量切换——灰度管验证、蓝绿管切换。

模式三：模型热更新——同一进程内的权重替换

热更新：不重启进程，在运行的推理引擎里替换模型权重——vLLM 的 sleep/wake 与权重更新接口、TensorRT-LLM 的引擎重载。热更新的机制与限制：同架构模型的权重替换可行（同结构、同分词器——权重形状必须匹配）、新架构模型必须重启进程；热更新时进行中的请求的处理策略（等队列清空再换、或新旧权重并存分批切换——引擎实现各异）。热更新的适用边界：同架构的微调模型迭代（RLHF 的新 checkpoint、领域微调的更新——同一基座的衍生物）适合热更新；基座模型的换代（架构变了、分词器变了）必须走蓝绿。热更新的独有风险：进程内状态的残留（旧模型的 KV 会话在权重替换后语义不一致——会话必须清空或迁移）——热更新省了重启，但状态的迁移责任仍在工程侧。

模式四：多模型并存与路由——灰度的终极形态

多模型并存 + 智能路由：同一网关后面挂多个版本的模型副本，路由层按策略分发（灰度比例、用户分桶、任务类型）——路由层成为模型迭代的控制面。架构的要点：模型的版本路由（请求头携带版本偏好或网关按策略路由）、成本的视角（多版本并存的显存成本随版本数线性增长——并存版本的数量要有上限、淘汰机制要自动化）、以及评测的联动（灰度版本的线上指标回流到评测体系——本库评测篇的影子评测）。收束：四种模式不是互斥的，是模型生命周期的不同阶段：微调迭代用热更新 → 新版本灰度验证（并存路由）→ 验证通过蓝绿全量 → 旧版本排空退役。模型发布的工程成熟度 = 为每种迭代形态选对发布模式的能力。

模型发布的评测联动：灰度期间的线上质量验证

模型发布（正文灰度）的评测联动：灰度期间的线上质量验证——灰度不只是流量的分配，是质量的验证流程。灰度的评测设计。对照组的建立（新旧版本的流量对比——本库影子评测的灰度版：同一请求新旧模型的产出对比）、对比的维度（回答质量的人工抽评——灰度期的人工抽评是质检的核心：每版本抽 N 条人工评分、延迟与吞吐的分位数对比、错误率的对比）、业务指标的联动（灰度版本的业务指标——满意度、任务完成率——技术指标全绿但业务指标跌 = 必须停的信号）。灰度的决策机制。推进/回滚的判据（预定义的判据：抽评分数不降 + 延迟不超 + 错误率不升 → 推进；任一恶化 → 回滚——判据在灰度开始前定义，不要灰度中拍脑袋）、灰度的节奏（5% → 20% → 50% → 100% 的阶梯，每步的停留时间足够收集数据）、以及紧急回滚的演练（回滚的流程要演练——回滚是灰度的安全带，安全带要试）。灰度的组织面：灰度的责任人（谁看数据、谁拍板）、灰度的日志与报告（每个阶段的对比报告——灰度的决策要有据可查）。评测联动的收束：灰度是「线上评测」的黄金窗口——真实流量、真实用户、新旧对照——灰度的评测数据，比任何线下评测都更接近真相；用好灰度窗口的评测，模型的迭代质量才有闭环。

模型发布的成本视角：双倍显存的账与优化的组合

模型发布（正文蓝绿）的成本视角：发布期间的显存账与优化的组合拳。发布期的显存账。蓝绿的账：新旧两组副本同时在线（双倍的显存与算力——切换窗口的成本）；灰度的账：新版本的小流量副本（增量可控——灰度比蓝绿的显存账友好）。优化组合一：权重的共享。新旧版本同基座的场景：基座权重共享（RLHF 的新 checkpoint 与旧 checkpoint 共享基座——LoRA 的场景显存增量极小：LoRA 权重是 MB 级——LoRA 模型的灰度成本几乎为零——本库 LoRA 篇的工程优势在发布环节的体现）。优化组合二：副本的复用。引擎的多模型并存（vLLM 的多模型服务——同一引擎托管新旧两版，显存的分时复用）。优化组合三：切换窗口的错峰。低谷期的切换（流量的低谷做切换——双倍显存的窗口放在低谷——切换时机本身就是成本优化的变量）。成本视角的收束：模型发布的显存账，是「模型迭代频率」与「算力预算」的交汇点——LoRA 的低成本灰度、蓝绿的窗口错峰、引擎的多模型并存，是三种把发布成本压下来的工具；发布的成本要纳入「模型迭代频率」的决策（发得太勤，发布成本本身成为大头）。

模型发布的进阶：多模型的并存管理与淘汰

模型发布（正文四模式）的进阶：多模型的并存管理与淘汰——多个版本模型共存的管理体系。多版本并存的管理。版本的注册（当前在线的模型版本清单——每个版本的流量占比、成本、质量指标）、版本的生命周期（灰度中 → 稳定 → 过时 → 下线——每个版本的阶段管理）、以及并存的成本（多版本显存的叠加——并存版本的数量上限：显存的预算决定并存的版本数）。淘汰的机制。旧版本的下线（流量的迁移：旧版本的流量逐步切到新版本——渐进的下线而非一刀切）、回滚的预案（新版本出问题的回滚路径——旧版本的下线时间要在回滚窗口之后）、以及归档的机制（下线版本的归档——模型不是删除，是归档：随时可以拉回来）。收束：多版本并存的管理，是推理服务「模型生命周期管理」的核心——版本从灰度到退役的每个阶段都有对应的资源、流量与监控策略——生命周期管理做好了，模型的迭代才不会变成运维的噩梦。

模型发布的灰度评测

模型发布的灰度评测：线上 A/B 的设计。A/B 设计：对照组的建立（新旧版本的流量分组——同流量对照组、用户分桶——同一用户始终同一版本保证体验一致）、指标采集（新旧版本各自的指标：质量抽评、延迟、错误率）。对比维度：回答质量对比（人工抽评分数——灰度期人工抽评是质检核心）、延迟吞吐对比（新旧模型性能差异——性能回退是灰度重要观察项）、业务指标对比（满意度任务完成率——技术全绿但业务跌必须停）。A/B 时长与样本量：统计显著性要求（样本量要够——5% 灰度跑一周数据才够显著）、灰度节奏（5% 到 20% 到 50% 到 100%，每步停留时间足够收集数据）。灰度 A/B 收束：灰度是线上评测黄金窗口——真实流量真实用户新旧对照——灰度评测数据比线下评测更接近真相。

小结

模型服务的发布有四种模式：蓝绿 + 排空（最稳、双倍算力）、流量灰度（渐进验证、按用户分桶保体验）、热更新（同架构权重替换、会话状态要处理）、多模型并存路由（灰度的终极形态、显存成本管理）。切换的独有难题（内存中的 KV 会话、流式输出、显存的并存）决定了「排空机制」与「会话迁移」是工程重心。模型发布不是部署问题，是「大脑的手术」——每种模式对应一种手术方式，选对方式取决于迭代的大小与风险容忍度。