模型弃用是一场等待发生的生产事故

你六个月前部署的模型在日历上已有一个日落日期。你可能没有标注它。你的值班轮换也不知道这件事。积压工作中没有对应的工单。当提供商最终拔掉插头时，你会在最糟糕的时刻收到生产环境中的 404 Model not found 错误，而且没有准备好的回滚方案。

这是大多数使用托管LLM的工程团队的标准故事。模型弃用被归类为供应商问题，而非运营问题——直到它变成一场事故的那一刻。

OpenAI在2024年1月一次性退役了33个模型。Anthropic弃用了Claude 3.5 Sonnet，给出了六个月的过渡期，于2026年2月到期。Claude 3 Opus于2026年1月退役。GPT-4.5-preview于2025年7月日落。随着提供商竞相推出新一代模型，模型更迭的速度非但没有放缓，反而在加速。如果你的生产系统按名称调用特定模型版本——出于可重现性考虑，确实应该这样做——你现在面临的是一个被伪装成库调用的机队管理问题。

为什么团队总是措手不及

根本原因是分类错误。团队将模型标识符视为软件库版本：一旦固定就保持不变，除非你主动选择升级。但托管LLM模型标识符更像是租赁基础设施。供应商决定租约何时到期。

这种错位的症状会慢慢积累。固定的模型版本感觉像是稳定性。冲刺周期接连过去。功能持续上线。弃用通知通过邮件或没人认真阅读的更新日志送达。日落日期在Slack话题中被确认，然后被产品工作淹没。然后，那天到来了。

第二种失败模式更为隐蔽：即使在硬性弃用之前，提供商有时也会在版本别名内静默更新模型行为。今天的 gpt-4-turbo 字符串不一定与三个月前的 gpt-4-turbo 是同一模型。依赖版本别名而非固定快照标识符（如 gpt-4-turbo-2024-04-09）的团队会在不更改任何代码的情况下遭遇行为漂移。上季度通过QA的提示词开始产生格式错误的输出或导致下游解析器失败。故障不会被标记为模型问题——它在应用层以bug的形式浮现。

你需要构建的兼容性矩阵

认真对待模型弃用的第一步是了解你正在运行什么。大多数使用LLM的代码库对此没有单一的事实来源。模型名称存在于环境变量中、散落在各服务的硬编码字符串中，偶尔也在数月未经审查的配置文件中。

建立模型清单。对于每条记录，追踪：模型标识符（固定快照，而非别名）、提供商、使用它的服务或功能、当前弃用状态以及预计日落日期。这不需要专用工具；一个维护好的电子表格就够用。重要的是它存在，且有人负责维护。

一旦建立了清单，将每个模型映射到提供商推荐的替代品。提供商会发布迁移指南——OpenAI维护着正式的弃用时间表，Anthropic发布了关于模型退役窗口期的承诺。你的工作是在截止日期之前将这些内容转化为计划好的迁移工单，而不是在截止日期之后。

为你技术栈中的每个模型指定一名弃用负责人。此人负责追踪日落日期、启动迁移以及协调发布。没有明确的所有权，任务就会扩散为集体责任，也就意味着没有人真正负责。

行为回归测试：团队跳过的那一步

迁移一个模型标识符并不是迁移。它是迁移的开始。你要迁移到的模型在任何有意义的意义上都不是即插即用的替代品——它有不同的倾向、不同的拒绝模式、不同的输出格式默认值，以及在对抗性输入下的不同行为。你现有的提示词是针对旧模型调优的。

验证迁移的唯一方法是在新模型处理生产流量之前进行系统性的行为测试。这意味着将你的提示词套件——你的黄金输入——同时通过旧模型和新模型运行，并沿着对你的应用程序重要的维度比较输出。

这些维度取决于你的使用场景。对于结构化输出任务，你要检查新模型是否仍然产生你的解析器可以处理的有效JSON，字段名称和类型是否一致，以及模型是否会幻觉出额外字段。对于摘要，你要检查长度、事实准确性，以及以前安全失败的边缘案例输入是否现在会产生有问题的输出。对于分类或提取，你要检查标签分布是否在可接受的阈值内发生了变化。

最糟糕的行为回归是那些不产生错误的——它们产生微妙错误的输出，通过验证但会降低产品质量。一个对有把握的声明多出3%可能性进行回避的新模型，在人工审查中可能察觉不到，但在两周内的下游用户行为中是可测量的。构建能够统计性地检测这些变化的评估，而不仅仅是捕获硬性失败的评估。

使回归测试套件持续针对你的生产提示词运行，而不仅仅是在迁移时运行。模型行为可能在版本系列内的更新之间发生漂移。如果你的测试套件只在你启动迁移时运行，你会在用户抱怨时发现漂移，而不是在你还能清晰地将其归因于某个原因时。

分阶段发布：像对待软件部署一样对待模型迁移

从0%直接跳到100%生产流量的模型迁移——是没有经验丰富的基础设施工程师会接受的服务变更部署策略——但这正是大多数LLM模型迁移在实践中的做法。

采用你在任何其他重大变更中使用的相同分阶段发布规范。这些机制可以干净地适应LLM提供商：

明确固定新旧模型标识符。将一小部分生产流量（1%到5%）路由到新模型，同时大多数流量继续使用旧模型。对两条路径进行监控，以发出可比较的指标：延迟、错误率、输出有效性（响应是否正确解析？）以及你定义的任何应用层质量信号。给金丝雀阶段一个真实的观察窗口——至少24小时的生产流量，理想情况下72小时，以捕获只在特定时间段或特定用户群体中出现的模式。

逐步扩大流量。常见的检查点是5%、20%、50%和100%，每个阶段都有人工参与的决策。决策标准应提前指定：如果错误率超过X，或输出有效性低于Y，则停止并在扩大之前调查。

在开始之前将回滚纳入计划。回滚路径是：将模型标识符改回固定的旧版本并重新部署。这应该是一分钟的操作，而不是事后的任务。确保旧模型仍然可以调用——在新模型完成完整发布并经历了一个平静期之前，不要停用你的旧配置。

一个实际的复杂情况：一些提供商本身不支持流量分割。在这种情况下，在应用层实现它。LLM网关或路由器（无论是内部的还是通过Portkey或LiteLLM等工具）让你可以按用户ID、会话哈希或请求元数据进行路由，而无需在应用代码中嵌入路由逻辑。这种架构还为你提供了一个实现回退的干净位置——如果主要模型返回错误，则针对备用模型重试。

作为工程规范的弃用生命周期

妥善处理模型弃用意味着将其整合到你用于其他一切事物的相同运营流程中。具体而言：

在你的事故管理系统中追踪日落日期。 一个有六个月过渡期的模型弃用，应在通知到达的当天生成一个工单——而不是在截止日期前三周。工单应包含迁移计划、指定负责人以及带有检查点的发布时间表。

将模型清单检查添加到你的依赖审计流程中。 如果你进行季度依赖审查，将LLM模型版本纳入范围。"我们的任何模型版本是否在90天内弃用？"这个问题应该在任何时间点都有可靠的答案。

设置对特定模型错误率发出警报的监控。 当提供商在日落之前开始对弃用模型进行速率限制，或者当静默更新改变了模型行为时，你希望从你的仪表板得知——而不是从用户报告。按模型标识符聚合错误率，以便能够及早检测到提供商侧的变化。

明确记录提示词-模型兼容性。 当你为特定模型调优提示词时，记录该依赖关系。提示词不是模型无关的。专门为从一个模型引出结构化输出而精心制作的提示词，可能会从其继任者那里产生垃圾。这份文档属于提示词旁边，而不是存在于某人的记忆中。

让模型升级变得平凡无奇

目标不是防止弃用影响你——那是不可能的。目标是将模型迁移从紧急情况降级为计划好的运营事件：需要两周而不是两天，经过彻底测试而不是匆忙修补，通过分阶段发布而不是一次性切换来完成。

处理得好的团队并没有更好的模型或更好的提供商。他们有更好的运营习惯：追踪他们正在运行什么，在被迫之前测试迁移，并以与任何其他高风险变更相同的方式部署变更——缓慢地，有可观测性，并且有一条清晰的回退路径。

另一种结果是在凌晨3点被自动警报叫醒，发现你的流水线依赖的模型在四小时前停止接受请求。两种结果都是可能的。避免第二种结果的运营规范并不特别复杂——只是不够光鲜，所以往往会被跳过，直到第一次事故为你提供了充分的理由。

在需要之前就开始建立模型清单。下一波弃用浪潮已经在日历上了。