DeepSeek 中断 4 小时 52 分后恢复：年内已至少 18 次服务异常

10 月 15 日一早，陆续有用户发现 DeepSeek 弹出服务器暂时不可用的提示。平台状态页面随后显示，对话服务与 V4.1 Flash 接口出现部分中断，网页端与接口性能下降，官方随即开展排查。

故障在当天 13 时 04 分被状态页标记为已解决，服务陆续恢复；从早间异常算起，前后持续 4 小时 52 分钟。

类似情况并不少见。进入 2026 年之后，DeepSeek 累计至少 18 次出现大规模异常，折算下来每月一到两次；3 月底的一次持续超过 12 小时，5 月接连 5 次中断，9 月也记录了至少 7 次波动。对一款被大量开发者接入生产环境的产品来说，这样的频率足以影响业务连续性。

官方与业内给出的解释集中在供需两端。需求侧，访问流量持续走高，模型能力提升带来更多调用场景；供给侧，高端算力采购周期长、机房扩容涉及电力与网络配套，短期难以跟上流量增速。两边挤压之下，稳定性反复承压。

算力路线是另一条线索。早期 DeepSeek 依赖英伟达 Hopper 架构的两款图形处理器，H100 与 H800，并开源过与之匹配的 FlashMLA 解码内核。到了 V4 系列，团队同时押注多条路线：华为昇腾 950 与昇腾 A3 超节点承担国产底座的角色，寒武纪、海光、摩尔线程的芯片也通过了 V4 的适配验证，同一套模型能在英伟达生态与昇腾生态之间切换运行。

多路线并行提升了供应韧性，但也带来工程复杂度。不同芯片的算子实现、通信库与调度策略存在差异，同一套模型要在多种硬件上保持一致的性能与稳定性，需要持续调优。对以低价与开源著称的 DeepSeek 来说，如何在成本、性能与可靠性之间找平衡，是比模型参数更难的课题。

对用户而言，现实建议是做好冗余：关键业务接入多家模型服务，或保留本地部署方案，避免把可用性押在单一平台上。

文章与图片内容转载网络，如有侵权请联系平台删除