AI 产品上线后，几乎不可能永远停留在同一个模型上。价格会变，能力会变，供应商会变，组织自己的成本和合规要求也会变。于是“换模型”就成了一件迟早要做的事。
问题在于，模型迁移从来不是把 model=old 改成 model=new 那么简单。很多线上事故，恰恰发生在团队以为这只是一个配置改动的时候。因为模型变化往往会同时带来输出风格、上下文限制、工具调用行为、错误语义乃至时延分布的变化，最后受影响的并不只是推理结果，而是整条产品链路。
更进一步说，模型迁移几乎总发生在系统已经跑起来之后。你不是在白纸环境里替换一个依赖，而是在真实用户、真实日志、真实预算和真实业务流程的压力下换核心能力。这意味着迁移这件事必须被当成一次产品级发布，而不是工程师自己的内部优化。
先确认你到底在迁移什么
很多团队说自己在“迁移模型”，实际上迁移的是好几件事叠加：
- 底层模型换了。
- provider 换了。
- 默认 Prompt 跟着换了。
- 参数和采样策略改了。
- 回退链路也一起调整了。
如果这些变化同时发生，最后即使结果变差，也很难知道问题源头在哪里。所以更稳妥的方式，是把迁移对象拆开，一次只验证一个主要变量。
最常见的失败方式，就是把一整组变化打包成“升级”。工程上这样做很省事，管理上也像是一次性完成目标，但对风险控制极不友好。因为一旦线上效果下降，你根本无法判断到底是底层模型能力变了，还是 Prompt 假设被破坏了，还是 provider 封装差异导致工具调用不稳定。迁移真正的难，不在于切换，而在于定位和可回滚。
迁移前，先做一份完整清单
成熟团队在切模型前，通常不会急着跑压测，而是先做一份迁移清单。清单里至少要回答这些问题：
- 当前模型服务哪些具体场景。
- 哪些场景是实时链路，哪些是异步链路。
- 哪些 Prompt、工具和工作流与它绑定。
- 是否有结构化输出、函数调用、JSON 模式等特殊依赖。
- 是否有关键客户或关键业务仅依赖这一个模型。
- 当前是否存在隐藏的回退、缓存或人工处理兜底。
很多平台上线久了之后，会逐渐形成大量“未被文档化的默认假设”。平时这些假设不显眼，但迁移时会集中爆炸。所以清单的价值，不只是帮助迁移，而是逼团队把原来那些依赖关系显式化。
兼容性先看四个地方
模型迁移前，我们通常先检查四类兼容性：
- 输入兼容性。上下文长度、消息格式、工具描述、结构化输出约束是否一致。
- 输出兼容性。文本风格、字段格式、JSON 稳定性、函数参数习惯是否一致。
- 性能兼容性。首响应、完整响应和尾部时延是否还在预算内。
- 成本兼容性。表面价格变化之外，重试率和回退率会不会一起变。
很多迁移之所以失败，不是因为新模型不够好，而是因为它没有兼容原本链路里那些“默认存在”的假设。
在这四类之外，还有一个很容易被忽略的点：行为兼容性。也就是说，新模型在相同输入下，是否还遵循原来的“产品习惯”。有些模型会更积极地下结论，有些模型更保守；有些模型更喜欢解释过程，有些模型更倾向给简短答案；有些模型明明结构正确，但语气和风格已经让用户感到产品“变了一个人格”。这些变化不一定能在传统准确率指标里体现出来，却会直接影响产品连续性。
离线评测只能筛掉明显问题
模型迁移前当然要做评测，但必须承认，离线评测能解决的问题是有限的。它擅长筛掉大方向错误，例如质量大幅退化、格式明显不兼容、某类任务普遍变差；但它很难完全模拟真实流量中的边界情况，例如复杂上下文拼接、异常输入、不同用户使用习惯以及峰值时段的负载波动。
因此更现实的做法，是把离线评测视为“进入灰度的门票”，而不是“可以全量上线的证明”。评测通过，只说明这次迁移值得进入下一阶段观察，不说明风险已经清零。
灰度不是可选项
只要线上流量还在跑，模型迁移就应该灰度。哪怕评测集结果很好，也不代表真实流量里不会出现新的边界情况。更何况很多问题只有在生产负载、生产上下文和真实用户行为下才会暴露。
一个更稳妥的迁移节奏通常是：
- 先在离线评测集中验证基础质量。
- 再在低风险任务上放少量真实流量。
- 观察稳定性、时延、结构错误和人工反馈。
- 确认没有明显退化后，再逐步扩大范围。
灰度的意义并不是“慢一点”，而是给系统留下足够大的纠错空间。
灰度策略本身也要分层。不是所有请求都适合同样的灰度顺序。通常更安全的路径是：先灰度到低风险、低价值、可人工补救的链路，再逐渐进入高频主路径和高价值业务。如果团队反过来做，先把实验直接放到核心场景，问题一旦出现，损失会被迅速放大。
回滚路径必须提前设计
模型迁移很容易出现一种情况: 大家都在想怎么切过去，却没人提前想好怎么切回来。等真正出了问题，才发现旧模型的配置、Prompt、回退规则甚至预算配额都已经改掉了，这时回滚就会变成新的风险动作。
所以我们更倾向于把回滚当成迁移设计的一部分。理想状态下，回滚应该像开关切换一样简单，而不是一次新的工程变更。
这背后有一个很重要的原则：不要在切换过程中破坏旧世界。也就是说，在新模型尚未稳定之前，尽量保留旧模型的可运行状态，包括配置、凭证、Prompt 版本、回退权重和预算边界。很多团队的问题就在于切换太彻底，以为这样更干净，结果一旦回滚，就必须临时恢复一堆已经被覆盖的依赖。
迁移窗口要和业务节奏匹配
模型迁移不是孤立动作，它会和业务节奏冲突。比如客户高峰期、月末结算期、大促活动、重要发布周，这些时间点都不适合做高风险迁移。哪怕技术团队已经准备完毕，也应该把迁移窗口放在组织可以承受观察成本和回滚成本的时段里。
这件事经常被低估，因为很多研发团队只从“什么时候有空”看迁移，而不是从“什么时候出问题代价最低”来看。真正成熟的迁移计划，一定会把业务窗口纳入考虑。
迁移责任必须归属明确
另一个常见问题是，迁移涉及的人很多，但责任边界不清。模型工程师负责能力评估，平台工程师负责路由和回退，产品负责人关注体验，运营又掌握一线反馈。如果没有一个明确 owner 把整个迁移过程串起来，团队很容易在出现异常时陷入互相等待。
更稳妥的做法，是提前明确：
- 谁负责做迁移决策。
- 谁负责评测和数据对比。
- 谁负责灰度观察和告警处理。
- 谁负责最终放量和回滚开关。
只有责任被明确，迁移才不会在关键时刻变成协同失灵。
阴影流量和双跑，对很多场景都值得做
如果业务链路足够关键，仅靠离线评测和小流量灰度，有时还不够。更稳妥的方式是做一段时间阴影流量或双跑比较，也就是让新旧模型在相同输入下同时运行，但只有旧模型结果对用户生效，而新模型结果只用于观察和比较。
这种方式虽然会带来额外成本，但能提前暴露很多只在真实输入下才会出现的问题，例如：
- 新模型在某些特定措辞下更容易误判意图。
- 新 provider 的结构化输出更不稳定。
- 新模型在高峰时段的尾部时延明显更差。
- 某些提示词在新模型上表现分化更大。
阴影流量的价值，在于它让团队能在不影响线上体验的前提下，看见真实差异。对关键产品来说，这种额外成本通常是值得的。
不要忽略依赖方沟通
模型迁移看起来像平台内部动作，但很多时候外部依赖方也需要被提前通知。比如使用方团队、客服运营、数据标注人员、风控同学、客户成功团队，他们未必参与技术实现，却可能第一时间感受到变化。如果这些人没有被提前告知迁移窗口、观察重点和反馈入口，那么平台即使已经做了很多准备，最终也会错过最关键的一线反馈。
更成熟的迁移做法，通常会在放量前明确：
- 哪些人需要重点观察结果变化。
- 出现异常时该走什么反馈路径。
- 哪些变化属于预期内，不需要误判成事故。
- 哪些症状一旦出现，应当立即触发回滚判断。
这类沟通听上去不像技术工作，但它对迁移成功率影响极大。
迁移完成后，还要有一段稳定观察期
很多团队在新模型全量后就宣布迁移结束，这其实太早了。更合理的做法，是保留一段稳定观察期，继续跟踪质量、时延、成本、人工接管率和用户反馈。因为有些问题只会在规模扩大后出现，例如缓存模式变化、预算结构变化、某些低频边界场景被放大。
稳定观察期的重点不是证明迁移“已经成功”，而是确认系统是否真的进入新的平衡状态。只有过了这段时间，旧模型相关资源才适合逐步下线。
别把一次迁移当成最终答案
很多团队做完一次迁移后，会默认“这件事完成了”。其实更有价值的做法，是把迁移过程沉淀成模板。因为模型生态变化太快，下一次迁移一定还会来。真正该积累的不是某次成功切换的结果，而是迁移方法本身：评测清单、灰度顺序、回滚标准、异常样本、沟通模板。这些才是团队下次能不能更稳更快完成迁移的关键资产。
迁移后最好沉淀一份“兼容性档案”
每做完一次模型迁移，团队其实都会得到一批非常有价值的信息：哪些 Prompt 在不同模型下表现差异最大，哪些工具调用最脆弱，哪些任务对时延最敏感，哪些 provider 封装差异会影响输出结构。这些信息如果只停留在某次项目复盘里，很快就会散掉；但如果把它们整理成兼容性档案，下次迁移成本会显著下降。
一份实用的兼容性档案通常会包括：
- 不同模型在关键任务上的行为差异。
- 已知不兼容项和规避方式。
- 某些 Prompt 或参数为什么不能直接复用。
- 某类工作流在迁移时需要额外关注的风险点。
- 已验证可行的灰度和回滚模式。
这类档案的价值，不在于写得多漂亮，而在于它让团队不必每次都从零重新踩坑。
结语
换模型是 AI 产品的常态，不是例外。真正成熟的团队，不会把模型迁移看成一次“升级”，而会把它当成一次需要严格验证、可灰度、可回滚的发布动作。
当你开始从依赖清单、兼容性验证、业务窗口、责任归属和回滚设计这些角度看待迁移时，模型切换就不再只是“换一家更强的供应商”，而是一次完整的系统治理过程。这样做虽然麻烦，但能避免最贵的一类代价：用线上体验去替代本该提前完成的验证。
换模型是 AI 产品的常态，不是例外。真正成熟的团队，不会把模型迁移看成一次“升级”，而会把它当成一次需要严格验证、可灰度、可回滚的发布动作。这样做虽然麻烦一些，但能避免最贵的一类代价: 用线上体验去替代本该提前完成的验证。