模型下线悬崖：当供应商淘汰你产品依赖的模型时会发生什么

大多数团队发现自己依赖模型的方式，和你发现承重墙的方式一样——试图拆掉它的时候。停用邮件到了，你在配置中替换了模型标识符，然后你的应用开始返回自信、格式优美、却微妙错误的答案。没有报错，没有崩溃，只是信任在缓慢流失，需要数周才能察觉，数月才能修复。

这就是模型下线悬崖：强制迁移揭示出你"模型无关"的系统其实从未无关过的那一刻。你的提示词、输出解析器、评估基线、用户的期望——所有这些都在悄悄地校准到即将按照别人的发布节奏而改变的行为特性上。

模型下线的步伐正在加速

如果你在 LLM API 之上构建产品，你就是在租用你的智能层。而房东按自己的时间表装修。

OpenAI 的停用页面现在读起来像繁忙机场的航班信息板。GPT-4o 的 API 访问在 2026 年 2 月终止。Assistants API 在 2026 年 8 月关闭前给了整整一年的通知，但像 gpt-4-0314 这样的旧版 GPT-4 快照只给了六个月。DALL·E 2 和 3 都在 2026 年 5 月下线。Anthropic 仅提前两个月通知就停用了 Sonnet 3.5。Azure 的模型退役政策在上游供应商决定之上又叠加了自己的时间线。

模式很清晰：模型代际越来越短，停用窗口在缩小，强制迁移的节奏在加快。如果你在 2023 年初基于 GPT-4 发布了产品，你已经至少面临了三次强制迁移事件。每一次都带有同样的风险：你的测试套件未设计用来捕获的行为变化。

为什么模型替换不是版本升级

工程师本能地会用库版本升级的心智模型来理解这件事。升级依赖，跑测试，发布。但 LLM 迁移违反了使版本升级可控的假设。

行为没有变更日志。 当模型供应商发布新版本时，你不会得到行为变化的 diff。你得到的是一篇关于基准测试改进的博客文章和模糊提到的"改进了指令遵循能力"。模型如何解释你领域中的模糊指令、如何处理边缘情况、如何组织推理——这些都没有记录，因为供应商自己可能也不完全理解。

提示词是模型专属的契约。 一个花了数周针对 GPT-4o 调优的提示词不是可复用的资产，而是一个校准到该特定模型行为特性的仪器。研究表明，仅在少样本设置中的格式变化就可能导致高达 76 个百分点的准确率波动。当底层模型改变时，你精心调优的提示词就变成了一份与不再存在的对手方签订的契约。

软故障比硬故障更糟糕。 传统的依赖升级要么正常工作，要么抛出错误。模型迁移会产生第三种结果：系统继续工作，但方式不同了。Tursio 企业搜索团队发现，用较新 GPT 版本测试现有提示词得到了 95.1% 和 97.3% 的通过率。听起来可以接受，直到你意识到每天一万次查询中就有五百次静默失败——不同的输出格式、改变的模糊指令解释、转移的推理策略。没有告警触发，没有错误日志。用户只是悄悄地失去了信心。

迁移的真实成本

模型迁移的表面价格是重写提示词的工程时间。实际成本要大得多。

一家医疗保健服务商从 Gemini 1.5 迁移到 2.5 Flash 时深刻体会到了这一点。这本该是一次节省成本的替换，却消耗了超过 400 个工程小时。新模型开始生成未经请求的诊断意见，造成了责任风险。尽管新模型"更便宜"，但由于新版本更加冗长，token 使用量暴增了 5 倍。整个 JSON 解析基础设施因为模型输出格式的变化而崩溃。他们花了数月构建的提示词库需要几乎完全重建。

这不是个例，而是将模型迁移当作配置更改而非其本质——平台迁移——的可预见结果。成本在多个维度上叠加：

• 提示词重新工程： 你提示词库中的每个提示词都需要测试和可能的调整。提示词越多，成本越高。
• 评估基础设施： 你现有的评估套件是针对旧模型输出校准的，基线需要重新计算。
• 缓存失效： 如果你构建了提示词缓存基础设施，它可能部分或完全失效。
• 集成测试： 解析模型输出的下游系统可能因新格式而崩溃。
• 机会成本： 花在迁移上的每个工程小时都是没花在功能开发上的一小时。

按任务成本而非 token 成本追踪的组织发现，迁移通常会使计算支出暂时增加 10 倍到 100 倍，然后优化才能跟上。

迁移测试手册

善于处理模型停用的团队有一个共同特征：他们在停用邮件到来之前就建好了测试基础设施。这个基础设施是什么样的。

尽早构建回归测试框架。 五十到两百个精选的输入输出对，代表你应用实际处理的多样化、有挑战性和对抗性的请求。这不是你的单元测试套件，而是一份行为契约，捕捉"正确"对你特定用例的含义。对你考虑的每个模型版本运行它，并随时间跟踪通过率。

将提示词与代码一起版本管理。 提示词需要与源代码相同的生命周期管理：版本控制、兼容性矩阵和迁移运行手册。当你调优提示词时，记录它是针对哪个模型版本调优的，以及它编码了哪些行为假设。这些文档将恐慌式的迁移转变为结构化的项目。

对模型变更使用金丝雀发布。 最初将 5% 的流量路由到新模型。你需要 200 到 500 个评分响应才能获得可靠的质量信号。监控的不仅是通过/失败率，还有输出特征的分布：长度、格式、置信度校准、拒绝率。一个通过了回归测试但输出长度增加 40% 的模型会破坏 UI 布局并推高成本。

实施影子部署。 将实时请求分叉到候选模型，让它在你真实系统的沙盒副本中完整执行，并比较轨迹差异。这能捕获隔离测试遗漏的交互效应——模型行为变化在代理流水线中的多个步骤之间级联的情况。

跟踪行为指纹，不仅仅是准确率。 两个模型可以在你的测试集上达到相同的准确率，同时行为截然不同。一个可能更谨慎，拒绝更多边缘情况。另一个可能更冗长。第三个可能通过提出澄清问题而非做出假设来处理模糊性。即使聚合指标看起来相当，这些行为差异对用户体验也很重要。

为不可避免的下一次迁移做好准备

对抗模型下线悬崖的最佳防御不是寄希望于它不会发生，而是构建你的系统使迁移成为可重复的流程而非危机。

抽象模型层。 这不意味着构建一个宏大的统一模型接口，而是确保你的应用代码不包含模型特定的假设。供应商特定的 API 调用应该隔离在一个薄适配器后面。提示词模板应该参数化并与业务逻辑分开存储。输出解析器应该对格式变化采取防御性策略。

保持多模型能力。 即使你在生产中只服务一个模型，也要定期针对至少一个替代方案测试你的关键路径。这有两个目的：验证你的抽象层确实有效，并在停用发生时给你一个预先测试过的后备方案。每月运行多模型测试的团队报告说，后续迁移大约只需首次迁移 25% 的工作量。

将模型视为有到期日的外部依赖。 每个生产 AI 功能都应该有一个明确的模型负责人——监控停用公告、维护回归测试框架并拥有迁移运行手册的人。将模型版本的到期日放入团队日历。停用不应该是一个意外，而应该是一个计划内的维护事件。

将评估设计为持续流程，而非上线门槛。 你的上线日评估套件在六个月内就会变成一台虚假信心制造机，因为外界在其周围不断变化。用户行为在演变，数据分布在漂移，"好"的定义在变化。持续更新你的评估数据集并重新校准基线。当迁移日到来时，你将确切知道"当前质量"是什么，并可以根据现实而非过时快照来衡量新模型。

更深层的问题：租来的智能

模型下线悬崖暴露了我们今天构建 AI 产品方式中的根本张力。我们正在我们无法控制、无法审查、无法保留的能力之上构建关键业务逻辑。每个提示词库都是以他人发布周期计价的技术债务。

这并不意味着你应该停止在 LLM API 上构建。这些能力太有价值，改进速度太快，大多数团队无法证明自行托管的合理性。但这确实意味着你应该将迁移作为一等架构关注点来构建，而不是事后考虑。

能够蓬勃发展的团队不是选对了"正确"模型的团队，而是构建了模型作为可替换组件的系统的团队——持续测试、干净抽象、不懈监控。因为你当前模型唯一确定的事情就是它最终会被停用。问题是你是从日历上还是从客户那里得知这一消息。