DeepSeek 宕机不到 5 小时，却把用户 7 天的账单全免了：这笔赔款约是「该赔的」34 倍

10 月 15 日早上 8 点 11 分起，DeepSeek 网页端和 App 集体弹「服务器暂时不可用」「服务器繁忙」。挑时间看更有感觉：8 点到 13 点，正好覆盖整个上午的工作时段。官方 API 状态页的时间轴是这样的：8:11 故障发生，9:06 定位原因，13:04 修复完成——全程 4 小时 53 分。这五个多小时里，聊天网页的用户顶多重试几次；真正被掐住喉咙的是另一群人。

DeepSeek 的网页对话免费，但 API 是按调用量收费的商业接口：接它的是编程工具、客服机器人、做 AI 应用的创业公司。主站一宕机，这些挂着它的服务跟着一起哑火。傍晚，DeepSeek 官方开放平台发布《服务恢复及补偿通知》，给出了一个相当罕见的方案：按账号 7 日内（10 月 8 日至 14 日）的消耗金额，以赠金形式全额返还——自动到账，之后 API 计费先扣赠金。社交平台上已经有人晒出到账截图。

这里有个容易混淆的点：这次补偿和网页聊天用户无关。免费用户在故障期间上不了线，确实受了影响，但赔付只覆盖掏钱的 API 账号——所以晒截图的清一色是开发者，晒的数字从几元到几百上千元不等。道理不复杂：付费关系里才有赔偿依据，免费服务的止损方式是把服务修好。普通读者真正该关心的反而是下面这笔账。

这笔补偿最不寻常的地方，是「全额」两个字。行业惯例是按故障时长折算，正着算：宕机 293 分钟，只占 7 天（10080 分钟）的 2.9%，一个 7 天消耗 500 元的开发者，按比例只该赔 14.5 元；DeepSeek 实际返了 500 元，约是比例赔付的 34 倍。反着算同样成立：想让「全免 7 天账单」和「按小时赔偿」打平，这场故障得连续不间断挂满 168 小时——整整一周。用一笔「宕机一周」额度的赔付，去覆盖一次 5 小时的事故，这不是按损失定价，是按关系定价。

为什么这么大方？两个解释都站得住。 一是 API 是 toB 生意，迁移成本极低——换个接口地址就能切换供应商，一次故障足以让客户永久切走，全额返还买的其实是「留下」。二是别忘了赠金的用法：它只能继续在 DeepSeek 平台消费，钱没有离开平台。账面上看是全额退款，实际更像一张代金券，边际成本远低于账面数字。说它是赔偿可以，说是营销预算换了个科目入账，也说得通。还有一个背景值得放在心里对照：就在 9 月底，DeepSeek 刚上调过部分 API 的价格，最高幅度不小。涨价之后不久来一次大方赔付，时间点凑在一起，信任修补的意味就更浓了。

比单次故障更值得留意的是频率。根据官方状态页的事件日历：9 月 2 日、9 月 15 日发生过网页和 API 部分中断，10 月 12 日网页部分中断，9 月以来还有 9 次「性能下降」。通知里「剥离单点依赖」的整改承诺，这已经是第三次出现在类似通报里了。给普通读者的两条实用建议：如果你的业务挂在某一家 AI 接口上，官方状态页值得收藏进书签；更稳妥的做法是预留第二家供应商，故障时一键切换——毕竟下一次全免账单的好事，不会总有。

今天就聊到这。有收获点个「赞」，想接着看就点个关注。