为啥DeepSeek又崩了?这次45分钟,但状态页近38天记录了9次服务异常

源自41位全网作者

11-07 18:43

2026年11月7日15时11分,DeepSeek官方状态页出现告警:对话服务与 V4 Pro、V4.1 Flash 两个 API 进入"部分中断",网页端和 App 的用户发出提问后收不到回复,屏幕上反复弹出"服务器繁忙,请稍后重试"。多家媒体当天记者实测确认,在DeepSeek界面输入信息后无法得到回复。15时56分,状态页把这条事故标记为"已解决,服务已恢复"——从发现到恢复,官方口径约45分钟。界面新闻知乎DeepSeek官方状态页

这是四天内的第二次:11月3日,DeepSeek网页与API已经发生过一次同等规模的部分中断,当晚服务虽告恢复,部分服务性能仍下降。界面新闻第一财经

为什么"又"崩了?DeepSeek至今没有公布这两次中断的技术原因。但把官方状态页的记录、第三方用户数据和产品发布节奏放在一起看,答案不是"运气差":崩溃正在从偶发事故变成结构性常态——用户用得更深、Agent生态烧掉的Token更多、新功能上线更密,而算力余量的扩充才刚刚开始兑现。恢复变快了,间隔也变短了。

状态页还原故障频率:单次更短,间隔更密

DeepSeek官方状态页从8月10日开始统计整体可用性,目前为99.82%——这个数字本身不差,但它的构成值得细看。仅10月1日到11月7日,状态页就列出了9条服务异常记录:5条"部分中断",4条"性能下降"。DeepSeek官方状态页

对比历史事故,趋势很清晰:单次时长在缩短,间隔在变密。3月底那次是DeepSeek成立以来最长的一次宕机,从首次发现异常到全面恢复持续接近12小时,其间还出现过修复后再次波动的二次故障。10月15日上午8时11分开始的异常持续近5小时,网页和App一度显示"服务器暂时不可用";而11月7日这次,只用了45分钟。38天9条记录意味着,用户侧的"崩了"体感已经从"几个月一遇"变成"一周可能碰上两次"。界面新闻知乎

把时间线拉长,崩溃在DeepSeek这里并不是新问题。2025年初,它就因线上服务遭遇大规模恶意攻击出现过多次短期宕机,官方不得不限制非+86手机号注册以保障服务稳定;此后每逢用户量激增或服务器资源紧张,宕机就会重演——2025年2月6日,官方甚至因资源紧张暂停过API服务充值。今年只是同一类压力发作得更频繁。界面新闻

压力从哪来:需求端在加速,供给端刚拿到钱

用户不只是更多,而是用得更重。QuestMobile 11月3日发布的秋季报告显示,2026年9月DeepSeek月人均使用次数65.9次、人均使用时长136.7分钟,季度环比分别增长5.8%和9.5%,同期豆包这两项指标在下降,用户黏性正在向DeepSeek集中。界面新闻

真正的新增变量是Agent生态。11月5日晚,DeepSeek Harness团队公布,截至11月4日、以使用官方API的用户为统计范围,Harness日活跃用户已达154万,第三方插件增至约3.5万个,日消耗Token约92万亿。聊天是一次一问,插件和智能体是机器对机器的连续调用,单次任务的Token消耗完全不在一个量级。界面新闻

产品动作又在同步加码。10月23日搜索引擎上线、10月31日发布Super-agent架构、11月3日推出"创造模式",新版模型在OpenRouter平台的单周调用量一度环比暴增801%、登顶全球首位。每一次上新都对应一波流量涌入,而历史多次故障的直接诱因恰恰就是新模型或新功能发布后的用户激增。36氪

供给端刚刚跟上。10月下旬,36氪在出海周报中记录DeepSeek完成超千亿元A+轮融资,宁德时代等产业资本入场,方向普遍指向算力扩建;从融资到账到集群建成上线存在客观周期,中间这段"需求已涨、余量未补"的窗口,正是状态页上这些橙色记录的来源。36氪界面新闻

至于周六下午这个时间点,社区里流传"崩了是要发新模型"的玩笑和"周末在调试新模型"的猜测,官方均未证实,只能作为未核验的传闻看待。至于宕机的机制,一个已被媒体反复引用的解释是:故障期间大量用户因页面卡顿而反复点击重试,导致平台访问量在短时间内异常激增,形成"雪崩效应",进一步加重了服务器负载。这次45分钟的快速恢复说明隔离和修复在变快,但防不住下一次过载的根源。界面新闻

用户现在该盯什么

对普通用户,这类短中断等待恢复即可,但有一个实际观察点:补偿。10月15日那次事故后,官方曾推出返还七日所有Token消费的补偿方案,当事用户的讨论记录至今可查。而这周11月3日、11月7日两次中断,截至发稿官方没有公布任何补偿计划,社区里"坐等返券"的调侃背后,是用户对补偿规则没有固定预期的不满。是否补偿、按什么口径补偿,是接下来几天值得盯的官方动作。知乎

对把DeepSeek放进工作流的开发者和重度用户,更现实的是降低单点依赖:重要任务保留中间产物、API调用做好重试与幂等设计,为关键链路准备第二家模型服务作降级备份,这类建议已在围绕本次故障的讨论中被反复提出。知乎

故障原因、下一轮补偿安排、以及千亿融资何时转化为可见的算力扩容——这三件事的答案,将决定"DeepSeek又崩了"这个话题下次上热搜时,是旧事重提还是终于翻篇。

内容由AI生成

精选参考来源

0
扫一下,分享更方便,购买更轻松
0评论

当前文章无评论,是时候发表评论了
提示信息

取消
确认
评论举报

最新文章 热门文章