10月15日早上8点11分，正是打工人刚泡好咖啡、准备开工的时间，DeepSeek的对话框先"停工"了。网页端和App同时弹出一行灰色小字：服务器暂时不可用。对话服务、V4 Pro和V4.1 Flash两个API一并中断。刷新没用，换网络没用，"DeepSeek崩了"很快冲上热搜。有人留言"打工人在工位急得团团转"，有人说"已急哭"，也有人开始找退路："已经切别的AI了"。被波及的不只是国内用户，第三方故障监测平台StatusGator一天内收到86条报障，卢森堡、波兰、纽约的用户都在反馈服务无响应。一个细节很能说明DeepSeek现在的地位：宕机当天，V4.1 Flash的全球调用量下滑了11%，依然排在OpenRouter榜单第一——就在这周，它的单周调用量约19.6万亿token，是全球调用量最高的模型。

停电五小时，电网怎么修的8时11分故障开始，对话服务和两个API陆续部分中断；9时06分官方更新"已定位原因，正在实施修复"；9时08分对话服务完全中断；12时49分"已实施修复，正在监控结果"；13时04分全面恢复。全程4小时52分钟，完完整整覆盖了9点到12点的上午高峰——而按DeepSeek8月起实行的峰谷定价，这几个小时恰好是全天计费最贵的时段，高峰价是闲时的两倍。
为什么修了近五个小时？快思慢想研究院院长田丰的解释是：诊断不慢，瓶颈在修复。大模型服务重启一次相当于一次小型发布，要重新加载权重、预热，再逐步放流量；如果缓存层被波及，恢复后命中率下降，计算压力还会反扑。更不巧的是修复过程撞上早高峰，卡顿时用户反复点"重试"，访问量被成倍放大。
当天傍晚，DeepSeek发布服务恢复及补偿通知，把病根归结为四个字：单点依赖。官方承诺全面梳理并剥离单点依赖，"坚决杜绝同类问题再次发生"。一位AI云计算服务商高管的评价更直接：如果不是外部故障，运维水平就是最大因素，测试、预发布、灰度升级、流量管理、回退机制这一整套工程基建，显然还没跟上模型迭代的速度——DeepSeek大约每一两个月就有一次上新，研究跑在了运维前面。

一张让人心情复杂的电费单补偿方案是这次事件里最有话题性的部分。
DeepSeek宣布：按用户账号7日内（10月8日至14日）的消耗金额，以赠金形式全额返还，赠金自动到账，后续API计费扣款优先从赠金账户扣除。对开发者来说，相当于这一周的API白用了。通知一出，社交平台上晒单不断：有人到账几毛钱，有人4元多、100多元、300多元，用量大的开发者到账超过3000元。有人夸"补偿挺有诚意"，有人调侃这是"梁式重置额度"，还有人说"也是吃到DeepSeek红利了"。
但另一本账就没这么轻松了。据官方服务状态页记录，2026年1月至今，DeepSeek累计出现44次服务异常，持续超1小时的较大故障约10次：3月底有过一次超12小时的跨夜瘫痪，5月单月连崩5次，9月以来故障频出，进入10月半个月已有5起。深圳前海香港商会产业研究院院长阳鑫算了笔账：按常见的99.9%可用性承诺，一个月只允许停摆43分钟左右，这一次近5小时，就用掉了差不多半年的额度——"严重在次数，不在单次"。
汇生国际资本总裁黄立冲把它定性为重大故障级别：一个面向全球用户、同时向企业提供API的平台中断近5小时，不能按普通网络拥堵理解，必须检查备用系统能不能及时接管。田丰的那句话被引用得最多："在智能体时代，AI越像员工，宕机越像停工。"

这次停电之后，该想的几件事宕机当晚，还有一个巧合被反复提起：同一天上午，阶跃星辰正式开源旗舰基座模型Step 5 Preview，很快冲上OpenRouter榜单第二位。对手在敲门的时候，自己停了电。
为什么便宜又好用的DeepSeek总是崩？田丰指出两个公开事实：V4.1 Flash内测期间每个账户最多只能同时处理20个请求；峰谷定价本身就是用价格削峰——说明算力余量本就不宽裕。如果新模型灰度测试和线上服务共用同一批算力，上新就等于在接近满载的机房里再挤进一个几千亿参数的模型。
同济大学副教授李王明卉把问题提到了另一层：高并发下对话和API同时中断，未必是模型本身出了问题，但值得整个行业反思——"我们究竟应该建设一个聪明的模型，还是应该建设一项可靠的智能服务？"真正的技术自信不是永远不出故障，而是能解释故障、控制影响，让用户对服务连续性有合理预期。能力的价值，必须乘以可用性。
开源社区OpenCSG的提醒则给到企业用户：当内容生成、数据处理、代码分析都通过API交给外部模型，服务中断的影响会沿着接口传进每家公司的业务流。自己的系统还在运行，其中一段工作却要等另一家公司复电——哪些任务继续用云端，哪些交给本地模型，哪些要建自己的推理环境，这次故障之后，都该提前想清楚。