模型停用日期不统一，采购合同该怎么写才不被动

一、这家公司收到 OpenAI 通知后改了主程序模型名，算不算迁移完成

不算。这家公司只改了主程序里一处模型名，但环境变量、YAML 配置、JSON 配置、按任务分流的路由表、备用模型与回退规则、定时任务与队列消费者，仍调用旧版本。

这些地方藏得深，不逐项检查就漏掉。比如一个定时任务每小时拉一次数据，用的还是 gpt-4o-2024-08-06；又比如备用模型在主模型超时后自动切换，也指向同款老版本。

微调模型更隐蔽。它基于旧底座训练出来，部署时仍依赖那个已停用的版本。只动主程序，等于只擦了黑板一角，整面墙还写着旧日历。

二、这家公司该信微软 Foundry 表还是 OpenAI 的公告

这家公司必须同时盯住两个来源。微软 Foundry 表写 gpt-4o-2024-08-06 停用日期是 2027 年 4 月 14 日，OpenAI 的公告写同款模型停用日期是 2027 年 1 月 14 日。

两个日期都来自官方页面，且各自有效。微软 Foundry 表更新于 2026 年 10 月 24 日，OpenAI 的公告发于 2026 年 10 月 14 日，都是最新公开信息。

企业没法挑一个信、另一个不信。它们不是互相否定，而是代表不同平台对同一模型的不同节奏安排。合同没约定以谁为准，就得把两个日期都当真。

三、这家公司按 Fireworks 标准版的 15 天通知期排计划，是不是过度反应

是过度反应。微软 Foundry 表里写，Fireworks 标准版（按词元计费）的模型在停用前只有 15 天通知期；但这只适用于 Fireworks 客户，不适用于这家公司正在用的 OpenAI API。

这家公司实际收到的是 OpenAI 在 2026 年 10 月 14 日发出的通知，从通知到下线共 92 天。拿 15 天去倒排，等于提前启动迁移，人力物力全压在最紧那条线上。

它真正该用的基准是 92 天。这既不是最长的 18 个月，也不是最短的 15 天，而是它手头这张通知单上白纸黑字的时间。

四、模型停用到底指训练终止还是部署终止

停用必须明确定义为部署终止。因为微调模型（经过微调的模型分两个阶段退役：训练和部署）的退役分两步：训练停用指不能再创建新训练任务，部署停用指不能再调用已训练好的模型。

例如 gpt-4.1（2025 年 4 月 14 日）的训练停用时间是不早于 2027 年 4 月 14 日，但部署停用是 2027 年 10 月 14 日，中间隔了半年。

如果合同只写“停用”，没说清是哪一步，供应商可能说“训练早停了，你早该换”，而业务系统还在靠那个已训练好的模型跑，突然断供就没人负责补这笔钱。

五、为什么同一款模型在微软 Foundry 表和 OpenAI 页面上停用日期不一样

因为微软 Foundry 表由微软发布，OpenAI 页面由 OpenAI 发布，微软和 OpenAI 是不同主体独立制定的日历。材料未说明哪一方具有优先效力。

微软表里的日期反映的是 Azure OpenAI 服务侧的运维节奏，OpenAI 公告反映的是其自有 API 的关停节奏。微软和 OpenAI 不是抄错，而是各自管各自的地盘。

企业不能指望平台之间自动对齐。就像两家快递公司各自发运单，日期不同不等于谁错了，只是发货时间表本来就不一样。

六、这家公司签合同时没写清停用定义，后续谁来担迁移成本

合同没写清停用定义时，迁移成本由这家公司自行承担。OpenAI 的公告和微软 Foundry 表都不构成合同条款，其中没有赔偿或违约责任说明。

公告是单方面通知，不是双向承诺。表是参考清单，不是履约依据。出了问题，供应商可以说“我们按自己日历执行了”，而采购方拿不出合同条款来主张权利。

这笔钱最后落在财务账上，不会自动转给平台方。它不是意外支出，而是合同缺位带来的必然代价。

七、钉死一个版本的这家公司，会遇到什么风险

这家公司会面临服务突然中断风险。比如照微软 Foundry 表日期排期，结果 OpenAI 在 2027 年 1 月 14 日关停 API，业务直接掉线。

又比如微调模型在 2027 年 10 月 14 日部署失效，而回退规则指向同一个已停用底座，导致故障无法切换走，业务只能硬扛。

钉死版本省了初期适配功夫，却把所有风险押在单一时间点上。一旦日历错位，补救窗口几乎为零。

八、换一个模型名就算迁移完了吗，没换完的是什么

没换完的是所有隐性调用点：环境变量、JSON 配置、YAML 配置、按任务分流的路由表、备用模型与回退规则、定时任务与队列消费者、基于旧底座做过的全部微调模型。

这些地方不写在主逻辑里，但每一条都在真实调用。比如一个 JSON 配置里写着 "model": "gpt-4o-2024-08-06"，它不受主程序改动影响。

还有一个容易被忽略的：工具调用（工具调用与结构化输出）。有些工具调用绑定特定模型版本，换了模型名，工具调用仍报错。

九、微调过的模型为什么有两张日历

因为微调模型退役分两步：训练停用指不能再创建新训练任务，部署停用指不能再调用已训练好的模型。

gpt-4o（2024 年 8 月 6 日）的训练停用是不早于 2027 年 4 月 1 日，部署停用是 2027 年 10 月 1 日。前者影响新能力上线，后者影响现有服务存活。

企业若只盯着训练停用日，可能误以为还能用半年，结果部署端提前失效，所有已上线的微调应用集体失能。

十、嵌入模型换了，为什么索引要重建

因为嵌入模型（text-embedding-3-large、text-embedding-3-small、text-embedding-ada-002 等）换代后向量空间结构变化，原有向量库无法直接复用。必须用新模型对全量数据重新编码生成新向量。

公开页面未提供这一步的工期，企业只能按自身数据量估算。比如千万级文档和亿级文档，重建耗时差别很大。

这不是配置开关就能换的活儿。它像换了一套度量衡，旧尺子量出来的所有数字，都得用新尺子重量一遍。

十一、新模型效果不如旧的，怎么证明是模型的问题

先拿一批真实问题在新旧模型上跑相同输入，对比回答质量、延迟与工具调用稳定性。若差异集中出现在新模型侧，且排除网络与配置问题，即可判断为模型变更所致。

不要只看平均分。要盯具体失败案例：比如同样问“查上季度华东区退货率”，旧模型返回表格，新模型只答“我不清楚”。

评估集不必大，但必须来自真实业务场景。合成题、测试题、通用问答题，都不能替代一线用户提的真实问题。

十二、自建开源模型是不是就没有停用问题

不是。Meta 的 Llama API 公共预览版在 2026 年 7 月 6 日关闭，腾讯云旧平台在 2026 年 9 月 30 日全面停服。平台、推理框架与云上的模型目录照样有停用日期。

十三、这家公司现在离 2026 年年底不远，先做哪一件事

这家公司先做全量调用点盘点。把程序里的模型名、环境变量、YAML 配置、JSON 配置、路由表、备用模型、定时任务与微调模型全部列出来。

这是后续排期与预算的基础。没这张清单，一切评估都是空中楼阁。盘点本身不花大钱，但能避免后续返工很多倍成本。

别等合同签完再动手。现在就开始扫，边扫边标风险等级：哪些调用点影响核心交易，哪些只用于后台报表，哪些已废弃但还挂着。

十四、迁移这笔工钱大概花在哪

迁移工钱主要花在三块：盘点与映射旧调用点到新模型、重跑评估集验证回答质量与延迟、重建嵌入向量库或重训微调模型。

公开页面未给出各环节人天或费用，企业需按自身系统复杂度估算。一个有三十个服务模块的系统，比单体应用多出数倍工作量。

钱不是花在“换名字”上，是花在“确认每一条路都通”上。每处配置改完，都要测通路、测边界、测失败回退。

十五、这家公司下一份采购合同里该写哪几句才不被动

合同必须写清三句：停用指部署终止不可调用；通知期不少于 92 天；替换模型需经这家公司与供应商双方书面确认，否则视为未履行通知义务。

这三句不是可选项，是底线条款。第一句堵住“训练停了算不算停用”的扯皮，第二句锚定实际收到的通知周期，第三句防止供应商单方面推一个不兼容的新模型。

少一句，就少一道保险。签字前不谈清楚，出事之后再补，代价远高于合同谈判多花的时间。