OpenRouter 重建提供商路由算法，兼顾价格、速度与可靠性

今天，我们宣布对 OpenRouter 自成立以来对提供商路由算法所做的最大改进。

此前，我们的默认路由器主要只奖励提供商一件事：低价格。新的路由器奖励的是对你来说真正最优的推理：便宜，同时快速、高吞吐且可靠。能提供更多价值的提供商会自动获得更多流量，因此每个提供商都有理由持续改进。这意味着你通过 OpenRouter 获得的推理会越来越快、越来越可靠、越来越划算，而你无需改动一行代码。

它已经见效了。新算法带来了显著改善：TTFT（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）是响应开始流式传输之前你需要等待的时长。它单独计入路由成本，尽管它已经计入吞吐量，因为交互式使用最依赖它。在智能体会话中，模型可能连续发起多次工具调用，每一次都要等待首 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)

成功的频率：可靠性与质量

一次失败的尝试仍然要付出其价格和等待时间，因此路由成本会计算必须重试直到成功为止的预期成本。如果每 5 次尝试中有 1 次失败，那么每个优质答案你需要为 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 小时的时间块，在每对匹配的时间块之间切换新路由器和旧路由器，每次切换后丢弃一小时的预热数据，并在整整一周内对具有代表性的开源模型样本衡量每个模型的影响。

结果

在实验进行的一周内，我们在旧路由算法和新路由算法之间均匀分配了超过 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%
吞吐量 p50	62.4 tok/s	72.6 tok/s	提高 16.3%	提高 13.8% 至 18.9%
每千次请求成本	$1.25	$1.32	提高 6.0%	提高 5.1% 至 7.0%
每百万 token 成本	$0.301	$0.324	提高 7.3%	提高 4.9% 至 9.6%
调用方 TTFT p50	1,130 ms	941 ms	降低 16.7%	降低 13.8% 至 19.7%
调用方 TTFT p95	6,032 ms	4,504 ms	降低 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。参见提供商路由指南。

常见问题

我需要修改代码才能使用新路由吗？

不需要。未显式指定提供商排序、也未设置提供商 order、only 或 ignore 列表的请求，会在已启用新路由的模型上自动使用新路由器。你的 API 密钥、请求体和模型 ID 均保持不变。

如何保留仅按价格路由？

在请求体中将 provider.sort 设为 price，在模型 slug 后追加 :floor，或在账户设置中将默认提供商排序设为价格。任何显式排序都会绕过新路由器。

新路由会覆盖我的提供商 order 或 only 列表吗？

provider.order 会绕过新路由器，并按你指定的顺序路由。provider.only 和 provider.ignore 仍会过滤候选集合，但新算法会在剩余的提供商中进行选择。

新路由会比仅按价格路由花费更高吗？

可能会，因为它有时会选择更快或更可靠的提供商，而不是最便宜的。在我们的线上实验中，每个请求的成本增加了 6.0%，同时 TTFT 改善了 16.9%，吞吐量改善了 16.3%，429 错误率降低了 67%。

在新路由下，提供商如何获得更多流量？

改善路由器评分的各项信号：有效价格、首 token 时间、吞吐量、错误率和限流率，以及输出质量。