部落格 / 模型觀察

同一模型換個 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 的延遲從哪來，見 這篇說明。