DeepSeek 在 2026 年 10 月 15 日晚间通过开放平台发布服务恢复及补偿通知：当天北京时间 8 时 11 分至 13 时 04 分，其服务系统出现故障，API 服务无法正常使用，网页端与 App 对话同样受影响。官方状态页记录，9 时 06 分已定位原因并实施修复，13 时 04 分问题解决、服务恢复，故障持续约 4 小时 53 分钟，受影响的包括对话服务以及 V4 Pro、V4 Flash 的 API。通知的补偿方案是：按每个账号 10 月 8 日至 14 日七天内的实际消耗金额，以赠金形式全额返还，自动到账，后续 API 计费优先从赠金账户扣除。
故障原因没细说，整改先点名单点依赖
通知没有公布故障的具体技术原因，只说明已启动服务稳定性的全面排查和彻底整改，重点是全面梳理并剥离单点依赖。也就是说，官方自己承认这次中断与单点依赖有关——某个环节没有冗余，它一倒，整条服务链跟着倒。这次故障的时长放在 DeepSeek 今年的记录里也靠前：据其事件日历，9 月 2 日和 9 月 15 日都出现过网页与 API 部分中断，10 月 12 日有过部分网页中断，9 月以来另有多次性能下降。偏偏这次撞上工作日上午的办公与调用高峰，依赖它跑业务的开发者和智能体应用被整段晾在原地。对正在通过 OpenCode 等免费渠道调用 DeepSeek 模型的开发者来说，这也是提醒：免费或低价渠道之外，生产系统还需要第二条腿。
为什么补偿按消耗算，而不是人人一份
按过去七天消耗全额返还，意味着用得越多、补得越多：轻度用户到账几角几元，重度用户晒出的截图里有上千元。这种算法本质上把补偿和实际损失挂钩——API 客户真正的损失是停机时段里跑不了的业务，而调用量正是业务规模的粗略代理。相比固定面额优惠券，全额返还一周消耗的姿态要高得多，成本也实打实：返还的是可直接抵扣未来账单的赠金，不是打折券。DeepSeek 没有设置申请流程，自动到账也省去了用户举证的摩擦。这套打法修补的不只是五小时的故障，而是开发者对「敢不敢把生产流量押在一家供应商身上」的信心。
稳定性正在变成模型竞争的另一条赛道
模型厂商过去比的是榜单分数和每百万 token 价格，今年以来，宕机时长和事后处置开始进入采购决策：一次近五小时的中断，足以让企业客户把双供应商、故障切换和状态页监控从「以后再说」提上日程。对 DeepSeek 而言，低价策略拉来了大量对成本敏感的调用量，而调用量越大，稳定性的短板被放大得越明显。这次补偿的诚意能挽回多少信任，取决于后续整改是否兑现——状态页接下来几个月的记录，就是最诚实的答卷。
