OpenRouter 重建供應商路由，提升推理速度與可靠度
How we rebuilt provider routing for better, faster inference
OpenRouter 重新設計供應商路由演算法，提升推理速度與可靠度。
- - TTFT 減少 16.9%，平均 837 ms。
- - 吞吐量 上升 16.3%，平均 72.6 tok/s。
新演算法顯著提升推理速度與可靠度，成本僅微幅上升，對開發者可直接使用，無需改寫程式碼，並可即時觀測效能變化
今天，我們宣佈自 OpenRouter 成立以來，提供商路由演算法最大的改進。
迄今為止，我們的預設路由器主要以低價格為唯一考量，獎勵提供商。新的路由器則獎勵真正最適合您的推論：便宜、快速、高吞吐量且可靠。提供更多價值的供應商自動獲得更多流量，讓每位供應商都有動力持續改進。這意味著您透過 OpenRouter 取得的推論將持續更快、更可靠、更具成本效益，且不必改動任何程式碼。
已經在運作中。新演算法已解鎖 TTFT（16.9%）、吞吐量（16.3%）和容量錯誤（驚人 67% 減少！）的顯著提升，成本僅略微上升（6.0%）。這是在供應商有機會為新演算法做最佳化之前的資料。請參閱我們完整的 實驗結果 以獲取更多細節。
工作原理：
- 它測量您實際得到的內容。 對於每個模型，它追蹤每個端點的實際價格、延遲、吞吐量和錯誤率，並為每個請求挑選成本與效能的最佳組合。
- 它即時回應。 當某個端點遇到問題時，流量會離開該端點，直到其恢復。
- 它獎勵更優的推論。 創新的供應商會自動獲得更多流量。
路由仍具備快取感知功能，故一旦我們將您指派至某個供應商，只要快取仍熱，您的會話將保持不變。
想要僅以價格為基準的路由？您仍可選擇。請參閱 什麼保持不變 中的供應商固定與排序。
我們之前的位置：僅以價格為基準路由的侷限性
OpenRouter 上大部分流量（約 77% 的請求）會送往由多家供應商提供的模型。當請求未包含明確的排序或供應商清單時，我們需要挑選一個供應商進行處理。迄今為止，我們幾乎完全依據輸入代幣價格來做此決定。價格越低的供應商會獲得越多流量，任何失敗的請求都會重新導向至下一個最便宜的選項。
這種僅以價格為基準的方法為使用者帶來了生態系中最低的價格，但也產生了一些未預期的後果：
- 即使品質差，便宜仍佔優勢。 回退機制捕捉失敗，但使用者仍需等待，速度提升未得到獎勵。
- 靜態排名。 演算法對即時效能變化視而不見，導致供應商必須降至完全被降級的程度才會在流量分配中反映。
- 邊際消失。 供應商唯一能夠獲得流量的方式是削價，這迫使他們削減對確保可靠性與品質的基礎設施投資。
- 定價遊戲。 我們所排名的價格幾乎全是提示輸入價格，供應商因此能以奇怪的定價組合維持流量份額，例如以人為低的輸入價格列示，然後以高價的快取或完成代幣彌補差額。
我們希望確保一個市場，競爭的供應商能透過提供更優的推論贏得流量，而非僅僅是更便宜的推論。
新演算法：最佳化為什麼好的答案“costs”
新的路由演算法會持續監控每個供應商的表現，以計算即時的路由成本（Routing Cost），該成本反映使用者為得到一個好答案所付出的費用。路由成本包含實際美元與美分的價格、等待回應所耗費的時間成本，以及在供應商失敗或回傳無效答案時重試的成本。
簡單來說：一次嘗試的成本是多少，且它成功的頻率是多少？
一次嘗試的成本：價格加等待
對於每一次請求，路由器會估算它將從模型最近流量中使用的輸入與輸出 token 數量。這一估算決定了嘗試的兩個部分：你將支付的價格以及你需要等待的時間。
實際價格
實際價格是供應商實際會向你收取的費用，根據最近測量的流量計算。它反映供應商的實際快取命中率以及模型輸入與輸出 token 的平均組合，因此可能與標價相差很大。這樣可以確保供應商無法藉由將昂貴的快取或輸出 token 藏在低輸入價格後面來獲得流量。
路由器以每個供應商的實際價格為你的請求定價，並優先選擇最便宜的選項。
吞吐量
吞吐量是與價格相互折衷的指標：較快的供應商可以收取更高費用，仍能贏得你的請求。它以每秒輸出 token 數量來衡量，涵蓋首個 token 的等待時間以及供應商流式傳輸完整輸出回應所需的時間。路由器會將該等待時間以每個模型設定的轉換率加入路由成本，轉換率基於供應商通常的收費與速度。
首個 token 的時間
首個 token 時間（TTFT）是你在回應開始流式傳輸前需要等待的時間。它獨立於吞吐量計算加入路由成本，因為互動式使用最依賴此時間。於代理機會話中，模型可能連續發出多個工具呼叫，每一次都會等待首個 token。
速率限制
速率限制（HTTP 429）表示供應商已達到容量上限並拒絕你的請求。你必須等待被拒絕後，整個請求才會轉到另一個供應商。路由器會將該等待時間及懲罰加入供應商的路由成本，並根據該供應商對請求的速率限制頻率進行加權，通常影響較小。重複的速率限制會在以下所述的流量上限與退避中產生更大影響。
成功頻率：可靠性與品質
一次失敗的嘗試仍會產生其價格與等待成本，因此路由成本會計算為了得到一次成功答案所需重試的預期成本。若每 5 次嘗試中有 1 次失敗，你實際上需要為每個好答案支付 1.25 次嘗試的費用。
可靠性
可靠性錯誤是因供應商失敗而導致的請求。你會失去這次嘗試並必須重試，因此每一次錯誤都會在路由成本中帶來較重的懲罰。
若某供應商對同一模型的錯誤率遠高於其他供應商，路由器會停止向其傳送請求，直至其恢復。
品質
品質衡量供應商回應是否可用。今日主要檢查是工具呼叫是否以正確格式回傳，且我們正加入更多檢查。每一次不良回應都會提升供應商的路由成本，因為便宜但錯誤的答案實際上成本高昂。
被標記為工具呼叫失效或基準準確度遠低於模型應有分數的供應商，將大幅落後，只會收到少量測試流量，直至標記解除。
將所有請求送往單一最佳供應商會導致其過載，因此流量會被分攤。速度更快的供應商可以承載更高的 Routing Cost 並保持競爭力。所有位於 競爭優勢 內的供應商共享大部分流量，稍微落後於最佳供應商只會略微增加成本。越過這個邊緣，流量分配會迅速下降。
三項保護措施位於頂部：
- Floor: 每個供應商都保留少量流量，這樣我們能觀察到陷入困境的端點是否改善。新端點從模型的典型數值開始，因此不需要流量歷史。
- Back off: 當供應商開始失敗或被速率限制時，其流量會逐漸減少，直至恢復。
- Cap: 路由器會學習每個供應商在返回 429 之前能承受的負載，並將剩餘流量分配給其他供應商。增加容量後，上限會自行提升。
保持不變的部分
- 設定
provider.order的請求將繞過新的路由邏輯，供應商按指定順序排列（預設仍以價格為基準）。設定provider.only或provider.ignore時，若剩餘多於一個供應商，將使用新演算法選擇。 - 明確設定
provider.sort（price、throughput或latency）時，會使用該排序方式，而非新演算法。 - 只有對話中的第一個請求會由演算法選擇供應商。後續對話將固定在原始供應商，以保持提示快取熱度。若該供應商不可用，對話會自動回退到其他供應商。
- 若嘗試失敗，請求將使用排名次高的供應商重試。
我們如何測量
為了測量新路由演算法的影響，我們必須超越傳統的 A/B 測試，因為路由行為的變化難以與對照組隔離。例如，如果新演算法更有效地將流量從表現不佳的供應商分流，舊演算法對該供應商的請求將發現更多容量可用並加速，從而扭曲結果。難度進一步加劇的是請求形態與量級模式的巨大變異。一位大型使用者如果自動產生大量高負載請求至單一供應商，無論使用哪種演算法，都可能人工提升該供應商的指標。
因此我們進行了切換回實驗：將每天分成 3 小時區塊，並在每對匹配區塊之間切換新舊路由器，每次切換時都設定一小時的燃燒期（丟棄資料），並在整整一週內測量代表性開源模型的每模型影響。
結果
在實驗週期內，我們將超過 2400 萬筆請求（共 1030 億個輸入 token）平均分配給舊版與新版路由演算法，並測量關鍵績效指標的影響。
| 測量專案 | 舊版 | 新版演算法 | 新版 vs 舊版 | 95% 可信區間 |
|---|---|---|---|---|
| TTFT p50 | 1,007 ms | 837 ms | 下降 16.9% | 下降 13.9% 至 19.8% |
| TTFT p95 | 4,601 ms | 3,733 ms | 下降 18.9% | 下降 15.7% 至 21.9% |
| Throughput p50 | 62.4 tok/s | 72.6 tok/s | 提升 16.3% | 提升 13.8% 至 18.9% |
| Cost per K requests | $1.25 | $1.32 | 提升 6.0% | 提升 5.1% 至 7.0% |
| Cost per M tokens | $0.301 | $0.324 | 提升 7.3% | 提升 4.9% 至 9.6% |
| Caller TTFT p50 | 1,130 ms | 941 ms | 下降 16.7% | 下降 13.8% 至 19.7% |
| Caller TTFT p95 | 6,032 ms | 4,504 ms | 下降 25.3% | 下降 21.6% 至 29.0% |
| 整體請求 p50（到最後一個 token 的時間） | 4.00 s | 3.24 s | 19.0% 較低 | 14.2% 至 23.6% 較低 |
| 整體請求 p95 | 41.5 s | 34.9 s | 16.0% 較低 | 12.2% 至 19.7% 較低 |
| 至少一次 429 錯誤 | 7.1% | 3.8% | −3.4 pt 67% 更少 | −4.2 至 −2.5 pt 62% 至 72% 更少 |
| 需要重試 | 10.4% | 6.9% | −3.5 pt 47% 更少 | −4.4 至 −2.6 pt 41% 至 52% 更少 |
| 每請求失敗嘗試所花時間 | 349 ms | 242 ms | −106 ms 55% 更少 | −181 至 −35 ms 48% 至 60% 更少 |
開始使用
如果你使用預設路由，則已完成。每個請求所使用的服務提供者資訊會顯示在回應中以及你的使用情況頁面。
要保留舊的僅價格路由，請將 provider.sort 設為 "price"，在模型 slug 加上 :floor，或在 帳戶設定 將預設排序設為價格。若要自行選擇供應商，請使用 provider.order 或 provider.only。請參閱 供應商路由指南。
常見問題
我需要修改程式碼才能使用新的路由嗎？
不需要。若請求未明確指定 provider sort、provider order、only 或 ignore 列表，則在已啟用的新路由模型上會自動使用新路由。你的 API 金鑰、請求內容與模型 ID 不變。
如何保持僅按價格路由？
在請求內容中將 provider.sort 設為 price，或在模型 slug 後追加 :floor，或在帳戶設定中將預設 provider sort 設為 price。任何明確的排序都會繞過新路由。
新的路由是否會覆蓋我的 provider order 或 only 列表？
provider.order 會繞過新路由，按你指定的順序進行路由。provider.only 與 provider.ignore 仍會過濾候選集，但新演算法會在剩餘的提供者中選擇。
新的路由會比僅按價格路由更貴嗎？
可能會，因為它有時會選擇速度更快或更可靠的服務提供者，而非最便宜的。在我們的實驗中，每請求成本上升 6.0%，但 TTFT 提升 16.9%，吞吐量提升 16.3%，429 錯誤率下降 67%。
在新的路由下，服務提供者如何獲得更多流量？
提升路由器評分的訊號：有效價格、首個 token 的時間、吞吐量、錯誤與速率限制率，以及輸出品質。