博客 / 模型观察

同一模型换个 OpenRouter 供应商，可用率能差多少

2026-10-17cdnping 编辑部约 5 分钟读完

同一个模型 id 在 OpenRouter 上会挂在多家推理供应商下。换一个 OpenRouter 供应商，可用率可能差出十个百分点以上，量化精度也不一样。cdnping 2026-10-17 的快照里，一款 DeepSeek 模型有 36 个供应商端点，多数过去 1 天可用率是 100%，最低的约 88%。延迟和吞吐这次全是空值，所以本文只比可用率和量化，并说明有数据以后怎么比另外两项。

#这份数据从哪来，能说明什么

数字取自 cdnping 模型监测页 背后的数据，源头是 OpenRouter 公开 API，快照日期 2026-10-17。看表之前先了解几件事：

• cdnping 从 2026-10-17 才开始采集，这里只是第一天的截面，不是长期统计。
• up_30m 是最近 30 分钟的可用率，up_1d 是最近 1 天的，两个值都由 OpenRouter 给出，cdnping 只做记录。
• 快照里 137 条端点记录的 latency 和 throughput 全部为 null。null 是这一轮没取到值，不是零。
• 可用率为 null 也不代表故障，常见原因是端点刚上架，或者窗口内请求太少。例如快照里一款 Kimi 新模型的 26 个端点，可用率全部为空。

为避免文章里出现具体的模型版本名，下面用模型 A 到 D 指代，完整 id 可以在 /models 页按端点数对上。

#同一模型在不同供应商上的可用率差多少

我们挑了 4 个有多个供应商、可用率字段齐全的模型。价格是 OpenRouter 的模型级标价（快照值，美元/百万 token，输入/输出），单个供应商的实际计价以 OpenRouter 页面为准。

#模型 A：36 个端点，最低 88%

36 个端点里，22 个的 up_1d 是 100%，8 个低于 99%。下表列出低于 99% 的全部端点，再附几个作参照：

“—”表示快照中为 null。从这张表能读出三件事。

只看 30 分钟会误判。8 个 1 天可用率低于 99% 的端点里，7 个的 30 分钟可用率是 100%，只有 CoreWeave 在 30 分钟窗口里也不满。

同一家供应商的不同端点表现不同。DeepInfra 标准端点是 100%，flex 端点是 96.68%；Fireworks 默认端点是 88.82%，/us 端点是 99.10%。选型要细到端点，只认供应商名字不够。

这一天的数据看不出“量化越低越不稳”。36 个端点里 fp8 有 17 个，fp4 3 个，mxfp4 1 个，未标注 15 个。1 天低于 90% 的 4 个端点里，fp8、fp4 和未标注的都有。

#模型 B：量化档位最杂

另有 StreamLake、Venice、Novita、Phala 四个端点 up_1d 为 100、up_30m 为空，表中略去。13 个端点里 8 个的 30 分钟可用率为空，说明这段时间路由到它们的请求很少，对应的 100% 背后样本也不多。

出品方自己的端点标注为 int4，部分第三方标的是 fp8。精度标得更高，不代表输出和官方端点一致，要以你自己的评测为准。

#模型 C 和模型 D：同一家的不同入口

模型 C 的 6 个端点都由 Google 自己提供，区别在入口（AI Studio 或 Vertex）、区域和服务档位（flex、priority）。这一天里，默认的 AI Studio 端点反而最低。

模型 D 的 8 个端点（Anthropic、Amazon Bedrock、Google Vertex 的 global/us/europe、Azure 的 global/us、Claude Platform on AWS）up_30m 和 up_1d 全部是 100，量化都没有标注。闭源模型由原厂或云厂商托管，端点之间的差异主要在区域、合规和配额，不在权重本身。

#这些数字该怎么读

可用率是 OpenRouter 视角的成功率，反映 OpenRouter 发往该供应商的请求成功了多少。你从自己的网络访问 OpenRouter 顺不顺，是另一段链路，要单独测。

1 天低于 90% 不一定是一整天都不稳。假设故障集中在一段时间，持续两三个小时就足以把 1 天可用率拉到 88% 左右。要分清是集中故障还是持续抖动，得看更长的历史，cdnping 积累几周数据后才能回答。

量化字段只说明部署方式。fp8、fp4、int4、mxfp4 是供应商自报的权重精度，unknown 表示没标。精度低一般更省显存、吞吐更高，对你的任务有没有影响只能自己测。怀疑模型“变笨”时，/models 页附有第三方评测项目的导航，cdnping 不转载它们的数据。

标价相同不等于成本相同。表里是模型级标价，同一模型 id 下不同端点的计价、缓存支持、最大输出长度都可能不同。批量任务还要算上失败重试：一个 1 天可用率 88% 的端点，单价再低，重试多出来的 token 和等待时间也是成本。

延迟和吞吐等 /models 页有数值了再比。到时建议把首 token 延迟和每秒 token 数分开看，交互式补全更看重前者，批量生成更看重后者。

#怎么给自己的项目挑供应商

#第一步：拉取某个模型的全部端点

OpenRouter 提供公开的端点查询接口，字段名以 OpenRouter 官方文档为准。把下面的 作者/模型名 换成你在 /models 页查到的模型 id：

MODEL="作者/模型名"
curl -s "https://openrouter.ai/api/v1/models/${MODEL}/endpoints" \
  | jq '.data.endpoints[] | {provider: .provider_name, tag: .tag, quant: .quantization, up_30m: .uptime_last_30m, ctx: .context_length}'

拉下来以后和 cdnping /models 页对一遍，确认看的是同一个模型 id 的同一批端点。

#第二步：按检查表筛选

#第三步：在请求里写明供应商偏好

OpenRouter 支持在请求体的 provider 字段里指定供应商顺序、量化范围和是否允许回退。下面是一个示例：

{
  "model": "作者/模型名",
  "messages": [{"role": "user", "content": "ping"}],
  "provider": {
    "order": ["deepseek", "deepinfra"],
    "quantizations": ["fp8"],
    "allow_fallbacks": true
  }
}

供应商名称只是示例，可用取值以 OpenRouter 官方文档为准。建议保留 allow_fallbacks。上面的数据里，单个端点一天内掉到 90% 以下并不少见，留几个后备端点比押在一家上稳。

#第四步：测自己这一侧的链路

前面的可用率都是 OpenRouter 到供应商这一段。从你的网络到 OpenRouter 这一段，可以在 cdnping 在线测速 页测 OpenRouter 的首次连接（含 DNS 与 TLS 握手）和往返时间。出现异常时，先到 /status/openrouter 和 /down/openrouter 看是不是平台侧的问题。

如果怀疑是本地网络、代理或 DNS，可以用 IP 与环境检测 查看出口 IP、大陆分流状态、DNS 泄漏和 WebRTC 泄漏，相关概念见 分流说明 和 DNS 与 WebRTC 泄漏。检测页可以生成带水印的结果图，生成前可以选择隐藏 IP，方便贴到工单或群里一起排查。使用任何海外 AI 服务，都请遵守对应的服务条款和当地法规。

#不想自己维护供应商顺序怎么办

也可以交给聚合网关处理。AGI Plan 是 cdnping 的出品方，两者由同一团队运营。AGI Plan 按能力组调度请求，并在 https://agiplan.dev/api/status/requests?month=YYYY-MM 公开逐小时、逐能力组的请求成功和失败计数，不需要登录，cdnping 的 /status/agiplan 页会镜像展示。它的可用率按真实请求计算，只有 5xx 算平台失败，和上文 OpenRouter 的端点可用率口径不同，两者不能直接比较。套餐和价格见 agiplan.dev/pricing。

#接下来可以看什么

• 收藏 /models，一周后再看模型 A 那几个低于 99% 的端点，判断是一次性故障还是一直不稳。端点的上架、下架、调价和量化变化，/models 页会自动记录。
• 订阅每周一自动生成的 稳定性周报。
• 数据来源和采集方式见 数据方法；国内调用 AI API 的延迟从哪来，见 这篇说明。