模型serving灰度回测规则详解课程 - 第1节
1.1 灰度发布定义
灰度发布（Gray Release / Canary Release）是一种渐进式的软件交付策略，其核心思想是让新版本的服务或模型仅对一小部分用户或流量生效，在验证其稳定性和效果后，再逐步扩大范围，直至全量覆盖。在模型服务场景中，灰度发布意味着将新训练的模型版本（V2）部署到生产环境，但只路由1%~5%的推理请求到新模型，其余请求仍由旧模型（V1）处理。
关键特征：
- 渐进性：流量从 1% → 5% → 20% → 50% → 100% 逐步切换。
- 可观测：实时监控新旧版本的延迟、吞吐、错误率、业务指标。
- 可回滚：一旦发现异常，立即将流量切回旧版本，影响面极小。
1.2 灰度发布 vs 蓝绿发布 vs 金丝雀发布
三种发布策略在模型服务场景中各有适用场景，核心差异在于资源占用、切换速度和风险控制。下表从六个维度进行对比：
| 对比维度 | 灰度发布（Canary） | 蓝绿发布（Blue/Green） | 金丝雀发布（Canary） |
|---|---|---|---|
| 资源占用 | 低（仅多部署少量新版本实例） | 高（需同时运行两套完整环境） | 低（同灰度） |
| 切换速度 | 慢（逐步调整流量权重） | 快（瞬间切换路由） | 慢（逐步调整） |
| 回滚速度 | 快（权重归零即可） | 快（切回旧环境） | 快（同灰度） |
| 风险暴露面 | 极小（仅影响小比例流量） | 中等（切换后全量暴露） | 极小（同灰度） |
| 模型版本对比 | 支持实时 A/B 效果对比 | 不支持细粒度对比 | 支持实时 A/B 效果对比 |
| 适用场景 | 模型效果验证、回测、渐进式上线 | 基础设施升级、无状态服务快速切换 | 同灰度（金丝雀是灰度的别名） |
注意：在模型服务领域，“灰度发布”与“金丝雀发布”常被混用，但业界更倾向于用“灰度发布”指代基于流量权重的渐进式策略，而“金丝雀发布”则强调先让少量实例（金丝雀）承担风险。本课程统一使用“灰度发布”术语。
1.3 灰度发布在模型服务中的价值
模型服务与普通应用服务最大的区别在于：模型效果无法通过单元测试完全验证。模型在离线评估中的 AUC、F1 等指标，与线上真实用户反馈之间往往存在偏差（Offline-Online Gap）。灰度发布为模型服务提供了以下核心价值：
- 降低上线风险：新模型即使存在数据漂移、过拟合或推理异常，也只会影响小部分用户，避免全量故障。
- 支持在线回测：在真实流量中对比新旧模型的业务指标（如 CTR、转化率、用户满意度），为模型迭代提供数据支撑。
- 渐进式资源扩缩：根据灰度期间的负载情况，逐步调整新模型的副本数，避免资源浪费或过载。
- 满足合规与审计：在金融、医疗等强监管场景中，灰度发布可保留完整的流量切换日志，满足模型上线审计要求。
常见误区：灰度发布不能替代离线评估。离线评估用于筛选候选模型，灰度发布用于验证线上表现。跳过离线评估直接灰度，可能导致资源浪费和无效迭代。
1.4 灰度发布核心流程（SVG）
下图展示了模型服务灰度发布的标准流程，从流量入口到逐步放量，再到全量上线或回滚：
1.5 灰度发布与蓝绿发布的架构对比（SVG）
为了更直观地理解两种策略的架构差异，下图展示了蓝绿发布与灰度发布在模型服务部署中的资源布局：
1.6 灰度发布在模型服务中的典型场景
以下列举三个高频场景，说明灰度发布如何解决模型服务的实际问题：
| 场景 | 问题 | 灰度方案 | 效果 |
|---|---|---|---|
| 模型效果回测 | 离线 AUC 高，线上 CTR 反而下降 | V2 模型灰度 5%，对比 V1 的 CTR | 快速发现数据漂移，回滚 V1 |
| 推理延迟优化 | 新模型参数量大，推理延迟可能超标 | 灰度 1% 流量，监控 P99 延迟 | 确认延迟在 SLA 内后再放量 |
| 模型版本兼容性 | 新模型输入特征格式变更 | 灰度期间校验请求/响应格式 | 避免全量上线后接口报错 |
最佳实践：建议在灰度发布前，先通过离线回测（Shadow Testing）将线上真实流量复制一份给新模型，但不返回结果给用户，仅用于评估效果。这可以进一步降低灰度风险。