模型服务金丝雀发布：把权重切流变成可验证、可回滚的上线流程

把模型镜像从 v17 改成 v18，Pod 就绪后逐步提高流量权重，看起来与普通 Web 服务灰度发布相同。实际风险更复杂：模型权重可能加载成功但回答质量下降，新的 tokenizer 让输入长度统计变化，量化内核在特定卡型上出现数值异常，KV Cache 尚未预热导致首批用户超时，或者同一会话在新旧版本之间漂移而丢失上下文。模型服务的金丝雀发布必须同时验证基础设施和模型行为。

发布单元应是不可变的“服务版本”，包含模型权重摘要、tokenizer、推理运行时及其镜像 digest、量化方式、GPU 架构、采样默认值、系统提示词版本和安全策略版本。仅记录一个模型名无法回滚；即使权重相同，运行时或默认参数变化也可能改变输出。构建产物进入制品库后要签名，并在发布记录中绑定离线评估报告。

四道门禁缺一不可

第一道是制品与兼容性门禁：校验哈希、许可证、镜像漏洞、GPU 驱动与 CUDA 兼容性，启动后执行确定性 smoke test。第二道是离线质量门禁：在冻结的数据集上比较任务成功率、结构化输出、引用正确性、安全拒答和关键切片，不允许用全局平均分掩盖某种语言或高风险任务的退化。LLM 评估框架 中的样本分层适合固化为发布契约。

第三道是性能门禁：用接近生产的输入长度、输出长度和并发分布压测，记录排队时间、首 token 延迟、每 token 延迟、吞吐、显存峰值和 OOM。第四道是上线门禁：检查旧版本仍可用、路由支持一键回退、容量能承受回滚后的全部流量、观测标签能区分版本。任何一道没有证据，发布控制器都不应开始切流。

影子请求先发现无用户影响的问题

影子阶段复制一小部分经过脱敏且允许用于评测的请求给新版本，响应不返回用户。不要复制带写工具、敏感原文或无法幂等执行的调用；必要时只发送特征相似的回放样本。比较新旧版本的错误类型、输出格式、延迟、token 用量和规则评分，并对高价值样本进行盲审。

影子流量不能证明真实体验，因为它不承担真实排队，也可能没有完整会话。因此通过影子门禁后，再从内部账号或明确的低风险租户开始金丝雀。建议按 1%、5%、20%、50%、100% 分阶段，每阶段至少覆盖一个业务峰值或预设最小请求量，二者取更严格者。百分比到时自动晋级会让低流量时段的十几个成功请求替代有效证据。

steps:
  - setWeight: 1
  - analysis: {template: model-quality-and-slo, minRequests: 1000}
  - setWeight: 5
  - pause: {duration: 30m}
  - setWeight: 20
  - analysis: {template: model-quality-and-slo, minRequests: 5000}

配置中的阈值必须来自当前稳定版本的基线和业务 SLO，而不是复制示例值。对错误率、P95 首 token 延迟、OOM、GPU 利用率和单请求成本使用自动门禁；对语义质量使用可快速计算的任务信号、用户重试率、格式校验和抽样评审。指标体系可与 LLM SLO 监控 对齐。

处理会话、缓存和预热

多轮会话应在一个兼容版本族内保持粘性，或显式迁移会话状态。若新版本改变 tokenizer、工具协议或上下文格式，中途切换可能让历史消息无法复用。路由键应包含会话 ID 和发布版本；回滚时明确哪些会话继续留在新版本、哪些从下一轮开始回旧版本，并在客户端避免把两个版本的流式输出拼接。

提示缓存与 KV Cache 必须带模型权重、tokenizer 和推理参数版本，不能让新版本读取旧版本缓存。切入真实流量前，用无敏感内容的代表性请求加载权重、编译内核并预热关键输入长度；预热成功不等于就绪，还应确认预留显存和并发槽位。Kubernetes readiness 只在服务具备处理请求的实际能力后变为成功，不能在端口开始监听时就放流。

AI 功能开关 可以用来把模型版本绑定到租户与任务，而不是只按全站随机百分比分流。这样发现某个代码任务退化时，可以停止该任务的放量，同时保留其他已验证场景。

自动回滚必须覆盖语义和容量

立即回滚条件包括安全策略绕过、跨租户数据、持续 OOM、错误响应格式激增或工具调用产生异常副作用。暂停并人工判断的条件包括质量代理指标轻微下降、单请求 token 增长、尾延迟接近预算。每个条件都要定义窗口、最小样本和数据缺失行为；监控失明时默认暂停，而不是把“没有指标”当作健康。

回滚过程需要先把新流量权重置零，再等待在途流式请求结束或达到截止时间，最后保留新实例和日志用于诊断。旧版本至少在观察期内保持热容量；如果为了节约 GPU 立即缩到零，所谓自动回滚会变成长时间重新拉取权重。容量规划应假设金丝雀和旧版本短期并存，并验证故障时旧池能接回全部流量。

发布完成后不要立刻删除旧权重和配置。保留发布清单、每阶段指标快照、人工审批、回滚事件与样本差异，直到观察窗口结束。若指标改善来自更短但不完整的答案，要在复盘中把质量和成本同时解释，而不是只庆祝延迟降低。

用演练证明控制面可靠

在预生产环境故意让分析指标接口超时、让新版本 readiness 抖动、制造 GPU OOM、改变输出 Schema，并在 20% 阶段触发回滚。确认控制器停止晋级、路由权重真实收敛、告警指向具体版本、旧服务恢复容量且会话没有串流。发布流程本身也要纳入 CI/CD 流水线设计 的权限、审批与审计边界，避免任何人绕过门禁直接修改生产权重。

模型金丝雀的成功标准不是“新 Pod 跑起来”，而是新版本在明确人群和任务上，用足够样本证明质量、性能、安全与成本均在预算内，并且任何一步都能迅速回到已知稳定状态。

延伸阅读

• LLM 评估框架
• LLM SLO 监控
• AI 功能开关
• CI/CD 流水线设计