故障开始时状态页显示部分中断
11月3日16点58分，DeepSeek的服务崩了。网页端和API一起出问题，对话服务、V4 Pro API、V4.1 Flash API，三项全部中招。一分钟后，相关话题冲上微博热搜——这已经是19天内的第二次。
两个多小时后，状态页翻回绿色，宣布恢复。但比起「又崩了」三个字，有一笔账更值得算：把价格打到最低的模型服务，稳定性的成本到底记在谁的头上？
从故障到恢复，官方公告只给进展、不给原因：排查、定位、修复、监控，一路更新到当晚宣布问题解决。截至成文，没有任何渠道说明这次为什么崩。
状态页通报修复进展，组件仍降级
同样没有下文的是补偿。10月那次有致歉和返款通知，这一次，官方一个字都没提。
所以先把边界画清楚：网上流传的种种归因，无论指向流量峰值还是架构缺陷，都没有得到证实，本文一概不采信。下面只回答三个问题：崩了几次、波及了谁、账单怎么算。
先把概念拆开。状态页上的「部分中断」和「性能下降」是两回事：前者是用不了，后者是能用但变慢。当晚这几项服务就在两种状态之间来回切换，更新记录显示17点06分起对话服务和V4.1 Flash API先后转入降级，17点13分一度显示恢复，二十来分钟后再次降级（分钟级梳理主要见于国际金融报单一来源）。
状态页时间条：中断与降级交替
18点25分，公告称修复已上线、正在观察运行结果，但当时三项组件仍显示降级。
今年到底崩了几次？同一件事，目前至少有三种数法：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
分歧不在数字，而在数法：算不算降级、算不算小抖动、以谁的记录为准。所以「崩了几次」大概率吵不出结果，真正该问的是另外三件事：单次有多严重、持续多久、波及谁。
停机的代价，上个月刚标过一次。10月15日上午，网页、App和同样这三项API大面积中断，官方状态页口径前后共4小时52分钟，正撞上工作日的办公高峰。
上次故障后的补偿通知弹窗
当天下午，官方开放平台挂出致歉与补偿通知：不搞固定金额，而是把10月8日到14日这7天里用户实际花掉的API费用全额折成赠金退回，自动到账、不限使用期限。
有用户晒出到账记录，从几毛几块到几百上千元不等，社区里有人把这波返款戏称为「重置额度」。那份通知同时承诺启动稳定性排查、剥离单点依赖，但同样没解释原因。一个多月后，同样三项服务再次出问题。
社交平台晒出的赠金到账记录
同一场故障，落在不同人头上，长度完全不一样。
当晚状态页：三项服务同时降级
1. 刷对话的普通用户：损失约两个小时，换个时段重试就好，顶多去热搜下面吐槽一句。
2. 赶时间的单次任务用户：下午的计划被打断，恢复后手动重跑，成本可控。
3. 把API当生产后端的开发者：最难受的一批。调度和工具链都握在自己手里，唯独核心推理不响应——产品不是变慢，是直接停摆，挨骂的还是他们自己的产品。
4. 把业务链路整个绑在单一模型接口上的中小企业：有评论提醒，持续数小时的停摆可能直接折算成订单损失，严重时甚至构成服务违约。
容忍度自上而下递减：越往下，宕机越不是谈资，而是事故。
为什么一崩就是全停？看三个结构性事实。其一，产品线收窄到没有备份：据行业媒体报道，今年9月DeepSeek把三种聊天模式合并，API产品线只剩V4.1 Flash和V4 Pro两款——这次出问题的两项API，恰好就是全线。没有备用线路，崩了就是全崩。
其二，价格确实低。官方API定价页显示，按百万tokens计价：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
定价页同时预告7月中旬起实行峰谷定价，高峰时段为平日的两倍。其三，便宜加易接入，让它成了大量下游的默认后端：有开发者反馈，不少编码agent近一年的做法是调度和工具链留在自己手里、推理外包给性价比最高的那家。一旦上游断供，缺的就不是快慢问题，是核心能力整块下线。
服务中断时段的空聊天窗口
租来的东西，租约里未必写赔偿条款。头部公有云的SLA普遍承诺99.9%起步的可用性；而大模型服务商的SLA标准尚未统一，不少中小厂商的合同甚至不承诺可用性，这一点多方看法相当一致。有企业级评测认为，DeepSeek定价极具竞争力，但SLA承诺的成熟度还没跟上AWS、Azure那类成熟托管服务。
镜头再拉远一点：故障两天前，华为云刚公告旗下两款开源盘古模型服务月底停服下线，官方建议用户分别迁往DeepSeek和智谱的对应模型。两天后，DeepSeek自己停了两小时——这只是时间线巧合，不构成因果，但它恰好画出行业的迁移方向：工作负载正在往少数几个高性价比的底座集中，篮子越少，每根柱子扛的重量就越大。
顺带交代两桩还悬着的大事：上市与融资。此前有媒体报道援引知情人士称，DeepSeek已聘请中信证券筹备科创板上市，之后又流传出千亿元级新融资方案——当事双方均无官方回应，属待核实信息，本文只当背景，不作结论。
据当时行业媒体的记录，故障期间已有竞品连夜招揽迁移用户。对开发者来说，比换供应商更要紧的，是把架构改到「崩得起」：
1. 上游冗余：同一套agent框架接入两三家API，按可用性和价格自动切换，别让调度和推理绑在同一辆车上。
2. 重试讲策略：用指数退避加熔断器，别让故障瞬间的重试风暴反过来放大流量。
3. 任务幂等：长链任务支持断点续跑，一次中断不该让整条链路报废重来。
4. 上下文资产化：对话历史和中间产物落盘自存，随时可以搬家，不把记忆寄存在任何单一上游。
这四件事没有一件算新技术，难的是平时就舍得为冗余掏钱。
选模型的逻辑正在换挡：过去比谁便宜、谁聪明，往后得先比谁不停机。模型能力还在往前跑，但决定体验下限的，越来越是脚下那块看不见的地基——这一次它替全行业演示了一遍：地基不该只搭一根柱子，下一根承重的柱子，可能是任何一家。
当晚状态页：问题已解决
最后交代口径：55次出自单一媒体统计，10次是多家媒体按官方状态记录得到的数字，18次属流传说法；本文所有时间、金额与状态表述，均以官方公告及公开报道登记口径为准。
