11 月 7 日，北京时间 15:11 到 15:56，DeepSeek 状态页记了一次“网页/API 部分中断”，45 分钟，受影响的是 V4 Pro、V4.1 Flash 两个 API，以及对话和搜索服务。公开记录只有两条，第一条就是“已实施修复，正在监控结果”，没说明原因。DeepSeek 状态页界面新闻
对调用 API 的人来说，45 分钟不算长。麻烦的是你手里那批请求到底算成功还是失败。当天下午，一个开发者贴出的记录是五次重试、八秒、全部 500：“已重试模型请求 (5/5) · 8s”。 失败原因写的是 Internal Server Error (500)，最后以流中断结束。小红书
默认重试策略是为“偶发失败”设计的：等一两秒再试一次。但区域性故障会在几十分钟里持续返回同样的错误。DeepSeek 的文档写得很清楚：500 是服务端问题，503 是过载，官方给的建议都是“短暂等待后重试”。 429 是请求太快或超过并发，要放慢。DeepSeek API 文档
并发限制还按账号算：flash 2500，v4-pro 500，换一个 API Key 也不会多出额度。 你的每个 worker、定时任务、agent 如果都在重试，账号就会被推回 429；等上游恢复，积压的请求又会一起拍上去。DeepSeek API 文档
还有一层。文档说，请求发出后可能一段时间没有响应：非流式会持续返回空行，流式会持续发 `: keep-alive`；如果 10 分钟内还没开始推理，服务端才会关闭连接。 也就是说，连接还在，不等于模型在干活。把 keep-alive 当进度，或把读超时设得比 10 分钟长，都会多等很久。DeepSeek API 文档
反过来，超时也不等于没有产生消耗，它首先只是客户端观察到的现象。 请求可能已经被接收、已经计费，甚至已经调用了工具。纯文本重放最多多花一次钱、换一个答案；发消息、改文件、下单这类有副作用的动作，盲目重放就是另一回事。知乎
如果这是你的系统，顺序大概是这样。
先停发，再重试。连续几个 503 或超时之后，把新任务暂停，队列留着，别让 cron 和 agent 继续往上叠。重试要有总预算：最多几次、总共等多久、超过就停；429 要退避，不要原地重试。
然后花一分钟判断。用一条最小请求确认是上游挂了，还是 key、余额、参数有问题。401、402、400、422 不该重试；500、503 才值得等。状态页只能当参考，它记录的是平台视角，不一定等于你这条链路的状态。
最后按任务决定等还是换。异步、纯文本、能接受延迟的任务，45 分钟通常等得起；交互式任务可以切到提前验证过的备用端点。DeepSeek 的接口兼容 OpenAI 和 Anthropic 格式，切换通常就是 base_url、key、model 三件事，但别把 DeepSeek 这套 `thinking`、`reasoning_effort` 参数原样转给另一家，也别在故障里第一次把生产会话发给一个没核对过数据规则的平台。代码和 agent 会话更要小心：中途换模型，系统提示、已完成的工具结果、待执行动作都可能对不上，暂停和恢复比“热切换”安全。
15:56 之后，服务恢复，你队列里压着的请求才真正开始跑。恢复时先去重，再放量，别让一次故障的尾巴拖成第二次。
官方在 10 月 15 日那次近 5 小时的故障后，按账号 7 天内的消耗 1:1 返了赠金。 那是补偿，不是预案。这 45 分钟里，能限制损失的是队列、幂等和一条提前验过的备用路线，不是事后再对账。蓝鲸新闻
