--- title: "同一模型换个 OpenRouter 供应商，可用率能差多少" description: "用 cdnping 2026-10-17 的 OpenRouter 快照，对比同一模型在不同 OpenRouter 供应商端点上的 1 天可用率和量化精度，说明空值怎么读，并给出拉取端点、筛选和设置供应商偏好的步骤。" url: https://cdnping.org/blog/same-model-different-providers-uptime language: zh-CN published: 2026-10-17 category: "模型观察" tags: ["OpenRouter","模型可用率","推理供应商","量化精度","选型方法"] source: cdnping.org license: Free to quote and summarize with a link to the url above. --- # 同一模型换个 OpenRouter 供应商，可用率能差多少 同一个模型 id 在 OpenRouter 上会挂在多家推理供应商下。换一个 OpenRouter 供应商，可用率可能差出十个百分点以上，量化精度也不一样。cdnping 2026-10-17 的快照里，一款 DeepSeek 模型有 36 个供应商端点，多数过去 1 天可用率是 100%，最低的约 88%。延迟和吞吐这次全是空值，所以本文只比可用率和量化，并说明有数据以后怎么比另外两项。 ## 这份数据从哪来，能说明什么 数字取自 cdnping [模型监测页](/models) 背后的数据，源头是 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](/models) 页按端点数对上。 ## 同一模型在不同供应商上的可用率差多少 我们挑了 4 个有多个供应商、可用率字段齐全的模型。价格是 OpenRouter 的模型级标价（快照值，美元/百万 token，输入/输出），单个供应商的实际计价以 OpenRouter 页面为准。 | 模型 | 出品方 | 供应商端点数 | 标价 输入/输出 | 上下文 | |---|---|---|---|---| | 模型 A | DeepSeek | 36 | 0.15 / 0.6 | 1,048,576 | | 模型 B | Moonshot AI（Kimi） | 13 | 0.671 / 3.35 | 262,144 | | 模型 C | Google（Gemini） | 6 | 2 / 10 | 1,048,576 | | 模型 D | Anthropic（Claude） | 8 | 2 / 10 | 1,000,000 | ### 模型 A：36 个端点，最低 88% 36 个端点里，22 个的 `up_1d` 是 100%，8 个低于 99%。下表列出低于 99% 的全部端点，再附几个作参照： | 供应商（端点） | up_30m | up_1d | 延迟 | 吞吐 | 量化 | |---|---|---|---|---|---| | CoreWeave (coreweave/fp8) | 93.33 | 88.08 | — | — | fp8 | | Fireworks (fireworks) | 100 | 88.82 | — | — | unknown | | Makora (makora/fp8) | 100 | 89.06 | — | — | fp8 | | Sail Research (sail-research/fp4) | 100 | 89.29 | — | — | fp4 | | DeepInfra (deepinfra/fp8/flex) | 100 | 96.68 | — | — | fp8 | | Alibaba (alibaba) | 100 | 97.21 | — | — | unknown | | BaseTen (baseten/fast) | 100 | 97.95 | — | — | unknown | | Baidu (baidu/fp8) | 100 | 98.26 | — | — | fp8 | | Fireworks (fireworks/us) | 100 | 99.10 | — | — | unknown | | SiliconFlow (siliconflow/fp8) | 100 | 99.38 | — | — | fp8 | | DeepInfra (deepinfra/fp8) | 100 | 100 | — | — | fp8 | | DeepSeek (deepseek) | 100 | 100 | — | — | unknown | “—”表示快照中为 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：量化档位最杂 | 供应商（端点） | up_30m | up_1d | 量化 | |---|---|---|---| | Moonshot AI (moonshotai/int4) | 100 | 100 | int4 | | Moonshot AI (moonshotai/highspeed) | 100 | 100 | int4 | | Inceptron (inceptron/int4) | 100 | 100 | int4 | | CoreWeave (coreweave/int4) | 100 | 99.72 | int4 | | Nebius (nebius/fp4) | 100 | 96.55 | fp4 | | SiliconFlow (siliconflow/fp8) | — | 100 | fp8 | | Alibaba (alibaba/fp8) | — | 100 | fp8 | | GMICloud (gmicloud/fp8) | — | 100 | fp8 | | Cloudflare (cloudflare) | — | 100 | unknown | 另有 StreamLake、Venice、Novita、Phala 四个端点 `up_1d` 为 100、`up_30m` 为空，表中略去。13 个端点里 8 个的 30 分钟可用率为空，说明这段时间路由到它们的请求很少，对应的 100% 背后样本也不多。 出品方自己的端点标注为 int4，部分第三方标的是 fp8。精度标得更高，不代表输出和官方端点一致，要以你自己的评测为准。 ### 模型 C 和模型 D：同一家的不同入口 | 模型 C 端点 | up_30m | up_1d | |---|---|---| | Google AI Studio (flex) | 100 | 100 | | Google Vertex (global) | 100 | 99.10 | | Google AI Studio | 100 | 97.99 | | Google Vertex (us) | — | 100 | | Google Vertex (global/priority) | — | 100 | | Google AI Studio (priority) | — | 100 | 模型 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： ```bash 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](/models) 页对一遍，确认看的是同一个模型 id 的同一批端点。 ### 第二步：按检查表筛选 | 检查项 | 判断方法 | 门槛示例（按业务调整） | |---|---|---| | 1 天可用率 | 看 `up_1d` | 生产主路由 ≥ 99% | | 30 分钟可用率 | 看 `up_30m`，为空说明样本少 | 不单独作为依据 | | 量化精度 | 看 `quant` | 与你评测过的版本一致 | | 端点后缀 | flex / priority / fast / us 等 | 区分服务档位和区域 | | 上下文长度 | 看 `ctx` | 覆盖你的最长输入 | | 单价 | 以 OpenRouter 页面为准 | 与预算匹配 | ### 第三步：在请求里写明供应商偏好 OpenRouter 支持在请求体的 `provider` 字段里指定供应商顺序、量化范围和是否允许回退。下面是一个示例： ```json { "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](/status/openrouter) 和 [/down/openrouter](/down/openrouter) 看是不是平台侧的问题。 如果怀疑是本地网络、代理或 DNS，可以用 [IP 与环境检测](/ip) 查看出口 IP、大陆分流状态、DNS 泄漏和 WebRTC 泄漏，相关概念见 [分流说明](/learn/split-tunneling) 和 [DNS 与 WebRTC 泄漏](/learn/dns-leak-webrtc-leak)。检测页可以生成带水印的结果图，生成前可以选择隐藏 IP，方便贴到工单或群里一起排查。使用任何海外 AI 服务，都请遵守对应的服务条款和当地法规。 ## 不想自己维护供应商顺序怎么办 也可以交给聚合网关处理。AGI Plan 是 cdnping 的出品方，两者由同一团队运营。AGI Plan 按能力组调度请求，并在 `https://agiplan.dev/api/status/requests?month=YYYY-MM` 公开逐小时、逐能力组的请求成功和失败计数，不需要登录，cdnping 的 [/status/agiplan](/status/agiplan) 页会镜像展示。它的可用率按真实请求计算，只有 5xx 算平台失败，和上文 OpenRouter 的端点可用率口径不同，两者不能直接比较。套餐和价格见 [agiplan.dev/pricing](https://agiplan.dev/pricing)。 ## 接下来可以看什么 - 收藏 [/models](/models)，一周后再看模型 A 那几个低于 99% 的端点，判断是一次性故障还是一直不稳。端点的上架、下架、调价和量化变化，/models 页会自动记录。 - 订阅每周一自动生成的 [稳定性周报](/reports)。 - 数据来源和采集方式见 [数据方法](/methodology)；国内调用 AI API 的延迟从哪来，见 [这篇说明](/learn/ai-api-latency-china)。