三大 AI 同时宕机！Azure 区域故障引爆 ChatGPT、Claude、Grok 集体瘫痪 90 分钟！

admin@yesmiracle.net (万戈) — Fri, 04 Sep 2026 00:00:00 +0000

昨天上午，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	Google	~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 可靠性危机深度拆解》

宕机 on AI博士 万戈