摘要
2026年3月29日至31日，DeepSeek 连续三天出现服务异常（网页/App/API），其中 3/29 夜间至 3/30 上午持续近 12 小时，创公司成立以来单次中断最长纪录；官方状态页记录为性能异常，业内普遍推测与 V4 模型灰度测试及算力/架构瓶颈有关。
时间线
2026-03-29 21:35 (CST)首次发现网页/App 服务异常，频繁提示"服务器繁忙"
2026-03-29 23:23 (CST)首次修复，部分用户可短暂登录
2026-03-30 00:20 (CST)再次排查并实施二次修复，服务仍波动
2026-03-30 10:33 (CST)官方公告故障修复，全部服务恢复（约 12 小时）
2026-03-30 全天仍有用户反馈不稳定（约 10 小时 13 分异常段）
2026-03-31 17:02 (CST)第三次性能异常开始
2026-03-31 18:05 (CST)第三次异常恢复（约 1 小时 3 分）
根因
官方定性为"性能异常"，未确认具体技术根因；业内分析指向模型迭代（V4）灰度测试、上下文窗口扩展至 1M Tokens 带来的 KV 缓存急剧膨胀，以及新旧架构在底层存储聚合层的冲突，暴露基础设施建设短板。此前 DeepSeek 已多次因用户量激增出现宕机。
放大因素
- 用户规模爆炸式增长，算力储备扩容滞后
- 模型迭代灰度测试叠加高并发，基础设施承压
- 用户因卡顿反复点击重试，进一步推高访问量
- 开源普惠路线与高昂芯片/机房建设成本之间的张力
缓解措施
- 技术团队多次紧急修复并监控，3/30 全面恢复
- 官方未列 V4 模型 ID，未发布正式根因复盘
经验教训
- 爆发式增长期须提前规划算力与架构承载，灰度测试应隔离风险
- C 端服务中断虽"技术性、暂时性"，但需透明沟通降低用户焦虑
- 长上下文/大 KV 缓存对存储聚合层提出更高要求，需专项压测
- 参考来源：DeepSeek 状态页 https://status.deepseek.com/ ；腾讯新闻 https://new.qq.com/rain/a/20260331A01F0G00 ；界面新闻/头条 https://www.toutiao.com/article/7623367662088880650
检查清单
- 灰度/模型迭代是否在隔离环境验证容量？
- 是否对长上下文 KV 缓存做专项压测？
- 重试是否有客户端限流，避免雪崩？
- 高增长期是否有算力扩容节奏评审？