旧款 GPT 接口迁移：模型替换后的验证重点

GPT-4o 迁移最费时间的部分，是证明换完模型后产品仍然可靠。原文把下线日期、请求参数、微调替代和回归测试串在一起，核心主张很明确：模型升级应该按一次系统变更来验收。

这份清单对维护 AI 应用的前端和全栈团队很有参考价值。不过，文中的产品能力、价格和日期均来自作者截至 2026 年 10 月 22 日整理的信息，以下按原文解读，未独立核验，不能直接当作官方公告执行。

先确认你调用的模型，到底哪天停

OpenAI API、Azure 和 ChatGPT 各有时间表。只记一个「GPT-4o 下线日」，很容易排错迁移窗口。

按原文，OpenAI API 将于 2027 年 1 月 14 日关闭以下快照及其微调模型：

• gpt-4o-2024-08-06、gpt-4o-2024-11-20。
• gpt-4o-mini-2024-07-18。
• gpt-4.1-2025-04-14、gpt-4.1-mini-2025-04-14。

推荐替代是 gpt-6-luna。更早的 gpt-4o-2024-05-13 和 gpt-4.1-nano 则于 2026 年 10 月 23 日关闭，前者对应替代为 gpt-5.6-sol。

Azure 的旧版 GPT-4o 于 2026 年 12 月 9 日退役，后续 GPT-4o、GPT-4o mini 和三个 GPT-4.1 规格则是 2027 年 4 月 14 日。旧版替代为 gpt-5.6-sol，后续 GPT-4o 替代为 gpt-5.1；原文称 Azure 未给 GPT-4.1 和 GPT-4o mini 指定替代。

更容易漏掉的是自动升级。Azure 的 Standard、Data Zone Standard 和 Global Standard 部署可能在退役时自动换模型，行为由 versionUpgradeOption 决定；设为 NoAutoUpgrade 会在退役时停止服务，Provisioned 部署则需要手动迁移。

没有代码提交，线上行为也可能变。

ChatGPT 的时间又不同：原文称 GPT-4o、GPT-4.1、GPT-4.1 mini 和 o4-mini 已于 2026 年 2 月 13 日退出 ChatGPT，当时不影响 API。

作者建议按三个月安排复测。其依据是：通用模型政策通常承诺至少六个月通知，但允许特殊情形缩短；这批通知从 2026 年 10 月 14 日到次年 1 月 14 日只有三个月。原文没有解释这次具体适用了哪项例外。

JSON 能解析，为什么业务仍然可能退步

旧模型通过的评测，不能自动算到新模型头上。

同一份提示词，新模型可能选不同工具、填不同参数。结构化输出通过 schema 校验，也只说明形状合规，不能证明字段含义和业务判断正确。

作者给了两个生产案例。商标文书系统把基础模型和微调模型放到相同输入上，用六个维度、0 到 10 分的法律完整性评测检查，每份草稿通过后才交给律师。销售陪练系统则把分数交给版本化规则，模型只写定性反馈，避免模型升级后，历史分数失去可比性。

这两个案例说明了设计方法，没有提供迁移前后的完整对照结果。

迁移测试可以按一条顺序推进：先记录质量、延迟和成本基线，再让新旧模型反复跑同一批案例，独立检查工具参数和结构化输出，然后用真实输入做影子测试，最后逐步放量。影子测试就是让新模型接收输入、记录结果，暂时不接管实际业务。

每个案例都要重复跑。作者强调，即使 temperature 0，托管模型也不能保证次次相同；安全案例要求每次通过，质量案例则看通过率。案例优先来自团队已经读过的真实失败。

原文还引用一项 109 名自愿参与者的调查：59% 的相关企业换模型后出现性能下降，需要改应用或回退。样本存在选择偏差，不能拿它估算自己团队的失败概率。

评测资产也要能带走。按原文，Evals dashboard 于 2026 年 10 月 31 日转为只读，Evals API、可复用 prompt 对象及 v1/prompts API 于 11 月 30 日关闭。提示词、案例和评分规则应保存在自己的仓库；旧模型也应保留到灰度评分稳定，避免过早失去回退路径。

换成 Luna，会牵动哪些请求和业务规则

作者建议先在原有端点上把 reasoning effort 显式设为 none。Luna 支持 none、low、medium、high、xhigh、max，默认是 medium。遗漏配置会直接启用推理，推理 token 按输出计费。

按原文，v1/chat/completions 只有在 none 下才能调用 Luna 工具；推理与工具一起使用，需要 Responses API。GPT-6 Astra 和 GPT-6.1 Sol 的任何工具调用都需要 Responses。Chat Completions 本身没有公布关闭日期。

非 none 档位还必须移除 temperature、top_p、top_logprobs，在 Chat Completions 上还要移除 logprobs。以前靠低温度维持格式的提示词，需要重新验证输出契约。

价格也要按整条调用链计算。原文列出的每百万 token 价格为：输入 $0.10、输出 $0.50、缓存输入 $0.01、缓存写入 $0.125。输入超过 272,000 tokens 时，整次请求的输入及缓存费率翻倍，输出费率乘 1.5；上下文窗口为 1,050,000 tokens。单价低，不保证任务总成本低。

微调迁移更麻烦。原文称 2027 年 1 月 6 日起，现有客户不能再创建相关微调任务，1 月 14 日已有模型随基础模型关闭，而 Luna 不支持微调。Azure 的 GPT-4o、GPT-4o mini 微调部署延续至 2027 年 10 月 1 日，GPT-4.1 微调延续至 10 月 14 日。

处理办法是拆开微调承担的职责：示例能否放回提示词，事实能否交给检索，结构能否由校验器约束。作者的商标系统把引用交给获准索引的检索，把五段结构交给校验器，微调负责推理模式、段落边界和语气。

计算、权限和阈值也应放在代码里。作者的保险语音代理把必要披露设为工具执行条件，模型换了，支付前置条件仍然成立。

我的判断

这篇最有价值的建议，是把行为验收和规则归属讲清楚。对带工具调用的应用，检查 JSON 是否合法只是起点，还要检查参数含义、权限和执行结果。

它也有明显前提：作者团队已经有评分规则、校验器和生产日志。普通团队未必具备这些条件，可以先覆盖关键失败案例，但不能因此把一次通过当成可靠性证明。

至于 Luna 是否更好、推理档位选多少，原文没有提供质量、延迟、成本的对照数据，仍是待验证的迁移建议。作者提到的 TypeSafe Jev 是有类型的决策模型，用来处理路由等有限选择；没有对照结果，就不足以判断它比普通代码规则更适合你的系统。

模型接口封装值得做，但它只能集中修改入口。端点能力、参数限制和输出语义，仍然需要逐项验收。

能拿来做什么

• 维护 Node 服务时，把模型 ID、供应商、部署类型、负责人和退役日期登记在一起。按原文，可定时读取 GET /v1/models 或单模型查询中的 shutdown_date；Azure 则检查 Models API 的 lifecycleStatus 和 deprecation.inference，在三个月复测窗口内触发处理。Azure 要盯住 Deprecating，等到 Deprecated 已经退役，调用会返回 410 Gone。
• 从已有 AI 功能里收集真实失败输入，保存预期工具、关键参数和输出约束，新旧模型重复运行同一批案例，再进入影子测试和小流量灰度。
• 在模型适配层显式配置推理档位，并检查该档位允许的端点和参数组合，同时记录任务总成本、延迟和通过率。
• 检查提示词及微调是否承担了权限、金额计算或必要披露。把这些规则落到工具执行代码中；若使用大小模型路由，任一模型更新后都重新校准分流阈值。