11 月 7 日 15:11，DeepSeek 状态页显示异常。 V4 Pro、V4.1 Flash 和对话服务同时“部分中断”。15:56 恢复正常。界面新闻
对普通用户，这是刷新几次；对开发者，网页和 API 一起失效，正在跑的 agent、批量任务、客服机器人会同时卡住。中国新闻周刊采访的一位企业大模型团队技术专家说，接入该模型的产品在那一时段直接停摆。
45 分钟不长，但如果只当成一次意外，就会漏掉三笔更贵的账。
第一笔：这不是偶发，尾部很长
官方状态页记录，10 月 2 日以来故障已有 9 起。10 月 15 日那次持续 4 小时 52 分，11 月 3 日是 1 小时 50 分。这 45 分钟只是其中一次，最长的一次近 5 小时。
状态页的可用性记录显示，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 万亿，不到三个月翻了四倍多。 这不是一次扩容能补上的缺口。中国新闻周刊
第二笔：“已修复”之后，状态页还会再次变红
11 月 3 日的状态页：16:58 部分中断；17:06 降级；17:13 Flash 和对话服务恢复“正常”；17:36 又降级；18:21 再次部分中断；18:48 才标记解决。 一个 17:13 看到“正常”就恢复全量流量的客户端，23 分钟后会再被打一次。状态页是快照，不是承诺；“已解决”只代表最后一条更新，不代表故障模式消失。11 月 7 日更直接：第一条更新就是“已实施修复，正在监控结果”——它记录的是处置节点，不是你第一次失败的时刻。DeepSeek 状态页
对开发者，这比停机更麻烦。只认“失败—重试”的逻辑会把一次故障放大成几次：agent 重跑已经发过邮件、下过单的步骤，产生重复副作用；所有客户端一起重试，还可能把账号顶到并发上限——Flash 2500、Pro 500，超了就是 429。 健康检查至少要等一个持续正常的窗口，再灰度放量；有副作用的步骤要有幂等键和检查点。“请求失败”和“请求可能已经成功”，必须分开处理。DeepSeek API 文档
第三笔：赔偿只赔 token，不赔停摆
10 月 15 日那次近 5 小时的中断，官方按账号 10 月 8 日至 14 日的消耗金额返赠金。 但它赔的是 token 钱。截至 11 月 7 日晚，能查到的仍是这一份补偿；11 月 3 日和 7 日这两次，没有看到同等级别的补偿。API 文档列了错误码、并发上限、价格，但没有可用性 SLA。微博
对靠这个 API 赚钱的产品，停 45 分钟可能有订单没进来、客户退款、你承诺给下游的 SLA 要赔。赠金抵不掉这些。赔偿是善意，不是风险控制。
那该怎么办
不用把 DeepSeek 换掉，但要把“它会周期性抖动”写进架构假设。
实时产品留一条预热的备用模型，别等 15:11 才改 base_url；它要拿你的 prompt 和 tool schema 跑过回归。非实时任务放进带检查点的队列，断了能续跑。批量任务可挪到谷时（工作日北京时间 09:00-12:00、14:00-18:00 是峰时，价格翻倍），但 11 月 7 日这次就是周六下午，周末也不安全。
还有一笔容易漏的：deepseek-flash 是滚动别名，不是你锁定的版本。10 月 17 日官方把它指向 V4.1-Flash-1017，上一代 V4 Flash 已经退役。 模型换了，prompt、JSON 输出、tool call 行为都可能变，代码却没改。把版本号记进日志，切换前跑回归。DeepSeek API 文档
DeepSeek 什么时候能稳住，开发者决定不了。能决定的是下次状态页再次变红时，你的任务是在排队，还是已经丢了。
