11月7日下午，DeepSeek 又崩了：官方状态页记录显示，本次故障自 15:11 起为网页/API 部分中断，波及对话服务、V4 Pro API 与 V4.1 Flash API。 这已经是本周第二次服务中断——11月3日也崩过一次，官方称 API 服务已恢复的同时，承认部分服务性能仍下降。 当晚官方发布说明，称中断问题已实施修复、正在监控结果，服务陆续恢复。 但对重度用户来说，"恢复"从来不是风险的终点：下一次可能只是性能下降而不完全崩掉，而你未必能第一时间发现。知乎知乎小红书
结论可以先行给出：DeepSeek 没有公开可承诺的可用性 SLA，宕机造成的业务损失也没有赔付渠道，补偿只是偶发的消费金额返还——把业务跑在这类 API 上，稳定性只能自己建。知乎
宕机越来越频繁、单次越来越短，但风险没有变小
把 2026 年几起标志性事件按官方口径排开：3月29日晚至30日上午的大宕机，从首次发现异常到彻底恢复耗时接近 12 小时，创下 DeepSeek 成立以来单次服务中断时长的纪录。 10月15日，官方开放平台发布服务恢复及补偿通知，承认当日 8:11 至 13:04 服务系统出现故障。 随后向 API 用户按过去一周用量 1:1 发放永久不过期的补偿赠金。到了 11 月，一周内两次中断，单次时长明显缩短，但间隔也在缩短。界面新闻知乎
官方从未公布全年故障清单，社区统计的"2026 年至今至少 18 次大面积服务异常、平均每月一到两次"没有官方背书。 不必纠结这个精确数字，被公开记录反复确认的是趋势本身。至于原因，官方对 11 月 7 日故障的根因未作披露，社区的主流解释指向算力与流量：MoE 架构下长思考和代码任务耗算量大，高峰期容易扛不住。 与此同时，DeepSeek 的用户规模和生态仍在快速膨胀，平台侧算力压力短期内看不到根本缓解的迹象。微博微博
补偿只返"话费"，不兜"业务"
10 月那次故障后，官方给出过真金白银的处理：宕机近 5 小时，无上限补偿用户近 7 日消费。 有开发者实测确认到账，“返了我一百多块钱”。 看清这份补偿的性质很关键：赠金返还的是你的 API 消费额，相当于退话费；任务失败的返工成本、订单流失、客户投诉，全部不在覆盖范围内。而 11 月的两次故障，官方截至发稿并未公布任何补偿。微博知乎
补偿不是合同义务，而是偶发姿态。把"崩了会赔"当作可以接受宕机的理由，等于把业务连续性的定价权完全交给对方。
真正该盯的是自己链路，然后分层建容错
部分中断和性能下降往往不会把状态页整个标红：11 月 3 日官方说 API 恢复时，用户当天的体感就是"短暂崩了一会儿，现在是半残状态"。 所以第一步不是等公告，而是监控自己的调用链路：核心路由的成功率、首字延迟分位数、流式断流率，任一项异常即告警并触发切换——状态页订阅只能作为辅助信号。知乎
在此之上，风险削减分三层落地。
调用层。 设死超时，别用客户端默认值；重试采用指数退避并加随机抖动，避免自家服务实例在故障时刻齐步重发、火上浇油；所有写入型请求做幂等，让重试无副作用；流式响应要能从断点续传或安全重放，因为"输出到一半 stream 结束"正是这类故障最常见的报错形态。
流量层。 重复度高的请求先走结果缓存，宕机时命中缓存的那部分流量完全无感；批量生成、离线分析等非实时任务改异步队列，把用户可见的"失败"变成后台的"延迟"，错峰自动重试。
厂商层。 业务代码只依赖自己封装的模型接口，而不是直接绑死某家的 SDK。多厂商互备加自动切换，本质是把个人习惯工程化。开发者早就自发"手上留几个 AI 轮流翻牌"。 对企业只是把这件事变成自动化能力。官方口径同样建议做多模型备份、设置降级方案。 降级路径可以设计成两档：先切到能力稍弱但便宜稳定的模型保可用，再视排队情况恢复原模型；关键链路还可以用自部署的开源权重模型兜底。知乎知乎
冗余程度按业务匹配：个人随手用，等恢复即可；内部效率工具，重试加缓存加一个备胎模型就够；对外收费、直接对客户交付的业务，双厂商路由、自有监控和降级预案是及格线。多厂商适配和回归测试的成本要长期养，但相比"每月一到两次"的故障频率，损失是在宕机当下按分钟计的，投入产出并不难算。
在官方公布 SLA 和标准化赔付条款之前，唯一可信的可用性指标是你自己链路的实际成功率。按"它一定会崩"来设计系统、给自己留一条切换退路，才是 DeepSeek 频繁宕机给开发者上的真正一课。
