GPT-4o与GPT-4.1将于2027年1月14日退出OpenAI API，开发者只剩92天

OpenAI 在 2026 年 10 月 14 日的弃用页面上悄悄新增了一条通知：使用 GPT-4o、GPT-4o mini、GPT-4.1 和 GPT-4.1 mini 的开发者被告知模型将于 2027 年 1 月 14 日从 API 中移除。从通知到停服，只有 92 天。

这条消息没有发布会，没有邮件轰炸，只有一个表格。如果你过去两年里用一个小模型搭了分类器、信息抽取器或者客服工单路由，那个没人再碰过的小调用会在 1 月 14 日之后直接失效。

哪些模型在名单上

根据 OpenAI 官方弃用页面，本次下线的四个模型及快照如下：

模型	快照 ID	替代模型
GPT-4o	gpt-4o-2024-08-06, gpt-4o-2024-11-20	gpt-6-luna
GPT-4o mini	gpt-4o-mini-2024-07-18	gpt-6-luna
GPT-4.1	gpt-4.1-2025-04-14	gpt-6-luna
GPT-4.1 mini	gpt-4.1-mini-2025-04-14	gpt-6-luna

通知中还有一句话值得注意：这些模型的微调版本遵循与基础模型相同的下线时间表。也就是说，一个微调过的 4o mini 会在同一天彻底消失。

表格列出的是带日期的快照，而不是裸的 gpt-4o 别名。GPT-4o 模型页面将 gpt-4o-2024-08-06 列为默认快照，而这个快照正在名单上。不要假设别名会活得更久，一定要检查你实际调用的确切 ID。

另外，gpt-4o-2024-05-13 和 gpt-4.1-nano 早已在本次通知之前就进入了下线流程，它们将在 2026 年 10 月 23 日关停。如果你固定了这两个版本，你的截止日期不是 92 天，而是只剩 9 天。

GPT-4o 的音频和实时模型不在本次名单中，它们有独立的日期，从 2027 年 1 月 20 日开始。

三个月通知期与六个月政策的落差

OpenAI 弃用页面有一段关于通知期的说明：对一般可用模型，承诺“至少 6 个月”；对专用变体，承诺“至少 3 个月”；对预览模型，“可能以更短的通知退役，例如 2 周”。

10 月 14 日到 1 月 14 日，正好是三个月。这个通知没有说明这些快照属于哪一类，也没有给出时间表缩短的理由，更没有附上迁移指南。

对比下方一条记录：10 月 1 日，OpenAI 给 gpt-5.1 和 gpt-5.3-codex 设定的关停日期是 2027 年 4 月 1 日，整整六个月，是这次通知期的两倍。

如果你通过 Azure 使用这些模型，日期并不遵循 OpenAI 的时间表。微软的模型退役页面列出这五个快照的退役时间为 2027 年 4 月 14 日，并且微调部署保留更久：gpt-4o 和 gpt-4o-mini 到 2027 年 10 月 1 日，gpt-4.1 和 gpt-4.1-mini 到 2027 年 10 月 14 日。不过该页面最后更新于 9 月下旬，早于 OpenAI 的通知，值得持续关注是否有变化。

迁移到 gpt-6-luna 需要面对什么

从每百万 token 的价格看，Luna 比它替代的所有模型都便宜：

模型	输入价格	输出价格
gpt-4o	$2.50	$10.00
gpt-4.1	$2.00	$8.00
gpt-4.1-mini	$0.40	$1.60
gpt-4o-mini	$0.15	$0.60
gpt-6-luna	$0.10	$0.50

但每 token 便宜不等于每任务便宜。Luna 模型页面列出三个会改变现有调用行为的关键差异：

默认开启推理。 Luna 默认以 medium 力度进行推理，除非你显式设置 reasoning.effort。力度可以从 none 到 max。一个 4o mini 分类器会立即回答，而 Luna 在默认设置下会先思考。

工具调用偏好 Responses API。 在 Chat Completions 上，函数调用仅在推理力度为 none 时可用。如果要使用内置工具，需要改用 Responses API。

不支持微调。 Luna 不支持微调。如果你的生产模型是微调过的 4o mini，没有对应的微调 Luna 可以迁移。OpenAI 从 2026 年 5 月起就限制了新的微调任务，现有客户将在 2027 年 1 月 6 日失去创建微调任务的能力。

另外，长提示词的成本更高。输入超过 272K token 时，Luna 对整个请求的输入按 2 倍计费，输出按 1.5 倍计费。

对于一个原本发给 4o mini 的快速廉价调用，最接近的替代起点是关闭推理的 Luna：

import OpenAI from "openai";

const client = new OpenAI();

const res = await client.responses.create({
  model: "gpt-6-luna",
  reasoning: { effort: "none" },
  input: "Label this ticket: refund not received",
});

console.log(res.output_text);

不过在切换之前，务必用你的评估集跑一遍对比。OpenAI 的通知没有对替换后的质量做任何承诺，而 92 天正是构建评估集的窗口。

reasoning.effort 是 OpenAI 在新一代推理模型上引入的推理预算控制参数，取代了早期 o 系列模型中只能通过系统提示间接影响思考深度的做法。它把模型的"思考量"显式暴露为一个可从 none 到 max 的梯度：none 表示跳过内部推理链，直接生成答案；medium 是多数模型的默认值；max 则允许模型在回答前展开尽可能长的思维链。这个参数直接影响延迟、输出 token 数和计费——推理过程产生的 token 同样计入输出费用。对分类、抽取、路由这类"输入明确、答案唯一"的任务，把力度设为 none 往往能在质量和成本之间取得比旧模型更好的平衡；而对需要多步推导的任务，调高力度通常带来显著的质量提升。迁移时最常见的坑是把新模型当作旧模型的等价替换，结果默认的 medium 让简单调用凭空多出数秒延迟和数倍输出成本。

Responses API 是 OpenAI 在 Chat Completions 之外推出的新接口，两者的核心差异在于状态管理。Chat Completions 是无状态的：每次请求都要把完整对话历史重新发送，服务端不留任何东西。Responses API 则允许服务端保存对话状态，客户端只需传 previous_response_id 就能续接上下文，同时把内置工具（网页搜索、文件检索、代码执行等）作为一等公民直接挂在请求上。这一设计让工具调用的编排从"客户端解析 function call、执行、再回传结果"的多轮往返，变成服务端可自主完成的循环。代价是接口语义、返回结构、计费口径都与 Chat Completions 不同，现有的解析代码、重试逻辑和 token 统计几乎都要重写。对于重度依赖函数调用的应用，这不是换个 URL 就能完成的迁移。

在 1 月到来之前找到每一个调用

先从自己的代码开始。git grep 只搜索被跟踪的文件，通常能跳过 node_modules 和构建产物：

git grep -nE "gpt-4(o|\.1)"

这个模式也会匹配音频、实时、TTS 和转录变体，以及 4 月通知中那两个日期不同的快照。所以要阅读命中结果，而不是简单计数。然后检查 grep 看不到的地方：环境变量、配置服务、功能开关和保存模型名称的数据库行。

接着询问 API。OpenAI 表示 List models 端点现在携带一个可选的 shutdown_date 字段。用 jq 可以打印账户中所有已宣布下线日期的模型，按时间从早到晚排序：

curl -s https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  | jq -r '.data[]
      | select(.shutdown_date != null)
      | "\(.shutdown_date)  \(.id)"' \
  | sort

环境变量、配置服务、功能开关和数据库行是代码搜索的盲区，却往往是模型 ID 真正生效的地方。典型情形是：代码里写的是 process.env.OPENAI_MODEL，真正的值躺在 Kubernetes ConfigMap、AWS Parameter Store、LaunchDarkly 开关或一张 tenants 表的列里；甚至同一个应用的不同租户绑定了不同的快照。这类外部配置还会随时间漂移——有人临时改成 gpt-4o-mini 做灰度，然后再也没改回来。因此排查必须双向进行：自下而上用 grep 找代码引用，自上而下从生产流量反查实际调用的模型 ID。后者的可靠做法是翻 API 响应头或用量日志里的模型字段，用真实流量而非静态配置来确认"此刻到底在调什么"。只有两边对得上，才谈得上完整清单。

让构建在 API 之前失败

同样的字段也出现在 Retrieve a model 端点上，几行 shell 就能在流水线中检测部署所用模型是否有下线日期：

#!/usr/bin/env bash

GitHub Actions 的工作流命令是一组形如 `::名称 参数::值` 的特殊字符串，脚本向标准输出打印这些字符串，runner 会拦截并转换成界面上的注解、分组或环境变量设置。`::error::` 会生成一条红色错误注解，并直接显示在对应的步骤和 PR 文件差异上；`::warning::` 是黄色警告；`::notice::` 则是蓝色提示。这类注解不会改变步骤的退出码，因此常与 `exit 1` 搭配使用：注解负责把信息展示给人看，非零退出码负责让流水线真的停下来。需要注意的是，工作流命令必须出现在行首才被识别，且消息中的换行、百分号、回车需要转义。相比单纯打印一行日志，注解的价值在于它能在 PR 页面和 Actions 摘要中被检索、被折叠，从而让"哪个模型即将下线"这类信息不会被淹没在数千行构建输出里。
# Fail CI when the model we call has a shutdown date.
set -euo pipefail
model="${OPENAI_MODEL:?set OPENAI_MODEL}"
url="https://api.openai.com/v1/models/$model"

shutdown=$(curl -sSf "$url" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  | jq -r '.shutdown_date // empty')

if [ -n "$shutdown" ]; then
  echo "::error::$model shuts down on $shutdown"
  exit 1
fi
echo "$model: no shutdown date announced"

::error:: 前缀是 GitHub Actions 的工作流命令，会以注解形式显示在运行记录上。一旦模型被移除，curl -f 会在错误响应上失败，脚本同样以非零状态退出。将 OPENAI_MODEL 设为带日期的快照而非别名。

对任何已宣布日期都失败是有意为之的严格：团队会从红色构建中得知下一次弃用，而不是从归档邮件里。如果这太吵，可以比较日期与某个窗口，只在窗口内失败。

把模型 ID 当作运行时版本或数据库引擎来对待，它是一个生命周期不受你控制的依赖。把它放在配置的某个统一位置，并维护一个评估集，让你在一个下午内就能判断替代模型是否扛得住。

92 天倒计时的真正含义

这次弃用事件折射出一个趋势：模型的生命周期正在变得越来越短，而基础设施的依赖管理还没有跟上。2024 年发布的 4o 快照在两年多后就面临下线，而替代品 Luna 在默认行为、工具调用方式和微调支持上都有根本性差异。

对于依赖 OpenAI API 的团队来说，92 天不是恐慌的时间，而是建立模型生命周期管理流程的时间。把模型 ID 纳入配置管理，建立评估集作为迁移的安全网，让 CI 在下一个弃用通知到来时替你发现它。模型会退役，但你的产品不必跟着退役。