OpenRouter 重建默认路由算法：TTFT 降 16.9%、429 错误减少 67%

今天，我们宣布对提供商路由算法进行自 OpenRouter 成立以来最大的一次升级。

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

它已经见效了。新算法带来了显著改善：TTFT 提升 16.9%，吞吐量提升 16.3%，容量错误大幅减少 67%！而成本仅小幅上升 6.0%。这还是在提供商尚未有时间针对新算法进行优化的情况下取得的。更多细节请查看完整的实验结果。

工作原理：

它衡量你实际得到的东西。对每个模型，它跟踪每个端点的实际价格、延迟、吞吐量和错误率，并为每个请求挑选成本与性能的最佳组合。
它实时做出反应。当某个端点出现问题时，流量会从它那里转移走，直到它恢复。
它奖励更好的推理。进行创新的提供商会自动获得更多流量作为奖励。

路由仍然会考虑缓存，因此一旦我们把你发送到某个提供商，只要缓存还是热的，你的会话就会留在那里。

想要仅按价格路由？仍然可以。请参阅保持不变的部分中关于固定和排序提供商的内容。

我们此前的状况：仅按价格路由的局限

OpenRouter 上的大部分流量（约 77% 的请求）流向由多个提供商提供的模型。当请求没有包含明确的排序或提供商列表时，我们需要选择一个提供商来发送请求。此前，我们几乎完全根据输入 token 价格做出这一选择。提供商越便宜，获得的流量比例就越高，任何失败的请求都会被重新路由到下一个最便宜的选项。

这种仅按价格的方法为用户带来了生态系统中最低的价格，但也产生了一些意想不到的后果：

便宜者胜，哪怕它很差。回退机制能捕获失败，但用户要一直等到回退完成，而且速度上的改进得不到奖励。
静态排名。该算法对实时性能变化视而不见，因此提供商必须退化到被完全降级的地步，才会反映在流量分配中。
利润消失。提供商赢得流量的唯一方式就是降价，这迫使它们减少对确保可靠性和质量的基础设施的投资。
定价游戏。我们用来排名的价格几乎全是提示词输入价格，因此提供商可以通过奇怪的定价组合来保住流量份额，比如列出人为压低的输入价格，然后用定价过高的缓存 token 或补全 token 来弥补差价。

我们希望确保这样一个市场：相互竞争的提供商通过提供更好的推理来赢得流量，而不仅仅是更便宜的推理。

新算法：针对一个好的回答“成本”几何进行优化

新的路由算法会持续监测每个供应商的表现，据此计算出一个实时的路由成本，用来衡量用户为得到一个好答案要付出多少代价。路由成本包含三部分：实际花费的美元金额、等待响应所耗的时间成本，以及供应商失败或返回不可用响应时重试的成本。

简单来说：一次尝试要花多少钱，成功率有多高？

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 或输出 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 平均分配给新旧两种路由算法，测量它们对关键性能指标的影响。

指标	旧版	新算法	新算法对比旧版	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 key、请求体和模型 ID 都保持不变。

如何保留只按价格的路由？

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

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

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

新路由会比只按价格的路由更贵吗？

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

提供商怎样才能在新路由下获得更多流量？

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