咨询热线：
0755-26643541
请扫码添加客服的企业微信进行沟通
日期：2026-08-03
我们维护的这套大模型推理服务，早期升级方式是"停服、换权重、起服务"。每次发布要挑凌晨、业务方捏汗、回滚靠重新部署老镜像，慢且易错。更致命的是新权重一旦上线即全量，万一推理质量劣化（比如某类意图识别掉点），全站用户立刻感知，只能紧急回滚，发布窗口被压缩到几乎没有容错。业务方明确说：升级不能停服务，劣化要能秒级切回。
我们落地了蓝绿双版本共存加灰度切流。推理服务同时跑两版权重（蓝等于当前稳定、绿等于待发布），网关侧按流量比例把请求分给蓝绿；先放 5% 流量观察延迟、错误率、质量指标，没问题再逐步放量到 50%、100%；全程健康检查探活，任一指标异常自动回滚到蓝。权重支持热加载，切换不重启进程。
第一个挑战是双版本权重共存与资源。两版同时占显存，我们用同一推理引擎加载两份模型副本，按 QPS 动态分配显存配额，灰度期绿版低配、全量后回收蓝版。
案例片段（已脱敏）： 蓝绿切流配置（示意）： route: blue: {weight: 95, model: "v3.2-stable"} green: {weight: 5, model: "v3.3-candidate"} health: check: "/healthz" p99_latency_s: 3.0 err_rate: 0.01 auto_rollback: true
发布记录：绿版放量到 50% 时 err_rate 跳到 0.04，自动回滚，业务零感知
第二个挑战是流量秒级切换。网关路由表热更新，权重调整下发后下一次请求即生效，不重连、不断流。
第三个挑战是健康探测与回滚。我们不只探活（进程在不在），还探"质量"——采样请求做自动评测，延迟或错误率越线即触发回滚，避免"活着但答得差"。
第四个挑战是权重热加载一致性。热加载期间新老请求可能命中不同权重，我们用请求级版本绑定，单个请求生命周期内权重不变，避免半路切换导致结果不一致。
单次发布时长从约 40 分钟（含停服窗口）降到 5 分钟内（纯切流）；升级零中断率达到 100%（灰度期内无业务感知）；回滚时长从约 15 分钟降到秒级；升级导致的质量劣化拦截率接近 100%，近半年因发布引发的客诉为零。
第一，模型升级别再停服，蓝绿加灰度是标配，发布窗口的焦虑会消失。
第二，健康检查要探"质量"不止探"存活"，答得差是更隐蔽的事故。
第三，回滚必须一键可触且秒级，这是敢放量的前提。
第四，请求级版本绑定保证热加载期间结果一致，别小看这个细节。
蓝绿部署真正跑顺之前，我们踩过一个典型的假成功坑。第一次灰度放量到五成时，看延迟和错误率都正常，就直接全量了，结果第二天业务方反馈某些长文档问答变傻了。查下来是绿版在新权重下对长上下文的注意力分配有回归，但我们的健康探测只采了短请求，没覆盖到长上下文场景。后来健康探测改成按请求类型分层抽样，长上下文也纳入质量评测，才真正拦住这类劣化。
第二个细节是双版本的资源调度。两版同时占显存，灰度期绿版流量小却占着一份完整模型副本，有点浪费。我们改成绿版低配副本加动态扩容：放量增大再按需要把绿版副本数提上来，全量确认后回收蓝版。显存曲线平滑，也没出现切换时的容量真空。
第三是回滚的果断。自动回滚最怕半回滚——切回蓝了但部分绿版缓存还在。我们让回滚动作带一个全局版本令牌，网关、推理侧都认这个令牌，确保整条链路同一时刻只有一个版本生效，杜绝了中间态。
再说发布节奏的文化转变。过去发布要挑凌晨、全员待命；现在蓝绿加灰度让发布变成白天随时可做的小操作，团队心态从如临大敌变成日常 routine，这才是工程成熟度真正的提升。
最后提醒一点：权重热加载虽好，但要在模型架构不变的前提下做。我们曾试过在一次大版本里既换权重又改输出格式，热加载后旧请求按新格式解析直接报错。架构变更永远走完整蓝绿，只有同构权重才走热加载，这条红线别碰。
回顾模型服务蓝绿部署这个项目，最容易被低估的是最后一公里。技术方案跑通只是开头，真正决定成败的是上线后那几周：健康探测有没有覆盖长上下文、回滚有没有全局令牌、双版本资源有没有平滑回收。我们见过太多项目栽在上线即交付的心态上，三个月后指标悄悄回潮。所以我们的做法一直是把上线当运营起点：按请求类型抽样健康探测、回滚演练、容量压测、自动化巡检，四件套缺一不可。另一个体会是，架构变更永远走完整蓝绿，只有同构权重才走热加载，这条红线别碰。以上是我们的一点体会，供同样做模型发布的团队参考。
蓝绿部署跑熟之后，发布从大事变成小事，但越是这样越不能松懈。我们保留每月一次回滚演练，故意把绿版弄坏看自动回滚是否还灵。演练次数多了，真出事时团队才不会慌。发布可靠，靠的是把演练当日常，而不是靠运气。