2026 下半年 LLM API 服务商可靠性与正常运行时间对比：宕机规律、SLA 差距与多路由回退架构

每家服务商都会宕机。问题在于你的应用会不会跟着一起挂。

2026 年前八个月，我们看着 LLM API 服务商以一种让传统 SaaS 发布节奏显得缓慢的速度发布新功能，然后在这个过程中把自己搞出一堆故障。这篇文章汇总了我们在 OpenAI、Anthropic、Google、DeepSeek、DashScope 和 SiliconFlow 上追踪到的可靠性数据，并把它转化成一套回退路由的决策框架。

OpenAI 兼容指供应商提供一个 chat-completions 接口，其请求与响应结构与 OpenAI API 契约足够接近——只需替换三个值（API key、base URL、模型名），原来的 OpenAI SDK 调用即可直接工作。最小实践面是POST /v1/chat/completions 带 messages、model， 并返回 OpenAI 形式的流式响应。

2026 年的可靠性全景

AI 和 ML API 是被追踪的 215 项以上服务中可靠性最低的类别。Nordic APIs 可靠性报告（覆盖 2025 年 10 月至 2026 年 2 月）给出了这个结论。Stripe 的正常运行时间在 99.99% 左右，Linear 是 99.96%。表现最好的 LLM API 服务商在 99.85% 到 99.90% 之间徘徊，最差的低于 98%。

ModelUptime 2026 年 5 月报告是一份独立的跨服务商监测，追踪 9 家服务商的 29 个模型，在一个月内记录了 177 起事故，平均正常运行时间 99.28%。

这组数字说明行业还远没有把可靠性问题解决好。

各服务商可靠性概况

下表汇总了公开状态页面、独立监测机构（ModelUptime、isDown.app、StatusGator、IncidentHub）和 Nordic APIs 报告的数据。

数据来源见 status.openai.com、status.claude.com/uptime、status.deepseek.com、ModelUptime 2026 年 5 月报告、Nordic APIs 报告

几个值得关注的地方。

• 自我报告和独立监测之间的差距确实存在。 DeepSeek 的状态页面显示 99.88%，而 ModelUptime 在同一时期测出 98.16%。服务商可以自行决定什么算"事故"，独立监测没有这层滤镜。
• 事故数量并不等同于宕机时长。 Anthropic 有 18 起事故，OpenAI 只有 6 起，但两家的正常运行时间几乎一样（99.85% 对 99.86%）。Anthropic 平均解决速度更快。
• Google 的严重事故比例最高。 35 起事故中有 12 起被标为严重，是所有服务商中最高的。Gemini API 的可靠性一直在波动。
• DashScope 和 SiliconFlow 缺乏独立监测数据。 这未必意味着可靠性差，阿里云的基础设施是成熟的，但我们无法用和其他服务商相同的方式去验证。

宕机规律和事故频率

OpenAI

OpenAI 在 2026 年 1 月的 28 天内记录了 11 起事故，平均 2.5 天一次。到年中，事故频率明显改善，5 月只有 6 起，状态页面显示 6 至 9 月的正常运行时间为 99.93%。多数事故在 30 到 90 分钟内解决。

OpenAI 只通过 Scale Tier 计划提供正常运行时间承诺。标准 API 客户没有合同级 SLA。从 2026 年 7 月开始，Scale Tier 流量在容量受限时会自动溢出到 Fast 模式。

Anthropic

Anthropic 的 Claude API 在 2026 年第一季度经历了不少波折。1 月下旬 Claude Opus 4.5 出现了一次持续 30 小时的解决周期。3 月 26-27 日的网络事故导致 Opus 4.6 和 Sonnet 4.6 出现大量错误。到年中，月度正常运行时间从 99.01%（7 月）改善到 99.59%（8 月）。

截至撰文时最近的一次事故发生在 2026 年 9 月 11 日，Claude Mythos 5.1 和 Claude Fable 5.1 出现了大量错误，来源为 isDown.app。Anthropic 没有为标准客户发布正式的 API 正常运行时间 SLA。

Google

Google 的 Gemini API 在 2026 年 5 月拥有最差的严重事故比例，35 起事故中有 12 起为严重事故。独立监测显示正常运行时间为 98.22%，远低于其他主要西方服务商。Google 没有发布 Gemini 专属的正常运行时间承诺，Vertex AI 客户可以参考 Google Cloud 的通用 SLA。

DeepSeek

DeepSeek 在 ModelUptime 2026 年 5 月报告中以 98.16% 的正常运行时间和 50 起事故排名垫底。2026 年 8 月 4 日，V4 Flash API 在同一天内出现了两次性能下降事故，第一次持续 1 小时 18 分钟。DeepSeek 自己的状态页面报告 6 至 9 月正常运行时间为 99.88%，与独立监测之间有显著差距。

DeepSeek 没有发布速率限制或正常运行时间 SLA。在重大模型发布后的需求高峰期，API 历来会出现较长时间的容量紧张。

DashScope（阿里云百炼）

DashScope 受益于阿里云的生产级基础设施。它没有维护一个专门针对百炼 Model Studio 的公开事故历史记录，也没有主要的独立监测机构单独追踪 DashScope API 的正常运行时间。

根据我们路由流量通过 DashScope 的经验，正常运行条件下性能稳定，偶尔在中国工作时段（北京时间上午 9 点到下午 6 点）出现延迟峰值，与区域高需求相关。

SiliconFlow

SiliconFlow 没有发布公开的状态页面或事故历史记录。作为一个专注于高性价比推理的年轻平台，它的可靠性记录更难独立评估。根据我们的观察，热门模型的 API 响应总体稳定，免费层模型在高峰时段偶尔返回 429（速率限制）响应。

SLA 的真实情况

大多数 LLM API 服务商不向标准 API 客户提供合同级正常运行时间 SLA。下表列出了各家实际提供的承诺。

"我们有状态页面"和"出问题了我们赔偿"之间的差距非常大。对于大多数服务商来说，状态页面是一种礼貌行为，不是承诺。

三种需要预案的故障模式

1. 硬宕机

API 返回 5xx 错误或超时。这是最容易检测到的一种，你的监控系统会立即发现。问题在于大多数团队没有自动回退机制。工程师打开状态页面，等着，然后切换到别的事情上。

一个 50 人的工程团队，按每人每小时 80-150 美元计算，关键依赖每宕机一小时的生产力损失在 4000-7500 美元之间。这个数据来自 BuildMVPFast 的分析。

2. 质量下降

API 返回 200 OK，但输出是错误的、缓慢的或被截断的。健康检查通过了，模型也在响应，只是响应质量很差。延迟从 500ms 飙升到 8 秒，结构化响应开始未通过 schema 校验。这种故障比干净的宕机更难发现，也更隐蔽。

3. 级联故障

你的 AI 服务商没有问题，但上游的什么东西坏了。2025 年 10 月 AWS DynamoDB 的事故波及了 141 个受影响服务。Cloudflare 11 月的故障连 OpenAI 自己的部分服务也一并拖垮了。你的依赖链比你想象的要深。

回退架构：多服务商路由方案

这些数据比任何营销话术都更能说明多服务商路由的价值。当你的主服务商宕机时，你的应用应该自动路由到备用服务商，而不是呼叫工程师。

以下是使用 OpenAI 兼容路由层的最小回退配置。

from openai import OpenAI

# 主路由：通过 TheRouter 发送请求，回退已配置
client = OpenAI(
    base_url="https://api.therouter.ai/v1",
    api_key="your-therouter-key"
)

response = client.chat.completions.create(
    model="openai/gpt-4o",  # 主服务商
    messages=[{"role": "user", "content": "Hello"}],
    # 当 OpenAI 返回 5xx 或延迟超过阈值时，
    # TheRouter 自动回退到 anthropic/claude-sonnet-4.6
)

通过服务商回退路由，应用代码完全不需要改动。路由层吸收服务商的不稳定性，从当前健康的服务商返回响应。

推荐的回退链

基于上面的可靠性数据，以下回退链可以最大化覆盖。

关键原则只有一条，永远不要把回退链堆在同一套基础设施上。 OpenAI 和 Microsoft 模型共享 Azure 基础设施。DashScope 托管的 DeepSeek 和 DeepSeek 直连 API 共享 DeepSeek 的后端。有效的回退链要跨越基础设施的边界。

决策框架：按可靠性要求确定最低回退深度

计算逻辑如下。假设服务商 A 的正常运行时间为 99.85%，服务商 B 也是 99.85%，两者独立运行，跨两者路由可以获得大约 99.9998% 的正常运行时间。前提是两者的故障不相关。共享基础设施或共享上游依赖会降低这个收益。

构建你的可观测性体系

在用户发现问题之前检测到性能下降，需要针对 AI 的监控手段。

1. 追踪每个服务商的延迟分布，而非仅看平均值。一个 p50 稳定但 p95 波动的服务商正在间歇性退化。
2. 按错误码监控错误率。 429 激增意味着速率限制，500 激增意味着基础设施故障，两者的应对方式不同。
3. 校验输出质量。 返回 200 OK 但内容是垃圾的情况比干净的 503 更糟糕。对结构化响应做 schema 校验可以捕获这类问题。
4. 订阅状态页面 webhook。 上面列出的每家服务商都会发布状态页面更新。订阅它们。提前 10 分钟知道一个正在发展的事故，比通过用户投诉发现要好得多。

关于 LLM 监控工具的详细对比，请参阅我们的 LLM API 可观测性和监控工具对比。

常见问题

哪家 LLM API 服务商最可靠？

没有哪一家能持续保持第一。Microsoft 在 ModelUptime 2026 年 5 月排名中以 99.90% 领先，但 Microsoft 只有一个被追踪的模型（Phi-4）。在拥有广泛模型覆盖的主要服务商中，OpenAI（99.86%）和 Anthropic（99.85%）之间仅差 0.01%。月度波动很大。

该不该根据可靠性数据切换服务商？

根据单月数据切换服务商为时过早。更好的做法是多服务商路由。保留你的主服务商以保证质量，添加一个回退以保证可靠性。实现细节请参阅我们的 LLM API 回退路由指南。

如何监控我使用的 LLM API 服务商的正常运行时间？

订阅你所用服务商的状态页面（所有主要服务商都有）。在此基础上叠加独立监控服务，ModelUptime、isDown.app 和 StatusGator 都在追踪 LLM API 服务商。对于你自己的流量，在应用层面记录每个请求的延迟和错误率。

为什么自我报告和独立监测之间存在差距？

服务商可以自行决定什么算状态页面上的"事故"。10 分钟的延迟峰值可能不会出现在状态页面上，但会被独立监测机构捕获。自我报告的正常运行时间在排除"性能下降"时也比独立监测更为激进。

多服务商路由会增加延迟吗？

配置得当的路由层在服务商选择上每个请求只增加 1-5ms 的开销。与 500-3000ms 的 LLM 典型响应时间相比，这个数字微不足道。路由带来的延迟成本远远小于等待一个退化中的服务商慢慢响应的延迟成本。

如何为我的使用场景选择回退服务商？

优先考虑基础设施的多样性，而非模型的相似性。你的回退应该运行在与主服务商不同的基础设施上。OpenAI 和 Azure OpenAI 共享基础设施。DeepSeek 直连 API 和 DashScope 托管的 DeepSeek 共享 DeepSeek 的后端。要跨越这些边界。更多关于不同服务商如何出错的细节，请参阅错误处理参考。

---

本文中的可靠性数据基于公开可用的状态页面和独立监测报告。正常运行时间数字是基于事故报告的近似值，不是 SLA 级别的测量。服务商的可靠性会随时间变化，请查阅文中链接的状态页面获取最新信息。