OpenAI 又崩了：ChatGPT 与 API 高延迟事故复盘

产品更新

5月27日深夜，OpenAI 确认 ChatGPT 与 API 出现高延迟，持续约5小时后修复。这已是近期第二次明显的稳定性事件，开发者对单点依赖的担忧再度升温。

OpenAI 又崩了：ChatGPT 与 API 高延迟事故复盘

如果你昨晚（5月27日）在调 OpenAI 的 API 写代码或者跑批量任务，大概率感受到了一种熟悉的卡顿——请求发出去，半天没动静，偶尔还吐个超时。不是你的网络问题，是 OpenAI 自己又出状况了。

北京时间 5 月 27 日 22 点 47 分，OpenAI 在状态页面正式确认 ChatGPT 和 API 出现"高延迟"（Elevated Latency），同时在 X 平台发了推文。整个事故持续了约 5 个多小时，直到今天（5 月 28 日）凌晨 4 点 06 分，官方宣布修复完成。

这事本身不算大新闻——大模型服务抖一抖早就不新鲜了。但放在最近这一两个月的语境里看，味道就不太一样了。

OpenAI 状态页面显示 ChatGPT 与 API 高延迟事件时间线

事故经过：一次典型的"高负载型"抖动

根据用户在 X、Reddit 和国内社区的反馈，问题最早从北京时间 5 月 27 日凌晨开始出现苗头——ChatGPT 网页端响应明显变慢，提交一个普通问题后，思考圆圈能转上十几二十秒才开始吐字。API 侧的表现更直观：p95 延迟飙升，部分长上下文请求直接 504。

OpenAI 的官方时间线大致是这样：

  • 凌晨起：用户陆续反馈延迟异常，但未触发官方告警
  • 22:47：状态页挂出 "Elevated latency on ChatGPT and API"
  • 次日 04:06：标记为已修复（Resolved）

值得注意的是，从用户感知到官方确认，中间有接近一天的时间差。这不是 OpenAI 第一次被吐槽"故障响应慢"——它的状态页面历来偏保守，往往要等到错误率指标越过某个内部阈值才会公开承认。

官方这次没有公布详细的事后分析（postmortem），只笼统归为"高延迟"。但从故障形态看，几乎可以肯定和容量调度有关——要么是某个区域的推理集群过载，要么是新版本灰度时遇到了流量尖峰未做好限流。

没修完的尾巴：Codex 和企业版还有遗留问题

主事故虽然标记为已解决，状态页面上其实还挂着两个小红点：

  1. Codex 上下文压缩速度慢于预期——这个对长文档编程任务影响比较直接，特别是用 Codex 处理大型代码库的场景，压缩慢意味着每一轮交互的首 token 延迟（TTFT）都会被拉长
  2. Android 版 ChatGPT 企业版切换工作区异常——这个是客户端层面的问题，影响范围相对有限，但企业用户多账号场景下挺糟心

这两个问题挂了好几天没修完，说明 OpenAI 内部确实有一些更深层的工程债务没还清。Codex 的上下文压缩慢，本质上是模型侧的优化问题，可能涉及 KV cache 管理或者投机解码（speculative decoding）路径的调优，不是简单重启服务能搞定的。

为什么最近 OpenAI 总掉链子？

把时间线拉长一点看，问题更明显。把今年以来 OpenAI 几次比较显著的事件串起来：

  • 5 月 27 日：本次高延迟事故，持续 5+ 小时
  • 此前的 11 月初：ChatGPT 与 API 错误率飙升，服务中断超 1 小时，OpenAI 自己定义为"Major Outage"
  • 更早：多次 GPT-4 系列模型在欧美早高峰时段出现限流加重

这背后有几个绕不开的结构性原因。

第一，用户增长还在跑赢容量扩张。 ChatGPT 现在的周活早就过 10 亿了，而且最近 GPT-5 系列和新版 Sora 上线之后，每个用户的平均 token 消耗量是指数级增长的——尤其是带视觉理解、长上下文、推理模式的请求，对 GPU 算力的吞噬远超传统对话。

第二，模型路由和混合部署越来越复杂。 OpenAI 现在同时维护着 GPT-5、GPT-5-mini、o 系列推理模型、Codex 专用模型等多条产品线，背后涉及不同的硬件配比和调度策略。任何一条线的容量调整都可能波及全局——比如把推理算力优先给 o 系列，那 GPT-5 主线就容易在高峰期掉链子。

第三，全球流量的不均衡。 北美工作日早高峰（对应北京时间凌晨到上午）历来是 OpenAI 的事故高发时段。这次事故也是从北京时间凌晨开始的，跟这个模式完全吻合。

开发者该怎么应对？

如果你是把 OpenAI API 接入到生产业务里的开发者，这种事故再次提醒：任何单一供应商都不能 100% 信赖。我说几条比较实在的工程建议。

1. 流式输出是底线，不是优化项

这个老生常谈了但还是要强调。如果你还在用同步阻塞模式调 API，遇到高延迟事故基本就是全员超时。stream=true 起码能让用户在前几秒看到响应开始，心理上接受度完全不同：

response = client.chat.completions.create(
    model="gpt-5",
    messages=[{"role": "user", "content": prompt}],
    stream=True,
)
for chunk in response:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

配合 SSE 推到前端，体验提升立竿见影。

2. 配置合理的超时和重试策略

很多人犯的错是用 SDK 默认配置——默认超时往往是 600 秒（10 分钟），高延迟事故来的时候连接会一直挂着，瞬间堆出大量僵尸请求。建议显式设置：

  • 短任务（普通问答）：超时 30-60 秒
  • 长任务（代码生成、长文档）：60-180 秒
  • 重试用指数退避，但限制总次数（2-3 次足够）
  • 对幂等请求才重试，非幂等的（如带 Function Call 副作用的）要小心

3. 多模型 fallback 不是奢侈品

这次 OpenAI 挂了 5 个小时，如果你的服务在这段时间能自动切到 Claude 或者 Gemini 上，业务连续性完全是另一回事。技术上其实不难——所有主流模型 API 现在都已经统一到 OpenAI 兼容格式，切换基本就是改个 base_url 和模型名。

顺带一提，这也是为什么聚合型 API 网关最近越来越受欢迎。像 OpenAI Hub（openai-hub.com）这种平台，一个 Key 同时对接 GPT、Claude、Gemini、DeepSeek 等主流模型，并且兼容 OpenAI 格式，国内直连——出现这种 OpenAI 官方抖动的场景，业务侧可以做无感切换，不用每家都申请 Key、各自维护一套 SDK。

4. 缓存和降级要前置设计

热门 prompt 的语义缓存、规则降级方案（直接返回模板回复或转人工），这些不是事故来了才临时加的，得在架构阶段就想清楚。

结语：稳定性正在变成竞争壁垒

两年前大家比的是模型能力，谁的 benchmark 高谁就赢。现在 GPT-5、Claude、Gemini 在各种榜单上互有胜负，差距不像以前那么显著了。模型能力进入对峙期之后，SLA、稳定性、延迟、价格——这些工程指标反而成了 to B 决策的关键变量。

OpenAI 这次 5 小时高延迟，对个人用户来说就是抱怨两句的事，但对那些把 API 写进核心业务流程的公司来说，可能意味着真金白银的损失。每次这种事故都会推动一批用户去做多供应商的兜底架构——这个趋势已经持续了一年多了，每次故障都会让它加速一点。

OpenAI 自己肯定也清楚问题在哪。Sam Altman 在最近的几次访谈里反复提到"compute is the bottleneck"——算力是瓶颈。但算力扩张是个慢变量，新一批数据中心要到下半年才陆续投产。在那之前，类似的延迟事件大概率还会再来几次。

做好心理准备，做好工程准备。

参考来源