ChatGPT、Claude、Grok 同時出事：證據證明咗乜，未證明咗乜

ChatGPT、Claude 同 Grok 喺接近同一時段出錯，令人懷疑係唔係有一場波及全行嘅 AI 基建大故障；呢個推測可以理解。但按目前公開資料，較準確嘅結論係：事故時間確有重疊，三間公司公開嘅原因卻唔同，亦未有證據證實三者由同一個連鎖故障引起。

逐間睇：已確認嘅事實係乜？

Grok：已確認孟菲斯運算中心故障

SpaceXAI 表示，Grok 嘅問題源於其位於美國田納西州孟菲斯（Memphis）嘅運算中心故障，並向受影響嘅「運算合作夥伴」致歉。報道指，Grok 約喺太平洋時間早上 6 時 30 分開始受影響，持續超過 3 小時後系統恢復。 3941

呢啲資料直接證實：孟菲斯設施當日確有事故，而且影響唔止 Grok。不過，公開聲明無講明受影響合作夥伴係邊個、技術故障模式係乜，亦無列出有冇其他外部服務託管喺該處。

ChatGPT 與 Codex：已確認路由錯誤

OpenAI 指，ChatGPT 同 Codex 嘅服務中斷由路由錯誤引起，約於 9 月 3 日太平洋時間早上 7 時 43 分開始；公司約於早上 8 時 17 分實施解決方案，之後繼續監察復原情況。 39

換句話講，公開資料明確支持呢次係 OpenAI 方面嘅路由問題；但呢個說法唔等於孟菲斯事故導致 OpenAI 出事。

Claude：確認有大量錯誤、確認已恢復，但詳細根因未公開

Anthropic 狀態頁記錄，多個 Claude 模型出現較高錯誤率，影響於太平洋時間早上 9 時 16 分／世界協調時間 16:16 結束。 33 同期報道形容，事件係由基建問題造成嘅局部故障。 28

不過，現有公開材料未披露詳細根本原因，亦未建立 Claude 事件同孟菲斯設施之間嘅關係。最穩妥嘅說法係：Claude 確實出現過、亦已解決嘅事故，但以目前公開資料而言，底層成因仍未明朗。

時間接近，唔等於有因果關係

三項服務並非喺一個已記錄嘅同一刻一齊失效。Grok 據報較早開始出問題；OpenAI 公布嘅路由錯誤時段係太平洋時間早上 7 時 43 分至 8 時 17 分；Anthropic 則表示 Claude 影響到早上 9 時 16 分先結束。 3339

重疊對營運當然有實際影響：依賴多個 AI 服務嘅用戶，喺一段時間內發現幾個選項都唔穩定。但時間上同時發生，唔足以證明有共同技術原因。共同依賴、流量轉移，或者一環扣一環嘅反應，都只係假設；要等供應商公開證據先可以確認。

目前仍然未證實嘅講法

現有證據未能證實以下說法：

• Grok、ChatGPT/Codex 同 Claude 之間存在一場單一連鎖故障；
• OpenAI 或 Anthropic 將生產推論工作負載部署喺受影響嘅孟菲斯地點；
• Azure、Cloudflare 或其他指定雲端、CDN、網絡供應商係共同肇因；
• 根據故障回報網站得出嘅用戶受影響總數，係經審核嘅獨立用戶數字；
• Cursor 嘅某次失敗、編程代理中斷，或任何下游工作流程，必然由其中一間供應商嘅事故造成，而唔係整合、驗證、排隊、速率限制、網絡或客戶端本身問題。

Cursor 狀態頁的確曾報告，其上游 OpenAI 同 Anthropic 模型出現較高錯誤率；呢點可以支持部分 Cursor 活動與上游供應商事故有關嘅解釋。不過，單靠呢點，唔可以證明每一次代理執行失敗或每個客戶工作流程嘅確切原因。 30

真正值得警惕：多模型唔代表真係夠分散

孟菲斯事故提到未具名「運算合作夥伴」，正好提醒大家：基建依賴好多時並唔透明。即使一個應用程式同時接駁幾家模型供應商，背後仍可能共用同一個身分驗證供應商、DNS 或 CDN 路徑、雲端區域、GPU 主機、模型閘道、程式碼託管平台、監察系統，或者工具後端。

即係話，API 層面有多個供應商，唔必然代表基建層面已分散。一個後備模型端點有冇用，取決於周邊依賴可唔可以一齊捱過同一種故障。

點樣為多小時 AI 供應商故障做準備

畫清完整依賴鏈

維護一份服務地圖，列出每個關鍵依賴：模型 API、閘道、雲端區域、DNS/CDN、身分驗證、向量資料庫、訊息佇列、程式碼託管、工具整合及可觀測性系統。已確認嘅次級供應商同重要未知項目，都應該記錄。

用真實工作負載測試後備路徑

預先整合替代供應商、較細模型或本地模型，然後用貼近生產環境嘅提示詞、結構化輸出、工具呼叫、安全要求、吞吐量限制同成本控制去測試切換。示範環境成功發一次請求，唔代表後備方案真係頂到正式流程。

令 AI 代理可以安全失敗

採用逾時控制、帶隨機抖動嘅有限重試、斷路器、冪等鍵、可持久保存嘅檢查點，以及清晰嘅暫停／繼續語意。任何不可逆操作前要有人手批准。事故後，代理應從已記錄狀態繼續，而唔係重複部署、採購、開工單，或者重複呼叫外部 API。

事故前定好降級模式

文件化列明：冇模型服務時，邊啲功能仲可用，例如搜尋、表格、規則式分流、排隊等待草擬、唯讀存取、人工升級處理，以及向客戶清楚交代服務狀態。亦要設定實際目標，包括最大排隊時長、人手處理能力、通知客戶嘅門檻，以及幾時必須停用自主操作。

加強供應商溝通與事故取證

訂閱供應商狀態更新，建立升級聯絡渠道，並在合約容許下訂明通知期望、事後事故報告要求同資料可攜條款。事故期間要保存世界協調時間（UTC）時間戳、請求 ID、回應標頭、錯誤內容、追蹤資料、路由紀錄、代理狀態、佇列日誌，同狀態頁快照。呢啲證據有助日後分辨：究竟係上游供應商故障，定係自己系統整合出問題。

喺真正重要嘅地方追求獨立性

對後果嚴重嘅工作流程，替代方案唔應只係換個模型品牌，仲要盡量喺供應商、區域、雲端、網絡路徑、驗證依賴同營運控制平面上有所不同。兩個模型端點如果同樣經過一個閘道，或者同處一個雲端區域，並唔算有意義嘅冗餘。

結論

9 月 3 日嘅事故唔應被當成「全世界 AI 一齊冧機」，亦未能證實係由孟菲斯中心觸發嘅三供應商連鎖故障。但佢確實提醒企業：表面上獨立嘅 AI 服務，可以喺同一時段一齊失靈；系統設計要預咗呢種情況，喺證據未齊之前安全地繼續運作。 333941