一、项目背景

有个业务方要把底层模型从旧版切到新版，新模型在内部评测里各项指标都好，但他不敢全量切，怕线上出岔子。我们当时的网关没有"按调用方灰度"的能力，模型切换要么全量要么不动。业务方没办法，自己在代码里写了个开关按用户比例放，结果放出去后发现新版对某种长尾问法答得变差，他手动回退时手抖切成了全量旧版，又把另一拨已经适配新版的流量打回去，两边都不对，吵了一周才理清。

这件事暴露的是：模型切换的风险不应该压在业务方手写 if else 上，网关作为统一入口，本该提供调用方维度的灰度切流，让切换可控、可观测、可秒回退。

二、落地场景

我们在网关侧加了调用方灰度能力。每个调用方（按应用 ID 或用户分组标识）可以配置灰度规则：把多少比例的流量切到目标模型版本，其余留在旧版。切换过程新旧两版并行服务，网关按规则分流。

灰度期间，看板同时展示新旧两版的延迟、错误率、业务自定义指标（如答非所问率），对照着看差异。一旦新版某个指标异常，规则一键回退到 0%，流量全部回旧版，秒级生效。灰度按阶段递进，比如先 5% 观察一天，再 20%、50%，最后全量，每一步都有数据支撑而不是拍脑袋。

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

调用方维度标识是第一道关。我们的鉴权体系本来只到租户，灰度要到应用甚至用户分组粒度，得在 token 里扩展维度字段，老调用方不强制，新规则按需带标。这里兼容性处理花了点功夫，不能因为加灰度让存量调用方报错。

比例切流精度看着简单，落到高并发下要保证同一用户尽量稳定命中同一版本，否则用户连续问两句一个新版一个旧版，体验割裂。我们用调用方标识加哈希做粘性分桶，比例准且稳定。

对照观测容易被忽略。很多团队切了灰度只看总指标，新旧混在一起看不出差异。我们要求灰度看板必须分版本独立展示，对比才有意义。

回退操作也做成网关侧一键，而不是改配置重启。业务方最怕的是切出问题收不回来，秒级回退给了他们底气，才愿意尝试灰度而不是永远停在旧版。我们给每次灰度留了完整记录，谁在什么时候放量到多少、回退了没有，事后可追溯，避免是不是切了的扯皮。粘性分桶参数我们也暴露成可调，不同业务用户分布不同，固定比例不一定适配，交给调用方自己按实际调更顺手。

调用方维度标识这块，我们特意在 token 里扩展了应用级字段，老调用方不强制升级，新规则按需带标，兼容性上花了功夫，不能因为加灰度让存量调用方报错。我们也给网关侧留了默认兜底，标识缺失时按租户整体灰度，避免新功能卡住老流量。灰度这事，兼容比花哨重要。

灰度期间的流量对照我们还加了成本视角。新旧两版单位推理成本不同，切流时顺带看费用变化，避免新版更准但贵太多，业务方事后被账单吓到。我们会把成本差写进灰度报告，让切换决策不止看效果也看钱。这点是我们被财务问过一次才加的，模型切换从来不是纯技术题，成本和效果得一起摆上桌。

灰度完成后，旧版本不是立刻删，而是保留一段时间做回滚备胎。我们吃过一次新版上线三天后暴露长尾问题的亏，幸亏旧版还在，秒切回去止血。保留期的成本不高，却换来随时能退的底气，这点和调用方灰度一样重要。

案例片段（已脱敏）： 某应用从模型 v2 灰度切到 v3，规则 5% 起步。看板显示 v3 在"发票类"问法上答非所问率 0.14，v2 仅 0.03。运营在 5% 阶段即暂停递进，算法针对该类问法补了 30 条样例做定向优化，重测后 v3 该类降至 0.04，才继续放量到 50% 直至全量。全程未影响 v2 存量流量，回退操作 0 次手动干预。

四、效果数据

灰度切入平均时长从原来业务方自己写开关加联调的约 3 天，降到约半天配置加观察。异常回退从手动改代码（平均约 40 分钟且易出错）变成网关一键秒级，异常回退误操作次数归零。对照差异的可见性提升后，全量事故（切出问题再回退不及）从季度 2 次降到 0。

调用方侧反馈最好的是"心里有底"，切换不再是一场赌博，每一步都有对照数据背书。

五、可复用经验总结

模型切换必须给调用方一个灰度开关，按应用或用户比例慢慢放，对照看新旧差异，异常一键回退，这不该让业务方自己写逻辑。我们那次出问题，根子就是网关没这能力，业务方手写的开关既不粘也不好回退，出事谁都甩不清。比例切流要做粘性分桶，不然同一用户两句问答版本跳变，体验更糟。灰度看板一定分版本独立展示，混着看等于没灰度。把切换风险收口到网关，比散落到各业务方代码里稳得多，也省了无数扯皮。