DeepSeek 中断 4 小时 53 分后恢复：按 7 天用量全额赠金，但只赔 API 用户

DeepSeek 今天上午崩了近 5 个小时，傍晚给出了补偿方案。

10 月 15 日傍晚，DeepSeek 官方开放平台发布《服务恢复及补偿通知》。按这份通知，当天 8:11 至 13:04 期间服务系统出现故障，API 服务无法正常使用；作为补偿，将按各账号 10 月 8 日至 14 日这 7 天的消耗金额，以赠金形式全额返还。

先看清范围：只赔 API 用户

这条最容易被忽略。故障影响的其实不止 API——当天上午，大量用户反映 DeepSeek 网页端、手机 App 和 API 均出现访问异常，对话时提示「服务器暂时不可用」，「DeepSeek 崩了」一度登上微博热搜。

但补偿通知的措辞明确限定在「API 用户」。也就是说，网页端和 App 上数量庞大的免费用户、以及主要通过网页对话使用服务的用户，不在这次补偿范围内。

再看性质：赠金，不是退款

补偿以「赠金形式」全额返还，自动到账，后续 API 计费扣款优先从赠金账户扣除。

翻译成人话：这笔钱不能提现，只能用于之后的 API 消费。对持续调用的开发者来说等价于真金白银，对已经打算停用的用户来说则不然。

力度其实不小，但容易误读

赔的是 10.8–10.14，也就是故障发生前的 7 天，不是故障当天。这个设计是有道理的：故障期间服务不可用，消耗本来就趋近于零，如果按当天算等于没赔。按故障前一周的用量返还，相当于把用户整整一周的消耗补了回来——放在行业里横向比较，这个力度算得上大方。

官方承认了单点依赖，但没说原因

DeepSeek 在通知中表示，已启动针对服务稳定性的全面排查和彻底整改，「全面梳理并剥离单点依赖，坚决杜绝同类问题再次发生」。

「剥离单点依赖」这句是实打实的表态——等于承认架构上存在单点故障。但具体故障原因，官方至今没有对外披露。根据 DeepSeek API 服务状态页，故障在 9:06 就已「定位原因，正在实施修复」，从定位到 13:04 恢复，中间还有近 4 个小时。

这不是第一次

如果把时间拉长看，这次中断更像是一条曲线上的最高点。据 DeepSeek 事件日历，9 月 2 日、9 月 15 日先后出现网页和 API 部分中断，10 月 12 日出现网页部分中断，加上今天这次，一个半月内已有 4 次明确的服务中断；此外 9 月以来还有 9 次「网页和 API 性能下降」。

作为国内调用量最大的大模型之一，DeepSeek 的 API 稳定性牵动的是下游一整串应用和企业服务。此前有报道称 DeepSeek 已确定 75 亿美元第二轮融资、年化营收突破 10 亿美元——在这个体量下，近 5 小时的全站中断，代价不只是几张赠金。

一句话结论

补偿方案诚意够，但覆盖面窄。真正的问题是：一个月 4 次中断、9 次性能下降之后，「剥离单点依赖」能不能真的把这条曲线压下去。