芯耀
276
DeepSeek又崩了！短短三天内已是第二次大中断。
3月31日下午17:02，DeepSeek状态页突然弹出“网页/APP/API性能异常”警报，数百万用户再次遭遇对话中断、刷新无响应，直至18:05才恢复正常。
就在3月29日晚21:35至3月30日上午10:33，平台还经历了成立以来最长单次宕机，网页端和App近12小时彻底瘫痪。
这不是一次孤立事故，而是三天内连续宕机，且影响面在网页、APP、API之间来回扩散。
更关键的是，官方至今没有给出原因。
这恰恰是问题最大的地方。
一家做大模型的公司，偶尔出故障不稀奇，但故障连续发生，范围从消费端一路蔓延到开发者接口，官方还始终没有给出清晰解释，这就问题大了。
对于普通用户，这意味着今晚写不了东西；
对To B客户来说，这意味着另一件更现实的事：
到底能不能把业务流程、客服系统、内容生产、代码生成、内部知识库、外部产品接口，接到这样一个随时可能宕机的平台上？
企业采购模型，从来不只买聪明，更买稳定。模型能力决定你能不能进场，服务稳定性决定你能不能留下。
如果一个模型一边在发布会上讲性能，一边在工作日把网页、APP、API轮流搞崩，它卖的就不是生产力，而是不确定性。
基于现有信息，关于这次DeepSeek为什么连续崩，至少有几种可能：
猜测一：修复引发了新的故障，或者变更本身就是故障源。
状态页时间线显示，3月30日当天官方曾两次表示“已实施修复并持续监控”，但问题并没有真正结束，第二天3月31日又出现新一轮网页/API 异常。
这个节奏很像先做修补，再做回滚，再触发新的瓶颈，或者某个依赖在补丁后出现连锁反应。它不是单点宕机，更像是变更控制失灵。
猜测二：流量压力和容量管理出了问题。
Times of India和彭博摘要都提到，Downdetector在用户侧捕捉到了集中报障，说明这不是后台自嗨式的小事故，而是外部用户确实大面积感知到了异常。
若流量峰值叠加限流、扩容、排队机制失灵，最常见的症状就是“server busy”、响应超时、部分入口先挂、修好后又反复。
到这个时候还在被容量问题反复击穿，说明平台治理并没有跟上用户规模。
猜测三：底层推理集群或路由调度层不稳。
这几次故障并非固定打在同一个入口：有时是网页/APP，有时是网页/API。入口不同，症状不同，但背后可能指向同一套模型服务和资源池。
如果是推理集群、负载均衡、模型路由、缓存或状态管理出了问题，用户看到的就会是多个入口轮番报错。
官方没有公开根因，所以现在不能下结论，但从受影响面的分布看，这比单纯前端崩了更说得通。
猜测四：和新版本或静默更新有关。
这条在社交平台上讨论很多。Reddit上有人直接猜测DeepSeek可能在为V4或某种服务器端更新做准备，也有人说故障后模型行为似乎出现变化。
但这只能算社交平台猜测。现在没有任何官方证据证明故障与新模型发布直接相关。
但不管答案是哪一种，DeepSeek 现在面对的都已经不是一次简单的公关危机，而是一次信誉危机。
DeepSeek现在最该修复的，恐怕不只是服务器，还有市场对它的信心。
#DeepSeek
（世界模型工场关注AI圈内部消息，交流八卦请添加作者微信：lovelisa1005，获取更多一手消息）
