OpenRouter 重建供应商路由算法，推理延迟更低、成本小幅上升

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

直到现在，我们的默认路由器主要只根据一件事来奖励供应商：低价。新的路由器奖励真正对你最好的推理：不仅便宜，还要快速、高吞吐且可靠。提供更多价值的供应商会自动赢得更多流量，因此每家供应商都有理由持续改进。这意味着你通过 OpenRouter 获得的推理会越来越快、越来越可靠、越来越划算，而你无需更改一行代码。

它已经初见成效。新算法带来了 TTFT（16.9%）、吞吐量（16.3%）和容量错误（降幅高达 67%！）的显著改善，而成本仅有小幅上升（6.0%）。而这还是在供应商有时间针对新算法进行优化之前取得的成绩。更多详情请查看我们完整的实验结果。

工作原理：

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

路由仍然具备缓存感知能力，因此一旦我们将你路由到某家供应商，只要缓存仍然有效，你的会话就会保持不变。

想要仅按价格路由？你仍然可以这样做。请参阅保持不变的部分中的固定与排序供应商说明。

过去的状况：仅按价格路由的局限性

OpenRouter 上的大部分流量（约 77% 的请求）都流向由多家供应商共同服务的模型。当请求未包含显式的排序或供应商列表时，我们需要挑选一家供应商来处理它。直到现在，我们做出这一选择的依据几乎完全是输入 token 价格。供应商的价格越低，获得的流量份额就越大，而任何失败的请求都会被重新路由到次便宜的选项。

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

便宜者胜出，即使它表现糟糕。回退机制能够捕获失败，但用户不得不经历漫长的等待，而速度提升也不会得到奖励。
静态排名。算法对实时性能变化视而不见，供应商必须退化到被完全除名的地步，其影响才会体现在流量分配上。
利润空间不断萎缩。供应商赢得流量的唯一途径就是降价，这迫使它们削减对确保可靠性与质量的基础设施的投资。
定价游戏。我们排名所依据的价格几乎全是提示输入价格，因此供应商可以通过奇怪的定价组合来保住流量份额，比如标出人为压低的输入价格，再用定价过高的缓存 token 或补全 token 把差额赚回来。

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

新算法：围绕一个好答案的“代价”进行优化

新的路由算法会持续监控每个提供商的性能，以计算实时的 Routing Cost（路由成本），反映用户为获得一个优质答案所付出的总代价。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 或输出 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 时间，加上提供商流式传输完整输出响应所需的时间。路由器会按每个模型设定的转换率将这段等待时间计入 Routing Cost，该转换率基于其提供商通常的收费和速度而定。

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）是指在响应开始流式传输之前你需要等待的时间。尽管它已经计入吞吐量，但它仍单独计入 Routing Cost，因为交互式使用对它的依赖最大。在 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）意味着提供商容量已满，拒绝了你的请求。你必须等待该拒绝返回，然后你的完整请求才会被发送给另一个提供商。路由器会将这段等待时间加上一个惩罚项计入该提供商的 Routing Cost，权重取决于其速率限制请求的频率，因此影响通常很小。反复出现的速率限制更多是通过下文所述的流量上限和退避机制产生影响的。

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)

成功率有多高：可靠性与质量

一次失败的尝试仍然会产生其价格和等待成本，因此 Routing Cost 会计算必须重试直到成功所需的预期成本。如果每 5 次尝试中有 1 次失败，那么每个优质答案你需要支付 1.25 次尝试的费用。

可靠性

可靠性错误是指因提供商自身原因而失败的请求。你会损失这次尝试并不得不重试，因此每个错误都会在 Routing Cost 中带来沉重的惩罚。

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)

如果某个提供商的错误率远高于同一模型的其他提供商，路由器将停止向其发送请求，直到其恢复。

质量

质量衡量提供商的响应是否可用。目前主要的检查是工具调用返回的格式是否规范，我们正在增加更多检查。每个不良响应都会提高该提供商的 Routing Cost，因为便宜的错误答案代价高昂。

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)

被标记为工具调用损坏、或基准测试准确率远低于模型应有得分的提供商，排名将大幅下滑，并且只能获得少量测试流量，直到标记解除。

把所有请求都发给单一最佳供应商会使其过载，因此流量是共享的。更快的供应商可以承受更高的 Routing Cost 并保持竞争力。竞争边缘以内的所有供应商共享大部分流量，稍微落后于最佳者只会损失一点份额。一旦超出边缘，流量份额就会迅速下降。

在此之上还有三道护栏：

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 测试的方法，因为路由行为的变化无法轻易与对照组隔离开来。例如，如果新算法能更好地把流量从表现不佳的供应商处分流走，那么旧算法发往该供应商的请求就会发现更多可用容量并变得更快，从而使结果产生偏差。让难度进一步加大的是请求形态和数量模式存在巨大差异。单个大客户向单一供应商发起一波自动化高强度请求，无论我们用哪种算法为其请求做路由，都会人为推高该供应商的指标。

因此我们进行了一项 switchback 实验：我们将每天划分为若干 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 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。参见提供商路由指南。

常见问题

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

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

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

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

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

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

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

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

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

提升路由器评分所依据的指标：有效价格、首个 token 时间、吞吐量、错误率和限流率，以及输出质量。