模型弃用本质上是系统迁移：如何应对模型供应商的停用计划

一家运行生产级 AI 分诊助手的医疗保健公司收到了一封令所有团队都心生畏惧的邮件：他们的推理服务商将在 90 天后停用他们正在使用的模型。他们更新了模型字符串，进行了快速的手动冒烟测试，然后发布了替代版本。三周后，新模型开始主动提供未经请求的诊断意见。Token 使用量暴增了 5 倍。整个 Prompt 模板由于新模型对指令表述的解读不同而失效。由于输出 Schema 发生了偏移，JSON 解析也宣告失败。

这并非个案。如果你仅仅将模型停用视为一种配置变更，而不是一次系统迁移，那么这就是你在模型停用周期中的常态体验。

LLM 服务商已经进入了一种激进的弃用节奏。OpenAI 在单次弃用浪潮中退役了 33 个模型。Anthropic 承诺在退役公开发布的模型前，至少提前 60 天通知。由于直到客户开始迁移才显现出来的功能对等差距，Google 将 PaLM 到 Gemini 的过渡期延长到了 2026 年。这种节奏并没有放缓——在 2025 年上半年，前沿服务商发布了超过 12 个主要模型版本。其中的每一次发布，都会在某些人的日程表上埋下一个未来的弃用事件。

处理得当的团队不仅仅是更换模型 ID。他们像进行任何其他生产系统迁移一样来处理模型停用：使用抽象层、回归测试套件、分阶段发布和回滚计划。而处理不善的团队则会太晚发现，他们的“迁移”实际上是一次彻底的重构。

为什么更换模型会破坏生产系统

对更换模型的天真心理模型是：新模型，旧行为。而现实情况是，来自同一服务商、在相邻数据上训练且架构相似的两个模型，对于同一个 Prompt 可能会产生截然不同的输出。

输出 Schema 偏移是最常见的失败案例。除非你的 Prompt 强制执行，否则模型不会绑定到特定的 JSON 结构——即便如此，不同的模型对结构化指令的解读也不同。OpenAI 模型倾向于 JSON 结构化输出；Anthropic 模型则更倾向于格式无关，并会遵循 Prompt 中最明确指定的任何 Schema。当你跨代迁移时，假设了特定字段顺序、键命名规范或嵌套深度的后处理代码可能会无声无息地失效。应用程序继续运行；它产生着自信、格式良好但细微错误的答案。

拒绝率的变化在测试中更难发现，因为它们是概率性的。GPT-4.1 在上下文达到 2500 字左右时表现出约 2.5% 的拒绝率；Claude Opus 4 在同一 Prompt 类别下具有不同的风险阈值，拒绝率接近 2.9%。你之前的模型无需多言即可处理的任务，在后继模型中可能会触碰安全边界。在低请求量时，这看起来像噪声。在大规模运行时，它就变成了功能退化。

分词器（Tokenizer）偏移是讨论最少、但也可能是成本最高的失败模式。当服务商在不同代模型之间更换分词器时，相同的输入文本会映射为不同数量的 Token。研究观察到偏移量高达 112%——这意味着原本耗费 500 Token 的 Prompt 现在需要超过 1000 Token。这会引发连锁反应，导致成本膨胀、有效上下文窗口缩短以及触发频率限制。它还创造了安全隐患：当团队在威胁模型中未考虑分词器行为时，旨在最大化 Token 消耗的对抗性输入会变得更加有效。

上下文腐化（Context rot） 随着上下文窗口的变化而加剧。新模型通常宣称拥有更大的标称上下文窗口，但最大有效上下文窗口——即模型保持可靠准确性的范围——可能不会按比例扩展。一个声称拥有 200K Token 上下文窗口的模型，在复杂的检索任务中，超过 50K Token 后可能会出现显著退化。迁移到具有更大窗口的模型并不自动意味着你的长文本工作负载会得到改善。

Prompt 兼容性会以更微妙的方式失效。较新的前沿模型往往对明确、直接的指令响应更好，而对于那些为了引导旧模型行为而必须采用的 Prompt 工程技巧，其表现反而更差。像“step by step”或“you are an expert in X”这种在旧模型中起支撑作用的指令，在后继模型中可能会被忽略、误解，甚至产生负面影响。你针对上一代模型进行的整个 Prompt 调优工作会部分失效。

你早就该构建的抽象层

能够平滑处理模型停用的团队都有一个共同的架构决策：他们的应用程序代码从不直接调用特定的模型 API。每一次 LLM 调用都通过一个内部抽象层进行路由——这是一个轻量级包装器，它接收规范的 Prompt 表示，并在运行时将其转换为当前服务商的格式。

这并不是什么奇特的架构模式。这与数据库应用程序为了避免硬编码 SQL 方言而使用的关注点分离（Separation of Concerns）是异曲同工的。抽象层完成了三件事：

• 它将模型选择与业务逻辑解耦。应用程序知道它想要完成什么；抽象层知道该调用哪个模型以及如何为该模型格式化请求。
• 它为模型更换创造了单一变更点。当一个模型停用时，你只需要更新抽象层的路由表，而不是几十处散落的调用点。
• 它实现了流量切分。一个构建良好的抽象层可以将配置比例的请求路由到金丝雀（Canary）模型，而其余请求继续访问稳定模型。

抽象层还应维护一个 Prompt 兼容性矩阵——记录哪些 Prompt 版本已针对哪些模型版本进行了验证。Prompt 是生产资产。它们跨模型代际产生的偏移和破坏，就像任何其他接口契约一样。将其视为配置而非代码，是团队积累技术债的一种方式，而这些债务只会在迁移期间爆发。

回归测试框架

在没有回归测试框架的情况下让模型退役，等同于在你的生产用户身上进行一场失控的实验。在更换模型之前，回归测试框架能为你提供“好”的明确衡量标准。

该框架需要三个组成部分：

黄金数据集。 一个包含 50 到 200 个代表性输入的集合，覆盖系统处理的任务范围——包括边缘案例、低频输入，以及最可能导致模型间行为差异的提示词模式。该数据集应独立于提示词编写者进行审查，以防止出现向恰好有效的案例倾斜的选择性偏差。

每个测试用例的评估标准。 不仅仅是“输出看起来是否合理”，而是一个结构化的正确性定义。对于结构化输出，这意味着 Schema 验证加上对字段值的语义检查。对于自由文本输出，这意味着使用单独的评审模型进行自动评估、人工标注，或两者兼而有之。标准需要足够具体，以确保两名评估者对给定的输出是否通过能达成一致。

对比报告。 将相同的黄金数据集分别在旧模型和新模型上运行，并将差异展示出来供人工审查。寻找旧模型通过而新模型失败的情况。同样要寻找即使两个版本在技术上都正确但输出结构发生变化的情况——Schema 漂移通常在演变成生产事故之前就会在这里显现。

针对 LLM 迁移的自动化回归工具研究表明，使用结构化对比工具的团队识别出的行为差异是进行人工审查团队的两倍，同时在相同的时间预算内探索了比后者广 75% 的提示词变体。一次性构建此框架的投入将在随后的每一次模型退役中获得回报。

升级指南

模型退役是可预见的事件。供应商会提前数月宣布。将迁移作为紧急演习来运行是一种选择，而非必然。

迁移应该在退役日期前 60 天开始，而不是最后 5 天。行之有效的路线图如下：

第 1–2 周：基准测试与发现。 针对即将退役的模型及其指定的继任者运行你的黄金数据集。生成对比报告。识别每一个失败的测试用例，以及每一个改变了 Schema 或结构的输出。

第 3–4 周：提示词修复。 对于每个失败的测试用例，确定修复方案是更改提示词还是应用层更改。提示词更改应像代码更改一样进行版本化、审查并提交到源码控制系统。跟踪哪些提示词已针对新模型完成了验证。

第 5–6 周：影子模式测试。 同时将实时生产请求发送到两个模型。丢弃新模型的响应但保留日志。将日志与旧模型的实际响应进行对比。这能发现分布偏移——即黄金数据集未覆盖的案例，因为它们代表了稀少但真实的生产输入。

第 7 周：金丝雀发布。 将 1–5% 的实时流量发送到新模型。监控关键指标：错误率、拒绝率、输出 Schema 验证失败率、Token 使用量、延迟，以及 AI 功能驱动的任何下游业务指标（转化率、活跃度、下游决策的准确性）。在扩大规模之前，针对具有代表性的流量模式，将金丝雀发布维持至少 48 小时。

第 8 周：全量发布。 如果金丝雀指标正常，则扩展到 100% 的流量。在抽象层中保留旧模型端点至少两周，作为回滚目标。

回滚策略与迁移路径同样重要。如果金丝雀发布显现出回归问题——如拒绝率飙升、输出 Schema 失败、业务指标下降——你需要能够在几分钟内（而不是几小时）将所有流量切回旧模型。抽象层的流量路由表应该支持在不部署的情况下进行热重载。

迁移后需要监控的内容

当新模型的流量达到 100% 时，迁移并未完成。新模型下的生产行为是一个新的基准，而不是旧基准的延续。

迁移后前 30 天内最重要的指标包括：

• 每个提示词类别的拒绝率。 按任务类型分解拒绝情况。整体稳定的拒绝率可能掩盖了某个特定提示词类别持续触碰安全边界的情况。
• 每个请求的 Token 使用量。 新模型中的分词器变化或冗余度偏移将在这里显现。持续的上行漂移是信号，而非噪声。
• 输出 Schema 验证失败率。 如果你根据 Schema 验证结构化输出，该指标应接近于零。任何非平凡的失败率都意味着新模型在某些你在测试中未捕捉到的输入类别中偏离了预期格式。
• 下游准确性指标。 如果你的 AI 功能为下游决策提供输入（如搜索排名、内容过滤、推荐系统），请监控这些决策的质量，而不仅仅是 LLM 的输出质量。模型中的行为变化可能会隐蔽地通过下游系统传播。

捕获问题最快的团队，是在迁移开始前就已建立这些指标仪表盘的团队，而不是在事故发生后才去建立。

组织维度

模型退役暴露了一个大多数团队发现得太晚的结构性问题：AI 系统的行为并没有完全在代码中定义。大量的行为存在于 prompt 中、下游系统的隐含预期中，以及最初进行模型集成调优的人员的制度化知识中。

当模型发生变化时，所有这些隐含知识都需要重新验证。如果这些知识从未被记录下来，重新验证就必须通过反复试验来完成，这就是导致迁移成本高昂的原因。那些报告迁移成本在 30,000 美元到 250,000 美元以上的团队，通常是在为 prompt 修复工作、回归测试，以及在产品、工程和运营部门之间就什么是“正确行为”达成一致的协调开销买单。

将行为预期记录下来——以黄金数据集、评估标准和 prompt 兼容性矩阵的形式——的投资，主要不是一项技术投资，而是一项组织层面的投资。它创建了一个关于正确性的共同定义，在模型退役、团队更迭以及关于新模型不同行为到底是 bug 还是 feature 的不可避免的争论中存续下来。

在“弃用跑步机”上生存的姿态

供应商不会放慢发布和退役的节奏。经济因素在向相反的方向推动：新模型开启了新能力，从而开启了新收入，并为下一代模型提供资金。12 到 18 个月的平均模型寿命并不是领域成熟前的临时状态。这就是运营环境。

那些能够以最小干扰消化模型退役的团队已经内化了两件事。首先，模型是一个具有文档记录周期的外部依赖，就像第三方库一样——你需要用同样的规程来管理它：抽象、版本锁定、自动化测试和计划内的升级周期。其次，为一次迁移构建的回归测试框架具有复利价值。每一次退役都比上一次更容易，因为黄金数据集在增长，评估标准变得更精确，操作手册（runbook）变得更精简。

那些把每次退役都当作突发事件的团队，正是那些每次都要从头开始重建的团队。区别不在于技术复杂性，而在于模型迁移是否被视为一等公民的工程规程，还是被视为一种事后补救。