DeepSeek API中断4小时52分，补偿一周消费背后的容灾课

10月15日，DeepSeek的聊天服务与两个API模型同时出现部分中断，持续4小时52分钟。事后DeepSeek宣布按账号7日内消费金额以赠金形式全额返还。这起事件暴露的不仅是单一厂商的稳定性问题，更是所有依赖单一模型API的应用都需要面对的容灾课题。

中断了什么，持续多久

根据DeepSeek^广告官方状态页，本次事件标题为「DeepSeek 网页/API 部分中断」，影响三个组件：对话服务、DeepSeek V4 Pro API服务以及DeepSeek V4.1 Flash API服务。时间线以UTC记录：00:11开始排查，01:06定位原因，04:49实施修复并监控，05:04宣布服务恢复。

据财新报道，网页端和App从北京时间约8:00开始显示「服务器暂时不可用」，对话服务从9:08起完全不可用。TechNode同样确认聊天服务和两个API模型均受影响。DeepSeek并未说明具体故障原因，但其补偿通知提到已启动服务稳定性全面审查，并将消除单点依赖。一个故障同时打掉聊天产品和两个API模型，这种措辞指向底层共享组件出了问题。

什么是「API兼容OpenAI格式」

OpenAI 在 2023 年之后事实上把 /v1/chat/completions 这套请求与响应结构变成了行业通用接口。所谓「兼容 OpenAI 格式」，指的是第三方服务复刻了这套路由、字段名和返回结构，使得原本为 OpenAI 写的 SDK、库和代码可以只改 base URL 与模型名就直接使用。DeepSeek、Moonshot、智谱、Together、Groq 乃至本地部署的 vLLM、Ollama 都提供兼容端点。这一约定极大降低了多供应商容灾的成本：切换不再需要重写调用层，代码里只需改变量。但它只保证「接口形状」一致，不保证输出风格、函数调用支持度、上下文长度或限流策略一致——这正需要评测来兜底。

补偿覆盖什么，不覆盖什么

据澎湃新闻和IT之家报道，补偿条款很直接：赠金金额等于账号10月8日至14日的消耗总额，以赠金形式自动发放给API用户。DeepSeek定价页面有一条对下期账单影响最大的细节：「当充值余额与赠送余额同时存在时，优先扣减赠送余额。」也就是说赠金到账后会先于现金被消耗。

这里有个关键错位：补偿跟踪的是你过去的消费额，不是你的实际损失。10月8日到14日消耗大的账号拿回得多，那周还在原型阶段的账号拿回得少——哪怕10月15日的中断正好打在你的上线日。补偿也止步于账单：产品未能响应的请求、堆积的重试、随之而来的客服工单，都不在补偿范围内。通知未说明赠金是否过期，建议直接查看DeepSeek平台的余额页面确认。

这不是9月以来的第一次

财新统计，自9月以来DeepSeek已发生13次故障，多数是网页和API的性能降级，其中4次涉及网页和API的部分中断。10月15日状态页显示，2026年7月至10月V4 Pro API服务可用率为99.74%，V4.1 Flash API服务为99.47%。

V4.1 Flash是个新模型，DeepSeek于9月10日发布，官方称其为「新架构家族中最小的模型」，在API中以deepseek-flash名称提供服务。有newsletter将这一连串故障与新模型的需求压力联系起来，但DeepSeek官方并未确认，只能当作猜测。

这些数据并不意味着DeepSeek格外脆弱。任何托管模型API都有不顺的早晨。真正的教训正是DeepSeek自己写在通知里的那句话：所有东西压在同一个依赖上就是风险——如果你的应用每次LLM调用都只发给一个供应商，你面临同样的问题。

可用率 99.74% 意味着什么

99.74% 的月度可用率约等于每月 1 小时 52 分钟的不可用（按月 30 天、43200 分钟计算）；99.47% 则约合每月 3 小时 49 分钟。这是「API 层」的统计口径，通常按请求成功率或时间片加权计算，不同厂商定义不同。对比来看，主流云厂商的单区域 SLA 常在 99.9%（每月约 43 分钟）以上，而头部 LLM 服务由于依赖 GPU 集群、推理排队与频繁的模型版本迭代，普遍低于传统云服务。这意味着把一个关键业务的全部 LLM 流量压在一个模型 API 上，年度累计中断时间达到小时级几乎是常态而非例外——这正是文章主张加 fallback 的量化依据。

给DeepSeek调用加一个备用供应商

DeepSeek API文档明确说明其API兼容OpenAI格式，基础URL为https://api.deepseek.com，并展示了与官方OpenAI Node SDK配合使用的方式。这让备用方案的成本很低：换一个base URL和模型，再建一个客户端即可。

代码中的几个选择是刻意的：

• timeout和maxRetries是SDK选项。短超时加单次重试，避免死掉的端点把你的请求挂住几分钟才轮到备用。备用端也设同样的限制，以防它本身也慢。
• 连接失败和超时会以无status的APIError子类形式抛出，因此status === undefined算作中断，429和5xx同样。
• 400或401不触发切换。请求格式错误或密钥失效是你自己的bug，发给第二家只会掩盖问题。
• 备用端可以是任何你已信任的、兼容OpenAI格式的端点，通过环境变量配置。成本不是首要考量，DeepSeek挂掉时它能不能顶住才是。

需要留意的是，不同模型可能给出不同答案。如果你要解析结构化输出，备用模型也要跑一遍评测。同时记录每个请求由哪家供应商服务，否则你不会知道有多少流量跑在备份上。

为什么 400/401 不该触发切换

HTTP 状态码可以按「谁的锅」分类：4xx 中 400（请求格式错误）、401（密钥无效）、403（无权限）、404（模型名不存在）都属于客户端问题，重发给另一家供应商只会得到同样的错误，反而掩盖了你代码里的 bug、配置漂移或密钥轮换遗漏。相反，连接失败、超时、429（限流）、5xx（服务端错误）都是供应商侧的瞬时故障，是 fallback 真正该接管的情形。这条「按错误性质路由」的原则是熔断器（circuit breaker）与重试策略的共同基础：对确定性错误快速失败，对瞬态错误才做退避与备援。

本周可以做的事

1. 打开DeepSeek平台余额页面，确认赠金是否到账、金额多少。
2. 记住赠金优先扣减，现金余额会在一段时间内纹丝不动——相应调整监控现金余额的消费告警。
3. 翻查10月15日00:11–05:04 UTC的日志，统计失败请求数。这个数字更接近中断的真实代价，而补偿覆盖不了它。
4. 按上文方式加入fallback，并在staging环境把主端点指向一个错误URL来测试切换是否生效。

一个更底层的工程判断

系统设计的核心永远在权衡：每个依赖失败时你要付出什么，以及你为活过那次失败要提前支付什么。模型API只是这份依赖清单上的一项。10月15日提醒的是，值得为它可能的消失提前做设计。

如果你的模型调用方是编码Agent，那么选型时也要把这一点纳入考量：能否按任务切换不同的Agent、模型和账号，能否在一个Agent达到用量限制时把任务无缝迁移到另一个。多供应商容灾不应只是API层的补丁，也应是工具链本身的能力。

依赖清单与「可替代性」设计

成熟系统通常维护一份依赖清单（dependency inventory），逐个标注：失效概率、影响范围、是否有降级路径、恢复时间目标。模型 API 只是其中一项，和数据库、身份认证、CDN、消息队列并列。一个常被忽视的维度是「可替代性」（substitutability）——不仅是接口能否替换，还包括数据格式、评测基准、计费方式、账号配额能否平滑迁移。编码 Agent 场景尤其如此：任务状态、会话历史、工具调用协议往往与特定 Agent 绑定，切换时迁移成本远高于换一个 HTTP 端点。把可替代性作为选型指标，意味着在采购和架构阶段就为「这家明天消失」预留成本，而不是等故障发生后再临时打补丁。