开源模型一旦受限，团队先丢的是切换能力

模型一旦开始受限，最先坏掉的通常不是推理结果，而是切换能力。接口名还在，仓库还在，原来的产线却开始卡在额度、区域、鉴权和合规提示上。真正麻烦的不是少了一个模型，而是发现原来那条路径只适合“继续用原模型”，不适合“在同一周内换到另一套栈”。

这类变化在产品侧看起来像某个供应商不可用，在工程侧其实是一次依赖暴露。提示词、输出解析、函数调用 schema、长上下文长度、token budget、重试节奏、风控阈值，全都藏在原模型的默认行为里。只要替换对象一变，这些默认值就要重新过一遍。

切换窗口先暴露问题

外部限制真正到来时，团队经常才看清楚，评测不是一条分数线，而是一整套对齐动作。旧模型把空白填得很顺手，新的开源模型也许在 benchmark 上并不差，但在 JSON 稳定性、拒答口径、工具调用顺序上会出现不同的毛刺。毛刺单独看都不大，连起来就会把自动化链路顶坏。

更难受的是，这种差异通常不会一次性爆出来。第一页看起来正常，第二页开始漏字段，某次函数调用多绕了一步，某个重试在边界条件下把旧结果回灌回来。上线以后，表面上还是同一个模型名，实际已经换成了另一种行为分布。

重新对齐比替换模型更慢

把一个模型替换掉，往往要同时替换四件事：输入格式、输出验收、异常回退、监控阈值。只替模型不动这些东西，结果就会变成同一套业务逻辑在两种行为分布里摇摆。线上最难看的故障，通常不是完全失败，而是偶发地成功、偶发地漏字段、偶发地多吐一句解释，后面系统又把这些边角当成正常输入继续传下去。

这也是为什么“能跑”不等于“能迁移”。开源模型的价值确实在于可替代，但替代不是把权重指过去就结束了。只要输出格式、工具调用和长度上限还没重新收紧，迁移就只完成了一半。表面上的模型切换，最后会变成提示词、解析器、重试器和回滚链条的联合改造。

备用路径要按正式路径建设

备用模型如果只放在文档里的某个“降级方案”小节，到了真要切换时基本来不及。更稳的做法，是把主模型和备用模型都纳进同一套基线：同一批样本、同一套指标、同一版解析器、同一条发布回滚链。这样变化来时，切换只是在已经跑过的路径里改路由，不是临时造一套新系统。

这件事最值钱的地方，不在于备用模型有多便宜，而在于它有没有被当成正式能力维护。真正成熟的团队，不会把“换模型”理解成一次采购动作，而会把它看成一条运行时路径。路径平时可能不用，但只要外部收紧、额度变化、区域限制变严，这条路径必须能自己站起来。

开源模型能不能继续拿到，只是第一层问题。更现实的判断是，团队有没有能力在外部模型收紧后，把工作流平滑搬到另一套栈上，而不是把业务停在原地等供应商恢复。真正要保住的不是某个模型名字，是一条能反复切过去的路径。