DeepSeek 網頁與 API 大當機 2 小時 44 分：對話服務全斷，V4 Pro 連帶受災

編按:本文綜合整理自 IT之家原報導、DeepSeek 官方 status page、ChainCatcher / KuCoin 快訊、IncidentHub 30 天 outage history、Reuters 過去報導、MLQ.ai 編輯,並加入 Siami 編輯部觀點與分析。

事件始末:2 小時 44 分,從 Investigating 到 Resolved 的完整時間軸

DeepSeek 在 2026 年 10 月 15 日台北時間下午 4 點 11 分(08:11 UTC)爆發大規模服務中斷,旗下三項核心元件同步異常。DeepSeek 官方 status page 把這次事件編號為 change_id 7116348214287,標題為「DeepSeek 網頁/API 部分中斷(DeepSeek Web/API Partially Unavailable)」,但實際影響範圍比標題嚴重得多。

• 08:11 UTC(16:11 台北):V4 Pro API 進入 full_outage、V4.1 Flash API 與對話服務維持 operational,狀態標記為 Investigating。
• 08:14 UTC:V4 Pro API 降級為 degraded,問題已開始被定位。
• 08:24 UTC:V4 Pro API 進一步降為 partial_outage,官方於此時段將狀態推進至「正在監控修復結果」。
• 08:31 UTC(16:31 台北):三項元件同步進入 partial_outage,其中對話服務在 08:48 後惡化為 full_outage。
• 13:24 UTC(21:24 台北):官方 status 標記為 resolved,所有元件恢復 operational。

從 08:11 到 13:24,DeepSeek 核心服務總計中斷 2 小時 44 分 50 秒。IncidentHub 第三方監測紀錄同樣驗證這個時間區段,而 Downdetector 在事件期間累計收到 533 筆使用者回報,Errors/Partial Outage 與 Completely Down 兩類投訴各佔一半。

為什麼這件事重要:中國開源 AI 模型的單點依賴風險

把這次中斷放進「中國 AI 服務全球可用性」的大框架看,意義遠超過單一公司 3 小時的服務降級。

第一, DeepSeek 已經不是中國本地玩家。自 2025 年初 DeepSeek-R1 震撼全球以來,這家公司憑藉極低的 API 定價與開源權重,迅速成為歐美獨立開發者、學術研究、新創團隊的預設選項之一。Hacker News 上一位開發者留言直接說明這個現象:「DeepSeek 對隨機的 API-based 工作很 OK,因為它便宜。」(news.ycombinator.com/item?id=49274600)。這意味著 DeepSeek 任何一次中斷,都會直接影響數十個國家的開發者,而不只是中國用戶。

第二, 本次事件特別嚴重的點是「對話服務 full_outage」。對話服務(Chat Service)是 DeepSeek 對 C 端使用者最核心的入口,V4 Pro API 是企業用戶主力的付費 API,兩者同步異常代表 DeepSeek 整個產品線在 2 小時 44 分內幾乎全面失靈。對比起 9 月底到 10 月初多次「partial_outage / degraded」事件,這次是 30 天內最嚴重的一次。

第三, 「large-scale malicious attacks」的官方敘事正在被戳破。DeepSeek 過去多次 API 異常時,官方 status page 都會用「大型惡意攻擊(large-scale malicious attacks)」作為說法,Reddit r/DeepSeek 與 r/SillyTavernAI 社群多次質疑這只是把基礎設施問題包裝成資安事件。本次事件 status page 完全沒提到「malicious attacks」,僅用「Investigating → Identified → Resolved」標準三段式,顯示官方在敘事策略上有所調整。

第四, 30 天內 11 次異常事件已成結構性問題。根據 IncidentHub 監測,DeepSeek 在過去 30 天共有 11 次被官方登錄的 outage 或 degradation 事件,包括 9/17、9/20、9/23(兩次)、10/1、10/8、10/12(兩次)、10/15(本次)。多數事件雖然官方 status page 顯示為「~1 min」(這是 IncidentHub 的顯示下限,實際可能更長),但 11 次的密度對任何企業級 SLA 都是警訊。

Siami 觀點:這次事件再次驗證一個老問題——開源模型不等於開源基礎設施。DeepSeek 釋出 V4 Pro、V4.1 Flash 權重給全球開發者,但 API 服務仍然是 DeepSeek 杭州機房單一來源。對企業用戶來說,「在本地跑 DeepSeek 模型」跟「用 DeepSeek API」是兩個完全不同的可用性故事。

數據解讀:90 天 uptime 數字背後的真相

DeepSeek 官方 status page 同時公布了各元件過去 90 天的 uptime 數據,值得讀者細看。

• DeepSeek V4 Pro API:90 天 uptime 99.74%。
• DeepSeek V4.1 Flash API:90 天 uptime 99.47%。
• 對話服務(Chat Service):90 天 uptime 99.45%。
• 上傳文件服務:90 天 uptime 100%。
• 搜索服務(Search Service):90 天 uptime 99.92%。

如果只看這些數字,DeepSeek 的服務品質其實還算不錯(99.9% 等於一年只允許 8.76 小時中斷)。但實際上,90 天內 11 次異常事件、加上 3 月底那次持續 7 小時 13 分鐘的史上最長中斷,代表 DeepSeek 的中斷是「次數頻繁、單次長度可控」的型態,這種特徵對自動化生產線特別致命——每一次短暫中斷都可能觸發 retry storm,把整個 batch job 拖進 timeout。

值得質疑的兩點:

• 「Identified」時間是否被誇大? KuCoin 快訊引述 ChainCatcher 報導,稱 09:08 官方就標記為「已識別(Identified)」,但實際服務直到 13:24 才 fully resolved。從「識別原因」到「修好問題」中間有 4 小時 16 分的落差,這段時間開發者只能等待,說明 DeepSeek 即使知道問題在哪,修復也並非 trivial。
• 「full_outage」定義是否被低估? 對話服務從 partial_outage 惡化到 full_outage 是 08:48 後,但 DeepSeek status page 對外的 incident 標題仍是「Partially Unavailable」,這個用詞對 C 端使用者會誤導,讓人以為只是「有點慢」而不是「完全不能用」。

與 3 月 30 日 7 小時大當機的對比:結構相似,規模縮水

今年 3 月 30 日,DeepSeek 發生「史上持續最長」的大當機,從凌晨開始一路掛到 10:33 a.m. 台北時間,總計 7 小時 13 分鐘。Reuters 當時的報導把這次事件定位為「自 2025 年初病毒式爆紅以來最長的中斷」。

對比本次 2 小時 44 分的中斷,可以看到幾個結構相似點:

• 時段:兩次都發生在亞洲時段的上班時間(3/30 是台北凌晨 4 點開始、本次是台北下午 4 點開始),暗示亞洲使用者負載是觸發因素之一。
• 元件範圍:兩次都是多個 API 元件同步異常,顯示 DeepSeek 的基礎設施在不同服務之間存在共享瓶頸(可能是負載平衡、API gateway、或底層 GPU 池)。
• 「修復但無細節」:兩次事件官方都沒有公開 root cause analysis,僅用「已解決」帶過。

不同點是:

• 3 月那次只影響對話服務,API 相對正常;本次則是 V4 Pro API、V4.1 Flash API、對話服務三項同步異常,API 受災更廣。
• 3 月那次期間,DeepSeek 剛被美國出口管制升級列入新一波清單,部分媒體揣測與硬體供應有關。本次事件沒有這類外部變數,純粹是服務本身問題。

開發者社群的真實反應:備援方案成顯學

事件發生後,DeepSeek 使用者社群的反應呈現兩極。

憤怒派集中在 r/DeepSeek 與 r/SillyTavernAI 兩個 subreddit。代表性留言包括「DeepSeek 之前公告是 large-scale malicious attacks,結果現在又掛了」、「open source 模型再強,API 服務不穩定就沒意義,該備援方案還是要備」。特別是 SillyTavernAI 社群,他們的 V4 Pro API 工作流對單一中斷極為敏感——bot 角色扮演、記憶持久化、情緒一致性,任何中斷超過 30 分鐘就會破壞對話上下文。

務實派則在 Hacker News 與 V2EX 上討論「如何備援」。常見建議包括:

• 同時訂閱 DeepSeek + Qwen + 至少一個西方模型(Claude / GPT),透過 router 自動切換。
• 把「關鍵路徑」放本地開源模型(DeepSeek 權重本來就可下載,只是 7B/8B 版本需要 24GB VRAM),非關鍵任務才用 API。
• 在 production 程式碼加 exponential backoff + circuit breaker,不要假設任何單一 API 永遠在線。

這場事件給企業 IT 的具體教訓是:「DeepSeek 在亞洲時段是骨幹,西方時段要降級」的時段路由策略可能比單一供應商更划算。畢竟 DeepSeek 凌晨的中國用戶最閒,西方使用者最活躍,任何「全球 24x7 服務」都應該把 SLA 風險分散到至少 2 個供應商。

後續觀察重點:這 30 天要看什麼

• DeepSeek 會不會發布 root cause analysis? 過去幾次事件官方都僅以「已解決」收尾,沒有 post-mortem。如果本次 DeepSeek 願意公開「為什麼 3 個元件同步掛掉、為什麼修了 4 小時 16 分」,那會是中國 AI 服務少見的透明度里程碑。
• 是否有外部攻擊跡象? Status page 這次沒提 malicious attack,但 8 月時 DeepSeek 曾因「large-scale malicious attacks」連續公告數次。安全研究社群(例如 CrowdStrike、Mandiant)是否會在後續報告中提及,值得追蹤。
• 對 DeepSeek 商業客戶的影響? DeepSeek 企業級 SLA 通常承諾 99.9% 月度可用性,本次單一中斷就吃掉 0.38% 月度配額。若企業客戶在合約中要求 SLA credit,DeepSeek 是否會主動補償,將是觀察其企業級成熟度的指標。
• 西方對手中標的機會? OpenAI、Anthropic、Google 都對中國 AI 服務不穩定「虎視眈眈」,本次事件後,使用 DeepSeek 的獨立開發者是否會跳槽到 Claude 或 GPT-4,將直接影響 DeepSeek 在西方的市場份額。
• 價格戰是否加劇? DeepSeek 之所以能在西方站穩腳跟,核心是「便宜 + 開放」,如果「便宜」被「不穩定」對沖,DeepSeek 勢必得在價格上更激進才能留住客戶。3 月底 7 小時大當機後,DeepSeek 並未降價;本次事件後是否會,是價格戰的關鍵訊號。

無論如何,DeepSeek 在過去 30 天 11 次異常、加上 3 月 30 日 7 小時大當機的累計數據,已經為 2026 年的「中國 AI 服務全球可用性」留下了教科書級的案例。對 Siami 讀者而言,任何把 DeepSeek 當作唯一 LLM 供應商的 production system,都應該重新檢視備援架構。