大模型服务的优雅退出与热更新-不停机发版的工程细节

小助手

37人浏览 · 2026-11-03 08:37:35

小助手 · 2026-11-03 08:37:35 发布

文章目录

摘要

推理服务发版最怕两件事：请求被硬生生掐断、以及新版本上线后显存没清干净导致雪崩。优雅退出看起来只是处理一个信号，真做起来涉及连接 draining、长连接的会话收尾、健康检查摘除顺序、以及预热与回滚的编排。本文按真实发版流程拆开讲这五步，并给出长时任务场景下的特殊处理。2026 奇点智能技术大会（11 月 20-21 日·北京万达文华酒店）AI Infra 与 AgenticOps 专题会涉及这类运维工程。

▸ 核心结论：不停机发版的成败在顺序：先摘流量，再等存量请求结束，最后才退进程；顺序错了必然有损
▸ 关键权衡：draining 时间越长越安全但发布越慢；要按请求时长分布定一个明确上限并配合强制终止
▸ 适合谁读：做推理平台、在线服务与运维的工程同学——经历过「发版即报警」的人

优雅退出
  场景    一     为什么大模型服务更难停
  摘流    二     先从负载均衡摘掉
  收尾    三     存量请求怎么等
  退出    四     进程退出的最后一公里
  热更    五     热更新与预热
  回滚    六     回滚要比发布更快
  长任务  七     长时任务的特殊处理
  落地    八     清单与衔接大会

一、为什么大模型服务更难停

9 月 25 日起 GitHub Copilot 把 Agent 能力改成按额度计费，Agent 任务从「几秒的补全」变成「几十分钟的长任务」。长任务一旦跑起来就不能随便被打断，这对服务的发版方式提出了新要求：你不能再假设所有请求都能在几十秒内结束。本文讲的就是这个前提下的不停机发版怎么做的。

普通无状态服务的请求是毫秒级到秒级，摘流后等几秒就能安全退出。大模型推理不一样：单次请求可能几十秒甚至更长，多轮会话有状态、KV Cache 在显存里，Agent 类任务甚至能跑十几分钟。这意味着两件事：draining 的等待时间要按分钟计，而不是秒；进程退出前必须显式释放 GPU 资源，否则驱动层的清理可能滞后于新进程启动，导致显存不足。再加上模型加载本身要几分钟，一次「快速发版」的真实耗时远超预期。

二、先从负载均衡摘掉

第一步永远是摘流量，但细节容易做错：

摘除要有确认：向负载均衡或注册中心发起下线后，要等到确认生效再进入下一步，不能假设立即生效。
健康检查与摘除要区分：健康检查失败会让上游立即停止转发，但它同时可能触发自动重启逻辑，把正在退出的实例又拉起来。
长连接要主动通知：已经建立的 SSE 或 WebSocket 连接不会因为摘除而断开，需要服务端主动发结束信号。
摘除后要有静默期：等上游的连接池与缓存刷新，通常几秒到几十秒，视探测间隔而定。

这一步的顺序错误是「发版即报警」最常见的原因：进程已经开始退出了，上游还在往里打新请求。

发布窗口的选择也值得讲究。很多团队习惯在深夜发布，觉得影响小，但深夜往往是批处理、定时任务、跨时区用户的活跃期，反而容易出问题。更合理的做法是按本服务的真实流量曲线选低谷，并且避开上下游的发布窗口。发布协调这件事在微服务多的时候尤其重要——三个服务同时发布，互相的 draining 会叠加成一场雪崩。

发版时序（顺序不能反）
  1. 摘流量 ── 等待确认生效 ── 静默期
        │
  2. draining ── 在途请求归零 or 超时（P99 × 2~3）
        │
  3. 收尾 ── 释放显存 / flush 日志指标 / 关闭连接
        │
  4. 退出进程 ── 规范退出码
        │
  5. 新版本 ── 加载模型 ── 预热 ── 就绪检查 ── 接流量
        │
  6. 金丝雀观察 ── 达标放量 / 不达标回滚

三、存量请求怎么等

摘流之后进入 draining，要点是设明确上限而不是无限等待：

统计在途请求数，等到归零或超时。
超时后分级处理：能安全中断的（普通问答）直接返回可重试错误；不能中断的（有副作用的写操作）要走完。
给客户端返回明确信号，让它可以立刻重试到别处，而不是干等到超时。
draining 期间拒绝新请求，但保持健康检查「存活」状态，避免被上游判定为故障实例而触发连锁动作。

上限的取值要依据真实数据：看 P99 请求时长，draining 上限设为它的两到三倍。拍脑袋设三十秒，遇到长请求就会大批中断。

四、进程退出的最后一公里

请求处理完不等于可以安全退出。还要做：

显式释放 GPU 上下文与显存池，不要依赖进程退出时的隐式回收。
刷写缓冲：日志、指标、追踪数据要 flush，否则最后一批观测数据丢失，排查时正好缺最关键的时段。
关闭连接池与文件句柄，避免 TIME_WAIT 堆积。
退出码要规范：正常退出、 draining 超时退出、异常退出要用不同码，便于编排系统判断。

还有一个坑：容器环境下的终止宽限期。默认宽限期往往只有三十秒，而大模型服务的 draining 可能需要几分钟。这个参数必须显式调大，否则容器会被强制杀掉，优雅退出完全失效。

五、热更新与预热

减少停机感的关键是新旧版本并行：

滚动更新：逐批替换，每批之间观察指标，不达标就暂停。
预热：新实例启动后先加载模型、跑几轮样例请求触发懒初始化，通过就绪检查后才接流量。
金丝雀：先放百分之几的真实流量，观察错误率与时延，没问题再放量。
容量缓冲：更新期间要有额外容量，否则摘掉一批就没法承接同等负载。

预热这一步在大模型服务里尤其重要。没预热就把流量打进去，第一批请求会触发编译、显存分配、缓存构建，时延是正常值的几倍，表现为发布后短暂告警——实际上只是冷启动。

六、回滚要比发布更快

回滚路径必须事先准备好并且演练过：

保留上一个版本的镜像与配置，随时可切。
回滚要能一键触发，不需要重新构建。
模型版本与服务版本要能独立回滚：很多时候出问题的是模型，退回上一版模型比回滚服务更快。
回滚的判断标准要预先写死：错误率超过多少、P99 超过多少、持续多久就触发。不要依赖现场讨论。
数据兼容性要提前考虑：新版本写了新格式的数据，回滚后老版本读不了，这种情况要在设计阶段就避免。

最后这条最容易被忽略。没有数据兼容设计的回滚，会把一次发布故障升级成一次数据事故。

有状态服务还要考虑会话迁移。如果会话状态只存在本地内存里，摘流就意味着这批用户的会话全部丢失。要么把状态外置到共享存储，要么在 draining 时把活跃会话迁移到其他实例。前者是架构层面的改造，后者是发布层面的补丁。短期可以用后者救急，长期还是要解决状态外置的问题。

七、长时任务的特殊处理

Agent 类长任务是优雅退出的最大挑战，因为它可能跑十几分钟，等它结束会让发布卡住。可行方案：

任务检查点：长任务定期保存状态，中断后可从检查点恢复，这样允许在安全点终止。
任务迁移：把在跑的任务移交到其他实例，要求状态可序列化且传输成本可控。
分离部署：把长任务调度层与推理层分开，推理层可以频繁更新，长任务层保持稳定。
明确告知用户：长任务因发版中断时给出清晰提示与恢复入口，比静默失败好得多。

分离部署是多数团队最终的选择：让需要频繁迭代的部分可以频繁迭代，让需要稳定的部分保持稳定，用架构解决发布矛盾。

还有一个细节值得做：把发布过程本身做成可观测的。记录每次发布的开始时间、每个实例进入 draining 的时刻、draining 实际耗时、预热完成时间、以及期间的被拒请求数。有了这些数据，发布相关的告警就能快速归因——是 draining 太短、预热不足、还是版本本身有问题，看数字就知道，不用现场猜。

八、衔接大会专题

在线服务的发布治理、推理平台的可用性与运维自动化，属于大会 AI Infra 与 AgenticOps 专题的典型话题。2026 奇点智能技术大会与 C++ 及系统软件技术大会同期举办，时间 2026 年 11 月 20-21 日，地点北京万达文华酒店，共设 9 大专题、70 余场演讲，覆盖大模型技术、Agentic Scaling、AI 原生软件研发、AI 计算平台、企业级 AI 原生应用与落地、智能体应用创新与开发实践、多模态与世界模型演进、从具身智能到物理 AI、AI+ 行业应用实践。做平台运维的同学可以在这一专题对一对自己的发布流程。