云原生 AI 模型灰度：别把新模型一次性推给所有流量
一、模型灰度比普通服务更需要谨慎
普通服务灰度主要关注错误率、延迟和资源。AI 模型灰度还要关注答案质量、引用准确性、成本变化和用户反馈。新模型接口兼容，不代表业务效果一定更好。
模型上线如果一次性切全量，问题会很难回滚。用户看到错误答案，成本突然上升，缓存命中下降，都可能在短时间内扩大。模型灰度应该像发布节奏一样可控。
二、灰度维度要多层
flowchart TD A[请求进入] --> B{灰度策略} B --> C[旧模型] B --> D[新模型] C --> E[质量与成本指标] D --> E E --> F[扩大或回滚]灰度可以按租户、用户、场景、功能或流量比例切分。高风险场景先不要切，比如财务解释、生产配置、客户承诺类输出。低风险场景先试，观察质量和成本。
还可以做影子流量。用户仍然看到旧模型结果，新模型在后台生成，用于对比质量、延迟和 token。影子模式能提前发现问题，但要注意数据权限和额外成本。
三、指标不能只看错误率
model_canary: answer_accept_rate: 0.71 citation_support_rate: 0.92 cost_per_request: 0.038 p95_latency_ms: 1800模型灰度指标至少包括采纳率、引用支持率、用户重试率、人工驳回率、成本和延迟。错误率低不代表质量好，因为很多错误答案不会抛异常。
评测集也要参与灰度。上线前跑离线评测，上线后看真实流量。离线评测保证基本盘，线上灰度验证真实分布。两者缺一不可。
promote: 质量不下降，成本可接受，延迟稳定 rollback: 关键场景退化，投诉上升，成本异常四、回滚路径要提前准备
模型灰度要能快速回滚。配置中心、模型路由、缓存版本和提示模板都要支持切回。只切模型不切提示词，有时仍然会出问题，因为模型和提示词是共同工作的。
回滚后要保留问题样本。不要只恢复服务就结束。退化样本要进入评测集，后续再上线时必须通过。模型迭代不是盲目追新，而是让每一次失败都变成测试资产。
模型灰度还要处理缓存。旧模型生成的缓存结果，未必适合新模型策略；新模型生成的结果，也不应污染旧模型缓存。缓存 key 应包含 model_version、prompt_version 和 retrieval_version。否则回滚后仍可能读到新模型留下的结果。
提示词也要随模型灰度一起管理。同一个提示词在不同模型上可能表现不同。灰度配置里最好明确模型、提示模板、工具 schema 和安全策略版本。这样线上出现退化时，团队能知道是哪一层变化导致问题。
成本阈值要提前设定。新模型质量提升 2%，但成本提升 80%，是否接受要看业务场景。没有成本门槛，模型升级很容易变成“效果更好一点，账单更重一截”。
最后，灰度报告要面向决策。报告不只是技术指标，还要说明是否扩大、保持、回滚，以及理由。模型发布需要节奏感，不能每次都靠临时开会判断。
还要设计人工抽检池。灰度期间抽取新旧模型差异较大的样本，让业务或标注人员判断。自动指标能发现趋势，人工抽检能发现语义细节。两者结合，模型发布才不会只看冷冰冰的数字。
多模型路由也要避免用户体验跳变。同一个会话中，如果前半段用旧模型，后半段突然切新模型，风格和能力可能变化。会话级粘滞能减少这种割裂。灰度不是每个请求随机抽签，用户体验也要稳定。
五、总结
云原生 AI 模型灰度要按场景和流量分层，结合影子流量、离线评测和线上质量指标，并准备完整回滚路径。
新模型不是一键替换。能灰度、能观测、能回滚，才配进入生产流量。
