DeepSeek 开放平台在 2026 年 10 月 15 日发布服务恢复及补偿通知：北京时间当天 8:11 至 13:04，平台服务系统出现故障，该时段内 API 服务无法正常使用，网页端和 App 的对话服务也同步受影响。对把 DeepSeek 接进生产系统的团队来说，这不是一次刷新页面就能绕过去的抖动，而是持续近 5 个小时的业务中断；通知里更值得看的是补偿口径，它决定了受影响用户能拿回多少。
补偿按 7 日消耗全额返还，以赠金形式到账
补偿方案写得很具体：平台按每个账号在 10 月 8 日至 10 月 14 日这 7 天内的消耗金额，以赠金形式全额返还，赠金自动到账，后续 API 计费扣款先从赠金账户里扣。也就是说，返还额度不按故障时段的调用量计算，而是按故障前一周的实际消耗计算，重度用户拿到的赠金会明显高于轻度用户。已经在用 DeepSeek API 的团队，今天最该做的事是登录开放平台核对赠金是否到账、金额与自己 7 日账单是否对得上；对不上的，先留存账单记录再联系平台。
受影响范围：对话与两个 API 服务同时异常
从官方状态页当天的记录看，异常组件包括对话服务、DeepSeek V4 Pro API 服务和 DeepSeek V4.1 Flash API 服务，状态页在 13:04 标记问题已解决、服务恢复。故障期间，不少用户遇到消息发送后长时间无响应、页面提示服务器暂时不可用的情况。网页端用户最多是工作被打断，API 接入方的损失更直接：线上产品的功能链路、批处理任务和智能体工作流会跟着一起停摆，这也是这次补偿主要面向 API 消耗金额的原因。
平台承诺剥离单点依赖，接入方也要留后手
DeepSeek 在通知中表示，已启动针对服务稳定性的全面排查和整改，重点是全面梳理并剥离单点依赖，避免同类问题再次发生。这个表态是否兑现，要看后续状态页的事故频率，而不是看通知措辞。对接入方更现实的功课有两件：一是给关键链路准备可切换的备用模型或降级方案，不要让单一接口决定整个产品是否可用；二是把状态页监控和告警接进自己的运维体系，故障发生时第一时间切流，比事后核算补偿更能减少损失。补偿能补回一周的调用费，补不回故障时段流失的用户。
