摘要
2026 年 9 月 3 日，xAI 的 Grok 在全球范围（web / iOS / Android / X 平台）发生约 3 小时 35 分钟的服务中断。母公司 SpaceX 在当天下午的公开声明中将根因归因于「今早孟菲斯算力中心的一次中断」，并向受影响的算力合作伙伴致歉。由于 Anthropic 与 xAI 于 2026 年 5 月同 SpaceX 签署了算力合作计划，Grok 的推理负载显著依赖 SpaceX 的孟菲斯算力节点，该节点单次中断即拖垮全局服务。本事件归为依赖类（dependency），严重度 p1。
时间线
2026-09-03 06:30 PTGrok 在所有平台与服务上报告中断，状态页显示「正在调查中断」
2026-09-03 上午中断持续，Grok 聊天与全系列自动化服务完全不可用
2026-09-03 当日下午SpaceX 对外声明：Grok 的问题源于「今早孟菲斯算力中心的一次中断」，并致歉「受影响的算力合作伙伴」
2026-09-03 10:05 PT事件标记为完成，xAI 称「已解决问题，流量恢复正常」
2026-09-04 02:04 / 02:07 UTC各平台（Android / web）陆续恢复（与同日 ChatGPT、Claude 中断窗口高度重叠）
根因
SpaceX（xAI 母公司）官方归因：Grok 中断源于其孟菲斯（Memphis）算力中心（compute center）的一次中断。Grok 的主力推理节点部署在该中心，属于 xAI 与 SpaceX 算力合作框架下的共享算力基础设施。SpaceX 在声明中特别向「受影响的算力合作伙伴」致歉，措辞指向该中心同时为其他合作方承载算力——这解释了为何 Anthropic 与 xAI 在 5 月宣布的算力合作，使两家公司的负载可能落在同一物理算力节点上。
需注意：SpaceX 仅给出「中心中断」这一层级的归因，未进一步披露该算力中心自身为何宕机（如电力、制冷、网络或硬件等具体诱因），属厂商披露但未深挖的归因。
放大因素
- Grok 推理负载高度集中于单一算力中心（孟菲斯），缺乏跨中心 / 跨区域的推理容灾，单点物理基础设施故障即导致全局不可用。
- xAI 与 Anthropic 同 SpaceX 的算力合作，使多家前沿模型的推理可能共置同一物理节点，放大了相关故障域（common-mode）。
- 事件与同日 ChatGPT（路由错误）、Claude（基础设施问题）中断窗口高度重叠，初期被广泛误读为「共享云底座塌方」，但 WIRED 核实 Cloudflare / AWS / Azure / Google Cloud 当窗状态页均正常，证实三者为相互独立的故障。
缓解措施
- SpaceX 定位并恢复孟菲斯算力中心，流量恢复正常后标记事件完成。
- xAI 向受影响的算力合作伙伴致歉，暗示后续将审视算力冗余与故障隔离。
经验教训
- 推理算力若集中绑定单一物理中心，该中心的任何中断都会直接转化为全局服务不可用；须建设跨中心、跨区域的推理容灾。
- 多模型厂商共享同一算力合作方的物理节点，会在基础设施层形成隐藏的相关故障域，合同隔离不等于故障隔离。
- 「同时段多厂商中断」不等于「同一根因」；判定共享依赖须以 hyperscaler / CDN 状态页实测为据，避免想当然归因。
- 厂商一句「某中心中断」属浅层归因，事后复盘应追问中心自身宕机的物理诱因（电力 / 制冷 / 网络 / 硬件）。
检查清单
- 推理负载是否跨多个算力中心 / 区域部署，单中心故障是否触发全局降级
- 是否与算力合作方存在物理节点共置，形成相关故障域
- 多供应商容灾是否仅停留在合同层，物理层是否真正隔离
- 是否以 hyperscaler / CDN 状态页实测佐证「共享依赖」假设，避免臆断
- 厂商归因是否追问到中心自身宕机的物理根因（电力 / 制冷 / 网络 / 硬件）
- 是否对关键推理路径配置熔断与降级返回，而非硬失败