一、项目背景

我们有个客户同时接了三四个大模型，有的擅长长文，有的便宜但偶尔抽风。业务想上新模型，又怕效果不如老的把全站体验带崩，于是长期以来都是半夜人工切流量，谁值班谁胆战心惊。我们进场时，最近一次全量切模型因为新模型在某个长尾场景答得稀烂，投诉一个早上，技术负责人当场拍板以后不许半夜手动切。说实话，这种靠人肉守半夜的发布方式，迟早出事，只是还没轮到更惨的那次。我们后来接手，第一件事就是把这套发布流程从人身上卸下来，先给模型上线这事儿装上刹车和方向盘。

二、落地场景

我们在网关层做了多模型编排：一个请求可以先过小模型做意图分类和路由，再决定走哪个大模型精答；也可以主模型出问题自动切备用模型。新模型上线走灰度，按流量比例从一成慢慢放到全量，过程中实时比对新旧模型的回答质量和关键指标。一旦回退判定触发，流量自动切回老模型，不用人工干预。编排策略和灰度比例都在管控台配置，谁改了什么有记录，出了问题能溯源到具体一次变更。业务方第一次看到灰度曲线时，说终于不用半夜盯着大盘了，那种如释重负的表情我们见过好几次。

三、关键技术挑战与解决思路

编排策略的表达力是个坑。最早我们想用固定的分支链路，结果业务要的编排花样太多，代码改不过来。后来改成声明式编排配置，把串联、并行、回退都抽象成策略原语，业务自己拼。灰度切分也不能简单按用户哈希，长尾用户容易被忽视，我们用分层采样，保证每个用户分层都有灰度流量。回退判定最难，不能只看报错率，有些模型不报错但答非所问，我们加了回答质量探针，质量低于阈值持续一段时间才触发回退，避免抖动误杀，也避免该回退时不回退。可观测也是坑，编排链路一旦长，延迟和错误来源难定位，我们给每一步打标，链路追踪直接看出卡在哪一环。多租户隔离是第五个坑，不同业务方共用网关却要互不可见，我们按租户维度切路由、切计量、切大盘，一个业务方的配置泄露不到另一个那边，审计也按租户拆开。

四、效果数据

灰度发布成功率（按计划比例平稳放量到全量）从人工时代的约六成提升到接近百分之百，发布事故数从平均每两次发布出一次降到连续二十多次零事故。回退触发准确率（误判率）控制在约百分之三，基本都是短暂抖动误杀，不影响主流程。编排链路额外延迟控制在二十毫秒以内，业务无感。最近一次新模型上线，灰度三天平稳放量，过程中发现长尾场景质量掉，自动回退，没惊动任何人，第二天业务才知道昨晚放过一次新模型。值班群里那句今晚不用守了第一次被发出来。业务侧新模型上线频率从每月不到一次提升到每周能试两三个，迭代节奏明显快了。技术团队终于从发布恐惧里解脱出来，把精力放回模型效果本身，而不是守着半夜的大盘。

五、可复用经验总结

模型上线这事儿，能灰度就别全量，这是用半夜事故的教训换来的。回退必须自动化，靠人盯半夜切模型迟早翻车，这一条我们坚持得最死。回退判定不能只盯报错率，不报错但答非所问更隐蔽，质量探针是我们后来补上的，补完才真正睡得着。编排用声明式配置比写死代码灵活太多，业务自己能拼策略，技术不用每次跟着改。灰度采样要做分层，别让长尾用户当炮灰，这点是被一个长尾客诉提醒后才加的。链路打标这层，是排障排到崩溃才补的，补完定位时间从小时级降到分钟级。多租户隔离这层上线前被业务方催了好久，真切下去才发现它顺带把计量账单的扯皮也消了。这层我们一开始觉得是锦上添花，上线后才意识到没有它，多业务方根本不敢共用一个网关。现在新接一个业务方，配置加一条隔离策略就行，半天搞定，以前要排期两周。

结语

灰度加自动回退这套跑顺之后，客户技术团队最大的变化是不再恐惧上新模型了。我们复盘时觉得，工程上最有价值的不是某个算法，而是把发布这件高风险动作变成了可逆的、可观测的普通操作。这套思路后来被我们当成新模型上线的标准姿势，再没人为半夜切流量失眠过。

案例片段（已脱敏）： 多模型编排与灰度路由配置（示意）： strategy: classify→route(modelA:长文, modelB:通用, fallback:modelC) gray: {new_model: 10%→30%→60%→100%, step=24h, watch:[quality, err_rate]} 监控：新模型长尾场景质量分 0.61 < 阈值 0.75，持续 40min → 自动回退至 modelC 本次灰度 3 天，误杀 1 次（抖动），发布事故 0，链路附加延迟 18ms，业务无感知，定位耗时分钟级，上线频次 月<1 → 周 2~3。