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 伪代码）

ts 复制代码

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）事故条目与公开报道整理，仅作技术讨论。