外观
模型发布（model rollout）是把新版本模型的流量从 0 逐步切到 100% 的过程，核心目标是「效果要线上验证、出问题要能秒级回滚」。 为什么模型发布比代码发布危险得多？因为代码发布失败是「崩」，模型发布失败是「悄悄变差」：新模型不会抛异常，只是推荐结果变蠢、误报率升高，用户感知是「好像不如以前了」，而你未必有告警。加上数据漂移，离线指标再好看也挡不住线上翻车。这篇讲三种主流策略（金丝雀、蓝绿、A/B）的选型、金丝雀的完整落地流程、三层回滚机制与发布前 checklist。理论背景见 MLOps 流水线，网关实现的完整实战见 模型网关与灰度发布。
发布的核心心智
发布不是「切流量」，是「受控实验」。 每次发布都在回答一个问题：新版本是否比旧版本好？答案要靠线上指标证明，不是靠发布者的信心。
一、为什么模型发布更危险
| 差异 | 代码发布 | 模型发布 |
|---|---|---|
| 失败形态 | 崩溃、报错、5xx | 效果退化，系统「正常」运行但输出变差 |
| 检测手段 | 错误率、可用性 | 效果指标（点击率/准确率/转化），口径复杂 |
| 回滚触发 | 错误率告警即可 | 效果指标劣化，需要先定义「劣化」 |
| 环境相关 | 代码与环境强耦合 | 还耦合数据分布：同一模型今天好明天差 |
数据漂移让情况更糟：新模型刚上线表现好，一周后输入分布变了，效果下滑——你发布的不是「正确版本」，而是「在当前数据分布下正确的版本」。这就是为什么模型发布必须有监控和回滚机制（监控落地见 可观测性落地）。
二、三种策略对比：金丝雀、蓝绿、A/B
| 策略 | 原理 | 流量切分 | 回滚速度 | 效果验证 | 适用 |
|---|---|---|---|---|---|
| 金丝雀（Canary） | 新版本逐步加量，随时可退 | 5%→20%→50%→100% | 秒级（回退切流） | 系统指标 + 效果指标逐档观察 | 默认首选 |
| 蓝绿（Blue/Green） | 新旧两套环境，整体切换 | 一次切换 0%↔100% | 快（切回旧环境） | 切换前不能同流量对比 | 基础设施大改、要求整切 |
| A/B 测试 | 长期并行，统计对比 | 固定分流（如 50/50） | 取决于验证周期 | 严格统计显著性 | 效果验证、算法迭代决策 |
选型判断：默认金丝雀（可控、可回滚、可验证三位一体）；蓝绿用于「金丝雀做不了的整体切换」（数据库迁移、依赖大版本）；A/B 用于「要严谨回答效果」的场景，通常和金丝雀组合——金丝雀负责发布安全，A/B 负责效果定论。
三、金丝雀发布流程详解
3.1 四档切流与每档观察
典型节奏：5% → 20% → 50% → 100%，每档停留 10-30 分钟（效果类指标至少观察一个业务周期）。
| 档位 | 流量 | 观察重点 | 通过条件 | 失败动作 |
|---|---|---|---|---|
| 1 | 5% | 系统指标：错误率、P99、显存 | 错误率 ≤ 旧版本，P99 不劣化 | 立即回滚，排查环境差异 |
| 2 | 20% | 系统 + 基础效果（准确率/空响应率） | 效果指标无显著下滑 | 回滚或退回 5% 调参 |
| 3 | 50% | 业务效果指标（点击率/转化/收入） | 与旧版本持平或更好 | 回滚并组织分析 |
| 4 | 100% | 全量后 24-48 小时持续盯 | 无回归，错误预算未加速消耗 | 回滚预案立即生效 |
关键原则：每档只放行一次「不劣化」证明，不要跨档跳级。 跳级的代价是：出了问题时定位范围是「流量扩大 + 模型变更」两个变量叠加。
3.2 自动回滚条件
把「回滚条件」写成可执行的规则（网关/编排层执行）：
text
自动回滚触发条件（任一满足即回滚）：
- 错误率 > 旧版本 1.5 倍持续 5 分钟
- P99 延迟 > SLO 阈值持续 10 分钟
- 效果指标（如转化率）相对旧版本下滑 > 3%，持续一个业务周期
- 系统资源告警（OOM、显存打满）
手动回滚触发条件（任何人可发起）：
- 业务方反馈异常、客服工单上升
- 任何「说不清原因」的指标异常，先回滚再排查3.3 灰度期间的监控项
灰度不是「看监控」，是「盯一套为对比设计的指标」：同指标、双版本、同一口径。
- 系统指标：新旧版本的错误率、P99、QPS（按
versionlabel 分开，见 可观测性落地 的 labels 规范）； - 效果指标：转化率、点击率、准确率——旧版本必须同流量观察，否则没有对照；
- 漂移信号：输入分布变化，见 监控与可观测性。
四、蓝绿部署：整切与成本
蓝绿维护两套完整环境（绿=当前、蓝=新），验证通过后把入口流量整体切到蓝，蓝绿互换角色。
| 优势 | 代价 |
|---|---|
| 切换极快（秒级），回滚就是再切一次 | 双倍资源成本（两套 GPU/实例常驻） |
| 新环境可以做充分的预验证 | 两套环境数据/配置容易漂移不一致 |
| 适合无法逐档放量的变更 | 不适合验证效果差异（没有同流量对照） |
text
┌────────────┐ 流量 ┌────────────┐
用户 ───▶│ 网关/负载 │─────────▶│ 绿环境(旧 v1) │
│ 均衡器 │──┐ └────────────┘
└────────────┘ │切换瞬间 ┌────────────┐
└────────▶│ 蓝环境(新 v2) │
└────────────┘何时选蓝绿：基础设施变更（升级依赖大版本、CUDA 升级、K8s 集群迁移）——这类变更无法用 5% 流量验证，只能整环境验证。代价是成本，判断标准：「整切风险」vs「双倍成本」哪个更贵。
五、A/B 测试：分流、显著性与时长
金丝雀回答「能不能上」，A/B 回答「到底好不好」。两者常常组合：金丝雀发布到全量后，再用 A/B 长期验证算法效果。
5.1 分流与对照
- 分流单位：按用户 ID 哈希分流，保证同一用户始终在同一版本（避免「今天 v2 明天 v1」污染效果）；
- 样本量：预计算最小样本量（可用统计工具，如 Evan Miller 样本量计算器）；经验值：CTR 从 3% 提到 3.2%（+6.7%）的改进，50/50 分流约需 50 万次曝光才能有 95% 置信度；
- 防污染：A/B 期间不叠加其他变更（「只改一个变量」）。
5.2 显著性判断与时长
text
判断标准（三层递进）：
1. 置信区间不包含 0（效果统计显著）
2. 提升幅度 > 最小业务收益（统计显著 ≠ 业务值得上）
3. 无意外副作用（相关指标未恶化，如「点击率升了但退货率升了」）
时长决定因素：
- 样本量足够（低流量模型可能需要数周）
- 覆盖至少一个完整业务周期（周/月节奏）
- 排除季节性：同周期与基线对比A/B 不是发布工具
A/B 测试期间用户长期体验在差版本上，如果差距明显，是在拿真实用户做实验。所以 A/B 要配合止损规则（如 3 天观测期后若明显劣化立即全量回滚），不要「测满 4 周再说」。
六、回滚机制：三层回滚
回滚不只是「切回旧模型」，要区分三层，各自有独立的回滚路径：
| 层 | 回滚内容 | 怎么做 | 速度 |
|---|---|---|---|
| 模型层 | 模型版本 | 模型注册中心指向旧版本（MLflow 等），网关/服务重新加载 | 秒级-分钟级 |
| 特征层 | 特征/预处理逻辑 | 特征服务回滚到旧特征配置；注意模型与特征版本必须配对 | 分钟级 |
| 代码层 | 服务代码 | 旧镜像/旧 deployment 回滚 | 分钟级 |
三层版本必须联动
模型是配合「旧特征」训练出来的。只回滚模型不回滚特征，等于「新鞋配旧袜」——效果照样错。回滚前先确认模型、特征、代码三个版本是否还是「配套训练/验证过」的组合。模型版本管理见 MLOps 流水线。
bash
# 典型回滚动作：K8s Deployment 切回上一版本镜像
kubectl rollout undo deployment/inference-api
# 或模型层：改配置指回旧版本并 reload
kubectl patch configmap model-config --type merge \
-p '{"data":{"model_version":"v1.2.0"}}'七、发布前 checklist
- [ ] 离线评估完成，新模型验证集指标达标；
- [ ] 效果指标已定义且新旧版本口径一致（同一套计算逻辑）；
- [ ] 灰度四档计划写好：档位、每档观察项、停留时长；
- [ ] 自动回滚条件配置到网关/编排层，并演练过一次；
- [ ] 三层回滚预案就绪：模型版本、特征版本、代码镜像都标记好；
- [ ] 监控面板就绪：双版本对比视图、效果指标视图；
- [ ] 通知就位：发布群、值班表、负责人（发布本身是团队协作事件）；
- [ ] 回滚后动作有预案：分析根因、修 bug、重新走灰度。
八、常见坑
- 灰度期间缓存污染：新旧版本共用缓存，新模型的输入被旧缓存命中，效果对比失真。解法：缓存键带上模型版本，或灰度期禁用易变缓存。
- 效果指标口径不一致：新版本指标算在模型层，旧版本算在业务层，两者「对比」毫无意义。解法：指标计算统一收口到同一服务，只按 version 分流。
- 跨档跳级：5% 直接到 100%，出问题定位变量太多。解法：档位是纪律不是流程，跳级必须有书面批准。
- 回滚预案「有」但没演练：真出问题时发现 rollback 命令权限不对、镜像 tag 打错。解法：发布前做一次「演练回滚」（切 1% 流量再切回）。
- 只盯系统指标不看效果：P99 完美但转化率掉 5%，系统「健康地变差」。解法：效果指标进发布 gate。
检查清单
- [ ] 选择了与变更类型匹配的策略（默认金丝雀）；
- [ ] 四档切流计划与自动回滚条件已配置并演练；
- [ ] 三层回滚（模型/特征/代码）版本配套关系确认；
- [ ] 效果指标口径统一、有旧版本对照；
- [ ] A/B 场景：样本量、显著性阈值、止损规则齐备；
- [ ] 发布后 24-48 小时持续观察排班有人。
延伸阅读
- 模型网关与灰度发布 —— 网关分流、路由与灰度的完整实战
- MLOps 流水线 —— 模型注册、版本管理与流水线上下文
- 可观测性落地 —— 灰度期间双版本监控与告警配置
- 监控与可观测性 —— SLO、漂移检测的理论基础
- 常见陷阱与反模式 —— 全量发布翻车现场与根因
- 压测与容量规划 —— 发布前容量验证（新版本能扛峰值吗）
参考资料
- Argo Rollouts（K8s 金丝雀/蓝绿）：https://argoproj.github.io/rollouts/
- Kubernetes 官方文档（Deployment 回滚）：https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
- Evan Miller 样本量计算器：https://www.evanmiller.org/ab-testing/sample-size.html
- Google SRE 手册（发布工程）：https://sre.google/sre-book/release-engineering/