推理服务上新不翻车：模型灰度发布的四个台阶

模型迭代比传统服务频繁得多——今天换个 prompt 版本、明天换个微调 checkpoint，每次都全量切换等于每次都在赌。这篇把推理服务的灰度发布拆成四个台阶，从粗到细，按团队阶段选位置。

台阶一：双版本并行 + 按流量切分

最基础的形态：新旧两个实例组同时在线，网关按百分比分流。5% → 20% → 50% → 100%，每档观察一个完整业务周期（至少覆盖一次流量高峰）。关键细节：分流按用户而不是按请求——同一用户一会儿新版一会儿旧版，体验会精神分裂（前后回答风格突变）。用户 ID 哈希取模是最简单的粘性方案。

台阶二：金丝雀用户组

从随机 5% 进化到指定用户组：内部账号先行、灰度白名单、活跃度低的用户先上。好处是爆炸半径可控且反馈质量高——内部用户能说清楚「哪里变差了」，随机用户只会默默流失。

台阶三：按请求特征路由

翻译场景的实际做法：短句请求先走新模型（试错成本低），长文档请求留在旧版本（质量敏感）；或者按领域路由——技术文档灰度、文学类不动。这个台阶的前提是请求打标：入口处给每个请求标上特征（长度、语域、来源），路由规则才有抓手。

台阶四：自动评估门禁

灰度观测从「看投诉」升级为「自动评估」：灰度流量抽样跑评估集（质量分、格式合法率、术语一致率），指标劣化超阈值自动回切。这一步把发布从「人盯」变成「门禁」，是规模化后唯一可持续的方案。评估集不用大——每类请求 50~100 条代表性样本就够门禁用，但必须定期换血防止过拟合。

回切比切换重要

所有台阶的共同要求：回切必须秒级。网关层保留旧实例组 30 分钟以上（缩容可以，别销毁）；配置中心的路由规则带版本历史一键回滚；灰度期间新旧版本的请求日志分开存，回切后的对比分析全靠它。

结语

灰度发布的本质是花 20% 的复杂度买 80% 的安全感。四个台阶不必一步到位——台阶一今天就能做，台阶四等请求量上来再做。但「回切秒级」这个底线，从第一天就要守住。