10月15日，DeepSeek网页和App再次出现服务异常，部分用户看到“服务器暂时不可用”的提示。官方状态页显示，本次故障从北京时间8时11分开始，至13时04分标记为已恢复，历时4小时53分钟。

官方将本次事件列为网页及API部分中断，受影响的包括对话服务、V4 Pro和V4.1 Flash接口。9时06分，官方表示已定位原因、正在修复；12时49分，状态转入修复后观察阶段。不过，最终的恢复公告仍未说明具体故障原因。

这距离上一次异常只隔了三天。10月12日，DeepSeek也曾出现对话服务部分中断，随后恢复。

每次报错，大家第一反应往往是“用的人太多了”。但要弄清DeepSeek为什么反复出状况，还得看看它的算力怎么分、单个任务要占多久资源，以及后台到底出了什么问题。

算力不全用来回答用户

据The Information 9月24日报道，DeepSeek超过七成的算力用于模型训练，用于推理的不到三成。

训练是研发下一代模型，推理则是让已经发布的模型回答问题、生成内容。对一家模型公司来说，买来的算力既要支持研发，也要维持每天的日常服务，不能全部拿来接待用户。

当然，留给推理的算力不到三成究竟够不够用，单看比例还下不了定论：总算力有多大、同一时间涌入多少请求、每个任务占多少资源，都会影响最终体验。9月披露的这组数据，也不能直接拿来解释10月15日的故障。

但这组数字引出了一个现实问题：DeepSeek在继续研发新模型的同时，给日常服务留出了多少余量？ 平时能正常回复，不代表流量突然冲高时也能从容应对。

不只是人多，还要看每次用多久

同样是打开DeepSeek，随口问一句天气，和让它分析长文档、生成大段代码，给服务器带来的工作量并不一样。哪怕同时在线的人数相同，后台承受的压力也可能相差很大。

按DeepSeek官方文档的规则，一个请求从发出到模型回答完毕，期间都算作一个并发请求。前面的请求还没跑完，新的请求又不断涌进来；如果响应速度跟不上，排队等待的任务就会越积越多。所以看服务器忙不忙，不能光数来了多少用户，还得看每个任务需要占用多久。

DeepSeek已经设置了账号并发上限，也实行峰谷定价。目前，API空闲时段价格为高峰时段的一半。以Flash输出为例，每百万token在空闲时段收费4元，高峰时段为8元。

半价能吸引不赶时间的用户错峰调用，可白天赶着交稿、写代码的人，未必能等到优惠时段再用。价格可以分流一部分请求，却没法替服务器多变出算力。

“太火了”不能代替故障说明

算力分配和并发机制，能帮助外界理解DeepSeek面临的日常压力，但还不能证明每次中断都是因为算力不够。

DeepSeek自己的接口文档，就把“服务器内部故障”和“高流量导致过载”列为两类不同错误。用户在聊天窗口里只看到一句“暂时不可用”，没法判断后台到底是请求太多忙不过来，还是系统本身出了故障，更不能把历次中断都归结为同一个原因。

因此，要想少出故障，也不只是多买芯片那么简单。DeepSeek还需要进一步说明：这次中断到底因何而起、为什么会波及多个服务，以及修好之后怎么避免问题重演。

偶尔用它聊几句，报错后还可以稍等再试；但对把接口接进产品、靠它处理日常工作的开发者来说，一次中断可能让后面的任务跟着全停下来。模型好用、价格便宜，能吸引大家来尝鲜；可真要把每天的工作交给它，用户还得看它关键时刻稳不稳定，会不会干到一半突然掉链子。（易句）

（本文由AI撰文，网易编辑负责校对）