16:58，三项服务同时异常
11月3日16时58分，DeepSeek状态页同时把三项服务标成异常：对话服务、V4.1 Flash API“部分中断”，V4 Pro API“性能下降”。第一财经在17时14分发布的报道里写到，记者测试时聊天界面显示“服务器繁忙，请稍后重试”。截至18时25分，状态页仍写着“已实施修复，正在监控结果”，三项服务仍处于异常状态。这距离故障开始已经过去一个半小时。官方没有说明这次故障的具体原因，状态页只留下“排查”和“监控”两类更新。第一财经DeepSeek状态页
一个月，8起异常
这不是一次孤立的“手滑”。从10月2日到今天，DeepSeek官方状态页可查的服务异常有8起。最长的一次是10月15日上午的“网页/API部分中断”，从08:11拖到13:04；10月2日凌晨那次持续1小时54分；其余多数只有几分钟。微博上有人只写了一句：“每次都在我急用的时候…”。微博
155万亿Tokens/天，和一张卡的故障
每次崩完，最常见的解释是“人太多、算力不够”。这个解释不算错，但太粗。DeepSeek在10月20日自己发过一篇《DeepSeek V4.1 Flash 大规模推理部署实践》，把推理系统拆开讲。那里面有一个比“GPU不够”更具体的答案：真正决定服务能扛多少的，不是单卡算力，而是你愿意为故障留多少闲置容量。
官方给出的数字很硬：V4.1 Flash 的单一集群服务吞吐是155万亿Tokens/天，整体收入是每卡每小时38美金（按谷价）。平均下来，这个吞吐相当于每秒处理约18亿个token。DeepSeek
支撑这个吞吐的，是Prefill和Decode分离部署：Prefill用常见的8卡机器，Decode用64～128卡超节点；Block KVCache 放在3FS集群上，约100 PiB SSD，峰值聚合读带宽10 TiB/s，agent流量缓存3天、chatbot缓存7天。这套设计的核心是把每一块卡都尽量跑满。DeepSeek
但效率的代价写在另一段里：大EP部署下，一个实例的全部卡构成单一通信域，任意一张卡故障即导致整个实例不可用。重启是分钟级，容错靠“配额冗余+请求级重新路由”，不是靠缩短重启时间。DeepSeek
部署时要留两类余量：池子里有没被占用的ready机器，线上永远比算出来的需求多跑一些实例；配额占用率高于0.8时，禁止缩容。自动扩缩容还有限速和上下界。DeepSeek
换句话说，155万亿Tokens/天不是“服务器能扛多少”的固定答案，它是在某个冗余水平下跑出来的成绩。要让这个数字稳定，平台必须同时养着一批备着的卡。用户越多、价格越低，这批“闲卡”的成本越高；一旦流量涨得比扩容快，或者一次故障吃掉一个64～128卡的实例，余量就会被迅速抽干。
这也解释了为什么“已实施修复”之后，服务还会继续“性能下降”。重启后的容量不是按一下开关就回来：请求要重新路由，本机的SWA缓存要重算，扩缩容要按限速一步步放。对用户来说，页面上的“修复”只是一句话；对系统来说，那是一段以小时计的爬坡。
真正的极限，是留多少闲卡
需求端还在加码。QuestMobile 11月3日发布的报告显示，2026年9月DeepSeek月人均使用65.9次、136.7分钟，季度环比分别涨5.8%和9.5%；同期豆包的这两个数字是72.0次和132.5分钟，分别下降6.1%和7.8%。使用强度还在往上走。它自己的部署文章也写得很清楚，优化的目标就是“用更少的算力与能源支撑更多请求，让智能服务以更低的价格触达更多用户”。低价会继续把请求吸过来，这是它的竞争力，也是它的压力源。界面新闻DeepSeek
供给端不是没钱。10月底曝出的最新一轮融资约1055亿元，投资方里有长鑫存储、中芯国际、中国移动、中国电信。但钱可以买卡、买存储、租机柜，机柜要通电、并网、调试，国产芯片的产能和适配也要时间。36氪
梁文锋在7月的内部会议上说过，国产芯片已经能实现平替，硬件和生态都不存在问题，唯一的问题是产能不够。10月15日那次4小时52分的故障，从08:11开始，09:06才“定位原因”，12:49才进入“监控结果”，13:04恢复。真正花时间的不是发一条修复公告，而是把系统重新拉回可承载状态。36氪
所以，DeepSeek的“服务器承载极限”不是一个可以用GPU数量回答的问题。它是一条由冗余、缓存、网络和运维共同决定的曲线：跑得越满，越便宜；越便宜，越多人用；越多人用，留给故障的余量越薄。国产AI过去两年证明了自己能把模型做出来、把价格打下来；接下来要证明的，是当用户把它当生产力工具时，能不能为“不崩”持续付账。
