崩了 5 小时，退了一周账单：DeepSeek 的赔付算法

一次五小时的故障，把"模型稳不稳定"这个问题，从技术指标变成了账单上的一行数字。

一、发生了什么

据开源中国报道，10 月 15 日北京时间 8 点 11 分到 13 点 04 分，DeepSeek 服务中断近五个小时。受影响的不只是网页对话，V4.1 Flash 和 V4 Pro 两个模型的 API 也一起停了。早上有用户看到"服务器暂时不可用"，"DeepSeek 崩了"一度冲上微博热搜，据报道这是它本月以来规模最大的一次服务问题。

官方开放平台随后发了服务恢复与补偿通知，措辞是"对于此次故障给您带来的不便与困扰，我们深表歉意"。整改方向也写了：全面梳理并剥离单点依赖，杜绝同类问题再次发生。

补偿方案不是发券，是按账号退还。10 月 8 日到 14 日这七天的 API 消耗金额，以赠金形式全额返还，自动到账，后续调用先从这个赠金账户里扣。换句话说，这一周的 API 费用等于清零重来。

金额因人而异。凤凰网的报道里，有人拿到 3000 元，有人只有 200 多元——因为它挂钩的是你最近一周的实际消费，而不是一个固定数字。

值得注意的是整改那句话的措辞：剥离单点依赖。这等于承认架构里存在单点，而且这个单点足以让两个模型的 API 同时停摆。

二、跟你有什么关系

偶尔用网页版的：你拿不到补偿，也不需要。网页版免费，损失的是五小时的使用时间，换个工具就行。

自己写点小工具的：这是提醒你该看一眼错误处理。很多脚本只写成功分支，接口一挂就抛异常，连重试都没有。

把 API 接进业务的小团队：这次赔付是一笔意外收入，但真正的账单在下面——五小时里你的用户等不到结果，客服要解释，数据要补跑。这些不会有人退给你。更麻烦的是，如果故障发生在你的客户演示中间，损失的是信任，不是额度。

三、把这次故障当成一次免费体检

1. 先确认赠金到账，再核对金额。 按官方口径，返还金额对应 10 月 8 日至 14 日的消耗。如果你是走代理或第三方平台调用的，先确认这笔钱落在谁的账户上。

1. 给你的调用加一条备用路径。 不用一上来就做多云，先做最简版：主模型超时或返回错误码，就切到备选模型，并记录切换次数。切换次数超过阈值，说明你该重新评估供应商。

1. 把"不可用"写进你的监控。 至少三个指标：请求失败率、首字延迟、连续错误次数。没有监控的话，你会在用户投诉时才知道服务挂了。

1. 算一次停机的成本。 用你的日均调用量乘以停机时长，再乘以每次调用的业务价值。这个数字如果超过你一年的 API 账单，那就该认真做冗余了。

四、三个别信的说法

「按用量全额退，说明服务很稳。」 反了。敢这么退，恰恰因为故障规模够大、影响够广，需要用超出常规的赔付来止损。这是一次公关与信任修复，不是稳定性的证明。

「小团队不需要考虑多供应商。」 要看你的调用是不是在关键路径上。写周报、做摘要，挂了就等一会儿；自动接单、实时报价，挂了就是丢单。前者可以单押，后者不行。

「开源模型可以自己部署，就没有可用性问题。」 自部署把故障从"别人的"变成"你的"。机器会宕、显存会炸、模型升级会出兼容问题，只是责任人和恢复时间都换成了你自己。省下的钱，一部分要拿去买运维。

五、一句话结论

这次赔付最值钱的地方不是那几百块赠金，是它提醒你：把全部调用押在一家模型上，等于把可用性外包给了一份你没法看的运维文档。

信息来源

• 开源中国关于 DeepSeek 故障与补偿的报道，2026-10-17：https://www.oschina.net/news/503040

功能与价格以官方公告为准。本文写于 2026 年 10 月 17 日。