DeepSeek 宕機近 5 小時後致歉：按 7 天 API 消費全額返贈金
10 月 15 日，DeepSeek 經歷了一次罕見的長時中斷：北京時間 8:11 至 13:04，服務系統出現故障，持續 4 小時 53 分鐘。當天晚間，DeepSeek 開放平臺釋出《服務恢復及補償通知》，就故障致歉，並給出了一個相當直接的處理辦法——按賬號最近 7 天 API 消費金額的 100%，以贈金形式全額返還。
時間線：從「伺服器暫時不可用」到恢復
故障最早由使用者發現。15 日早間，不少人發現 DeepSeek 對話時彈出「伺服器暫時不可用」的提示。DeepSeek API 服務狀態頁面隨後確認：對話服務與 V4 Pro、V4 Flash API 服務中斷，8:11 為故障起點。
狀態頁記錄了修復過程：9:06 更新為「已定位原因，正在實施修復」，直到 13:04 才給出「本次問題已解決，服務已恢復」。整套流程接近五個小時——對以「基礎設施」自我定位的大模型服務來說，這是以分鐘計的硬停擺。
受影響的除了網頁對話，還有兩條主力 API。這意味著下游一類真實業務被同時掐斷：接入 DeepSeek 的 Agent 平臺、程式設計工具、批處理管線在故障時段內的呼叫都會失敗，需要重試、降級或人工兜底。對把 API 當作生產依賴的開發者來說，近 5 小時的停擺不是一條提示，而是一次事故。
值得注意的是，這次是對話服務與 API 一起中斷。在通行的架構裡，兩者通常共享推理叢集、排程閘道器與賬號體系等底層元件——這也解釋了為什麼「剝離單點依賴」會成為官方整改的核心表述：越是共享的底層元件，越接近系統級單點，為它做冗餘與隔離的成本也越高。
這也不是孤例。據澎湃新聞梳理的 DeepSeek 事件日曆：9 月 2 日、9 月 15 日均出現過網頁與 API 部分中斷，10 月 12 日出現部分網頁中斷；9 月以來還有 9 次「網頁和 API 效能下降」。故障頻率與 9 月密集的釋出節奏（V4.1-Flash 上線、降價、使用者量走高）疊加在一起，讓「穩定性」被放到與新模型並列的位置上討論。
補償方案：7 天消費全額返贈金
補償通知的核心內容只有幾條：按賬號 10 月 8 日至 14 日（共 7 天）的消耗金額，以贈金形式全額返還；贈金自動到賬，無需申請；此後 API 計費扣款優先從贈金賬戶扣除。官方原話是「將按賬號 7 日內（10.8-10.14）的消耗金額以贈金形式全額返還」。
這個口徑值得多看一眼：補償並非按「故障 5 小時內受影響的呼叫量」計算，而是整整 7 天的消費全量返還。對使用者來說，這等於免掉一週的 API 成本；對 DeepSeek 來說，這是一個簡單、無爭議、重度使用者直接受益的演算法——用量越大退還越多，無需逐條核對損失。
注意形式：返還的是贈金而不是現金退款，用途上只能抵扣後續 API 費用。據媒體報道，社群裡已經有使用者曬出到賬截圖，金額從幾毛、幾元到數千元不等，取決於各自此前一週的用量。
為什麼是贈金而不是現金退款？這在大模型行業並非孤例：介面事故之後以平臺額度返還，既完成了賠付動作，也把補償留在了生態內部；而額度最終能否兌現成價值，取決於使用者是否繼續在平臺上消費。DeepSeek 的做法是把「7 天全量」與「贈金形式」綁在一起——力度給足，形式可控。
適用邊界同樣值得留意。多家媒體報道指出，這輪補償主要面向直連 DeepSeek 開放平臺的使用者；通過第三方應用或轉售渠道接入的，通常需要聯絡各自的服務商。此外按平臺通行條款，服務方對故障的責任上限一般為近期已消耗的服務費用，間接損失不在賠付範圍內。
官方態度：「剝離單點依賴」
在道歉之外，通知裡另有一句關鍵表述：「我們已第一時間啟動針對服務穩定性的全面排查和徹底整改，全面梳理並剝離單點依賴，堅決杜絕同類問題再次發生。」「單點依賴」在工程語境裡的含義很明確——系統中某一處沒有冗餘的基礎設施或元件，一旦它出問題，整條鏈路隨之級聯失效。官方沒有披露這次故障的具體技術根因，但把「剔除單點」作為整改關鍵詞，等於間接說明了事故性質。
另有媒體注意到，不同狀態頁面對 15 日事件的歷史展示並不完全一致——一個頁面一度顯示當日「無事件記錄」，與當天的狀態更新、補償通知並不吻合。對以 API 為主業的平臺來說，狀態頁與公告的口徑一致性，本身就是「可信基礎設施」的一部分。
放在更大的背景下看：2026 年的大模型競爭已從「能力釋出」進入「服務質量」階段。當模型能力趨同、價格戰持續，可用性——SLA、故障透明度、賠付機制——才是開發者和企業客戶真正的選型依據。模型再強，如果一週內多次效能下降、一次停擺五小時，下游就要為它準備冗餘與兜底。
對照行業慣例看，故障補償並沒有統一標準，通行條款裡服務方的責任上限通常是近期已消耗的服務費用；而這次「臨近一週消費全額返還」的力度，明顯高於這條底線。某種意義上，它把「AI 基礎設施出事故之後賠什麼」的預設預期向上錨了一格。
對開發者來說，這次事件的提醒也很直接：關鍵鏈路避免單點依賴並不只是平臺的事——多供應商並行、故障時自動降級、對狀態頁與公告做訂閱監控，這些「無聊的工程」才是把大模型接入生產的前提。從故障到致歉再到補償，DeepSeek 用一天走完了應急流程；而「剝離單點依賴」能不能兌現，要看下一次壓力到來時的表現。