OpenRouter 重建提供商路由算法，TTFT 降低 16.9%

今天，我们宣布对 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。请参阅提供商路由指南。

常见问题

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

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

如何保留仅按价格路由？

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

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

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

新路由会比仅按价格路由成本更高吗？

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

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

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