Scott Morse · 2026年10月28日
今天，我们宣布对供应商路由算法进行自 OpenRouter 成立以来最大的一次改进。
此前，我们的默认路由器主要只奖励供应商一件事：低价格。新路由器奖励的是对你而言真正最优的推理：便宜，同时也快速、高吞吐且可靠。能提供更多价值的供应商会自动赢得更多流量，因此每个供应商都有理由持续改进。这意味着你通过 OpenRouter 获得的推理会不断变得更快、更可靠、更具成本效益，而你无需改动一行代码。
它已经见效了。新算法在 TTFT（16.9%）、吞吐量（16.3%）和容量错误（显著降低 46%！）方面带来了大幅改善，而成本仅小幅上升（6.0%）。而这还是在 供应商 有任何时间为新算法进行优化之前。查看我们的完整 实验结果 了解更多详情。
工作原理：
- 它衡量你实际获得的效果。 对于每个模型，它会跟踪每个端点的实际价格、延迟、吞吐量和错误率，并为每个请求挑选成本与性能的最佳组合。
- 它实时做出反应。 当某个端点出现问题时，流量会从该端点转移，直到它恢复。
- 它奖励更好的推理。 进行创新的供应商会自动获得更多流量作为奖励。
路由仍然会感知缓存，因此一旦我们将你分配到某个供应商，只要缓存仍然有效，你的会话就会保持在该供应商上。
只想要按价格路由？你仍然可以这样做。请参阅固定和排序供应商 保持不变的部分.
我们此前的状况：仅按价格路由的局限
OpenRouter 上大多数流量（约 77% 的请求）都流向由多个供应商提供的模型。当请求未包含显式排序或供应商列表时，我们需要选择一个供应商来发送请求。到目前为止，我们几乎完全基于输入 token 价格做出这一选择。供应商越便宜，它获得的流量比例就越高，而任何失败的请求都会被重新路由到下一个最便宜的选项。
这种仅按价格的方法为用户带来了生态系统中的最低价格，但也造成了一些意想不到的后果：
- 便宜者胜，即使它表现糟糕。 回退机制捕获了失败，但用户要等待回退完成，而且速度提升并未得到奖励。
- 静态排名。 算法对实时性能变化视而不见，因此供应商必须退化到被完全取消排名的地步，才会在流量分配中体现出来。
- 利润空间消失。 供应商赢得流量的唯一办法就是降价，这迫使它们削减对保障可靠性和质量的基础设施的投资。
- 定价游戏。 我们据以排名的价格几乎全是提示输入价格，因此供应商可以用奇怪的定价组合来保住流量份额，比如标出人为压低的输入价格，再用定价过高的缓存或补全 token 把差价赚回来。
我们希望确保这样一个市场：相互竞争的供应商通过提供更好的推理而非仅仅更便宜的推理来赢得流量。
新算法：以优质回答的“成本”为优化目标
新的路由算法会持续监控每个供应商的性能，以计算实时路由成本，该成本反映用户为获得优质回答所付出的代价。路由成本涵盖以实际美元和美分计的价格、等待响应所花费的时间成本，以及供应商失败或返回不可用响应时重试的成本。
简单来说：一次尝试要花多少钱，成功的频率有多高？
一次尝试的成本：价格加上等待时间
对于每个请求，路由器会根据模型近期的流量估算它将使用多少输入和输出 token。这一估算同时决定了一次尝试的两个部分：你要支付的价格和你要等待的时间。
有效价格
有效价格是供应商实际会向你收取的价格，根据近期实测流量计算得出。它反映供应商真实的缓存命中率以及模型输入和输出 token 的平均构成，因此可能与标价相差很大。这确保供应商无法通过用低廉的输入价格掩盖昂贵的缓存或输出 token 来赢得流量。
路由器按每个供应商的有效价格为你的请求计价，并优先选择最便宜的选项。
吞吐量
吞吐量与价格之间存在权衡：更快的供应商可以收取更高费用，却仍能赢得你的请求。它按端到端每秒输出 token 数衡量，因此包含首 token 时间加上供应商流式传输完整输出响应所需的时间。路由器会按每个模型设定的换算率，将这段等待时间计入路由成本，换算率基于其供应商的典型收费和速度。
首 token 时间
首 token 时间（TTFT）是指响应开始流式传输前你需要等待多久。它单独计入路由成本，尽管它已经计入吞吐量，因为交互式使用最依赖它。在智能体会话中，模型可能连续发起许多工具调用，而每一次都要等待首 token。
速率限制
速率限制（HTTP 429）意味着供应商容量耗尽，拒绝了你的请求。你需要等待这次拒绝，然后你的完整请求会转到另一个供应商。路由器会将这段等待时间加上一项惩罚计入该供应商的路由成本，并按其触发速率限制的频率加权，因此影响通常很小。反复出现的速率限制则更多通过下文所述的流量上限和退避机制产生影响。
成功率：可靠性与质量
一次失败的尝试仍然要付出其价格和等待时间，因此路由成本会计算必须重试直到成功一次的预期成本。如果每 5 次尝试中有 1 次失败，那么每个好答案你要为 1.25 次尝试付费。
可靠性
可靠性错误是指因供应商原因而失败的请求。你会损失这次尝试并不得不重试，因此每次错误都会在路由成本中带来沉重的惩罚。
如果某个供应商的错误率远高于同一模型的其他供应商，路由器就会停止向其发送请求，直到它恢复为止。
质量
质量衡量的是供应商的响应是否可用。目前主要的检查是工具调用是否格式正确返回，我们还在增加更多检查。每个糟糕的响应都会提高该供应商的路由成本，因为一个廉价的错误答案代价高昂。
被标记为工具调用异常、或基准准确率远低于该模型应有水平的供应商会大幅落后，并且只会获得少量测试流量，直到该标记被清除。
接近者得近：流量如何分配
将每个请求都发送给单一最佳供应商会使其过载，因此流量是共享的。更快的供应商可以承担更高的路由成本并保持竞争力。在 竞争优势 分得大部分流量，而稍稍落后于最佳供应商只会付出很小的代价。一旦超出竞争优势范围，流量份额就会迅速下降。
顶层设有三道防护栏：
- 下限： 每个供应商都会保留一小股流量，这样当表现不佳的端点有所改善时我们能及时发现。新端点从该模型的典型数值起步，因此无需流量历史记录。
- 退避： 开始失败或触发速率限制的供应商会获得更少流量，直到其恢复。
- 上限： 路由器会了解每个供应商在开始返回 429 之前能承受多少负载，并将剩余流量分流给其他供应商。增加容量后，上限会自动提高。
保持不变的部分
- 设置
provider.order的请求会绕过新路由逻辑，供应商按指定顺序排列（默认仍和以前一样基于价格）。设置provider.only或provider.ignore时，如果剩余供应商多于一个，将使用新算法从中选择。 - 显式指定
provider.sort(price,throughput、或latency）会使用该排序方式，而不是新算法。详见 供应商路由指南 了解全部详情。 - 对话中的第一个请求会由算法选择一个供应商。进行中的对话会固定在其原始供应商上，以保持提示缓存处于热状态。如果该供应商变得不可用，对话将自动回退到另一个供应商。
- 如果某次尝试失败，请求会按排名次高的供应商重试。
我们如何衡量
为了衡量新路由算法的影响，我们必须超越标准的 A/B 测试，因为路由行为的变化很难与控制组隔离开来。例如，如果新算法能更好地将流量从陷入困境的供应商处引开，那么旧算法发往该供应商的请求就会发现可用容量更多、速度更快，从而使结果产生偏差。进一步加剧难度的是请求形态和流量模式的巨大差异。单个“鲸鱼”用户若针对某一供应商发起大量高负载请求，就会人为抬高该供应商的指标，无论我们用哪种算法来路由其请求。
因此我们进行了一项切换实验：我们将每天划分为 3 小时的时间块，在每一对匹配的时间块之间切换新路由器和旧路由器，每次切换后丢弃一小时的预热期数据，并在整整一周内对具有代表性的开源模型样本测量了每个模型的影响。
结果
在实验进行的一周内，我们将超过2400万次请求和1030亿输入token平均分配给新旧两种路由算法，并测量其对关键性能指标的影响。
| 指标 | 旧算法 | 新算法 | 新算法对比旧算法 | 95%置信区间 |
|---|---|---|---|---|
| TTFT p50 | 1,007毫秒 | 837 毫秒 | 降低 16.9% | 降低 13.9% 至 19.8% |
| TTFT p95 | 4,601 毫秒 | 3,733 毫秒 | 降低 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 毫秒 | 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.3 个百分点 减少 46% | -2.5 至 −4.2 个百分点 减少 35% 至 59% |
| 需要重试 | 10.4% | 6.9% | −3.5 个百分点 减少 34% | -2.6 至 -4.4 个百分点 减少 25% 至 42% |
| 每次请求在失败尝试中花费的时间 | 349 毫秒 | 242 毫秒 | −106 毫秒 减少 30% | -35 至 −181 毫秒 减少 10% 至 52% |
常见问题
我需要修改代码才能使用新的路由吗？
不需要。没有显式指定供应商排序、也没有指定供应商顺序的请求会自动使用新路由器。你的 API 密钥、请求体和模型 ID 都保持不变。
如何继续使用仅按价格路由？
在请求体中将 provider.sort 设为 price，在模型 slug 后追加 :floor，或在账户设置中将默认供应商排序设为 price。任何显式排序都会绕过新路由器。
新路由会覆盖我的供应商顺序，还是只覆盖列表？
provider.order 会绕过新路由器，并按照你指定的顺序进行路由。provider.only 和 provider.ignore 仍会筛选候选集合，但新算法会在剩余的供应商中进行选择。
新路由的成本会比仅按价格路由更高吗？
会，因为它有时会选择更快或更可靠的供应商，而不是最便宜的供应商。在我们的实时实验中，每次请求的成本增加了 6.0%，同时 TTFT 改善了 16.9%，吞吐量改善了 16.3%，429 错误率下降了 46%。
在新路由机制下，供应商如何获得更多流量？
改善路由器评分的信号：实际价格、首 token 时间、吞吐量、错误率和速率限制率，以及输出质量。