旧版 OpenAI 模型停用与迁移时间表

模型迁移最容易漏掉的，往往是配置文件里的旧名称、SDK 没有标记的弃用字段，以及换了模型后不再兼容的调用参数。作者围绕 OpenAI 的模型关停安排，做了一次从代码扫描到请求改造的演练：查 SDK 警告只能覆盖一部分问题，替换模型字符串也不能保证迁移完成。

原文依据的是截至 2026 年 10 月 15 日的资料，最近一批关停日期是 2026 年 10 月 23 日。下面按这份历史记录解读，不把它当作实时公告。比日期清单更有用的，是它展示了怎样找全依赖、区分验证范围，并检查工具调用的迁移条件。

先分清关停日期、模型别名和替代方案

原文列出的第一批关停对象包括 gpt-3.5-turbo、gpt-4、gpt-4-turbo、gpt-4.1-nano、o1、o1-pro、o3-mini、o4-mini 和 gpt-image-1，日期为 2026 年 10 月 23 日。作者引用的关停定义是模型或端点不再可访问，因此建议按请求直接失败准备。具体错误码，原文没有给出。

代码中的替代关系也并不统一：gpt-3.5-turbo 和 o4-mini 指向 gpt-5.6-terra；gpt-4、gpt-4-turbo、o1、o3-mini 指向 gpt-5.6-sol；gpt-4.1-nano 指向 gpt-5.6-luna；gpt-image-1 指向 gpt-image-2.5-sunburst 或 -flare。所给正文没有完整表格，不能据此补齐所有型号的替代项。

另外几批需要分开看：

• GPT-4o、GPT-4o mini、GPT-4.1、GPT-4.1 mini 的指定快照，列在 2027 年 1 月 14 日，替代项是 gpt-6-luna。
• tts-1 和 tts-1-hd 列在 2027 年 1 月 6 日；音频与实时模型列在 2027 年 1 月 20 日。
• openai-go v3.78.0 将 gpt-5、gpt-5-mini、gpt-5-nano、o3 标为弃用，并写明 2026 年 12 月 11 日关停。但作者指出，相关公告条目只列了带日期的快照。

这里的区别是：快照对应明确版本，gpt-4o-mini 这样的别名则需要平台解析。原文没有找到证据，能说明快照退出后这些别名会指向哪里。作者采取的策略是跟随快照提前迁移，这是保守的工程判断，不能写成官方明确承诺别名同时失效。

微调模型的问题更深。按原文引用的规则，微调版本跟随基础模型关停，例如 ft:gpt-4o-mini-2024-07-18:... 同样到 2027 年 1 月 14 日停止响应。而 gpt-6-luna 不支持微调，平台还计划在 2027 年 1 月 6 日后停止让现有客户创建新微调任务。当时指南仍列出的监督微调基础模型，仅有三个 GPT-4.1 快照。

因此，依赖微调的产品需要考虑用提示词和示例重建行为，再用自己的评测集与旧模型输出比较。这是行为迁移，工作量不能按改一个配置项估算。

为什么 SDK 没报警，代码仍然可能受影响

作者搭了一个测试服务，把模型名分别放进 SDK 常量、字符串常量、回退映射、环境变量默认值和 YAML 配置。

结果是：staticcheck 2026.2.2 只报出一处，作者另写的扫描器找到九处引用。

这与 Go 的弃用检查机制有关。openai-go 使用标准的 // Deprecated: 注释，staticcheck 的 SA1019 可以据此提示。但 SDK 将类型声明为 type ChatModel = string，直接写下的模型字符串只是普通字符串，没有可供 SA1019 检查的弃用标记。

还有时间差：openai-go v3.78.0 发布于 10 月 13 日，1 月那批关停消息在 10 月 14 日宣布，因此该版本的 ChatModelGPT4oMini、ChatModelGPT4_1Mini 尚未带上标记。

作者的扫描器补了两层覆盖：检查 .go、.py、.ts、.js、.yaml、.json、.toml、.env 文件中的完整模型 ID，并解析 SDK 模块目录里的 shared/shared.go，把 openai.ChatModel... 常量还原成模型名称。运行方式是 go run ./scan -sdk $(go list -m -f '{{.Dir}}' github.com/openai/openai-go/v3) ./app，命中后以状态码 1 退出，可以接入 CI。

完整匹配很关键。扫描器不能把 gpt-4o 或 gpt-4.1 中的 gpt-4 当成一次命中，否则迁移清单会混入大量误报。

但这个工具仍有边界。无关 YAML 键里的裸 o1 可能误报；只存在于部署环境变量或数据库里的模型名，它也看不到。示例中的 text-embedding-3-small 没有出现在关停清单中，因此没有被报告。

弃用检查覆盖的是已标记的代码符号，迁移盘点还要覆盖配置和运行环境。

工具调用不能只替换 model 字段

作者接着演示了把使用工具的 gpt-4o-mini 请求迁移到 gpt-6-luna。

按原文引用的指南，GPT-6 Sol 和 GPT-6 Luna 在 Chat Completions 中使用 function calling，需要设置 reasoning_effort: "none"，而 Luna 的默认值是 medium。只改模型名，可能就会碰到调用条件不兼容的问题。

下面这段参数解决的是工具调用所需的推理档位，以及旧 token 参数的迁移：

openai.ChatCompletionNewParams{
    Model:    openai.ChatModelGPT6Luna,
    Messages: []openai.ChatCompletionMessageParamUnion{openai.UserMessage("Weather in Oslo?")},
    Tools:    []openai.ChatCompletionToolUnionParam{weatherTool},
    // gpt-6-luna 在 Chat Completions 中调用函数需要设置为 "none"。
    ReasoningEffort:     shared.ReasoningEffortNone,
    MaxCompletionTokens: openai.Int(500),
}

重点看 ReasoningEffort 那一行：它是这个工具调用场景的兼容条件。若希望 Luna 在同一个请求里既推理又调用工具，原文给出的方向是迁移到 Responses API。

作者用本地 httptest stub 记录请求体，迁移前后得到下面的差异：

before (messages and tools omitted):
{
  "max_tokens": 500,
  "model": "gpt-4o-mini",
  "temperature": 0.2
}
after (messages and tools omitted):
{
  "max_completion_tokens": 500,
  "model": "gpt-6-luna",
  "reasoning_effort": "none"
}

这里还要看 max_completion_tokens：它替代 max_tokens，并且计入推理 token。SDK 字段说明虽然写了旧字段已弃用，却没有使用标准的 // Deprecated: 标记，所以 staticcheck 也没有提示 MaxTokens。

参数删除同样需要读清条件。指南要求在 effort 不是 none 时移除 temperature、top_p、top_logprobs，以及 Chat Completions 的 logprobs；对于 none 是否接受这些参数，原文没有找到明确说明，作者于是也删除了 temperature。

不过，这次实验没有 API key，没有向 OpenAI 发请求。它证明的是 SDK 能构造出预期请求体，尚未证明远端接受请求，更没有验证模型是否正确调用工具。

我的判断

这篇最有价值的部分，是把迁移拆成了三个可检查的问题：哪里还引用旧模型、请求参数是否符合新接口要求、替代模型能否保持业务行为。前两项有扫描和本地实验支撑，第三项仍需要业务自己的评测。

作者给出的价格与窗口对比也值得保留：按原文，每百万 token，gpt-6-luna 输入为 $0.10、输出为 $0.50，GPT-4o mini 分别为 $0.15 和 $0.60；上下文窗口则从 128,000 增至 1,050,000 tokens。

这些数字支持单价更低、可容纳文本更多，却不足以证明迁移后的总成本必然下降。原文没有提供真实任务的输出长度、工具调用成功率、延迟或质量对照。更大的窗口，也不能直接等同于更好的长文本任务效果。

对于微调改提示词，作者给的是迁移方向，没有给效果对照。我认可先用旧评测集检查这个方案，但不能替它保证等价。

扫描器也适合放在已有 SDK 检查旁边使用。它能覆盖字符串和配置，却依赖关停表持续更新；普通文本命中还需要人工确认。相比只升级 SDK，这份额外工作有明确价值，但九处引用的结果仅来自作者的测试服务。

能拿来做什么

• 给前端项目的服务端接口、Node 服务和配置目录做一次模型清点，同时检查环境变量默认值、回退模型和部署平台中的实际配置。仓库搜索结果只能覆盖其中一部分。
• 把迁移检查细化到每类请求。使用工具时检查 reasoning_effort，检查 max_tokens 与 max_completion_tokens，再确认 temperature 等参数的适用条件。
• 用本地 stub 检查 SDK 实际发送的请求体，再补真实接口验证。分别记录请求是否被接受、工具参数是否正确、最终回答是否达到业务要求。
• 如果产品依赖微调，先保留代表性输入和旧模型输出，用同一批样本评估提示词加示例的替代方案，再决定是否切换。