十三小时的断线 DeepSeek全球宕机事故复盘：技术、依赖与行业考题

一、先看事实：这一晚发生了什么二、技术上讲，为什么一挂就是十几个小时推理服务的“重”，是传统Web服务没有的全站停服13小时，更像入口层出了问题恢复慢，是因为不能直接重启三、现象：三亿人为什么一夜之间没了着落四、影响：谁受伤，谁受益五、这次事故留下的功课给依赖AI服务的企业和开发者给平台方六、结语资料与数据说明

2026年10月27日傍晚，DeepSeek的用户发现网页转不动了。先是响应变慢，接着彻底没有回音。到了晚间，API接口和聊天机器人双双停服，靠它写作、写代码、跑办公流程的人和系统一起停摆。10月28日凌晨，官方宣布服务恢复，此时距故障开始已过去约13个小时。这是DeepSeek自2025年以来最长的一次断线，全球约3.5亿用户受了影响。

对大多数用户来说，这一晚的体验就是刷新、等待、换个工具再试。但对做AI基础设施的工程师，以及把业务押在单一AI服务上的公司来说，这13个小时值得认真复盘一次。这篇文章梳理事件经过，分析大模型服务为什么一挂就是十几个小时，以及这次事故对各方意味着什么。

10月27日傍晚，服务开始出现异常。用户端最先感受到的是卡顿，随后网页和App完全无法使用。到了晚间，问题扩大到API层面——这意味着受影响的不再只是普通用户，所有通过接口调用DeepSeek的第三方应用、企业集成和开发者程序全部失效。聊天产品和API同时停服，等于前后两条路都断了。

图1 事故时间线：从27日傍晚故障开始到28日凌晨宣布恢复

深夜，社交媒体上的投诉大量涌现。有人贴出稿子写了一半写不下去的截图，有开发者抱怨自己的自动化流水线整条挂掉。工程团队连夜抢修。10月28日凌晨，官方宣布服务恢复，并表示会持续监控系统性能。

有两个细节值得留意。第一，官方声明没有说明故障原因，截至发稿也没有公布根因分析。第二，这是DeepSeek自2025年以来持续时间最长的一次断线。它不是第一次出问题，但这一次的量级不同：同样的故障，放在用户还少的年份只是几万人的麻烦，这次是三亿多人的麻烦。

传统Web服务出故障，常见处理办法是把坏节点摘掉，剩下的机器顶上，或者干脆重启进程，分钟级就能恢复。大模型在线服务做不到这一点，根源在于推理本身的重量。

一次大模型推理，需要把模型权重完整装进GPU显存。DeepSeek使用的是参数量极大的混合专家（MoE）模型，权重文件的量级以百GB计。一台GPU节点从冷启动到能承接流量，要经过权重加载、显存分配、算子初始化、预热请求这一整套流程，耗时以十分钟计，而不是秒。如果故障波及的是一个集群而不是几台机器，恢复时间就直接按小时算了。

图2 大模型在线服务的调用链与最可能造成全站停服的单点位置（示意图）

故障的形状能透露不少信息。单台推理节点或单个集群出问题，典型表现是部分请求失败、部分区域不可用，总有一部分用户是好的。而这次是API与聊天接口同时、全面、持续地停服，全球用户无一幸免。

从工程经验推断（注意，官方未公布原因，这一段是分析而非结论），这种整条路全断的形态，通常指向入口和核心链路上的组件：网关、负载均衡、调度系统、鉴权服务，或者它们共同依赖的某个基础组件。后端GPU集群再健康，流量进不来，对用户来说就是全站死了。

入口层在传统架构里恰恰是最成熟的部分，网关技术已经用了二十年。但大模型服务的入口比普通网站复杂得多：要处理长连接和流式响应，要按token计量计费，要做模型版本路由，单个请求占用的资源又比网页高出几个数量级。新场景叠在老组件上，正是新故障的温床。

就算故障定位了，为什么还要花几个小时？三个原因。

定位本身就不快。现代服务是几十个微服务的组合，夜间值班人手有限。故障如果是多个问题叠加的，比如一次发布引入的配置错误撞上流量高峰，排查链路会拉得很长。

预热成本绕不开。权重加载、缓存重建是需要物理时间的。重启后的推理集群KV缓存全空，命中率归零，同样的硬件能承载的吞吐大打折扣。这时候如果立刻放量，很容易二次过载，把刚救回来的系统再压垮一遍。

放量必须灰度。对一家用户数以亿计的平台来说，恢复动作不敢一键全量。标准做法是小流量验证、逐步放开，每一步盯着指标走。这个过程看着慢，防的却是二次故障——二次故障对用户信任的伤害，远大于让用户多等一小时。

图3 长时宕机恢复过程的典型阶段拆解（阶段划分为示意，非官方数据）

把这些加起来：夜间定位两三个小时，修复与部署若干小时，预热一两个小时，灰度放量再一两个小时，13小时并不是一个离谱的数字。这正是AI推理服务与传统云服务在运维上最大的差别之一：传统服务的恢复时间单位是分钟，大模型服务是小时。

比故障本身更值得琢磨的，是用户的反应。

社交媒体上的抱怨分几类：稿子写一半卡住的内容创作者、代码补全突然哑火的程序员、办公自动化流程整条停住的企业员工、接口调用全线报错的开发者。仔细看这些抱怨会发现一个共同点：这些人不是偶尔用用DeepSeek，他们的工作流已经深度绑在上面——提示词是围绕这个模型调的，模板是按它的输出习惯做的，自动化管道是按它的接口写的。

这就是过去两年悄悄发生的事：AI服务从新奇玩具变成了生产工具，但大多数人的依赖感知没有跟上。换一个AI工具，听起来只是换一个网页，实际意味着重调提示词、重做模板、重新适配输出格式，对企业还意味着重新核算成本。所以那一晚很多人宁可反复刷新，也没有立刻换工具，直到确认短期内真的修不好。

图4 一次停服的影响如何扩散到全球约3.5亿用户

3.5亿这个数字，说明DeepSeek以低成本策略积累的用户基数之大，也说明一个事实：当一项服务的用户达到这个量级，它就不再只是一款产品，而是事实上的公共基础设施。只是基础设施该有的可靠性标准，它还没有拿到手。

用户与企业是最直接的损失方。个人损失的是效率，企业损失的是真金白银——办公自动化管道停一个晚上，等于相关业务线停摆一个晚上。事发当晚，不少合作企业和开发者临时转用备选AI工具。可以预期，这次事件之后，会有更多企业在采购AI服务时认真读SLA条款，而不是只对比价格和跑分。

DeepSeek自身的信任损耗是确定的，损失多大取决于后续处理。13小时的最长纪录、不公布原因的声明方式，都会被反复提起。对基础设施工型的服务来说，一份透明的事故复盘比漂亮的公关辞令更能留住大客户，而前者恰恰是目前缺的。

竞争对手短期受益。宕机期间，OpenAI、Anthropic等服务的流量显著增长。这相当于一次免费的用户教育：很多人第一次认真配置了第二家AI服务。但这些流量能不能留下来，取决于迁移后的体验差异。历史上，云服务宕机引发的迁移潮大多在故障恢复后回流，真正留下的，是那些本来就想换的用户。

图5 宕机期间的用户迁移：一家停摆、别家接盘（依据报道定性描述绘制的示意图）

行业层面受的触动最深。媒体在事后分析中指出，这次事故暴露的是全球AI基础设施整体的可靠性压力：GPU算力紧张，让不少平台在容量冗余上精打细算；推理成本敏感，让多活架构这类烧钱的设计被一再推迟；用户量的爆发速度，又远超运维体系成熟的速度。DeepSeek只是第一个把这道题演给三亿人看的。

把“AI服务不可用”写进业务连续性计划，就像对待云宕机、断电和断网一样。具体做法不复杂：接一家备选供应商，平时让关键链路在两家之间各跑一部分流量，故障时自动切换。算一笔账：两家可用性各为99%的供应商互为备份，假设故障相互独立，组合可用性是1-(1-0.99)的平方，约99.99%，年停机时间从3.7天降到53分钟。这笔账值得每个技术负责人算一遍。

图6 冗余的算术：多备一路与单点依赖的年停机时间对比（理想模型演算）

主备模型的输出差异要提前评测，不要等到故障那晚才发现备用模型接不住自己的提示词。降级策略也要分级：关键任务排队重试，非关键任务切小模型或延后，极端情况回退人工流程。这些事情在系统正常时做，成本很低；在系统瘫痪那晚做，来不及。

图7 多供应商容灾参考架构：把AI不可用当作可预期的故障来设计

入口层去单点是最优先的功课。多区域部署、多活架构在传统云厂商那里是标配，在AI行业还不是。这次事故大概率会加速它变成标配。混沌工程和故障演练，也该从大厂专属变成行业常规。

还有一个不那么技术的问题：事故透明度。没有根因分析的恢复声明，短期看保护了声誉，长期看损害的是企业客户的信心。企业采购最怕的不是出故障，而是出了故障不知道为什么、也不知道会不会再来一次。

AI正在变成水电一样的底层服务，这话说了两三年。10月27日晚上算是给了一句注脚：水电停13个小时是事故，AI停13个小时，三亿人能做的只是刷着社交媒体等修复。

对个人，这一晚的成本是一篇没写完的稿子；对企业，是一条停摆的业务线；对行业，是一道提前暴露的考题。故障终会被忘记，流量终会回流，但有一个结构性事实不会消失：单一服务的可靠性有物理上限，而整个社会对AI的依赖还在加深。解法并不神秘，无非是工程界用了几十年的老办法——冗余、降级、演练、透明。只是这一次，这些老办法要在一门极新的行业里，重新学一遍。

本文事件经过依据2026年10月27日至28日的公开报道整理（TechRepublic、CyberInsider等多家媒体报道）。截至发稿，DeepSeek官方未公布故障根因，文中关于故障位置与恢复过程的技术分析，基于公开报道的事实与通用工程经验推断，属分析性内容而非官方结论。文中标注“示意图”的图表为定性示意，非实测数据；图6的可用性对比基于故障相互独立的理想化假设演算。