DeepSeek频繁崩溃复盘：API中断的真实原因与AI服务稳定性欠账

11 月 3 日下午 16:58，手机上的告警机器人连着推了七条消息。同一分钟里，我们接入的 DeepSeek V4.1 Flash 接口错误率从 0.3% 跳到 41%，前端页面开始出现“服务器繁忙，请稍后重试”。

我在一家做智能客服的公司负责模型接入，这种夜晚并不陌生。

先做的不是怀疑平台，而是自证清白：看网关 QPS 曲线、查证书有效期、翻 DNS 解析记录、确认代理池没被打满。四项都正常，我才打开官方状态页——“网页/API 部分中断”，受影响的是对话服务、V4 Pro API 和 V4.1 Flash API。

三个入口同时挂，说明问题不在某个模型实例上。它们共用网关、鉴权、调度和计费，任何一层抖动都会一起倒下。这也是我这两年踩得最多的坑：看起来是“模型崩了”，实际是外围组件先崩。

往回看，同一个月里这不是第一次。10 月 15 日早上 8:11 到 13:04，服务中断五个多小时，官方事后说要“全面梳理并剥离单点依赖”，并按 10 月 8 日至 14 日的消耗金额全额返赠金。再往前的 5 月，8 日、21 日、24 日、28 日连着出事。有统计说全年异常次数已接近二十次，而同期用户量涨了六成多，算力储备只增了个位数。供需缺口摆在那里，出事只是时间问题。

我把原因归成三类。第一是算力弹性跟不上流量曲线：GPU 集群从下单到可用以周计，一次热点事件却能在两小时内把调用量翻倍。第二是单点依赖，很多团队把路由器、调度器、模型服务串在一条链上，省事，但没有隔离。第三是重试风暴——平台一抖，所有客户端同时重试，本来只坏了一半的容量被瞬间压垮。

第三点最值得说。我们早期就是这么干的：超时 60 秒，失败自动重试三次，还带并发。平台越不稳，我们打得越狠。后来改了三件事：超时压到 25 秒；重试上限两次，必须带随机抖动；在线请求和离线任务分池隔离，离线批量全部挪到凌晨队列，白天只保在线。

再加一条多模型路由。主模型熔断后自动切备用，切换脚本演练过四次，真出事时 90 秒完成。常见问答做了本地缓存，命中率大概三成，故障窗口里这部分请求根本没打到 API。

改造之后，同样长度的中断，我们对外接口的 P99 从 42 秒降到 9 秒，七成以上的失败请求被兜底逻辑接住。用户体验仍有损，但没有出现大面积投诉。

这里有个判断我想说清楚：AI 服务的稳定性和传统 API 不是一个难度。单次请求成本高、耗时长、输出长度不可预测，突发流量还带着明显的“事件驱动”特征。把模型当成永不掉线的水电煤，是很多团队最初的天真。

所以接入方的正确姿势，不是等平台承诺 99.99%，而是先把降级路径设计好：什么业务可以等，什么业务必须立刻给答案，什么情况下干脆告诉用户“当前高峰期，稍后重试”。把这三件事写进 SLA，比任何道歉信都管用。