昨天上午,ChatGPT 挂了。Claude 也挂了。Grok 也挂了。三个 AI 届最大的竞争对手在同一个 90 分钟窗口内齐刷刷倒下,这个巧合已经不是"巧合"能解释的了。
如果你当时正在用 AI 写代码、做客服、跑自动化流程,你大概经历了从困惑到焦急到无奈的全过程。打开 ChatGPT — 报错。切到 Claude — 也报错。再试 Grok — 同样不行。这不是你的网络问题,是整个上层 AI 堆栈的底层基础设施出了问题。
时间线:从第一波报错到全面恢复
9 月 3 日早上 7:53 AM PT(约北京时间晚 10:53),Downdetector 开始收到第一批关于 ChatGPT 的异常报告。起初看起来像是早高峰的正常波动,但数字很快就不正常了——5000、10000、22000……爬升速度远超普通故障。
OpenAI 自己的状态页面在 10:58 UTC(6:58 AM ET)确认检测到「ChatGPT 和 Codex 的异常错误率上升」,波及 15 个 ChatGPT 组件和 4 个 Codex 组件。Anthropic 紧随其后确认 Claude.ai、Claude API、Claude Code 和 Claude Cowork 全部出现部分中断。xAI 的状态系统也记录到 Grok 模型级故障。
到上午 11:00 ET 前后,三大平台的报错量同时达到峰值。随后工程师们陆续部署了缓解措施,到 12:42 PM ET(9:42 AM PT),所有服务基本恢复正常。整个事件持续了约 90 分钟。
数字不说谎:各平台受损规模
| 平台 | 运营方 | 峰值报错数 | 云供应商 |
|---|---|---|---|
| ChatGPT / Codex | OpenAI | 37,000+(合并达 66,000+) | Microsoft Azure |
| Claude | Anthropic | 1,324 | Microsoft Azure |
| Grok | xAI / X | 1,365 | Microsoft Azure 关联设施 |
| Copilot | Microsoft | 未单独量化 | Microsoft Azure |
| Gemini | ~500 | Google Cloud |
看这张表,一个模式呼之欲出:所有重度倒下的平台,全都跑在 Azure 上。 Gemini 作为唯一在上面扛住的巨头,因为它的家是 Google Cloud。
根因:Azure East US 把三家一起端了
多个来源交叉确认,三条断路汇聚到同一个源头:Microsoft Azure East US 区域的网络基础设施故障。
ChatGPT 的主力推理跑在 Azure 上。Claude 的推理集群同样大量使用 Azure。Grok 也和 Azure 关联基础设施深度绑定。当 Azure East US 区域的底层网络退化时,这三家几乎在同一时刻感知到了故障——不是一家一家地崩,而是一起崩。
有意思的是,Cloudflare 在同一时段也被报道出现服务问题,AWS 也有轻微症状,但没有任何来源将 Cloudflare 或 AWS 定位为根因。Azure East US 区域故障是多方交叉验证后最一致的结论。
集中化风险:当你的「多云」方案只在同一朵云里
这次事件揭开了 AI 行业一个被低估的结构性风险:几乎所有头部 AI 公司的推理基础设施都集中在同一家云上。
理论上,AI 公司都有"多云"或"多区域"架构。但实际生产环境中,主力推理集群为了性能和成本优化,常常深度绑定某一家云厂商的特定区域。ChatGPT 绑定 Azure East US,Claude 也一样,Grok 也跑在 Azure 相关设施上。当你以为自己是"多云容灾",实际上只是"多云但在同一朵云里"。
Gemini 的数据最有说服力。 Google 的 Gemini 跑在 Google Cloud 上,这次峰值报错仅约 500 条——与 ChatGPT 的 37,000+ 形成鲜明对比。这不是 Gemini 更稳定,而是 Google Cloud 没有跟 Azure East US 一起崩。
巧合中的巧合:同日 GPT-6 Astra 官宣
就在宕机几小时后,OpenAI 正式发布了 GPT-6 Astra。公司总裁 Greg Brockman 称之为「世代级的跃迁」,将其定位为可能代表 AGI 到来的模型。
一个品牌早上刚经历了 90 分钟的全球宕机,下午就发布了可能是公司历史上最重要的模型——这种戏剧性的时间线安排,让社交媒体上关于"发布前出大事"的调侃不断。不过从实际时间线看,宕机发生在早上 7:53 AM PT,而 OpenAI 的正式发布在下午 4:21 PM ET,两者相隔超过 8 小时,更像是糟糕的日程巧合而非因果关联。
AI 在生产环境中的脆弱性
三年前,AI 宕机意味着你暂时问不了问题。现在,AI 宕机意味着开发流水线中断、客服系统停摆、自动化流程断链、业务数据延迟。
这次事故影响了:
- 用 ChatGPT Codex 写代码的开发者(AI-pair-programming 直接停摆)
- 依赖 Claude API 做内容生产的企业
- 接入了 Grok API 的第三方应用
- 使用 Microsoft Copilot 的 Office 用户
Gartner 预测 2026 年 AI 基础设施支出将持续高速增长,但这次宕机提醒我们:钱花在算力上的同时,也必须花在韧性上。
写在最后
如果你是一个在公司内部搭建 AI 平台的技术负责人,今天的故事应该让你停下来想一想:
你的推理负载是不是也只绑定了单一云区域?你的所谓「高可用架构」在云区域级故障面前能撑住吗?降级到推理能力较差的备用区域时,业务能接受吗?
如果你是开发者依赖 AI 工具工作,这个故事就更直接了——如果明天 ChatGPT 和 Claude 同时宕机,你的备选方案是什么?本地的模型也好、另一个云区域的推理端点也好,容灾计划的最后一道防线不能也是一个跑在 Azure East US 的服务。
这次 90 分钟的三重宕机是云集中化风险的一次教科书级展示。下一次,可能就不止 90 分钟了。
📌 延伸阅读: 这并非 AI 基础设施第一次出现可靠性危机。今年 8 月,GitHub 经历了 8 天内 6 次宕机,同样暴露了单点依赖的脆弱性:《8 天 6 次!GitHub 可靠性危机深度拆解》