api中轉站怎麼選：可用率、計費、資料政策等 8 項可核對的檢查

部落格 / 開發工具

api中轉站怎麼選：可用率、計費、資料政策等 8 項可核對的檢查

cdnping 編輯部約 7 分鐘讀完

選 api中轉站，先看它給出的東西能不能自己核對：可用率有沒有公開的原始資料和計算口徑，賬單能不能和每次請求的 token 對上，資料怎麼處理有沒有寫成文字。能核對的服務，出了問題你至少知道問題在哪；只能“相信”的服務，出了問題只能等。

下面是 8 項檢查，每項都寫了怎麼驗證，適合在充值或訂閱之前做一遍。

api中轉站到底做了什麼，為什麼要單獨評估？

中轉站（也叫 API 閘道器、聚合閘道器）在你和模型提供方之間多加了一層：你的請求先到它的入口，再由它轉發到上游。好處是換模型只改一個介面地址，結算方式也可能更方便；代價是多了一個會出故障、會計費、會接觸你請求內容的環節。

所以評估的物件有三個：這一層自己穩不穩，它怎麼收錢，它怎麼對待你的資料。上游模型本身的質量和故障，是另一回事，要分開看。

8 項檢查清單（可以直接照做）

#檢查項合格的樣子怎麼驗證
1公開可用率與口徑有原始計數可下載，寫明分子分母拉取資料，自己算一遍
2計費單位與賬單單位有換算公式，單次請求可對賬發固定請求，對比 usage 與扣費
3資料保留政策寫明是否落盤、是否訓練、是否轉售找到書面條款並截圖存檔
4介面格式寫明相容哪種格式，流式與工具呼叫可用用你實際的工具跑一次
5退款與發票條款寫在頁面上，而不是“聯絡客服”看頁面，不看聊天記錄
6故障覆盤故障後有時間、影響範圍和原因說明找最近一次故障的記錄
7出口與延遲入口延遲穩定，首 token 時間可接受在自己的網路裡測連線與 TTFT
8授權宣告如實說明與模型廠商的關係看官網是否聲稱“官方授權”

下面逐項展開。

1. 可用率數字是怎麼算出來的？

“99.9% 可用”這句話本身沒法驗證。要問三件事：

  • 統計物件：是定時探測（每幾分鐘 ping 一次入口），還是真實使用者請求？探測只說明入口通不通，真實請求才反映你實際遇到的失敗。
  • 失敗的定義：4xx（如金鑰錯誤、額度不足）算不算失敗？上游超時算誰的？口徑不同，同一段時間能算出差很多的數字。
  • 能不能拿到原始資料：只有一個百分比，就只能信；有逐小時的成功和失敗計數，才能自己復算。

下面以 AGI Plan 為例，看“可核對”是什麼樣。先說明關係：AGI Plan 是 cdnping 的商業合作方。這裡用它舉例，是因為它的資料公開、我們能完整引用，不代表推薦結論。

它的可用率介面不需要登入：

# 預設返回 CSV；加 format=json 返回 JSON
curl -s "https://agiplan.dev/api/status/requests?month=2026-10&format=json"

返回的是逐小時、逐能力組的成功和失敗計數。口徑寫明為：可用率 = 成功 /（成功 + 因平臺自身原因失敗），只有 5xx 算平臺失敗。cdnping 的 AGI Plan 狀態頁 映象展示同一份資料。

我們在 2026-10-17 從這個介面取的資料快照（視窗為 2026-10-15 19:00 至 2026-10-17 18:00，北京時間，共 48 個小時桶）裡：

  • 48 小時合計成功 13,963 次、失敗 2,177 次，按上面的口徑算出約 86.5%。
  • 失敗集中在 10 月 16 日 14:00 和 15:00 兩個小時：這兩小時成功 1,119 次、失敗 1,599 次，單小時可用率分別約 47.9% 和 34.2%。
  • 按能力組的 30 天可用率：國產組約 98.0%，均衡組約 95.0%，前沿組約 94.4%，快速組約 81.7%。

這些數字並不好看。資料公開以後，壞的時段也會擺在那裡：你能看出故障集中在哪幾個小時、哪個能力組，再判斷自己的用法能不能接受。只有一個百分比、沒有原始計數，就做不了這種判斷。

評估任何一家時，可以照這個方法做：拿到原始資料，自己求和，看最差的那幾個小時，再看分組差異。

2. 計費單位能不能和請求對上？

中轉站常用自定義單位（點數、積分、CU 之類）。要確認兩件事：單位和 token 之間有沒有公開的換算公式，單次請求的扣費能不能查到明細。

例如 AGI Plan 寫明 1 CU = 基準模型 1,000 個輸出 token，按量充值 1 元 = 500 CU。有了公式，你才能把賬單換算回 token，再和模型官方價格對比。

驗證方法：發一個輸入、輸出都固定的小請求，記下響應裡的 usage 欄位，再去後臺看這次扣了多少。

export BASE="https://relay.example.com"   # 示例地址，換成你要評估的服務
export KEY="sk-..."

curl -s "$BASE/v1/chat/completions" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"<模型名>","max_tokens":50,
       "messages":[{"role":"user","content":"只回答數字：1+1="}]}' \
  | python3 -m json.tool | grep -A4 usage

同樣的請求連發 5 次，扣費應該基本一致。如果後臺只有餘額變化、查不到單次明細，月底就很難對賬。模型調價、換算比例調整時，也要能及時知道，方法見 大模型 API 價格變動的三路追蹤。

3. 你的請求內容會被存下來嗎？

請求裡常有程式碼、文件甚至金鑰。要找的是書面條款，至少回答三個問題：請求正文是否落盤、保留多久；是否用於訓練；是否轉售或共享給第三方。

能寫成一句話的政策更好核對。例如 AGI Plan 寫的是“請求正文預設不落盤，內容不訓練、不轉售”。找到條款後截圖並記下日期，條款日後改了，你手裡有對照。

不管條款寫得如何，不要把生產金鑰、使用者隱私資料放進提示詞，這一條對官方 API 同樣適用。

4. 支援哪種介面格式，你的工具能不能直接用？

現在常見的有 OpenAI 格式和 Anthropic 格式兩種。例如 Claude Code 走 Anthropic 格式，Codex 走 OpenAI 格式。只相容一種，意味著你有一部分工具接不上。

驗證時別隻跑一次普通對話，至少覆蓋這三項：

  1. 流式輸出：加 "stream": true，看是否逐段返回，而不是攢到最後一次性吐出。
  2. 工具呼叫：用你實際的 agent 工具跑一個需要讀檔案或執行命令的任務。
  3. 長上下文：塞一份較長的檔案，看會不會被截斷或報錯。

各工具的介面地址怎麼改，可以參考 Claude Code、Codex、OpenCode 自定義介面配置。

5. 退款和發票寫在哪裡？

這一項只看一件事：條款是否寫在公開頁面上。“有問題找客服”不算寫明。需要報銷的團隊，要確認發票型別和開具方式是否在頁面上說清楚。

聊天記錄裡的承諾很難作為依據，書面條款至少能截圖存檔。條款如果標註為草案或“即將上線”，就按還沒有處理。

6. 出過故障嗎，有沒有覆盤？

任何服務都會出故障。據 cdnping 從官方狀態頁同步的事件記錄（截至 2026-10-17 的快照），2026-09-17 以來 OpenAI 記錄了 25 條事件（其中 major 4 條），Claude 記錄了 8 條（其中 major 6 條）。中轉站的可用率上限受上游影響，這是事實；要看的是它出問題時說不說清楚。

驗證方法：翻它的公告、狀態頁或更新日誌，找最近一次故障，看有沒有寫明開始和結束時間、影響了哪些模型或分組、原因是上游還是自身、之後改了什麼。

回到第 1 項的例子：公開計數能告訴你 10 月 16 日下午那兩小時失敗很多，但計數本身不給原因。所以第 1 項和第 6 項要一起看，前者告訴你“發生了什麼”，後者告訴你“為什麼，以後會不會再來”。狀態頁的事件等級怎麼讀，見 怎麼看 OpenAI 和 Claude 狀態頁；近期上游故障的彙總在 2026 年 9–10 月 AI 服務故障盤點。

7. 從你這裡訪問，延遲能接受嗎？

中轉站的延遲由兩段組成：你到它入口的網路，加上它到上游的轉發與推理。別人測出來的數字只代表別人的網路，要在自己的環境裡測。

第一步，開啟 cdnping 線上測速，在瀏覽器裡看各 API 入口的“首次連線”（含 DNS 與 TLS 握手）和“往返”（連線複用後 3 次請求的中位數）。

第二步，用 curl 拆開看各階段耗時：

curl -s -o /dev/null "$BASE/v1/models" \
  -H "Authorization: Bearer $KEY" \
  -w "DNS %{time_namelookup}s | TCP %{time_connect}s | TLS %{time_appconnect}s | 首位元組 %{time_starttransfer}s | 總計 %{time_total}s\n"

在一天裡的不同時段各測幾次。/v1/models 不經過推理，反映的主要是閘道器本身；真正影響體驗的是流式請求的首 token 時間（TTFT）。三段延遲怎麼區分，參見 AI API 延遲拆解：連線、往返與 TTFT。

另外，同一個模型名，背後可能是不同的推理供應商和不同的量化精度，輸出質量和速度都可能不同。可以在 cdnping 模型監測 看各供應商的可用率和量化標註，背景知識見 推理供應商與 fp8、fp4 量化。同一模型在不同供應商上的可用率差距，見 同一模型換個 OpenRouter 供應商，可用率能差多少。

8. 它說自己是“官方授權”嗎？

去模型廠商的官方渠道核實，而不是看中轉站自己怎麼說。如實說明自己身份的服務更可信一些。例如 AGI Plan 在官網明確說明自己不是官方授權渠道。

另外，部分模型在部分地區不提供服務。中轉站標註的地區可用性（例如“僅境外”）以其官方頁面為準，使用時請遵守模型廠商的服務條款和當地法規。

檢查完怎麼做決定？

把 8 項結果填進上面的表格，按這個順序取捨：

  1. 第 3、8 項有一項說不清，直接排除。資料政策和身份說明是底線。
  2. 第 1、2 項決定能不能長期用。可用率無法復算、賬單無法對賬的服務，適合小額試用，不適合放進工作流。
  3. 第 4、7 項決定好不好用。這兩項和你的工具、網路強相關，只能自己測。
  4. 第 5、6 項決定出事時的處境。條款和覆盤越清楚，出問題後的溝通成本越低。

先小額或按量開始，用自己的真實任務跑一週，同時每天拉一次公開可用率資料（如果有的話），和你自己的報錯日誌對照。兩邊對得上，再考慮長期訂閱。

相關文章

繼續閱讀