ChatGPT、Claude、Grok 同時出錯：已知事實與未證實推論

ChatGPT、Claude 與 Grok 在接近的時間出現錯誤，很容易讓人懷疑是整個 AI 基礎設施一起失效。但目前公開紀錄支持的結論更有限：事故時間確實重疊，三家業者披露的原因卻不同，沒有證據能確認三者由同一場連鎖故障引起。

各家已確認了什麼？

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

SpaceXAI 表示，Grok 的問題源於其位於美國田納西州孟菲斯的運算中心故障，並向受影響的「運算合作夥伴」致歉。報導指出，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 分、亦即 UTC 16 時 16 分結束。 33 當時報導將事件描述為基礎設施問題造成的部分中斷。 28

然而，現有公開資料未披露詳細根因，也未建立 Claude 事故與孟菲斯設施之間的關聯。合理的說法是：Claude 確實經歷過一場已排除的事故，但其底層原因在公開資訊層面仍未釐清。

時間重疊，不等於因果關係

三項服務並非在同一個可驗證時刻同時失效。Grok 的通報較早開始；OpenAI 給出的路由錯誤窗口是太平洋時間上午 7 時 43 分至 8 時 17 分；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