DeepSeek深夜崩溃3小时，为何算力跟不上用户暴涨？

3月29日晚，大量用户发现DeepSeek无法加载内容，页面停在“服务器繁忙”提示上。21:55问题被正式确认，23:01官方才宣布恢复访问。此前，它的日活用户在一季度飙升至2亿，而算力储备仅增加8.3%。

23:01刚过，DeepSeek主页重新能打开，状态栏跳出“已恢复访问”。就在不到两小时前，网页、App、API三端同时卡死，提示同一句“服务器繁忙，请稍后再试”。从19:30起到恢复前，近三个小时，所有请求都没有返回结果。

同在社交平台，#DeepSeek崩了#的话题登上热搜，高峰时阅读量过亿。有人截图自己付费会员页面，还来不及点“续费”按钮就被系统踢出。一部分开发者在反馈社区留言：‘接口全部超时，任务队列空转。’

当晚21:55，DeepSeek内部监控发现异常流量。22:28状态页面更新：“已定位到问题，服务正在逐渐恢复中。”直到23:12，大部分功能才恢复，23:39标记“事件已解决”。官方的时间线很清楚，却掩不住用户间的议论——为何又是熟悉的宕机节奏。

这不是第一次。2月28日，同样的提示语出现，“服务器繁忙”持续接近一小时；3月5日再现，叠在论文提交和开发高峰。每一次都在使用量激增的节点上。前次官方解释为用户量暴涨导致“系统熔断”。

但近一季的数据更极端。DeepSeek日活从1.2亿激增到2亿，增长幅度66.7%。同期计算资源的增加只有8.3%。供需之间差了一个数量级，这意味着同样的模型推理要在几乎相同的硬件上完成更多任务。

2025年上线至今，它多次位居应用商店榜首，一度超越ChatGPT。2月初累计下载破1.1亿，周活跃用户逼近9700万。那种暴涨的势头，使“崩溃”几乎成了周期性指标。

宕机的不只是网页。那晚移动端也打不开，API接口直接返回500错误。对开发者来说，这意味着自动化流程中断，数据流断裂。对普通用户而言，就是一句卡死的提示。

技术人员后续在论坛上确认，本次异常起于模型请求队列过载。短时间内的写入峰值让服务端逻辑锁定，系统触发保护机制。与1月26–27日那次全面宕机不同，这回响应恢复较快，没有再出现历史对话消失的情况。

不过，故障发生的时间值得注意。几乎每逢重大模型更新前，都有类似波动。1月末曾披露遭受海外DDoS攻击，而今年2月末又传出DeepSeek将上线多模态模型V4，可同时处理图片、视频与文本。升级前的压力测试，很容易与用户访问叠加。

付费用户的焦虑也在放大。一位持年会员的用户写下“花了钱，却最先掉线”，贴在热搜评论下，引来数千回应。DeepSeek在官网公告区没有就赔偿或延长期限作说明，只在状态页留下一行字：“本次宕机未造成数据损失。”

从这些碎片能拼出的，是一条重复的曲线：用户数暴涨—系统迟滞—热搜爆发—深夜恢复。每次都铺陈着相似步骤，唯独峰值的数字一次比一次大。到3月29日这天，服务器仍旧在原地吃紧。

当访问数逼近2亿、算力增长却只有8.3%，当23:01恢复页面还滚动着“已解决”字样，这种不对称还能支撑多久？下一次“服务器繁忙”，会不会又是在新模型开放的那一刻？