模型灰度发布新模型上线不能只靠一次人工体验模型升级很容易被低估。新版本回答更流畅人工试几条觉得不错就切全量。结果上线后才发现成本涨了、延迟变了、某些任务退化了甚至安全策略不稳定。模型也是生产依赖灰度发布不能省。我会把模型发布当成普通服务发布一样治理版本、流量、指标、回滚、对比和审计都要有。模型能力再强也要过基础设施这一关。一、模型版本要显式存在业务请求不能只写latest。要能明确知道每次调用的是哪个模型、哪个模板、哪个安全策略。flowchart TD A[请求进入] -- B[路由规则] B -- C[旧模型 90%] B -- D[新模型 10%] C -- E[指标记录] D -- E E -- F[对比与回滚决策]灰度期间新旧模型要同时记录延迟、token、错误、用户采纳和人工抽检结果。只看成功率不够因为模型可能“成功返回了更差答案”。二、路由规则要可配置模型灰度最好在推理网关层完成。业务服务不需要知道灰度细节。model_rollout: task: customer_summary stable_model: model-a-2026-06 candidate_model: model-b-2026-07 traffic_percent: 10 rollback_if: p95_latency_increase: 30% cost_increase: 20% safety_violation_rate: 0.5%回滚条件要提前写好。不要等事故发生时再开会争论是否回滚。基础设施应该让回滚成为正常动作而不是承认失败。三、评估集要覆盖真实任务人工体验几条样例不够。至少准备一组离线评估集覆盖高频任务、边界输入、长文本、多语言和安全样本。{ case_id: summary_long_context_001, task: customer_summary, input_ref: s3://eval/case001.txt, checks: [factual_consistency, no_extra_claim, valid_json] }离线评估不能替代线上灰度但能挡住明显退化。线上灰度再观察真实流量表现。四、成本变化也是发布风险新模型质量提升一点但 token 输出更长、单价更高、延迟更大未必值得全量。模型发布报告要把质量、延迟、成本放在一起看。尤其是 AI 平台多个业务共用模型服务一个模型升级可能影响整体 GPU 容量。没有成本指标的模型灰度是不完整的。灰度期间还要保留样本回放能力。把旧模型和新模型对同一输入的输出、耗时、token、策略命中记录下来抽样给业务方复核。这样讨论退化时有证据不会变成“我感觉新模型更好”。compare_id: rollout_20260702_001 old_model: model-a-2026-06 new_model: model-b-2026-07 input_hash: 8f2c... checks: latency, cost, json_valid, safety_policy, human_preference另外模型灰度要有冻结窗口。重大活动、流量高峰、下游供应商不稳定时不要顺手升级模型。基础设施里的保守有时是在替业务省事故。五、总结模型灰度发布不能只靠一次人工体验。显式版本、网关路由、离线评估、线上灰度、成本延迟监控和快速回滚都是必要环节。模型是能力也是依赖。依赖上线就要按生产标准治理。