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 用一天走完了应急流程；而「剥离单点依赖」能不能兑现，要看下一次压力到来时的表现。