模型 EOL 倒计时：将供应商 LLM 视为外部依赖项管理

2026 年 1 月，OpenAI 仅提前两周通知便将若干 GPT 模型从 ChatGPT 中退役——而就在此前不久，其 CEO 刚刚在公开场合承诺在此次退役后会"提前充分通知"。对于那些已将工作流构建在这些模型之上的团队而言，这份公告无异于周五下午收到的一条页面报警。那一次 API 未受波及，但下一次未必如此。

你当前调用的每一个模型都有弃用日期。部分日期已列在供应商的文档页面上，另一些尚未宣布。操作层面的问题不是你的生产模型是否会被退役，而是你能否在问题发生前及时收到通知并从容应对，还是在用户开始遭遇故障后手忙脚乱地迁移。

这在软件工程中已是有解之题。库有 EOL 日期，操作系统有支持窗口期，业界数十年前就已围绕依赖项生命周期管理建立了工具、流程和文化规范。AI 工程尚未跟上，但底层模式完全相同：将模型版本视为你无法控制的外部依赖项，并据此构建系统。

季度弃用的跑步机

供应商模型弃用现已大致以季度为周期推进。仅 2024 年，Anthropic 就退役了 5—6 个独立模型版本，包括 Claude 1.x、Claude Instant 1.x 及若干 Sonnet 快照。OpenAI 的弃用页面列出了 2023 年以来数十个已退役的模型，通知期从 14 天（仅 ChatGPT 模型）到约 12 个月（旗舰 API 模型）不等。Google Vertex AI 的标准通知期目标为 6 个月，但对于平台上托管的第三方模型，最短仅给过 1 个月。

一个主要前沿模型从发布到退役的典型寿命为 12—18 个月。如果你的应用具有多个由 LLM 驱动的功能，那么任何时候都应预期至少有一项活跃的弃用迁移正在进行。三个功能时，这实际上成了持续状态。

各供应商的实际策略汇总如下：

• OpenAI（API，GA 模型）：最少 60 天通知；实际上，主要模型通常有 6—12 个月。
• Anthropic：实际通知期 60—90 天；部分主要模型获得了 6 个月。
• Azure OpenAI：GA 模型最少 60 天；预览版最少 30 天。
• Google Vertex AI：标准 6 个月；预览模型更短。
• ChatGPT UI（非 API）：最低仅 14 天。

请注意，以上任何一个窗口期都不足以让一个毫无准备的工程团队在正常迭代节奏下完成高质量迁移。那些能无惊无险处理弃用的团队，是在需要之前就建好了迁移基础设施。

"冻结版本"的幻觉

在进入处置手册之前，有必要先正视一个危险假设：锁定带日期戳的快照版本——gpt-4o-2024-08-06、claude-3-5-sonnet-20241022——能为你提供稳定的行为保证。

并非总是如此。

2023 年，斯坦福大学和加州大学伯克利分校的研究人员记录到，GPT-4 在质数识别上的准确率从当年 3 月的 84% 骤降至 6 月的 51%，降幅达 33 个百分点——而 API 版本号始终未变。相同的模型标识符，不同的行为。思维链提示的遵从率发生了变化，代码生成错误增多，OpenAI 起初坚称什么都没有改变。

2025 年初，开发者记录到 gpt-4o-2024-08-06 出现行为变化：JSON 解析失败和分类器崩溃，均未抛出 API 错误。应用表面上正常运行，实则静默出错。

在没有版本号变更的情况下发生行为漂移的情况很罕见，但确实存在。其含义是：你的回归测试套件需要持续对线上端点运行，而不仅仅在迁移时运行，以便捕获静默变更。这与你对一个无法控制的第三方 API 进行监控的方式完全一致。

模型清单：管理之前，先看清楚

任何弃用管理系统的基础，都是一份系统所调用的每个模型的最新清单。这应当是一个一等公民制品，而不是在弃用通知到来时才去代码库里用 grep 重建。

每条记录需包含：

• 精确的模型标识符（锁定的快照版本，而非别名）
• 哪些服务和功能在使用它
• 已公告的 EOL 日期（查看供应商弃用页面）
• 推荐的替代方案

llm-model-deprecation Python 库提供了一个 scan 命令，可遍历代码库查找硬编码的模型字符串，并对照其每周刷新的弃用注册表进行标记。在 CI 中运行此命令，可确保已弃用的模型名称无法通过代码审查。deprecations.info 提供 RSS/JSON 信息流，汇总了来自 OpenAI、Anthropic、Google AI、Vertex AI、AWS Bedrock 等平台的退役公告——将其接入 Slack 频道，可在邮件通知到来之前就获得预警。

一个操作细节：生产环境中绝对不要使用模型别名版本。gpt-4.1（无日期后缀）会静默解析为 OpenAI 指定的最新版本。gemini-1.5-pro（无版本后缀）在 gemini-1.5-pro-002 发布当天就开始接收该版本的流量。别名相当于供应商版本的 npm ^ 操作符——你在接受未经测试的自动升级。请锁定带日期戳的快照版本。

行为回归测试套件的真实面貌

当弃用通知到来时，迁移决策并不是"新模型在 MMLU 上得分是否更高？"，而是"新模型对于我的应用实际执行的任务，是否能产生可接受的输出？"这是两个不同的问题，答案也不同，而且只有你能回答其中一个。

基准测试陷阱是真实存在的。依赖供应商提供的新模型基准测试分数的团队发现，旧模型在其特定任务上的表现明显更优——包括客户反馈摘要、领域特定分类、具有 10 步以上的指令遵循链。基准测试衡量的是基准测试所衡量的内容，你的回归测试套件衡量的是你的应用实际做的事情。

从有据可查的迁移经验中得出的原则是：50—100 个精心挑选的黄金样本，胜过数千个合成样本。这些黄金样本应来源于：

• 关键用户路径——你绝对不能破坏的流程
• 已知边缘案例——过去曾引发问题的输入
• 结构化输出边界——你的解析器所依赖的 JSON Schema，以及用于测试 Schema 强制执行的近似输入
• 行为约束——拒绝行为、长度或语气对你的应用至关重要的案例

对旧模型和候选替代模型分别运行此套件，并在关键维度上进行评分：格式合规率、已知真值的事实准确性、响应长度方差、指令遵从度。若任何指标低于基线的 95%，即为一个标记——不一定是拦截项，但需要调查和记录。

DeepEval 提供了与 pytest 兼容的接口，用于构建这些测试套件。LangSmith 可将生产跟踪直接转换为评估数据集。关键在于在需要之前就构建好这些基础设施——在收到弃用通知后从生产流量中抽取的黄金样本，通常不包含你将在迁移过程中发现的边缘案例。

迁移处置手册

给定一份弃用通知和一套运行正常的回归测试套件，迁移分为五个阶段：

确定影响范围。 使用你的模型清单（或可观测性工具的模型使用细分数据），找出所有调用已弃用模型的服务。Anthropic 的控制台可导出包含 API 密钥和模型细分的 CSV 文件。在通知期的第一天就做这件事。

评估破坏性变更。 并非所有模型迁移都等同。2026 年初的 gpt-4o → gpt-5.1 迁移涉及更严格的 JSON Schema 强制执行、系统提示权重变化（GPT-5 强制执行了早期版本处理方式较宽松的指令层级），以及输出详细程度的变化——默认情况下输出更简短。以上任何一项都可能静默地破坏下游解析。阅读模型说明文档，阅读迁移指南（如有），并查阅社区论坛，了解其他从业者已发现的行为变化报告。

运行回归测试套件和影子流量。 在对两个模型运行黄金样本测试后，以影子模式部署候选模型——将 100% 的生产请求异步复制到新模型，用户只看到旧模型的输出。影子运行 7—14 天以覆盖完整的业务周期。追踪延迟差值、成本差值和格式合规率，若任何指标越过阈值则触发自动告警。

逐步上线。 先以 5% 的金丝雀流量运行 24—48 小时，然后分阶段提升：25% → 50% → 100%，每个阶段保留回滚能力。在 EOL 日期之前，将旧模型版本保持为热备用。

记录行为差异。 迁移完成后，记录变化了什么、哪些地方需要更新提示词，以及出现了哪些边缘案例。这将成为下次迁移的处置手册。

拥有版本化提示词和自动化回归测试套件的团队，完成此类迁移只需"几周时间"。没有这些基础设施的团队则需要"几个月"。迁移时间 4—10 倍的差异，几乎完全取决于测试基础设施是否在通知到来之前就已就绪。

让迁移成本低廉的架构

支撑快速迁移的技术模式是模型抽象层——你的应用与接口（ModelClient）交互，而不是直接调用供应商端点。更换具体实现只需修改一个配置值，而不必在业务逻辑中搜寻硬编码的模型字符串。

LiteLLM 为 100 多个 LLM 提供与 OpenAI 兼容的接口；修改一行配置，你的 gpt-4.1 调用就能路由到 claude-sonnet-4-6。Portkey 在此抽象之上增加了提示词版本管理、A/B 测试和故障转移路由。对于弃用管理而言，其核心优势在于：当你需要对新模型进行影子测试时，只需在网关层添加一条路由规则，无需修改代码。

将此与把提示词版本化为一等公民制品（而非嵌入应用代码的字符串）相结合。提示词变更应经历与代码变更相同的审查流程，具备相同的回滚能力。当模型迁移需要更新提示词时，这些变更应是可审查、可差异对比且可独立部署的。

API 架构退役问题

模型弃用是可以管理的，API 架构退役则不然。

当 OpenAI 于 2026 年 8 月退役 Assistants API（Threads/Runs）并以 Responses API 取而代之时，基于 Assistants 构建的团队面临的是全面重架构——而非配置修改。线程管理、运行轮询、文件附件处理，所有这些都需要重新实现。这与将 gpt-4o-2024-08-06 替换为 gpt-5.1-preview 是截然不同的迁移类型。

类似的风险存在于你的系统与供应商特定原语耦合，而非标准接口的任何地方。OpenAI 的结构化输出模式、Anthropic 的工具调用格式、供应商特定的函数调用 Schema——这些都可能以模型抽象层无法保护你的方式被退役或变更。

此处的缓解措施是限制供应商特定耦合的表面积。在标准接口存在的地方使用标准接口（与 OpenAI 兼容的 API 被广泛支持）。将供应商特定代码隔离到适配器模块中。当你发现自己与供应商特定的 API 原语深度集成时，明确记录该依赖项——这是一项负债，应与模型版本一样具有同等的可见性来追踪。

设置内部 EOL 截止日期

一条可靠的操作规则：将内部迁移截止日期设置为 EOL 日期前 30 天，目标是 EOL 日期前 60 天。这为最慢路径的迁移（出现意外的破坏性变更，需要提示词工程迭代）留有缓冲，同时又不必在通知到达的瞬间就开始工作。

60 天的缓冲还给你留出了运行完整两周影子流量的时间，在截止日期前仍有四周用于金丝雀上线。在 30 天时才开始迁移的团队，实际上是在赌新模型行为不会出现任何意外——而意外频繁到足以列入计划。

让这套机制运转起来的关键，是在你有具体弃用需要处理之前就将其构建完毕。模型清单应是一份长期维护的制品，每次部署新模型时都要更新。回归测试套件应随着每次生产问题的出现而增长。影子流量能力应作为评估新模型版本的常规方式，而不是在截止日期压力下临时搭建的一次性项目。

将模型视为依赖项

核心框架是业界迟迟未能采纳的那一个：供应商 LLM 是外部依赖项。它们有版本发布，有支持窗口期，有破坏性变更，会被弃用。

软件业界关于依赖项管理所积累的一切知识都适用于此。锁定特定版本，追踪 EOL 日期，升级前运行回归测试，维护有据可查的迁移路径，在紧急情况发生前就构建好工具链。

那些能以最小干扰处理模型弃用的团队，并没有做什么特别的事情。他们只是将标准的依赖项管理规范应用到了大多数团队至今仍视为魔法的那部分技术栈——而且是在 EOL 倒计时耗尽之前就做到了这一点。