46家AI API可用性实测：OpenAI掉出前15，区域差异才是关键

数据来源与方法：30天、158万次探测的独立监测

独立监测项目 llmlatency.dev 在 2026 年 9 月 18 日至 10 月 17 日的 30 天窗口内，对 46 家 AI 推理 API 进行了持续探测。数据采集自德国、美国中部、东京和圣保罗四个区域的云数据中心，每 5 分钟发起一次请求，总计 1,580,667 次。

探测路径覆盖 DNS → TCP → TLS → 首字节的完整网络链路，超时、连接错误或 HTTP 5xx 均计为失败；4xx 因探测请求不携带密钥，被视为“API 有应答”。只有同时从 2 个以上区域失败、且同期没有其他供应商出现故障时，才被归因为该供应商的独立宕机。这种归因规则可以有效排除区域性网络问题和上游共因故障。

需要明确的是，这些数字是观测可用性（observed availability），而非服务等级协议（SLA）。它反映的是外部客户端从四个数据中心实际看到的情况，绝对数值会优于普通移动端用户的体验，因此供应商之间的横向对比才是更有意义的部分。

观测可用性与SLA的区别：观测可用性（observed availability）指第三方从外部网络实际测量到的服务可达比例，由探测结果直接计算得出；而服务等级协议（SLA）是供应商与客户之间的合同承诺，通常包含赔偿条款和特定的计算口径（如按月、排除计划维护）。SLA 数字往往经过供应商自行统计和筛选，可能不包含短暂抖动或特定区域故障。因此，观测可用性常低于官方 SLA 宣称值，但更贴近真实用户体验。在对比不同供应商时，应确保使用同一来源的观测数据，避免将第三方监测结果与厂商公布的 SLA 混为一谈。

整体排名：头部差距以分钟计

30 天平均可用性排名前四的分别是 Meta Llama API（99.986%）、Anthropic Claude（99.985%）、OpenRouter（99.985%）和 Google Gemini（99.983%）。OpenAI 以 99.930% 排在第 18 位，掉出了前 15。

46 家 API 中，24 家在一个月内保持在 99.9% 以上，中位数为 99.90%。Anthropic 与 OpenAI 之间的差距是 0.055 个百分点，换算成时间约为每月 24 分钟。对于大多数应用场景，这个量级的差异远小于自身代码缺陷或网络抖动带来的影响。

排名末尾的 01.AI（Yi）可用性为 97.275%，与头部相差约 2.7 个百分点，对应每月约 19 小时的不可用时间，量级差异明显。

百分点与分钟数的换算：可用性百分比的小数点后每一位代表不同的不可用时长。以 30 天（约 43,200 分钟）为基准，1 个百分点对应约 432 分钟，0.1 个百分点约 43 分钟，0.01 个百分点约 4.3 分钟。因此，99.9% 与 99.99% 之间看似只差 0.09 个百分点，实际每月不可用时间却相差近 39 分钟。文中 Anthropic 与 OpenAI 的 0.055 个百分点差距，正是通过此换算得出约 24 分钟。理解这一换算关系，有助于开发者将抽象的百分比转化为可感知的故障时长，从而评估对业务的实际影响。

最差区域：被平均值掩盖的真实风险

平均可用性只能说明一半问题。数据显示，46 家供应商中有 24 家的最差区域是东京，17 家是圣保罗，5 家是德国。美国中部从未成为任何一家的最差区域。

这一分布有明确的工程含义。如果你的用户集中在亚洲或南美，应重点看区域列而非平均值。以 OpenAI 为例，其全球平均可用性为 99.930%，但东京区域为 99.814%，差距接近 0.12 个百分点。ByteDance 豆包在圣保罗的最差区域可用性为 98.891%，显著低于其 99.260% 的均值。

对于面向特定区域用户的产品团队，部署多区域冗余或选择在该区域表现更稳定的供应商，比纠结全球平均值更实际。

归因宕机：问题集中在少数供应商

30 天内共记录 51 次归因宕机，分布在 15 家供应商。ByteDance 豆包（11 次）、01.AI Yi（10 次）和 SambaNova（9 次）合计占据了一半以上。可用性最高的四家 API 在此期间没有记录到任何归因宕机。

归因宕机次数与可用性百分比并不完全对应。例如 Cerebras 的可用性为 99.907%，但记录了 2 次归因宕机共 6 分钟；而 Moonshot Kimi 可用性 99.850%，仅 1 次宕机但持续 36 分钟。单次故障的持续时间对用户体验的影响，往往比故障频率更值得关注。

归因宕机（attributed outage）的判定逻辑：该指标并非简单统计所有失败请求，而是通过多区域交叉验证来排除区域性网络问题或上游共因故障。具体规则是：只有当同一供应商同时从 2 个以上探测区域失败，且同期没有其他供应商出现类似故障时，才将该次失败归因于该供应商自身。这种设计能有效区分“供应商宕机”与“探测点网络抖动”或“互联网骨干网故障”。因此，归因宕机次数更接近供应商侧的真实故障事件，而非客户端感知的全部错误。开发者可借此判断故障源是否在供应商内部。

局限性：网络可用不等于推理可用

监测方主动说明了几个关键限制。首先，探测点是云数据中心而非消费者网络，因此绝对数字比手机端用户看到的更好，供应商之间的比较才是有效信息。

其次，网络层可用性与推理成功并不等同。一个主机有应答但模型队列卡住的情况，在此口径下仍计为“在线”。真实的推理探测（以实际首 token 时间为指标的请求）是另行报告的。

第三，30 天只是一个时间窗口，存在样本期偏差的可能。实时页面每 30 分钟基于最近 24 小时重建，可作为补充参考。数据集以 CC-BY-4.0 协议开放，附带 DOI，也可通过 pip install llmlatency 在 Python 中直接调用。

对开发者的实际参考

这份数据的价值不在于给供应商排座次，而在于提示两个选型维度。其一是区域视角：全球平均值可能掩盖你目标市场的真实表现。其二是故障模式：高频短故障和低频长故障对产品的影响完全不同，前者适合重试机制，后者需要降级预案。

头部供应商之间每月几十分钟的可用性差距，在工程上通常可以通过多供应商路由和自动重试来消化。真正需要警惕的是那些可用性低于 99.5%、或单次故障持续超过 30 分钟的供应商——它们更可能成为系统稳定性的短板。