11月7日下午3点11分，一位开发者盯着屏幕上的后台日志。
“已重试模型请求 (5/5) · 8s”
失败原因写着 Internal Server Error (500)，最后以流中断结束。
同一天，微博热搜上还挂着“梁文锋DeepSeek不止国运级”的话题，知乎上的提问已经变成了“如何看待11月7日DeepSeek再次崩溃？”。
一边是顶流光环，一边是报错弹窗。对于普通用户来说，下午3点11分到3点56分的这45分钟，无非是网页对话框弹出“服务器暂时不可用”，多刷新几次的事。
但对于把业务绑在API上的团队来说，中国新闻周刊采访的一位企业大模型团队技术专家说得很直接：接入该模型的产品在那一时段直接停摆。



这次中断波及了DeepSeek的对话服务、搜索服务，以及V4 Pro、V4.1 Flash两个核心API。官方状态页在15:56恢复正常，公开记录里只有两行字，第一条便是“已实施修复，正在监控结果”，没有解释原因。



01｜一个月坏9次，暴涨的调用量把算力顶到了墙角如果把45分钟当成一次偶然的意外，账就更容易算错。
翻看DeepSeek官方状态页的记录，从10月2日算起，类似的故障已经发生了9起。10月15日那次停了4小时52分，11月3日停了1小时50分。
状态页上的可用性数字看着挺体面：8月到10月，V4.1 Flash API可用性是99.46%，V4 Pro是99.74%。但把这两个百分比放进一年8760个小时里换算一下，意味着Flash一年大约有47.3小时不可用，Pro也有22.8小时。
99%听起来像“基本没问题”，落到实际业务上，就是一年里总有两天时间，你的系统得学会自己面对黑屏。



故障变多的背面，是调用量在疯长。
OpenRouter的周榜数据显示，10月19日至25日这一周，DeepSeek V4.1 Flash的周调用量冲到了33.6万亿token，环比增长801%，排在全球第一。而在7月底那一周，这个数字还是7.22万亿。不到三个月翻了四倍多，这种体量的涨幅，不是靠一两次常规扩容能立竿见影补上的。
很多团队想过避开高峰期，把批量任务挪到谷时——毕竟工作日北京时间09:00-12:00、14:00-18:00属于峰时，价格翻倍。但11月7日这次偏偏发生在周六下午。周末也没能成为安全区。
02｜状态页变绿之前，瞎重试比停机更要命上游服务挂了，开发者自己写的默认重试策略，往往会成为压垮系统的第二根稻草。
多数系统的默认重试是为“偶发抖动”设计的：报错了，等一两秒再发一次。但遇到长达几十分钟的区域性故障，这套逻辑就会出大乱子。
DeepSeek的API文档里写得很明白：500是服务端问题，503是过载，官方建议“短暂等待后重试”；429则是请求太快或超过并发上限。这里有个容易踩的坑——并发限制是按账号算的，Flash上限2500，V4 Pro上限500，哪怕你在后台换一个API Key，也不会多出半点额度。
当故障发生，你手里的每个worker、定时任务、agent如果都在各自闷头重试，整个账号很快就会被顶到429的并发天花板上。等到15:56上游好不容易恢复，积压在队列里的请求在同一秒拍上去，能把刚喘过气的接口再冲垮一次。



11月3日那次故障就是个典型例子：
16:58 显示部分中断；17:06 降级；17:13 Flash和对话服务恢复“正常”；17:36 又降级；18:21 再次部分中断；18:48 才彻底标记解决。如果哪个客户端在17:13看到状态页变绿就立刻恢复全量流量，23分钟后就会迎头撞上第二波故障。
更隐蔽的坑在于连接状态和计费。按照文档说明，请求发出后如果迟迟没有响应，非流式接口会持续返回空行，流式接口会一直发 : keep-alive，直到10分钟内还没开始推理，服务端才会掐断连接。
连接还在，不等于模型在干活；把keep-alive当成进度条，或者把读取超时设得比10分钟还长，只会让系统在原地干等。



反过来，客户端报了超时，也不等于这笔请求没产生消耗。 请求可能已经被服务端接收、已经扣了token费，甚至已经触发了下游工具。
如果是纯文本生成，重放一次顶多多花点钱；但如果你的agent正在执行发邮件、改文件、下订单这类带副作用的动作，盲目重跑一遍，麻烦就不是几分钱token能解决的了。
03｜赠金不管赔客户，备胎得在平时验好10月15日那场近5个小时的大停机之后，DeepSeek官方做过一次补偿：按账号在10月8日至14日7天内的消耗金额，1:1返还了赠金。
但截至11月7日晚，公开渠道能查到的依然只有这一份补偿记录，11月3日和11月7日这两次中断，还没有看到同等级别的返还。况且，翻遍API文档，里面列清了错误码、并发上限和价格，唯独没有可用性SLA（服务等级协议）。
官方返赠金是善意，但它赔的只是token钱。靠接API做商业化产品的团队，停摆45分钟意味着进不来订单、客户要求退款，甚至要向自己的下游赔付违约金。这些账，赠金抵不掉。
没有必要因为45分钟的宕机就把DeepSeek换掉，但必须把“它会周期性抖动”写进日常的架构假设里。
真遇到连续几个503或超时，第一步是先停发、管住重试。把新任务暂停，队列留着，别让定时任务继续往上叠。给重试设个总预算，遇到401、402、400、422这类密钥、余额或参数错误直接停手，只有500和503才值得等。



第二步，分任务找退路。 异步、纯文本、能容忍延迟的活儿，45分钟等得起，加好幂等键和检查点，等恢复后先去重再慢慢放量；但直接面对用户的实时交互产品，手里得留一条预热过的备用模型通道。
DeepSeek的接口兼容OpenAI和Anthropic格式，平时切过去也就是改一下 base_url、key 和 model 三项。但千万别等到下午3点11分报错了才去临时改代码——DeepSeek特有的 thinking、reasoning_effort 参数不能原样丢给别家，生产环境的会话也不能在故障时第一次发给一个没核对过数据规则的平台。
至于跑了一半的代码和agent会话，中途硬换模型会导致系统提示词和工具返回结果对不上，老老实实暂停，往往比“热切换”更安全。
还有一处细节得留心：deepseek-flash 只是一个滚动别名，不是锁死的版本。10月17日官方已经把它指向了 V4.1-Flash-1017，上一代V4 Flash随之退役。模型底子换了，JSON输出和工具调用的脾气都可能跟着变。
把具体的模型版本号记进日志，备用路线在平时拿真实的Prompt跑通回归测试。毕竟DeepSeek什么时候能彻底稳住，接API的人说了不算。
来源：IT之家、什么值得买、新浪新闻、界面新闻、中国新闻周刊、蓝鲸新闻、知乎、微博