DeepSeek宕机频发背后：日活暴涨66%算力仅增8%的供需失衡解析

5月24日，DeepSeek的服务可用性再次成为行业焦点。与以往不同，此次关注源于大规模服务中断。相关话题迅速登上微博热搜，大量用户报告遭遇持续性“服务器繁忙”错误，核心功能近乎不可用。这是本月内第三次被公开记录的大范围故障，其服务稳定性正面临严峻考验。

梳理近期事件，DeepSeek的基础设施压力显而易见。就在5月21日下午，其网页端与移动应用曾发生大规模异常，高负载的深度推理功能被直接限制访问。将时间线前移，5月8日V4预览版发布当日，170万新增用户的瞬时涌入导致系统全线崩溃，工程师耗时数小时才逐步恢复。追溯至3月底，平台甚至经历了近12小时的连续服务中断，创下了上线以来的最长宕机纪录。

频繁故障的根本驱动力，在于算力供给与用户需求间的结构性失衡。关键数据揭示了这一矛盾：2025年初至2026年初，DeepSeek日活跃用户从1.2亿激增至2亿，增长率达66.7%。然而，同期可用的算力储备仅增长了8.3%。用户规模呈指数级扩张，而底层计算资源的增长却是线性的，这一巨大缺口直接导致了服务瓶颈。

此外，多重外部因素加剧了系统压力。首当其冲的是完全免费的商业模式。该策略虽极大降低了使用门槛，吸引了海量用户，但也意味着所有流量高峰都毫无缓冲地直接冲击后端基础设施。其次，特定时段的高强度计算需求集中爆发，例如毕业季期间，长文本生成、复杂代码调试与优化等任务激增，这些恰恰是计算资源消耗最大的应用场景。多种压力源叠加，在流量峰值下极易突破系统的设计承载极限。

技术架构的双刃剑效应

除资源约束外，其底层技术架构的特性也带来了复杂挑战。DeepSeek采用的MoE（混合专家）架构以高效的推理性能著称，但该架构对算力调度与负载均衡的精度要求极高。当并发请求激增时，特定领域的“专家”模块极易成为性能瓶颈，若调度系统响应不及，可能引发级联故障。

另一方面，平台当前似乎尚未部署成熟的弹性限流与服务体系降级策略。在标准的云原生架构中，当系统负载超过阈值时，会自动触发流量控制，优先保障核心服务链路，并对非关键请求进行降级处理，从而避免整体系统雪崩。从DeepSeek数次全局性瘫痪的表现推断，此类高可用性防护机制可能存在短板，致使局部过载迅速演变为全局服务中断。