OpenRouter 如何重建供應商路由，提升推理速度與表現

今天我們宣佈，自 OpenRouter 成立以來，供應商路由演算法迎來最大幅度的改進。

至今，我們的預設路由器主要按一個條件獎勵供應商：價格低。新路由器會優先採用真正最適合你的推理服務：價格實惠，同時快速、吞吐量高而且可靠。提供更多價值的供應商會自動獲得更多流量，令每家供應商都有動力持續改進。因此，透過 OpenRouter 取得的推理服務會愈來愈快、愈可靠、成本效益愈高，而你毋須更改任何程式碼。

新演算法已經見效：TTFT（首個 token 延遲）改善了 16.9%，吞吐量提升 16.3%，容量錯誤大幅減少 67%，而成本只輕微增加 6.0%。這些改善都發生在供應商有時間針對新演算法進行最佳化之前。詳情請參閲我們的完整實驗結果。

運作方式：

衡量你實際取得的服務。對每個模型，演算法會追蹤各端點實際收取的價格、延遲、吞吐量及錯誤率，並為每個請求選出成本與效能的最佳組合。
即時回應狀況。端點出現問題時，流量會轉往其他端點，直至該端點恢復正常。
獎勵更出色的推理服務。勇於創新的供應商會自動獲得更多流量。

路由仍會考慮快取狀態；一旦我們把你導向某家供應商，只要快取仍然有效，你的工作階段就會繼續使用該供應商。

想只按價格路由？仍然可以。請參閲「維持不變的內容」，瞭解如何固定和排序供應商。

過往做法：只按價格路由的限制

OpenRouter 的大部分流量（約 77% 的請求）都流向由多家供應商提供服務的模型。如果請求沒有明確指定排序方式或供應商清單，我們就要選擇一間供應商來處理。至今，我們幾乎完全按輸入 token 價格作選擇。供應商收費愈低，獲得的流量比例就愈高；請求失敗時，系統會重新路由到下一個最便宜的選項。

只按價格的做法雖然讓用戶取得整個生態系統中最低的價格，卻也帶來一些意料之外的後果：

便宜即勝，即使品質欠佳。備援供應商能接手失敗請求，但用戶仍要等待；而速度提升也不會獲得獎勵。
排名固定不變。演算法看不到即時效能的變化，因此供應商必須先退步到完全被降級，流量分配才會反映出來。
利潤空間消失。供應商要取得流量，唯一方法就是減價，這會迫使他們削減對確保可靠性和品質的基礎設施投資。
價格策略遊戲。我們用來排名的價格幾乎只有提示輸入價格，因此供應商可以透過奇怪的定價組合保住流量份額，例如刻意把輸入價格定得很低，再以過高的快取或生成 token 價格賺回差額。

我們希望建立一個市場，讓供應商靠提供更好的推理服務，而不只是更便宜的推理服務來取得流量。

新演算法：以優質答案的「成本」作最佳化

新的路由演算法會持續監察各家供應商的效能，計算即時路由成本（Routing Cost），以反映用戶為取得優質答案實際付出的代價。路由成本涵蓋實際金額、等待回覆所花的時間，以及供應商失敗或提供無法使用的回覆時所需重試的成本。

簡單來説：每次嘗試要花多少成本？成功的機會又有多大？

Diagram: cost of one try, $0.40 price plus 0.60 waiting, is 1.00. Divided by an 80% chance it works, that is a Routing Cost of 1.25 per good answer. Lower wins more traffic. (light mode)

Diagram: cost of one try, $0.40 price plus 0.60 waiting, is 1.00. Divided by an 80% chance it works, that is a Routing Cost of 1.25 per good answer. Lower wins more traffic. (dark mode)

每次嘗試的成本：價格加上等待時間

對每個請求，路由器會根據模型近期的流量估算所需的輸入和輸出 token 數量。這個估算同時決定一次請求的兩項成本：你要支付的價格，以及需要等待的時間。

實際價格

實際價格是供應商根據近期實測流量向你收取的價格。它反映供應商真正的快取命中率，以及模型輸入和輸出 token 的平均組合，因此可能與價目表相差甚遠。這可避免供應商把昂貴的快取或輸出 token 藏在低輸入價格之後，藉此取得流量。

Chart of average input and output tokens per request by prompt size, on log scales. As prompts grow from about 370 to 670K input tokens, output only grows from about 190 to 1,050 tokens, so input goes from 2 times output to 8 times at 5.7K input tokens, 90 times at 93K, and 630 times at 670K. (light mode)

Effective price example: 40K uncached input tokens at $2.00/M is $0.080, 60K cached input tokens at $0.50/M is $0.030, and about 4K output tokens at $8.00/M is $0.032, for an effective price of $0.142 for one request. (light mode)

路由器會按每家供應商的實際價格為你的請求估價，並優先選擇最便宜的選項。

吞吐量

吞吐量是價格以外的另一個取捨因素：速度較快的供應商即使收費較高，仍有機會取得你的請求。吞吐量以端到端每秒輸出的 token 數量衡量，因此包括等待首個 token 的時間，以及供應商串流輸出完整回覆所需的時間。路由器會按模型設定的換算率，把這段等待時間計入路由成本；換算率取決於該模型的供應商通常收取多少費用，以及速度有多快。

Throughput example: a 5 second time to first token plus 500 tokens streamed in 5 seconds is 50 tokens per second end to end, with the time to first token included. (light mode)

Throughput example: a 5 second time to first token plus 500 tokens streamed in 5 seconds is 50 tokens per second end to end, with the time to first token included. (dark mode)

首個 token 延遲

首個 token 延遲（TTFT）是指你要等多久才會開始收到串流回覆。即使這段時間已計入吞吐量，它仍會獨立增加路由成本，因為互動式使用尤其受它影響。在 agent 工作階段中，模型可能要連續呼叫多個工具，每次呼叫都要先等到首個 token。

An agent session: reasoning, then five tool calls, then more reasoning and the response. Each step waits for a first token, so the tool calls are mostly waiting on time to first token. (light mode)

An agent session: reasoning, then five tool calls, then more reasoning and the response. Each step waits for a first token, so the tool calls are mostly waiting on time to first token. (dark mode)

速率限制

速率限制（HTTP 429）表示供應商容量不足，因而拒絕了你的請求。你要先等候這次拒絕，之後整個請求才會送往另一家供應商。路由器會把等待時間和懲罰一併計入該供應商的路由成本，並按它限制請求的頻率加權，因此通常影響不大。下文所述的流量上限和退避機制，會讓持續出現的速率限制造成更大影響。

A 429 makes you wait for the rejection, then your full request goes elsewhere. Example: a 2.50 wait plus penalty times a 0.4% 429 rate adds 0.01 to the Routing Cost. (light mode)

A 429 makes you wait for the rejection, then your full request goes elsewhere. Example: a 2.50 wait plus penalty times a 0.4% 429 rate adds 0.01 to the Routing Cost. (dark mode)

成功的頻率：可靠性與品質

一次失敗的嘗試仍會產生價格和等待時間，因此路由成本會計算直到成功為止、預期需要重試的成本。若有 1 次失敗出現在 5 次嘗試之中，取得一個成功答案平均要支付 1.25 次嘗試的費用。

可靠性

可靠性錯誤是由供應商引致的請求失敗。你會浪費這次嘗試並需要重試，因此每次錯誤都會令路由成本大幅增加。

Reliability example: a 1% error rate times an 8x penalty per error raises the Routing Cost by about 8%. (light mode)

Reliability example: a 1% error rate times an 8x penalty per error raises the Routing Cost by about 8%. (dark mode)

如果某供應商對同一模型的錯誤率遠高於其他供應商，路由器就會停止向它發送請求，直至它恢復正常。

品質

品質用來衡量供應商的回覆是否可用。目前主要檢查工具呼叫的格式是否正確，我們也正在加入更多檢查。每個不良回覆都會提高供應商的路由成本，因為便宜但錯誤的答案代價很高。

Quality example: 95% of tool calls well formed raises the Routing Cost by about 5%. (light mode)

Quality example: 95% of tool calls well formed raises the Routing Cost by about 5%. (dark mode)

如果供應商因工具呼叫格式錯誤，或基準測試準確度遠低於模型應有水平而被標記，它的排名就會大幅下降；在標記解除前只會獲得少量測試流量。

如果把每個請求都送往唯一最佳供應商，它會不堪負荷，因此流量會分散分配。速度較快的供應商即使路由成本較高，仍然可以保持競爭力。位於競爭區間內的供應商會分得大部分流量，排名稍遜於最佳者只會少量減分。超出這個區間後，流量份額便會迅速下降。

另外設有三項護欄：

Diagram of requests flowing to three providers. A is at its cap, so the extra spills over to other providers. B is struggling, so it gets less. C is furthest behind but still gets a trickle. (light mode)

最低流量：每家供應商都會保留少量流量，讓我們察覺效能欠佳的端點何時改善。新端點會以該模型的典型數據作起點，因此不需要先累積流量紀錄。
退避：供應商開始出錯或觸發速率限制時，分配給它的流量會減少，直至恢復正常。
上限：路由器會瞭解各供應商可承受多少負載，才會開始回傳 429 錯誤，並把超出的請求分配給其他供應商。增加容量後，上限會自動提高。

維持不變的內容

設定 provider.order 的請求會略過新的路由邏輯，並按指定次序選擇供應商（預設仍與以往一樣按價格排序）。設定 provider.only 或 provider.ignore 時，如果剩餘供應商多於一家，系統會用新演算法從中選擇。
明確設定 provider.sort（price、throughput 或 latency）時，系統會使用該排序方式，而非新演算法。
系統只會為對話中的第一個請求以演算法選擇供應商。為了讓提示快取保持有效，進行中的對話會固定使用原來的供應商。如果該供應商無法使用，對話便會自動轉交另一家供應商。
一次嘗試失敗時，系統會把請求重試並送往排名下一位的供應商。

測量方法

為了衡量新路由演算法的影響，我們不能只用標準 A/B 測試，因為路由行為的變化很難與對照組分開。例如，如果新演算法更善於把流量從效能不佳的供應商轉走，舊演算法送往該供應商的請求就會有更多可用容量，因而變快，令結果出現偏差。請求形態和流量模式極為多變，也進一步增加了測量難度。只要一名高流量用戶向單一供應商發起大量自動化、高運算需求的請求，不論我們採用哪種演算法來路由，都可能人為推高該供應商的指標。

因此我們進行了交替切換實驗：每天分成 3 小時區段，並在每一對配對區段中交替使用新舊路由器；每次切換後先進行一小時預熱，期間的數據不納入計算。整個實驗為期一週，並以具代表性的開源模型樣本衡量各模型所受的影響。

結果

在為期一週的實驗中，我們把超過 24 百萬個請求及 103 十億個輸入 token 平均分配給新舊路由演算法，並衡量對主要效能指標的影響。

指標	舊版	新演算法	新版與舊版比較	95% 區間
TTFT 第 50 百分位	1,007 毫秒	837 毫秒	低 16.9%	低 13.9% 至 19.8%
TTFT p95	4,601 毫秒	3,733 毫秒	低 18.9%	低 15.7% 至 21.9%
吞吐量 p50	62.4 token／秒	72.6 token／秒	高 16.3%	高 13.8% 至 18.9%
每 K 次請求成本	$1.25	$1.32	高 6.0%	高 5.1% 至 7.0%
每 M 個 token 成本	$0.301	$0.324	高 7.3%	高 4.9% 至 9.6%
呼叫端 TTFT p50	1,130 毫秒	941 毫秒	低 16.7%	低 13.8% 至 19.7%
呼叫端 TTFT p95	6,032 毫秒	4,504 毫秒	低 25.3%	低 21.6% 至 29.0%
整個請求 p50（至最後一個 token 的時間）	4.00 秒	3.24 秒	低 19.0%	低 14.2% 至 23.6%
整個請求 p95	41.5 秒	34.9 秒	低 16.0%	低 12.2% 至 19.7%
至少觸發一次 429	7.1%	3.8%	−3.4 個百分點少 67%	−4.2 至 −2.5 個百分點少 62% 至 72%
需要重試	10.4%	6.9%	−3.5 個百分點少 47%	−4.4 至 −2.6 個百分點少 41% 至 52%
每個請求在失敗嘗試上所花的時間	349 毫秒	242 毫秒	−106 毫秒少 55%	−181 至 −35 毫秒少 48% 至 60%

開始使用

如果你使用預設路由，就無須採取任何行動。每個請求由哪家供應商處理，會顯示在回應和活動頁面中。

若要保留舊有的只按價格路由，請把 provider.sort 設為 "price"、在模型 slug 後加上 :floor，或在帳戶設定中把預設排序設為價格。若要自行選擇供應商，請使用 provider.order 或 provider.only。詳情請參閲供應商路由指南。

常見問題

使用新的路由方式需要更改程式碼嗎？

不需要。對於已啟用新路由器的模型，凡未明確指定供應商排序、provider order、only 或 ignore 清單的請求，都會自動使用新路由器。你的 API 金鑰、請求本文和模型 ID 均維持不變。

如何繼續使用只按價格路由？

在請求本文中把 provider.sort 設為 price、在模型 slug 後加上 :floor，或在帳戶設定中把預設供應商排序設為價格。任何明確指定的排序方式都會略過新路由器。

新的路由方式會覆蓋我設定的 provider order 或 only 清單嗎？

provider.order 會略過新路由器，並按你指定的次序路由。provider.only 和 provider.ignore 仍會篩選候選供應商；新演算法則會在剩餘供應商之間作選擇。

新的路由方式會比只按價格路由更貴嗎？

有時會，因為它偶爾會選擇速度更快或更可靠的供應商，而非最便宜的選項。在我們的實際實驗中，每個請求的成本增加了 6.0%，同時 TTFT 改善 16.9%、吞吐量提升 16.3%，429 錯誤率則下降 67%。

供應商如何在新路由方式下取得更多流量？

改善路由器評分時採用的訊號：實際價格、首個 token 延遲、吞吐量、錯誤率和速率限制率，以及輸出品質。