DeepSeek 5月六连崩，是时候重视 LLM API 故障转移了

青萍叙事2026-05-29

前言

5 月 8 日，DeepSeek V4 刚上线，流量像开闸一样涌进来，服务器直接扛不住，服务瘫痪了好几小时。
用户群里炸了锅，有人论文写到一半白写，有人线上业务直接中断。

当时大家觉得，新版本上线嘛，出点状况也正常。

然后 5 月 21 日，又崩了。

5 月 24 日，再崩一次。

5 月 28 日，第四次，虽然只持续了半小时，但频率已经到了让人不得不正视的程度。
到了月底一数，光 5 月就崩了六次。

如果你的应用依赖 DeepSeek API 做核心业务，这一个月你过得恐怕不太好。

一个月崩六次，不只是 DeepSeek 的问题

先回顾一下 5 月 DeepSeek 的”战绩”：

5 月 8 日：V4 版本上线，流量激增导致服务全线瘫痪，持续数小时
5 月 21 日：再次出现服务中断
5 月 24 日：第三次，约 32 分钟
5 月 28 日：网页对话和 API 同时不可用，约半小时

四次公开报道的大故障，加上两次小规模异常，一个月凑齐了六连崩。

如果你去翻历史记录，会发现 DeepSeek 的宕机史远比这丰富。
3 月底那次最夸张：从 3 月 29 日晚到 3 月 30 日上午，服务断断续续地崩了超过 12 个小时。
有开发者调侃说”DeepSeek 该改名叫 DeepSleep”，也有付费用户在社交平台吐槽”关键时刻掉链子”。

当然，这不是 DeepSeek 一家的问题。
ChatGPT 刚上线那会儿同样三天两头崩，Claude 早期也是”边哭边修”。
AI 行业的通病是：用户增长速度远远超过算力扩容速度。

但这不是我们原谅它的理由。
当你的产品、论文、业务流程绑死在 DeepSeek API 上，它每崩一次，你就损失一次。

单点依赖，是技术架构最大的敌人

做过后端开发的人都懂一个道理：任何外部依赖都可能随时挂掉。

数据库要配主从，服务要搞多活，CDN 要设备用源。
但在 LLM 这块，很多开发者的做法却是：注册一家大模型平台的 API 账号，拿到 Key，往代码里一写，完事。

这就是典型的单点依赖。

DeepSeek 六连崩的教训是：你选择的 LLM 提供商再强、再便宜，也不等于你的应用稳了。
算力瓶颈、流量洪峰、模型灰度测试、机房网络抖动，任何一个环节出问题，你的用户就面临服务降级甚至完全不可用。

更麻烦的是，这些出问题的环节你完全无法控制。
你既不能帮 DeepSeek 扩容，也不能替他们修机房网络。
你能做的，是在自己的架构里留好退路。

LangChain 的 with_fallbacks，最简单的退路

如果你已经在用 LangChain 开发 AI 应用，那配故障转移的成本其实很低。

LangChain 的 RunnableWithFallbacks 机制，本质上就是一句话的事：给 LLM 调用配一个或多个备用模型。
主力模型挂了，自动切到备选。

DeepSeek 当主力，通义千问当备选，写起来就这几行：

from langchain_core.chat_models import ChatOpenAI

deepseek = ChatOpenAI(
    model="deepseek-chat",
    api_key=os.getenv("DEEPSEEK_API_KEY"),
    base_url="https://api.deepseek.com/v1",
)

tongyi = ChatOpenAI(
    model="qwen-plus",
    api_key=os.getenv("TONGYI_API_KEY"),
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)

model = deepseek.with_fallbacks([tongyi])

model.invoke("帮我写一封英文商务邮件")

就这么简单。
with_fallbacks 接收一个 Runnable 列表，按顺序依次尝试。
第一个失败了，自动走第二个；第二个也失败，接着试第三个，直到有一个成功或列表跑完。

如果想控制哪些异常才触发回退，可以指定 exceptions_to_handle：

model = deepseek.with_fallbacks(
    [tongyi],
    exceptions_to_handle=[ConnectionError, TimeoutError]
)

这样可以避免把某些本应报错的问题（比如输入格式错误）也送进回退流程。

不只给模型配，链也行

with_fallbacks 不仅可以用在单个模型上，还能用在整条链上。
比如你有一条完整的 Prompt + Model + OutputParser 链，也可以整体配 fallback：

from langchain_core.prompts import PromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnableLambda

# 主力链：DeepSeek
primary_chain = (
    PromptTemplate.from_template("用中文写一个关于{topic}的短故事")
    | deepseek
    | StrOutputParser()
)

# 备用链：通义千问
fallback_chain = (
    PromptTemplate.from_template("用中文写一个关于{topic}的短故事")
    | tongyi
    | StrOutputParser()
)

# 终极兜底
def ultimate_fallback(inputs):
    return f"抱歉，LLM 服务暂不可用。关于 {inputs['topic']} 的故事暂时写不了，请稍后再试。"

chain = primary_chain.with_fallbacks([
    fallback_chain,
    RunnableLambda(ultimate_fallback)
])

result = chain.invoke({"topic": "一只会写代码的猫"})

这个思路的好处是，整条链的失败会被捕获，不只是模型调用本身。
如果 Prompt 处理出错、Parser 解析失败，也能触发 fallback。
而且最后一个 RunnableLambda 兜底，确保了无论如何用户都能得到一个响应。
虽然是降级的，但总比 500 页面强。

跨提供商的多层架构，才是真正的抗风险

前面两个例子是 DeepSeek + 通义千问的搭配，放到生产环境里，可以再加一层兜底：

主力层：DeepSeek API（便宜，效果好，但不够稳）

备用层：阿里通义千问 API（国内，延迟低，质量尚可）

兜底层：本地跑的小模型（慢但完全可控，极致降级）

代码上可以这样组织：

import os
from langchain_core.chat_models import ChatOpenAI  # 兼容 OpenAI 格式的各家 API

deepseek = ChatOpenAI(
    model="deepseek-chat",
    api_key=os.getenv("DEEPSEEK_API_KEY"),
    base_url="https://api.deepseek.com/v1",
)

tongyi = ChatOpenAI(
    model="qwen-plus",
    api_key=os.getenv("TONGYI_API_KEY"),
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)

model = deepseek.with_fallbacks([tongyi])

很多国内大模型厂商的 API 兼容 OpenAI 格式，直接用 ChatOpenAI 类就能对接。
这意味着你不需要为每家单独写适配代码，with_fallbacks 天然支持。

实施故障转移的正确姿势

看到这里你可能已经准备动手改代码了。
但有几件事建议先想清楚。

第一，延迟 vs 可靠性要权衡。
每次 fallback 都有一个超时等待时间，主力模型挂了才会切到备选。
如果你的主力 DeepSeek 响应很慢但没彻底挂，整个请求的耗时可能翻倍。
建议给主力模型设置合理的超时，快速失败，快速降级。

第二，fallback 链不宜太长。
理论上你可以串七八个模型，但实际每多一个备用，在最坏情况下的响应时间就多一份。
建议最多配 2-3 层，含一个兜底。

第三，不要把 fallback 当负载均衡用。
with_fallbacks 的设计初衷是异常应对，不是流量分发。
如果你想在多模型间做负载均衡或者成本优化，要用别的手段。

第四，监控和告警不能少。
fallback 成功不代表问题不存在。
当 fallback 被触发时，应该有日志和告警通知你：DeepSeek 又崩了，代码自动切到了阿里云。
然后你可以决定是等恢复还是手动切换。

不只是技术方案，更是业务兜底

回头看 DeepSeek 的五月份，六次宕机，短的半小时，长的数小时。
对于聊天工具用户来说，可能只是”等一会儿再用”。
但对于接入 API 做业务的应用来说，每一分钟的服务中断都在流失用户和收入。

把应用架构从”单模型依赖”升级成”多模型容灾”，付出的代价只是几个 API Key 和几十行代码。
带来的收益是在 LLM 提供商不可用时，你的应用不会跟着一起停摆。