本文為 So you want to use OpenRouter? — Mo Moustafa 之繁體中文翻譯整理，原文版權歸原作者所有。
表面上看起來似乎很簡單，但很遺憾，往下挖每一層都是痛苦。
我經營的 Olly 是一個存在於 iMessage 裡的 AI 助手，透過 OpenRouter 使用開源模型。到目前為止，Olly 已處理超過 1,800 萬則訊息，其中約三分之一是透過 OpenRouter 使用開放模型。這樣的流量足以讓我們至少碰上每一種邊緣案例一次。以下是我希望自己一開始就知道的事情。
先快速說明幾個詞彙：模型（model）指的是權重；供應商（provider）則是 OpenRouter 將請求路由過去的服務商。他們在自己的 GPU 上託管模型，採用自行選擇的精度與「專有」最佳化，也使用各自的 XML／工具解析器——因此，每家也都有一份「專有」的錯誤清單。當你呼叫 deepseek/deepseek-v4-flash 時，實際上可能會用到約 20 家你大多沒聽過的公司。紙面上它們是同一個模型，實際表現卻大不相同。
好，以下是你應該留意的一些陷阱。
1. 同一個模型的基準測試結果可能差異極大
OpenRouter 會針對同一模型執行各供應商基準測試：GPQA Diamond，以及 TAU-Bench Airline（工具呼叫任務）。以下是今天 DeepSeek V4 Flash 0731 的排行榜；每家供應商提供的都是完全相同的權重：
DeepSeek V4 Flash 0731，每個點代表一家供應商，2026-09-07
70%
75%
80%
85%
90%
55%
60%
65%
70%
75%
80%
GPQA Diamond（知識）
TAU-Bench Airline（工具呼叫）
DeepSeek：GPQA 90.2%，TAU 81.3%
第一方
NextBit：GPQA 89.9%，TAU 76.6%
Alibaba Cloud Int.：GPQA 89.4%，TAU 76.8%
SiliconFlow：GPQA 90.0%，TAU 75.4%
NovitaAI：GPQA 89.3%，TAU 76.0%
Ionstream：GPQA 87.2%，TAU 78.0%
GMICloud：GPQA 89.0%，TAU 75.8%
Reka AI：GPQA 89.1%，TAU 75.4%
Parasail：GPQA 89.0%，TAU 75.4%
Baidu Qianfan：GPQA 89.6%，TAU 74.8%
Cloudflare：GPQA 88.4%，TAU 75.0%
CoreWeave：GPQA 87.1%，TAU 76.0%
DeepInfra：GPQA 89.2%，TAU 73.9%
StreamLake：GPQA 87.8%，TAU 74.9%
Phala：GPQA 88.2%，TAU 74.5%
Inceptron：GPQA 87.9%，TAU 74.1%
AtlasCloud：GPQA 88.3%，TAU 73.6%
Together：GPQA 86.9%，TAU 75.0%
Decart：GPQA 87.9%，TAU 73.3%
Venice：GPQA 86.8%，TAU 74.2%
AkashML：GPQA 88.5%，TAU 72.5%
Morph：GPQA 85.8%，TAU 74.9%
Wafer：GPQA 84.1%，TAU 76.0%
Ambient：GPQA 86.4%，TAU 73.5%
Relace：GPQA 87.2%，TAU 71.7%
Io Net：GPQA 84.1%，TAU 74.5%
Makora：GPQA 86.9%，TAU 71.7%
Mancer：GPQA 85.5%，TAU 70.8%
Sail Research：GPQA 70.8%，TAU 75.2%
OpenInference：GPQA 70.5%，TAU 70.8%
Nebius：GPQA 75.6%，TAU 65.3%
DigitalOcean：GPQA 75.3%，TAU 58.4%
OpenRouter 的 deepseek/deepseek-v4-flash-0731 各供應商排行榜，2026-09-07。採 32 天滾動平均；將游標移到點上可查看名稱。
第一方 DeepSeek：GPQA 90%、TAU 81%。DigitalOcean 使用相同權重，卻只有 75% 和 58%。多數託管商在工具呼叫上比第一方低 5 至 7 個百分點，另有四家在知識測試上直接崩跌。對代理而言，TAU 才是重要指標，而 20 個百分點的差距絕不是雜訊。（七月時更糟：Fireworks 的 TAU 只有 46%，落後 30 個百分點。）
在信任某家供應商之前，先查看最接近你實際工作負載的基準測試；切換模型時也要重新檢查，因為同一批供應商在 GLM-5.3 上的表現完全不同。
2. 視覺模型可能遇上「看不見」的供應商
我注意到圖片任務出現一些奇怪的非確定性行為，因此把相同的三張小圖片（一個字母、單一純色、彩色背景上的單字）送到兩個開放視覺模型的每一家託管商：
Qwen3.5 122B，2026-07-31
字母 K
純紅色
紫色背景上的單字
DeepInfra
✗ 誤讀為 R／I
✗ 說是藍色
✗ 回答「funny，淺藍色」
Alibaba
✓
✓
✓
AtlasCloud
✓
✓
✓
Novita
✓
✓
✓
SiliconFlow
✓
✓
✓
MiniMax M3，2026-07-31
字母
單字
顏色
Venice
✗「未提供圖片」
✗ 同上
✗ 同上
Together
✗「未提供圖片」
✗ 同上
✗ 同上
其他供應商（包括第一方）
✓
✓
✗ 全部辨識成錯誤色調
各託管商結果記錄於 2026-07-31。MiniMax 的顏色辨識在所有供應商（包括第一方）都失敗，因此這是模型本身，而非供應商的問題。
DeepInfra 的 Qwen 端點把 K 看成 R、把紅色說成藍色，還把「umbrella」描述成「funny」；同一權重在另外四家託管商上卻全部答對。Venice 和 Together 完全看不到 MiniMax 圖片。模型頁面聲稱支援圖片輸入，但其中兩家供應商其實不支援；更糟的是，它們還會假裝一切正常並回傳 200 OK。
3. 對某些供應商而言，effort 旋鈕只是裝飾
所有地方都接受 reasoning.effort，但它是否真的有效，取決於模型與供應商。我固定使用每一家提供 DeepSeek V4 Flash 0731 的供應商，從生產環境機器以 low、high、max 三種設定傳送相同提示詞，每種各執行三次。以下是輸出的推理 token 數：
DeepSeek V4 Flash 0731 經由 OpenRouter，2026-09-07：effort 真的有效嗎？
0
500
1000
1500
2000
alibaba
atlas-cloud
baseten
cloudflare
coreweave
deepinfra
digitalocean
gmicloud
mancer
morph
nextbit
novita
open-inference
parasail
phala
reka
relace
sail-research
siliconflow
streamlake
together
venice
wafer
每次呼叫的推理 token 數；相同提示詞、固定供應商，每種 effort 各呼叫 3 次。● low ● high ● max
DeepSeek V4 Flash 0731：多數供應商會遵守設定，但請看看 digitalocean、gmi-cloud、mancer 和 venice。
請針對每一家供應商追蹤你的 effort 設定實際產生了多少推理 token。
4. 量化篩選並不能替你換來品質
OpenRouter 允許依供應商宣稱的精度進行篩選，例如 quantizations: ["fp8"]（而非 fp4）。直覺上，位元越少，模型就越笨。我曾在 DeepSeek 上使用這個篩選條件一個月，之後把各供應商基準排行榜與各家自行宣告的精度並排比較：
DeepSeek V4 Flash 0731：依宣告量化方式區分的 GPQA Diamond
fp4（5 家）
Reka AI：89.1%
Inceptron：87.9%
AtlasCloud：88.3%
Relace：87.2%
Sail Research：70.8%
fp8（11 家）
Baseten：88.0%
NextBit：89.9%
SiliconFlow：90.0%
NovitaAI：89.3%
GMICloud：89.0%
Parasail：89.0%
Baidu Qianfan：89.6%
CoreWeave：87.1%
DeepInfra：89.2%
StreamLake：87.8%
OpenInference：70.5%
bf16（1 家）
Morph：85.8%
未知（10 家）
Fireworks：88.9%
DeepSeek：90.2%
Alibaba Cloud Int.：89.4%
Cloudflare：88.4%
Phala：88.2%
Together：86.9%
Venice：86.8%
Wafer：84.1%
Makora：86.9%
DigitalOcean：75.3%
45%
55%
65%
75%
85%
95%
DeepSeek V4 Flash 0731：依宣告量化方式區分的 TAU-Bench Airline
fp4（5 家）
Reka AI：75.4%
Inceptron：74.1%
AtlasCloud：73.6%
Relace：71.7%
Sail Research：75.2%
fp8（10 家）
NextBit：76.6%
SiliconFlow：75.4%
NovitaAI：76.0%
GMICloud：75.8%
Parasail：75.4%
Baidu Qianfan：74.8%
CoreWeave：76.0%
DeepInfra：73.9%
StreamLake：74.9%
OpenInference：70.8%
bf16（1 家）
Morph：74.9%
未知（9 家）
DeepSeek：81.3%
Alibaba Cloud Int.：76.8%
Cloudflare：75.0%
Phala：74.5%
Together：75.0%
Venice：74.2%
Wafer：76.0%
Makora：71.7%
DigitalOcean：58.4%
55%
65%
75%
85%
95%
GLM 5.3 Flash：依宣告量化方式區分的 GPQA Diamond
fp4（1 家）
DeepInfra：87.3%
fp8（14 家）
CoreWeave：85.1%
Baseten：84.3%
Z.ai：87.0%
Parasail：85.8%
NextBit：85.9%
StreamLake：88.2%
NovitaAI：85.5%
GMICloud：85.7%
Modal：83.0%
SiliconFlow：83.3%
Reka AI：86.7%
Morph：84.6%
io.net：73.6%
Sail Research：50.7%
bf16（0 家）
未知（8 家）
DigitalOcean：89.6%
Together：86.4%
Makora：78.0%
Venice：89.0%
Fireworks：86.1%
Friendli：84.4%
Wafer：90.2%
Cloudflare：84.4%
45%
55%
65%
75%
85%
95%
GLM 5.3 Flash：依宣告量化方式區分的 TAU-Bench Airline
fp4（1 家）
DeepInfra：73.3%
fp8（9 家）
Z.ai：73.2%
Parasail：74.0%
NextBit：70.3%
StreamLake：76.0%
NovitaAI：77.9%
GMICloud：75.5%
Modal：78.6%
Reka AI：75.0%
Morph：74.7%
bf16（0 家）
未知（7 家）
DigitalOcean：73.3%
Together：75.0%
Venice：74.2%
Fireworks：73.9%
Friendli：74.8%
Wafer：80.0%
Cloudflare：74.6%
55%
65%
75%
85%
95%
每個點代表一家供應商。排行榜分數與宣告的量化方式皆取自 OpenRouter，日期為 2026-09-07。當天有出現在排行榜、卻未出現在端點清單中的供應商（DeepSeek 7 家、GLM 1 家）未列入。
fp4 託管商的成績落在 fp8 群體中段。DeepSeek 的三個最差 GPQA 成績分別來自 fp4、fp8，以及一家未宣告精度的供應商。GLM 在兩項基準測試中表現最佳的 Wafer，根本沒有宣告精度。精度不是品質的可靠替代指標；硬性篩選還會縮小 OpenRouter 在供應商故障時可切換的備援池。應該依排行榜篩選，而不是依位元數。
5. 工具呼叫藏在文字裡
理想情況是：模型以某種標記格式輸出呼叫，供應商的解析器把它轉成結構化工具呼叫，接著我的程式碼執行它。但有時解析器會漏掉，回覆就會變成這樣：
<use_skills><parameters>{"skills":["search"]}</parameters></use_skills>
而且不同供應商發生的頻率差異非常大。
你會頻繁、頑固地碰到這種情況，最後不得不在自己這端開始解析。需要以相反方式處理的情況有兩種：被標記包住的工具呼叫，以及被完整或部分標記包住的一般回覆。如果想看我針對 DeepSeek／GLM 寫的一些解析範例，可以讓你的代理參考 github.com/0xmmo/190proof。
6. 200 OK，卻沒有答案
推理模型有時會把所有內容都放進 reasoning 欄位，然後回傳 content: null、finish_reason: "stop"。用了 345 個 completion token、HTTP 200，卻沒有任何東西能顯示給使用者。
200 只表示請求已被服務，不代表回覆裡真的有答案。若沒有 content、也沒有工具呼叫，就應視為失敗，丟出錯誤並重試。
7. 空殼 completion
這和上一種情況相關，但不完全相同。有些端點會回傳 200，同時 content 為 null、reasoning 為 null，甚至連 usage 物件都沒有。七月時，DeepSeek 上的 StreamLake 就是如此：它約占我的流量 20%，卻占空白 completion 的 92%。一個月後，Together 在 DeepSeek 0731 checkpoint 上也出現同樣問題。
8. 相同模型，不同的歷史訊息規則
DeepSeek 在思考模式下會輸出 reasoning_content 區塊。在代理迴圈中，模型常會在推理內容為空時呼叫工具。如果你把這段空白的推理歷史傳回 OpenRouter，而請求被路由到例如 SiliconFlow，它會回傳 400、錯誤碼 20015：「The reasoning_content in the thinking mode must be passed back to the API」（思考模式中的 reasoning_content 必須傳回 API）。Baidu、Alibaba 和 Cloudflare 卻能毫無異議地接受完全相同的歷史訊息。
所以，這份契約不是以模型為單位，而是以供應商為單位。也別以為可以省略工具歷史，否則模型會持續重試同一項任務。只是又多一件要處理的事情罷了。
9. 從生產環境測試，而不是你的筆電
這不只關乎速度與延遲。舉例來說：在我的 Mac 上，Venice 和 Novita 執行 DeepSeek V4 Flash 都非常正常；但從我的基礎設施發出探測請求時，幾乎每次都回傳 429。使用的是同一把金鑰、同一分鐘。我推測它們會依 IP 限流。
請從真正執行生產環境的地方做基準測試；每次少量執行，並採集比你直覺認為所需更多的樣本。
10. 為什麼不乾脆固定單一供應商？
我一度設定 provider.order: [cloudflare, baidu, alibaba]，並搭配 allow_fallbacks: false。也就是說，我固定的不是一家，而是三家不同且可靠的供應商。兩週後，Baidu 開始對所有請求限流（429）；Cloudflare 被發現已完全不再提供那個模型；於是 100% 的流量都落到 Alibaba，接著 Alibaba 也開始回傳 429。OpenRouter 排名第一的模型（DeepSeek V4 Flash）固定到三家最可靠的供應商後，現在整個服務仍然掛了，Olly 也一起掛了。
祝你狩獵愉快。
Hacker News 網友反應整理
討論來源：So you want to use OpenRouter?｜Hacker News（整理時顯示 724 points、194 則留言）
整體風向
多數有實際使用經驗的留言者認為，文章描述的供應商差異與不穩定問題確實存在，而且通常比預期嚴重。常見案例包括工具呼叫失敗、回覆中斷、空白 completion、推理內容洩漏到一般對話、圖片輸入失效、嚴重降速，以及同一模型在不同供應商間表現大幅波動。不少人表示，這篇文章終於解釋了先前被誤認為是模型、提示詞或應用程式本身造成的異常。
但討論並非一面倒否定 OpenRouter。另一派認為，OpenRouter 的核心價值本來就不是保證所有供應商完全等價，而是提供統一 API、單一餘額、集中式紀錄與政策管理，以及快速切換模型與供應商的能力。對個人開發、模型探索和快速基準測試而言，這些便利仍很有吸引力。
主要爭論：OpenRouter 應該只是介面，還是品質把關者？
- 批評方認為，OpenRouter 的宣傳重點是更好的價格、上線率與自動路由；如果使用者仍需自行逐一測試、封鎖或固定供應商，甚至自行處理 fallback，那麼中介層最重要的承諾並未實現。
- 辯護方認為，統一介面本身已經很有價值。不同供應商的推論堆疊與功能支援原本就不可能完全一致；認真的生產部署本來就應建立符合自身工作負載的 eval，再固定通過測試的模型與供應商。
- 折衷觀點是：OpenRouter 很適合探索、比較與集中管理，但不能被視為「隨機挑一家也會得到相同結果」的透明商品市場。抽象層降低了切換成本，卻沒有消除底層差異。
網友分享的實務問題
- 固定供應商仍是主流做法
- 快取會顯著影響成本
- 問題不只來自權重量化
- 視覺模型比純文字更容易踩雷
- 速度、上線率與品質不能分開看
社群提出的生產環境做法
- 為自己的真實任務建立小型 eval，而不是只依賴通用排行榜。
- 定期對「模型 × 供應商 × 設定」組合執行測試，檢查正確率、延遲、工具呼叫、結構化輸出、圖片支援與快取。
- 在正式環境使用 allowlist，選出少數候選供應商；路由時同時考慮品質、延遲、價格與可用性。
- 將空白內容、缺少工具呼叫、無 usage、異常短回覆和重複迴圈視為失敗，並自行建立 retry／fallback 邏輯。
- 保存每次請求實際使用的供應商與推論設定，否則異常發生後很難追查。
- 對研究或高一致性任務，應仔細驗證託管推論堆疊；部分留言者最後選擇租用 GPU 自行執行模型。
OpenRouter 團隊的回應
OpenRouter 共同創辦人兼營運長 Chris Clark（HN 帳號 numlocked）加入討論，表示團隊同時追求兩個有時互相衝突的目標：一方面讓大量供應商的容量能「直接運作」，另一方面保留價格、效能、資料政策、地區與硬體等多樣選擇。
團隊回覆的重點包括：
- OpenRouter 會持續在正式端點上執行基準測試，監控中位表現，並把偏離超過標準差的供應商移出預設路由池。
- 圖片無法解析、reasoning effort 失效、工具呼叫解析錯誤、空白 completion 與歷史訊息相容性等案例將進一步調查或修正。
- 團隊已即時監控工具呼叫解析問題，並透過 Auto Exacto 嘗試避開經常失敗的供應商。
- 官方不建議依量化格式篩選供應商，因為品質退化經常發生在權重之外的推論軟體堆疊。
- 官方否認 OpenRouter 自身會依 IP 限流，並希望取得更多重現資訊。
- 團隊正在導入面向生產應用的 QoS 等級，也承認目前客服人力不足。
- 另一位負責供應商合作的團隊成員表示，DeepInfra 的圖片測試在端點上線時曾正常、之後卻失效，顯示這些能力需要持續而非只在上線時驗證。
文章作者則回覆，OpenRouter 對其業務不可或缺；本文原意是提供技術參考，而不是全面否定服務。OpenRouter 團隊也表示，這類具體測試結果對改善路由非常有價值。
其他延伸討論
- 有人主張正式產品應直接整合模型供應商，以取得較高 rate limit、更可靠的快取與完整的供應商特有功能；也有人認為維護多組帳號、金鑰、餘額與介面本身就是不小的成本。
- 社群提到 Requesty、Vercel AI Gateway、Merge AI Gateway、自建路由器與直接使用 Fireworks 等替代方案，但也有人提醒：只要仍是跨多家第三方推論服務的聚合層，類似問題就可能再次出現。
- 除推論品質外，留言還討論了客服回應速度、餘額到期、API 金鑰限制、ZDR 是否可驗證，以及支出上限在大量並發請求下是否可靠等營運問題。
小結
社群最接近共識的結論是：OpenRouter 很適合統一存取、快速試驗與集中管理，但生產使用者仍必須把供應商視為會變動的獨立執行環境，而不是完全可互換的商品。真正可靠的做法不是只選模型，而是持續評估整個「模型、供應商、推論框架與參數」組合。