模型弃用跑步机：在收到停用通知邮件之前必须建立的规范

那些将“我们使用最新模型”视为美德的团队，距离长达一个季度的计划外工作只差一封下线邮件。当弃用通知送达时，决定你是否能消化它的架构决策早在几个月前就已经做好了——而且是由那些根本没考虑过迁移的人做出的。评估套件（eval suite）隐式地针对特定检查点（checkpoint）进行了训练。提示词（prompts）是针对特定的拒绝风格（refusal style）进行调整的。成本预测假设了特定的任务令牌（token-per-task）基准。路由器的硬编码回退（fallback）模型本身也即将消失。在邮件到来之前，这些决策看起来都不像是风险，而一旦邮件到来，它们看起来就全都是同一种风险。

模型弃用现在是 AI 技术栈中最可预测的意外。Anthropic 对公开发布的模型至少提供 60 天的通知期。OpenAI 的通知窗口从针对特定快照（snapshot）的 3 个月到针对基础模型的 18 个月不等，但在实践中，最近一批 ChatGPT 模型的退役对某些团队来说只有短短两周的预警。GitHub 在 2026 年 2 月的一次协调变更日志条目中，集中弃用了一系列 Anthropic 和 OpenAI 模型。现在的模式不再是“如果模型退役”——而是“每个季度，你的技术栈所依赖的至少一个模型会进入退役窗口，而这个时间表与你的路线图并不同步”。

这篇文章不是在邮件送达当天的迁移指南。它关乎的是在邮件到来之前必须具备的纪律，这样迁移就只是两周的机械式工程工作，而不是一个季度的评估闹剧、提示词考古和向客户道歉。

模型 ID 是一个带有公开停服日期（EOL）的依赖项

将能够消化弃用的团队与被其击垮的团队区分开来的唯一心态转变是：停止将模型标识符视为品牌名称，而开始将其视为带有公开停服日期（EOL）的库版本。

当你依赖 openssl 1.1.1 时，你不会写“使用安装的任何 OpenSSL”这样的代码。你会固定（pin）一个特定版本，跟踪该版本的 EOL 时间，并计划在安全补丁停止前完成升级。这种纪律在系统工程中如此普遍以至于几乎是隐形的——没有人会写博客讨论为什么要固定 OpenSSL 版本。

在 LLM 技术栈中，类似的纪律却很罕见。人们编写的默认代码通常是 model="claude-sonnet-4-6" 或 model="gpt-5" ——这些简短的别名（alias）会解析为请求当天提供商的任何当前默认版本。Anthropic 的文档明确区分了快照标识符（如 claude-opus-4-5-20251101，它是可复现的、版本固定的，并带有公开的退役日期）和始终指向系列中最新发布版本的滚动别名。固定版本至关重要，因为退役日期是真实存在的：Anthropic 的弃用表列出 claude-opus-4-20250514 将在 2026 年 4 月 14 日弃用，并在 2026 年 6 月 15 日退役。62 天。如果你的调用点使用的是别名 claude-opus-4，在出现故障之前，你根本不知道自己处于这条线的哪一侧。

这种懒惰的别名使用带来的代价是，你无法回答弃用邮件逼你面对的最基本问题：“我们的技术栈中哪里调用了这个模型？”如果没有针对每个调用点固定版本的注册表，答案只能是“我们会全局搜索一下，但可能会漏掉那些动态构建的调用点”。

版本化模型注册表

下线前基础设施的第一部分是版本化模型注册表。其形式很简单：一个单一事实来源，将每个生产调用点映射到已测试的特定模型快照、上次运行测试的日期，以及运行其提示词的负责团队。

注册表应当是构建产物，而不是电子表格。它需要是机器可读的、签入代码库的，并且是强制执行的——这意味着调用未在注册表中声明的模型的请求应该在 CI 或部署阶段失败，而不是静默地路由到 SDK 选择的任何默认模型。

一个可行的架构包括：

• 调用点标识符：一个稳定的字符串，如 support-classifier 或 ingest-extractor，用于命名业务面而非文件路径。
• 固定的模型 ID：带有日期后缀的完整快照标识符，绝不是别名。例如 claude-opus-4-5-20251101，而不是 claude-opus。
• 提供商和路由层级：直接 API、Bedrock、Vertex 或自托管，因为不同平台的弃用时间表各不相同。
• 上次评估基准：评估套件针对该特定模型版本最后一次运行的日期，附带运行记录链接。
• 所有者：指定的团队——不是平台邮件列表，不是“AI 基础设施”，而是一个拥有 Slack 频道和值班（on-call）轮转的团队。
• 退役日期：从提供商的弃用表中复制，附带来源 URL。

注册表在第一封下线邮件到达时就能体现其价值。与其花一周时间进行“全局搜索并祈祷”，不如查询注册表，获取受影响的调用点列表，传呼其所有者，并在已知范围内开始迁移。

弃用日历应与证书过期时间放在一起

没有日历的注册表只是一份清单。第二件基础设施是弃用日历——一个单一的时间线，追踪每个模型的停用日期，以及团队已经在管理的各种运维截止日期：TLS 证书过期、云端额度续期、供应商合同周年纪念、合规审计窗口。

将模型停用与证书过期放在同一个日历上的原因并非象征性的——而是因为组织已经具备了处理证书续期的“肌肉记忆”。有人负责它，有现成的操作手册（runbook），如果错过截止日期，还有呼叫升级流程。模型弃用需要同样的机制，而构建这种机制最廉价的方法就是将这项工作挂靠在已经拥有该机制的日历上。

日历中的每个条目都应包含：

• 停用日期（供应商发布的）。
• 迁移目标日期，保守设定为停用日期前 30 天，为意外情况预留空间。
• 指定负责人（带有呼叫升级流程，而非团队别名）。
• 回滚模型，同样需要固定版本，同样在同一个日历上并有自己的停用日期。
• 评估基准负责人，负责运行 n+1 评估。

日历应放在显眼的地方。不是在某个 PM 的 Notion 文档里。而是在列出“AWS 预留实例续期——2026 年 9 月”和“SSL 证书更换——2026 年 12 月”的同一个地方。

N+1 评估套件持续运行

迁移痛苦最深的根源在于：团队针对当前模型运行评估套件，然后在 60 天停用窗口的第 28 天发现，替代模型在 12% 的评估案例中失败了。错误不在于失败率，而在于直到截止日期临近才发现失败率。

解决这一问题的纪律是：每个生产环境的调用点不仅针对当前固定的模型运行其评估套件，还要针对 n+1 候选模型持续运行。当 claude-opus-4-5 在生产环境中运行时，该套件每晚也会针对 claude-opus-4-6 和 claude-opus-4-7 运行。这样，迁移差异在截止日期前几周就是已知量，而不是在第 28 天才跳出来的惊喜。

这比听起来要便宜。生产级 LLM 功能的评估套件通常有 50 到 500 个案例，每晚运行只需几分钟的计算量，其成本与恐慌性迁移的成本相比微不足道。其产出是一个仪表板：对于每个调用点，这里显示当前模型的通过率、n+1 模型的通过率、两者之间的差异，以及出现退化的案例 ID。

n+1 评估的隐藏好处是，它能在你有时间修复时暴露“提示词可移植性”问题。在 gpt-5.3 上表现出色但在 gpt-5.4 上表现糟糕的提示词，说明该提示词是针对旧模型的特性进行调优的。这是一个维护性漏洞，你宁愿在 3 月份的某个周二发现它，也不愿在模型停用前的周五才发现。

跳过这一步的团队最终还是得运行它，只不过是压缩在迁移窗口的最后一周，伴随着恐慌的工程师和糟糕的 Slack 讨论串。工作内容是一样的，唯一的变量是进度表。

回退路由器本身就是一个陷阱

大多数生产 LLM 系统都有回退路由器：如果主模型返回错误或超时，则针对备用模型进行重试。这种模式很好，但实现方式几乎总是错的。

错误的实现方式：备用模型被硬编码为一个模型别名，而不是具体快照。primary: claude-opus-4-7, fallback: claude-sonnet-4。这个备用模型没有固定版本，不在弃用日历上，不在评估套件中，而且离供应商停用该模型仅一步之遥。当回退路径真正触发时（它确实会触发，因为主模型会发生故障），系统会静默地路由到别名在当天所指向的任何模型，且没有评估基准。

正确的实现方式：回退模型本身就是一个注册表条目。固定快照、有负责人、经过评估测试。在弃用日历上列出并带有自己的停用日期。除了请求量较小外，在各个维度上都将其视为主模型。

这在书面上听起来显而易见，但在实践中几乎被普遍违反。这种不对称性在于，主路径因为是热点而受到关注。而回退路径只有在触发时才会受到关注，到那时你已经处于事故中了。预先构建回退注册表条目，并保持与主模型相同的严谨性，是避免“我们的回退模型三周前就停用了，直到发生故障我们才注意到”这种失败模式的唯一方法。

规划中无人提及的成本框架

以下是应该出现在平台团队季度规划幻灯片上的成本数据：一次强制模型迁移大约需要每个功能点（surface）两人周的工作量，加上评估基准重新对齐，再加上客户沟通稿的起草周期。

“每个功能点两周”的估算是各项报告中迁移工作量的中位数：当旧提示词失效时的重新调优、当 JSON 格式发生偏移时的输出解析器修复、当新模型在相同工作量下耗时增加 20% 到 40% 时的延迟重新调优，以及验证所有这些工作的测试人力。如果提示词足够健壮且评估套件状态良好，有些迁移可能只需一半时间。有些则可能是五倍——例如当新模型是推理模型而旧模型不是时，需要近乎完整的提示词重写和新的延迟预算。

将其乘以生产功能点的数量。一个运行五个 LLM 驱动功能的团队，在供应商每次停用模型时都要经历五次这样的过程。如果两家供应商每季度停用一次，这意味着在开发任何新功能之前，每年大约有 40 人周的强制迁移工作。这是一名全职工程师在无限期地吸收模型弃用工作，作为选择构建在托管模型之上的“税费”。

这个数字并不是停止构建在托管模型上的理由。它的意义在于在规划中公开这项成本，使其获得资金支持、明确负责人并可预测——而不是作为每季度的意外发现来挤占路线图。

夺回议价能力的合同模式

默认的企业级 AI 合同赋予了供应商对弃用时间线的单方面控制权。60 天的通知期是一个底线，而非谈判的结果。对于那些产品实质性依赖于特定模型行为的团队——如微调包装器 (fine-tuned wrappers)、受监管的工作流、具有性能 SLA 的面向客户的功能——这种默认条款过于薄弱。

能够换回议价能力的合同模式是在签署企业协议之前，协商确定指定模型版本的最低支持窗口。其形式包括：

• 指定版本承诺：合同中明确列出供应商承诺支持的具体模型快照（而非别名）。
• 最低支持窗口：对于基础模型，通常从发布之日起 12 到 18 个月，作为协商的底线。
• 迁移协助条款：如果供应商在窗口期内关停了指定版本，他们需承担定义的迁移成本或延长访问权限。
• 通知 SLA：比公共默认期限更长的通知期，针对指定版本通常为 120 天或更长。

这种模式仅适用于企业级档位，且只有在签署前进行谈判才有效。要求这些权利的筹码在你收到弃用通知邮件的那天就会消失。大多数团队之所以不提要求，是因为他们不知道这是可以谈判的。例如，微软标准的 Azure OpenAI SLA 根本没有涉及模型退役的重构成本——但版本锁定权在企业协议中是明确可以谈判的，企业顾问通常建议将其作为标准条款提出。

提出要求的成本很低。而不提出要求的代价是每次每个受影响面都要耗费两周的工程师工时。

组织失效模式：无人负责迁移

让模型弃用演变为每季度紧急任务的结构性模式是：平台团队负责模型注册表 (model registry)，产品团队负责提示词 (prompts)，但没有团队负责迁移。

平台团队的动力是交付注册表、配置日程表，然后认为工作已经完成。产品团队的动力是针对注册表当前列出的任何模型交付功能。当弃用邮件寄达时，平台团队将其转发给产品团队。产品团队将其视为打断路线图的工作并进行推诿。平台团队没有权力强制执行迁移，因为他们不拥有提示词，也无法运行评估 (evals)。退役日期过了，某些环节崩溃了。

解决方法不是增加流程，而是将迁移明确为一项独立的工作，并指定一名有权在产品团队路线图中确定优先级的负责人。一些组织通过将迁移定为平台团队的职责来解决这个问题——由平台团队自己进行提示词重新微调和评估基准重建 (eval re-baselining) 工作，并交由产品团队审核。这种权衡是平台工程师需要在多个功能组合之间进行上下文切换。另一些组织则通过强制机制来解决：注册表管控部署，未维护的调用点最终会导致 CI 失败。这种权衡是在发生事故时会产生生硬的摩擦。

这两种模式都有效。无效的模式是“平台团队负责基础设施，产品团队负责功能，而迁移是每个人的工作”。每个人的责任就是没有人的责任。

像对待操作系统一样对待模型

本文描述的规范并不新鲜。成熟的工程组织将其应用于操作系统、语言运行时、库依赖和 API 消费者：锁定版本、将生命周期结束 (EOL) 计入日程、测试回滚、指定负责人，并在合同中明确返工成本。

新鲜的是节奏。Linux LTS 拥有十年的支持期。Python 次要版本有五年支持期。而一个基础模型从发布到退役之间只有 12 到 18 个月，正式通知期可能短至 60 天。这种时间上的压缩并没有破坏这些规范——它意味着跳过规范的代价从每五年支付一次变成了每季度支付一次。

如果一个团队将此视为常规工程任务——建立注册表、日程表、n+1 评估、版本锁定的回退方案、合同条款、明确的所有权——那么每次模型关停都只会转化为几周的机械性工时。而如果一个团队将每封邮件都视为意外，那么他们将在一个快三倍的技术栈中重新领悟操作系统、库和 API 弃用的教训。邮件终会寄达。唯一的变量在于，你的日程表是否早已预见。