11月3日下午，DeepSeek又崩了。当天下午16时58分起，DeepSeek网页端与API出现部分中断，对话服务以及V4 Pro、V4.1 Flash两个模型的API同时受影响。用户端普遍遇到“服务器繁忙，请稍后重试”的提示。#DeepSeek崩了#很快登上微博热搜，抱怨集中在“任务跑到一半卡住”“等输出等到下班”。微博财经网科技
中断开始约十分钟后，官方状态页更新：此前发生的网页及API服务部分中断问题已实施修复，目前正在监控修复效果。不过公告同时明确，V4 Pro、V4.1 Flash的API服务及对话服务仍存在性能下降；最早的公告口径则是“正在排查问题，以确定故障原因”，截至当天17时50分许，官方没有公布本次故障的根因。所以这次“恢复”的准确读法是：官方修掉的是中断，没修完的是降速——网页聊天用户大多已能正常使用，把自动化流程接在这两个模型上的开发者和企业，超时、变慢并没有完全结束，还有用户反馈“恢复了没一会儿又崩”。新浪科技GPLP看科技
这已经不是DeepSeek今年第一次出问题。3月之后，中断节奏明显加快。界面新闻
3月29日至30日，DeepSeek崩溃近12小时才恢复正常，创下当时单次服务中断的最长纪录。3月31日17时02分，其服务状态页面显示网页/API性能异常，18时05分官方更新称该问题已解决、服务已恢复。5月28日上午，大量用户在社交平台反馈DeepSeek服务出现异常，状态页显示网页对话及API服务中断，原因已定位、正在实施修复。界面新闻界面新闻界面新闻
进入10月，中断变得更长也更频繁。10月15日，DeepSeek中断近5小时后恢复服务。10月27日傍晚起，网页、App与API再度同时停服，28日凌晨官方宣布恢复时，距故障开始已过去约13个小时，创下其2025年以来最长断线。加上今天这次，从10月27日到11月3日的一周里，已是第二次“网页+API”形态的中断。界面新闻知乎
这次故障官方还没有给出根因，此前几次也大多只公布恢复结果、不公布原因分析，负载吃紧只能作为最常被提及的可能解释，还不能急着画因果。而系统侧的压力是可以核对的：10月17日，DeepSeek发布了V4.1-Flash-1017新版本。一周后，经济日报援引OpenRouter数据，该模型在10月19日至25日处理了33.6万亿token，环比增长801%，排在这个平台调用量的第一位。知乎36氪知乎
对普通用户，最可靠的依据是官方服务状态页而不是热搜：这次公告里“已修复”与“性能仍下降”是同页并存的两句话，只读前半句会误判现状。对API和企业用户，有两个带先例的参考点。一是补偿——10月15日中断后，官方曾将故障前7天内账号的消耗金额以赠金形式全额返还、自动到账。不过按公开梳理，这份补偿只覆盖API付费用户，免费对话用户没有对应补偿，且赠金不能提现。今天这次是否同样出补偿公告，还要等官方后续。蚁工厂微博
二是调用策略。有开发者在10月27日事故当晚记录到，V4 Pro的请求首个数据块842ms到达、HTTP状态也是200，生成到87.6秒却直接断了。这位开发者的结论是：看到200不等于调用成功，要把结果分成正常结束、SSE服务端错误事件、网络层EOF三类，先确认收到协议规定的结束事件，再决定整次重试还是续写，否则可能出现重复内容和重复计费。这是单个开发者的日志观察，本人在文中也注明不能当作官方延迟基准，但对正处在“性能仍下降”时段里跑API的用户，恰好是最实用的排查思路。知乎
今晚值得盯的三个节点：官方是否公布根因，状态页的性能下降何时消除，以及是否复制10月15日的赠金补偿。对越来越多工作流绑在这套服务上的用户和企业，这三个答案比“崩没崩”本身更能说明它下一步的稳定性走向。
