ChatGPT、Claude、Grok 9 月 3 日一齊出事：其實係咪同一個故障？

9 月 3 日，ChatGPT、Claude 同 Grok 的確喺相近時間出現問題，令不少人感覺好似「成個 AI 網絡一齊冧」。不過，目前最穩妥的結論其實更有限：公開資料顯示三間公司的服務事故有時間重疊，但各自披露的原因並不相同，未有證據證明它們由同一個故障源頭造成。334148

當日發生咩事？

由於各公司狀態頁和第三方報道所用時間點不同，完整時間線未必能精確對齊；但幾宗事故的確有重疊，難怪用戶會覺得是同時發生。

• **Grok：**據報 xAI 的事故記錄由 13:30 UTC 開始，到 17:05 UTC 結束。xAI 後來把中斷歸因於其位於美國孟菲斯的運算中心故障。48
• **Claude：**Anthropic 表示，多個 Claude 模型及服務出現較高請求錯誤率，受影響包括 Claude.ai、API、Claude Code 和 Claude Cowork。事故約歷時 3 小時，於 16:16 UTC 解決。104148
• ChatGPT 與 Codex：OpenAI 指，內部一個路由錯誤由太平洋時間 07:43 起，令部分用戶無法在不同平台使用 ChatGPT 及 Codex；公司約於 08:17 實施修正，之後繼續監察服務情況。41

用戶報稱遇到登入失敗、對話無法載入、提示詞送出失敗，以及網頁或 App 無法使用等問題。以 Downdetector 為基礎的報道顯示，當晚約 8 時（印度標準時間），ChatGPT 收到逾 43,000 宗問題報告；Claude 則同時影響一般用戶和開發者工具。2339

各公司點解釋故障原因？

三間公司的公開說法，正正是不能把事件直接稱為「同一宗大故障」的原因。

**OpenAI：**公司發言人表示，ChatGPT 和 Codex 的問題源於 OpenAI 基建內的路由錯誤。41

**Anthropic：**公開狀態資訊把 Claude 的問題描述為基建事故，並確認多個模型和服務出現較高錯誤率；但現有資料未說明到底是哪一個組件失效。3948

**xAI：**事後報道指，xAI 把 Grok 故障與孟菲斯運算中心中斷連繫起來，並就受影響的運算合作夥伴致歉。48

這些說法不能完全排除有共用依賴層出現問題的可能，但同樣沒有建立出一個共同根本原因。

係咪 Microsoft Azure 或其他共同供應商出事？

**現有公開證據不足以證實。**沒有資料確認 Microsoft Azure、網絡供應商、內容傳遞網絡（CDN）、身份驗證服務，或其他共用第三方，造成 9 月 3 日全部事故。

當日報道曾把 Azure 列為值得留意的環節，因為它向涉及的公司提供雲端服務；但「有提供服務」不等於「就是肇因」。42 尤其故障時間多由用戶回報和各自狀態頁記錄，獨立系統剛好在相近時段出問題，並非不可能。

所以較準確的判斷是：**共同基建導致故障仍未獲證實。**在沒有供應商直接確認或技術事後報告前，不能把「Azure 某個區域故障導致全部服務中斷」當成已證實事實。

Anthropic 使用 Colossus 1，會唔會解釋 Claude 故障？

現有報道不足以證實 Anthropic 對 xAI／SpaceXAI 的 Colossus 1 設施有多大範圍的使用權，也不足以說明 Claude 在事故當刻的正式服務路徑是否依賴該設施。孟菲斯的故障影響 Grok，並不自動代表它也造成 Claude 中斷。48

做可靠性分析時，呢個分別好重要：即使存在商業運算安排，也不能因此推論某個面向用戶的服務，正正在該批運算資源上運行。

9 月 7 日印度用戶再報 ChatGPT 有問題，已知咩？

9 月 7 日另有報道指，部分 ChatGPT 用戶主要在內容生成方面遇到困難，亦有人反映瀏覽器和 App 出問題。一篇報道記錄約 261 宗用戶回報，其中內容生成佔大部分投訴。19

但這些資料沒有證實是全印度持續性大規模故障，沒有確認根本原因，亦沒有證據把它與 9 月 3 日事件連結。當日 03:07 UTC，一個外部監測服務測試到 ChatGPT 可正常連線，且未見異常錯誤；這較符合局部、間歇性或地區差異明顯的問題，而不是可證實的全國持續中斷。22

真正的教訓：多供應商唔等於一定有韌性

這次事件反映，愈多企業把 AI 用於客服、寫程式、研究、文件處理和自動化工作流程，一旦服務受阻，營運可以好快卡住。訂閱多個 AI 服務固然能減少單一供應商出事的風險，但若大家共用某些雲端、網絡、身份驗證、瀏覽器或整合環節，仍可能出現連帶失效。

較有韌性的 AI 工作流程，至少應包括：

• **人手後備與可保留的工作佇列：**關鍵工作應可復原，不要令失敗請求直接消失。
• **供應商切換機制：**合適的工作可改送其他模型供應商，但要假設關聯故障仍有可能發生。
• **防禦式 API 處理：**設定有限時逾時、退避重試、斷路器，以及可重複安全執行的工作設計，避免短暫故障引發重複處理。
• **降級運作模式：**預先定好沒有前沿模型時甚麼仍可繼續，例如規則式分流、快取答案、延遲交付或改由人手審核。
• **獨立監測與事故紀錄：**除了看供應商狀態頁，也要自行做合成監測，並保留日誌，清楚記錄哪一間供應商、哪個模型和哪個整合環節失效。

重點不是每次多個服務同時出問題，背後都必定藏有同一個原因；而是企業應預備好這種可能，並在下一次事故發生前，實際測試後備方案是否真係用得著。