DeepSeek 崩了吗？

DeepSeek

没崩 —— DeepSeek 运行正常

我们的监测源未发现异常。如果你仍然无法使用，问题很可能出在你本地 —— 下方的排查建议列出了常见原因。

正常 始于 · 检测于

监测数据详情

官方状态页
未提供
最近 1 小时测试请求
未对该服务运行测试
OpenRouter 调用流量
2 个模型中有 0 个出现异常，近 30 分钟请求成功率 100%
最近 1 小时访客报告
0

官方状态页 ↗访问 DeepSeek ↗

最近 24 小时

17:52 UTC — 正常18:22 UTC — 正常18:52 UTC — 正常19:22 UTC — 正常19:52 UTC — 正常20:22 UTC — 正常20:52 UTC — 正常21:22 UTC — 正常21:52 UTC — 正常22:22 UTC — 正常22:52 UTC — 正常23:22 UTC — 正常23:52 UTC — 正常00:22 UTC — 正常00:52 UTC — 正常01:22 UTC — 正常01:52 UTC — 正常02:22 UTC — 正常02:52 UTC — 正常03:22 UTC — 正常03:52 UTC — 正常04:22 UTC — 正常04:52 UTC — 正常05:22 UTC — 正常05:52 UTC — 正常06:22 UTC — 正常06:52 UTC — 正常07:22 UTC — 正常07:52 UTC — 正常08:22 UTC — 正常08:52 UTC — 正常09:22 UTC — 正常09:52 UTC — 正常10:22 UTC — 正常10:52 UTC — 正常11:22 UTC — 正常11:52 UTC — 正常12:22 UTC — 正常12:52 UTC — 正常13:22 UTC — 正常13:52 UTC — 正常14:22 UTC — 正常14:52 UTC — 正常15:22 UTC — 正常15:52 UTC — 正常16:22 UTC — 正常16:52 UTC — 正常17:22 UTC — 正常

24 小时前现在

最近 30 天

9月28日 — 暂无数据9月29日 — 暂无数据9月30日 — 暂无数据10月1日 — 暂无数据10月2日 — 暂无数据10月3日 — 暂无数据10月4日 — 暂无数据10月5日 — 暂无数据10月6日 — 暂无数据10月7日 — 暂无数据10月8日 — 暂无数据10月9日 — 暂无数据10月10日 — 暂无数据10月11日 — 暂无数据10月12日 — 暂无数据10月13日 — 暂无数据10月14日 — 暂无数据10月15日 — 暂无数据10月16日 — 暂无数据10月17日 — 暂无数据10月18日 — 暂无数据10月19日 — 暂无数据10月20日 — 暂无数据10月21日 — 暂无数据10月22日 — 暂无数据10月23日 — 正常10月24日 — 正常10月25日 — 正常10月26日 — 正常10月27日 — 正常

30 天前昨天

有数据的 5 天中，有 5 天无任何异常。

近期故障

过去 30 天内无故障记录。

关于此服务

我们测试 DeepSeek API。chat.deepseek.com 的免费聊天界面运行相同的模型，但在高负载下通常最先变慢，尤其是在新模型发布后的几天内，“服务器繁忙”提示会较为频繁。

其他模型 API 当前状态

DeepSeek：常见问题

是 DeepSeek API 挂了，还是我代码的问题？

请查看 HTTP 状态码。401 和 403 代表 API Key 或权限问题，400 和 422 代表请求参数格式错误，429 代表触发了速率限制或额度用尽。只有 500、502、503、504 以及请求超时，才意味着问题出在 DeepSeek 服务端。如果本站显示该服务正常但你依然收到服务端报错，可以用 curl 发送一个最小化请求，以排查是否是本地客户端库或代理的问题。

我的应用该如何应对 DeepSeek 突发故障？

对 429 和 5xx 响应采用指数退避重试，并加入少许随机抖动，同时限制最大重试次数；设置合理的超时时间，防止卡住的流式请求堆积。对于直接面向用户的场景，建议配置其他厂商的备用模型，并在连续几次请求失败后自动无缝切换——上方列表展示了当前哪些服务处于健康状态。

为什么别人说一切正常，我的请求却一直失败？

限制通常按组织和模型分别设定，因此你的账号可能会被限流，而其他人却能正常使用。在用量高峰期，新发布的模型和超大模型也往往最先被限频。请检查账号的用量页面，尝试改用较小的模型，并确认调用了正确的 base URL 和区域。

响应速度很慢但最终能返回，这算服务中断吗？

重点看首字（first token）延迟，而非总耗时。在我们自己的测试请求中，当首 token 耗时超过 3 秒且达到当天中位数的 3 倍以上时，我们就会标记为响应缓慢。长提示词（prompt）和长文本输出本身就需要较长时间，这属于正常现象，不会被视作故障。

你们怎么知道 DeepSeek 是否宕机？

针对 DeepSeek，我们综合参考OpenRouter 上 DeepSeek 相关模型的请求成功率和本页面收到的用户故障反馈。我们会以最新且最严重的状态信号为准，并自动忽略过期数据以保证准确性。页面会自动刷新；具体的判定阈值可在我们的“检测机制”页面查看。

检测机制 →