DeepSeek宕机5小时：一上新就崩？影响有多大？

来源：澎湃新闻

10月15日8时11分至13时04分期间，DeepSeek服务系统出现故障，导致该时段内API服务无法正常使用。此次DeepSeek故障时间持续近5小时，“DeepSeek崩了”等相关话题词迅速冲上微博热搜。故障修复后，DeepSeek为用户提供赠金补偿。

长时间宕机发生在工作日上班早高峰，普通用户、依赖API接口的企业开发者均受到波及。DeepSeek为何频繁出现故障？本次故障为何修复耗时长达近5小时？这次宕机事件究竟带来多大实际影响？

算力余量不宽裕，运维工程不到位

10月15日出现故障后，DeepSeek官方信息显示对话服务部分中断、DeepSeekV4.1 FlashAPI服务部分中断，网页/API性能下降，官方排查问题、定位原因。

快思慢想研究院院长、特邀评论员田丰告诉澎湃科技，DeepSeek大约每一两个月就有一次上新，任何一次故障往后看几周，大概率都能“对上”一次发布。今年DeepSeek发布节奏密集，4月份发布V4预览版，8月上线V4 Pro正式版，9月开启V4.1 Flash限时内测，9月10日正式发布。但所谓”一崩就上新”，相当一部分是事后归因，发布频率越高，巧合越多。

当然，也存在两个公开事实说明DeepSeek的算力余量不宽裕。田丰提到，一是V4.1 Flash内测期间，每个账户最多只能同时处理20个请求。二是DeepSeek推出峰谷定价时，官方给出的理由是更合理地配置资源、提升服务稳定性。用价格来削峰，说明余量本就不宽裕。

“如果新模型的灰度测试和线上服务共用同一批算力，那么上新就等于在一个接近满载的机房里，再挤进一个几千亿参数的模型。”田丰表示，发布前后，很可能正是算力余量最薄的时候。

“算力紧缺可以通过限流、熔断等方式保障服务稳定性，中断服务从根子上讲当然是算力极度紧张，但是运维也是能缓解的。”除了算力不足的推测，一位AI云计算服务商高管告诉澎湃科技，此次DeepSeek故障也透露出运维工程不到位。

“如果不是外部故障，一般运维水平是最大的因素，在运维工程上的建设应该还不完善。”他表示，模型厂商要提供良好的用户体验，需要建设完整的测试、预发布环境、灰度升级、流量管理、回退机制等流程，这需要工程基建和SOP（标准作业程序）流程建设。

田丰表示，单项技术再先进，也要服从整个系统的可靠性。DeepSeek的节奏由训练和研究驱动，研究型公司的迭代速度跑在了运维余量前面，运维只能被动跟上。

本次故障为何修复耗时长达近5小时？田丰表示，诊断并不慢，瓶颈在修复阶段，各项服务到下午1时左右才全面恢复。大模型服务重启一次，本身就相当于一次小型发布，重启要重新加载权重、预热，再逐步放流量。缓存重建也会二次冲击，如果缓存层受到波及，恢复后命中率会先下降，计算压力又会反过来冲击服务。此外，修复过程正好撞上早高峰，卡顿时用户反复点击“重试”，访问量也会被成倍放大，维护更难做。“恢复时间取决于两件事：修复通道是否与故障隔离，以及修复期间流量洪峰有多大。”

AI越像员工，宕机越像停工

对于此次故障，DeepSeek表示，已第一时间启动针对服务稳定性的全面排查和彻底整改，全面梳理并剥离单点依赖，坚决杜绝同类问题再次发生。作为补偿，DeepSeek将按用户账号7日内（10月8日-10月14日）的消耗金额以赠金形式全额返还，赠金自动到账，API计费扣款先从赠金账户扣除。

上述AI云计算服务商高管表示，补贴客户是一个云计算方向故障处理的常规操作，尤其是在模型行业，重置额度和补贴已经是司空见惯的行为。

“这次故障完整覆盖了9时-12时的高峰计价时段，损失的是全天最值钱的三个小时。”田丰表示，在智能体时代，AI越像员工，宕机越像停工。损失按任务长度放大，智能体跑到一半中断，上下文状态、改了一半的文件、执行到一半的工具链都可能从头再来。

开源大模型社区OpenCSG当天发文表示，这类大模型中断的影响会沿着接口传到使用它的企业。产品中的内容生成、内部系统的数据处理、研发工具中的代码分析，都可能通过API交给外部模型完成。当服务端暂时无法响应，相关任务也可能出现等待或失败。影响有多大，取决于这些能力在业务流程中承担了多少工作。

此次DeepSeek中断服务，也给全行业敲警钟。OpenCSG社区表示，通过API使用模型，企业可以减少早期部署和维护的投入，更快把能力接入业务。随着使用深入，外部推理服务也会成为业务运行的一项依赖。这次故障让这种依赖变得具体——企业自己的系统还在运行，其中一段工作却需要等待另一家公司恢复服务。

因此，对于长期承担业务任务的模型，除了检查回答质量和使用成本，还应了解它在哪里运行、日常调用经过哪些服务，以及自身能够管理哪些环节。OpenCSG社区表示，模型参与的业务越多，这些问题就越值得提前想清楚。企业可以进一步评估哪些任务适合继续使用外部服务，哪些能够交给本机运行的模型，哪些需要建设企业自己的推理环境。把适合的模型直接用进本地或企业日常工作，推理请求就可以在相应环境中完成，减少对原有单一服务入口的依赖。

田丰则表示，开源给了DeepSeek技术层面的冗余，信任层面却没有冗余。可靠性的另一半，是把出事原因讲清楚。

对于此次DeepSeek故障，截至澎湃科技发稿，DeepSeek不予置评。