DeepSeek 崩了 5 小时：你的 AI 应用为什么跟着一起挂？
2026 年 10 月 15 日，DeepSeek 网页端与 App 大面积不可用，官方状态页记录中断持续约 4 小时 52 分。本文不复述新闻，只讨论一个工程问题：当模型供应商挂掉时，你的系统为什么会跟着挂，以及怎么不挂。
一、先把事实摆清楚
- 约 08:00（北京时间）起，用户大面积反馈"服务器繁忙 / 暂时不可用"
- 08:11 官方状态页（status.deepseek.com）首次登记「网页/API 部分中断」
- 官方状态页列出的影响面有三类：DeepSeek V4.1 Flash API 部分中断、聊天服务部分中断、网站/API 整体性能下降
- 事故条目最终标记为已恢复，持续约 4 小时 52 分
- 据公开报道整理的时间线：09:17–09:40 媒体跟进，状态页一度更新为"已定位原因、正在修复"；09:30 实测 App 仍未恢复
还有一个更值得留意的数字：据公开记录，这已是 DeepSeek 2026 年第 18 次大规模服务异常。
结论很直白："会崩"不是意外，是常态。 对做 AI 应用的人来说，"选哪家模型"是产品决策，但"挂了怎么办"是工程底线。
二、真正的问题，多半不在供应商
如果你直接依赖单一模型供应商，你的可用性大致等于：
你的可用性 = 供应商的可用性 × 你的代码正确率
供应商一挂，你的核心功能就一起挂。三种最常见的单点形态：
- 前端直连：key 落在客户端，无降级、无鉴权，供应商挂了页面直接白屏
- 后端硬编码单 SDK：模型名写死，换供应商要改代码、发版
- 有封装层但没有降级：只是"多了一层"，没有"多一条路"
三、从"单点"到"多路"：四件事
1. 加一层 Model Gateway
统一接口 + 供应商适配器 + 路由策略（主备 / 加权 / 按能力 / 按成本）。上层业务只认接口，不认具体厂商。
2. 熔断 + 超时 + 重试
- 超时要拆开：首包延时（TTFB）和总时长分别设阈值，流式场景尤其重要
- 熔断：连续失败 N 次 → 打开 → 半开探测，按供应商隔离
- 重试：指数退避 + 抖动；只重试幂等请求，避免故障期间把上游打死
3. 降级策略（最关键的一环）
| 优先级 | 策略 | 效果 |
|---|---|---|
| 1 | 切备用供应商 | 能力基本不变 |
| 2 | 切更小的模型 | 质量降级，可用性保住 |
| 3 | 命中缓存 / 模板 | 覆盖高频问答 |
| 4 | 排队 + 明确提示 | 用户知道"在排队"，而不是无限转圈 |
| 5 | 关闭非核心功能 | 保住主链路 |
降级路径必须能演练：真拔线、真停服，跑一遍再说"我们有降级"。
4. 流式要能优雅中断
SSE 断流要能收尾：已输出的内容是否落库、失败是否可重放、是否幂等。别让用户看到半句话卡在那里。
四、可观测性：不然你永远在猜
- 指标：成功率、TTFB、fallback 触发率、按供应商维度的错误率
- 追踪：request-id 贯穿全链路，能回答"这次是谁挂的"
- 告警：错误率阈值 + 订阅供应商状态页
- 对账：按月看"哪家便宜、哪家稳"，用数据而不是感觉来选主备
五、一段可用的降级代码（TypeScript 伪代码）
type Req = { messages: unknown[]; timeoutMs: number; requestId: string };
type Res = { text: string; provider: string };
interface Provider {
name: string;
call(req: Req): Promise<Res>;
}
class ModelGateway {
constructor(
private providers: Provider[], // 顺序即优先级
private breaker: Breaker, // 按供应商隔离
private fallback: (req: Req) => Promise<Res>,
) {}
async chat(req: Req): Promise<Res> {
for (const p of this.providers) {
if (!this.breaker.allow(p.name)) continue; // 已熔断，跳过
try {
const res = await withTimeout(p.call(req), req.timeoutMs);
this.breaker.success(p.name);
return res;
} catch (err) {
this.breaker.failure(p.name); // 记账
log.warn('provider failed, trying next', { provider: p.name, requestId: req.requestId, err });
continue;
}
}
return this.fallback(req); // 小模型 / 缓存 / 明确报错
}
}
三个要点：
- 顺序即优先级，主备天然成立
- 熔断器按供应商隔离，别全局共享一个计数器
- fallback 必须存在，而且必须是"用户能接受的行为"，不能是抛异常
六、上线前 checklist
- 至少两家可用供应商，且都用真实流量跑通过
- 熔断 / 超时 / 重试参数有压测依据，不是拍脑袋
- fallback 路径有测试用例（拔线 + 停服都演练过）
- 供应商状态页与告警已订阅到具体的人
- request-id 贯穿日志，能定位"谁挂的"
- 按月做成本与稳定性对账
七、结语
DeepSeek 这次不是第一次，也不会是最后一次。模型会崩，但架构不该跟着崩。
把模型当"可替换的依赖"来设计，而不是当"基础设施"来信仰——这大概是 2026 年做 AI 应用最重要的一条工程常识。
本文事件信息来自 DeepSeek 官方状态页（status.deepseek.com）事故条目与公开报道整理，仅作技术讨论。
