停機4小時53分，返還7天消耗：DeepSeek贈金補償的計價結構

293 分鐘對 10,080 分鐘，是這份補償通知裡最值得先算的一組數字。北京時間 2026 年 10 月 15 日 8 時 11 分至 13 時 04 分，DeepSeek 的 API 服務中斷 4 小時 53 分；補償方案的返還基數，則是 10 月 8 日至 14 日整整七天的帳號消耗金額，全額以贈金回沖、自動入帳。10,080 除以 293，賠付基數對停機時長的倍數約 34.4 倍。

這個倍數放在雲端服務業的慣例裡相當少見。以亞馬遜 EC2 的服務點數機制為參照，月度可用性低於 99.99% 起賠 10% 的服務費抵扣，低於 95% 才拉到 100%，而且分母是整個月的費用。DeepSeek 的公告沒有出現任何可用性比例的分級計算，直接以近七日消耗為基數全額返還，等於把單次故障的賠付拉到分級表最頂格，且分母更小。

基數為什麼是七天

補償基數的選擇本身就是一份定價決策。按等比例原則，293 分鐘的停機對應七日消耗的 2.9%；DeepSeek 給的是 100%，放大約 34 倍。疊加「API 計費扣款先從贈金帳戶扣除」的規則，返還的贈金會優先吸收用戶後續每一筆支出，等於直接讓渡未來約一週的帳面計費能力。

基數的分配效果也值得拆。故障發生在工作日上午，重度用戶當天的損失遠高於日均水準；按七日全額返還，重度帳號拿到遠超其當日影響的面額，輕度帳號拿到的贈金則貼近實際損失。這個設計把補償往高消耗帳號傾斜，而高消耗帳號正是 API 業務留存壓力最集中的客羣。

時間切割同樣乾淨：故障時段止於 15 日 13 時 04 分，返還基數的統計窗止於 14 日，中間不夾故障當日的任何消耗，先排除「當日計費是否計入基數」的爭議。這類細節在消費端客訴裡最常見，事先切割等於省下一批客服與爭議處理成本。

贈金先扣：成本掛在未來的推理帳上

公告裡最有會計含義的一句，是計費先從贈金扣抵。贈金屬於服務抵用，現金不因補償直接流出 DeepSeek 的帳戶；流出時點遞延到用戶未來每一次呼叫，形式是推理算力、電力與頻寬。

拆開這筆遞延成本：推理服務的成本大頭是 GPU 叢集折舊，屬固定科目，無論用戶是否呼叫都按期攤提。贈金被消耗時，真正的增量支出主要是電力、頻寬與維運負載，兌現成本遠低於面額，前提是既有產能留有冗餘，不需要為消化贈金加購算力。這是航空裏程與零售禮券共通的會計邏輯，套在以低 token 單價擴張市佔的推理服務上槓桿更大，因為計費價與邊際成本之間的差距本來就薄。

對用戶端，兌現前提是繼續使用。一個七日消耗 50 萬元人民幣的企業帳號獲得等額贈金後，未來約一週的計費由贈金吸收；若期間把工作負載遷往其他模型，面額同步作廢。補償因此在結構上綁定留存，用面額換時間，成敗取決於贈金消化完之後用量是否回補。公告未載明贈金有效期限與可否轉讓，這兩個變數決定離場用戶還剩多少折現空間。

單點依賴與最貴的五小時

故障的時間點加重了這筆帳。8 時 11 分至 13 時 04 分完整覆蓋工作日上午，B 端排程任務與上班後的推理需求在這個時窗集中落空。官方公告把根因方向寫得明確：全面梳理並剝離單點依賴。單點依賴在工程語境裡指架構中沒有備援的關鍵節點，消除它意味著多機房、多副本與跨可用區部署，每一項都抬高資本支出並攤薄既有產能利用率。高可用性在成本表上從來不是免費欄位。

歷史脈絡讓這次的賠付義務更重。2025 年初 DeepSeek 在免費消費端高峯期曾多次中斷，當時本站以省下的訓練成本正在推理端按日計帳為座標拆解過該輪當機；那個階段商業計費規模有限，故障代價主要記在口碑上。到了 2026 年 10 月，同樣長度的中斷直接觸及付費生產環境，557.6 萬美元量級的訓練帳單之外，按日累積的推理計費讓每一次停機都有明確的賠付出口。收費與賠付義務一體兩面，這是基礎服務的共同軌跡：亞馬遜 2006 年推出 EC2 後，也是逐步才長出分級服務點數條款。

補償的天花板：只覆蓋 API 費

方案有一道明確的覆蓋上限：返還的是 API 消耗金額，即費用本身，不是下遊因停機產生的營業損失。對一個把 DeepSeek 接進產品的應用而言，五小時不可用影響的是自己的使用者與訂單，這部分損失可能是當日 API 費的數倍，但按產業慣例屬免責範圍。贈金回沖的是輸入成本，回沖不了機會成本。

由此可以排出受惠與承壓的序列。受惠最明確的是重度 API 用戶：七天消耗全返，等於未來約一週近乎免費，而故障時段影響最重的也正是這批帳號。其次是早已部署多模型路由的應用，故障期間自動切往替代模型，付出價差成本，事後仍照領 DeepSeek 贈金，淨效果可能為正。

承壓的第一位是 DeepSeek 自身。贈金先扣讓未來一至兩週的新增計費近零，帳面收入出現一個消化期；留存守得住，這是換取信任的一次性支出，守不住，就是離場補貼。第二位是同業：34.4 倍的賠付基準一旦進入企業採購的比價表，下次任何一家推理服務商故障，對照組已立在明處。在整個 AI 板塊的帳目上，資本支出與企業端收入回收的落差正被逐季檢視，可用性紀錄會直接寫進企業採購的換算表，SLA 條款的顯性化壓力由全行業分攤。

三種收場

情境一，贈金順利消化。七到十個營業日後計費恢復正常，重度用戶留存，DeepSeek 實際負擔的是邊際推理成本，事件收斂為一筆行銷性支出，34.4 倍的基準沉澱為口碑資產。

情境二，備援遷移加速。企業端借這次事故把單一模型依賴改造成多供應商路由，DeepSeek 在路由權重池的份額下滑，贈金成為部分帳號離場前的最後一筆消費。觀察指標是贈金消化結束後一個月的用量回補率。

情境三，基準外溢。賠付標準被採購方寫進合約範本，同業被迫在 SLA 條款、保險與價格之間重新配平，產能冗餘最薄的中小推理服務商承受最重的條款成本。

三種情境共用一個前提：整改兌現與否。公告已把剝離單點依賴寫進公開文本，這句話的工程兌現需要新的資本支出與部署週期。在下一次故障發生前完成，這份補償是危機管理的一次正向支出；反之，賠付基數仍是七天，帳會重新算一遍，而市場對第二次同因故障的寬容度，不會再用贈金衡量。