AREX Feed Article
OpenRouter 宣布自创立以来最大路由升级：不再按价格分流，改按「好答案的真实成本」分配流量
北京时间 10 月 30 日凌晨（UTC 时间 10 月 29 日 17:06），OpenRouter 在发帖称，公司自创立以来对提供商路由（provider router）最大的一次改进已经上线。按帖文说法，此前的默认路由主要按价格排序，新路由改为奖励「以请求实际成本衡量的最佳质量推理」，让请求保持低价的同时更快、更可靠；能提供更多价值的提供商自动赢得更多流量，每家提供商因此都有持续改进的理由。
帖子链接的（署名 Scott Morse）给出了更具体的数字：在一项持续一周的切换实验中，首 token 等待时间中位数下降 16.9%，吞吐量中位数上升 16.3%，至少遇到一次限流的请求占比从 7.1% 降到 3.8%，代价是每百万 token 成本上涨 7.3%。这些数字全部出自 OpenRouter 自己的实验，目前没有独立验证。
旧路由几乎只认输入价格：越便宜拿走越多流量
OpenRouter 在 X 账号中自述为「大模型的统一接口」，聚合 400 多个模型（其中 50 多个免费），提供统一 API；接入的推理提供商由它代为分发流量。按博客披露，平台上约 77% 的请求流向由多家提供商共同服务的模型——当请求没有指定排序或提供商名单时，由平台替用户挑一家，这次改的正是这段默认逻辑。
旧算法的挑法几乎完全看输入 token 价格：提供商越便宜，分到的流量越多，失败的请求被转投下一家便宜的。博客承认这套做法把价格打到了生态最低，同时列出了四个副作用：便宜但差的服务照样赢，失败会触发回退，用户却要在等待里耗时间；排名是静态的，提供商要退化到被整体除名，流量分配才会变化；提供商抢流量的办法只剩降价，被压缩的恰恰是保障可靠性和质量的基础设施投入；还有定价游戏——排序几乎只看提示输入价，提供商可以标一个虚低的输入价，再用昂贵的缓存 token 或补全 token 把差价赚回来。
输入价格之所以几乎等于全部排名，与真实流量的形态有关。博客给出的统计显示，提示越长，输入与输出的比例越悬殊：输入约 370 token 的短提示，输出平均约 190 token，输入只有输出的 2 倍；输入到 5.7K 时是 8 倍，93K 时是 90 倍；到 670K 的超长提示，输出平均也不过约 1,050 token，输入是输出的 630 倍。谁把输入价标低，谁就几乎锁定了排名。
Routing Cost：把价格、等待和重试折算成同一个数
新算法把「一个好答案要花多少钱」算成一个实时指标。按博客描述，路由器持续监控每个端点的实际表现，为每个请求计算 Routing Cost，其中包含三笔账：真金白银的价格、等待响应的时间成本、提供商失败或返回不可用结果时的重试成本。博客把它压缩成一句话：「一次尝试花多少钱？成功率有多高？」
官方算例：$0.40 的价格加 0.60 的等待，一次尝试成本 1.00；按 80% 的成功率折算，Routing Cost 为 1.25，数值越低赢得越多流量。
价格这一项用的是「有效价格」（effective price）：按最近实测流量计算提供商实际会收的钱，反映真实的缓存命中率和该模型的输入输出配比，因此可能与标价相差很大——定价游戏的口子由此堵上。博客的算例：40K 未缓存输入按 $2.00/M 计 $0.080，60K 缓存输入按 $0.50/M 计 $0.030，约 4K 输出按 $8.00/M 计 $0.032，单次请求的有效价格为 $0.142。
时间这一项分两笔。吞吐量按端到端每秒输出 token 计，含首 token 等待和整个流式输出的时间；博客说更快的提供商可以收更高的价仍然赢得请求，等待时间按每个模型单独设定的换算率折成钱，换算率参考该模型各家提供商的典型价格和速度。首 token 等待时间（TTFT，time to first token）被单独计入，理由是交互场景对它最敏感：一次 agent 会话里模型可能连续发起多次工具调用，每一步都在等第一个 token。
失败与限流按概率进账。提供商侧错误罚得很重：1% 的错误率乘以 8 倍罚金，Routing Cost 约升高 8%；一家提供商的错误率若远高于同模型的其他提供商，路由器直接停止向它发请求，直到恢复。限流（HTTP 429，提供商容量不足时拒绝请求）按发生频率加权计入等待加罚金——博客举例：2.50 的等待加罚金乘以 0.4% 的限流率，只给 Routing Cost 增加 0.01，单次影响通常很小，反复限流的影响主要通过护栏机制体现。
至于帖文里说的「质量」，博客的定义目前相当具体：主要检查工具调用是否格式正确，「还在增加更多检查」。每个坏答案都会推高该提供商的 Routing Cost，理由是「便宜的错误答案很贵」；95% 的工具调用合格率对应约 5% 的 Routing Cost 升幅。被标记工具调用损坏、或基准得分远低于该模型应有水平的提供商会大幅掉队，只分到少量测试流量，直到标记解除。
流量怎么分：竞争区间内分蛋糕，外加三道护栏
把所有请求都发给单一最优提供商会让它过载，因此流量是共享的。按博客描述，处在「竞争区间」（competitive edge）内的提供商分享大部分流量，比最优者落后一点就少拿一点；越过这条边界，份额快速下跌，掉队的提供商仍保留一小股试探流量。三条护栏叠加其上：Floor 保证每家都有涓流，以便察觉挣扎中的端点何时改善，新端点按该模型的典型数值起步，不需要流量历史；Back off 让开始失败或限流的提供商自动减量直至恢复；Cap 让路由器学习每家在触发 429 之前能承受多少负载，其余请求溢出给别家，提供商扩容后上限自动上调。
对开发者来说接口不变。按博客及 FAQ：不带显式排序和提供商顺序的请求自动走新路由，API key、请求体和模型 ID 都不用改；provider.order 完全绕过新逻辑，按指定顺序路由（默认仍按价格）；显式设置 provider.sort（price、throughput 或 latency）同样绕过；provider.only 和 provider.ignore 先过滤候选集，再由新算法在剩余提供商中选择。想保留纯价格排序，可以在请求体里把 provider.sort 设为 price、给模型 slug 末尾加 :floor 后缀，或在账户设置里把默认提供商排序设为 price。会话粘性也保留了：只有对话的第一条请求做算法选择，后续请求钉在原提供商上，保持提示缓存温热，该提供商不可用时自动回退；单次尝试失败则重试排名次高的提供商。
为什么不用 A/B 测试：一周切换实验，新旧路由对半分账
OpenRouter 没有采用标准 A/B 测试，并解释了原因：路由行为的变化没法从对照组里隔离——比如新算法把流量从一家状态不佳的提供商挪走，旧算法分给同一家的请求反而会因腾出了容量而变快，污染结果；请求形态和体量的巨大波动也会搅局，单个大户对着一家提供商发起的高强度自动请求，无论用哪套路由都会人为抬高该提供商的指标。
于是团队做了切换回切实验（switchback experiment）：把每天切成 3 小时的区块，在各配对区块之间来回切换新旧路由，每次切换丢弃 1 小时的预热数据，在一组有代表性的开源模型上测了整整一周。一周内共有 2,400 万余次请求、1,030 亿输入 token 被对半分给新旧两套路由。结果如下（p50 为中位数，p95 为 95 分位；原数值与百分比均取自博客原文，博客另给出 95% 置信区间，例如 TTFT p50 的改善区间为 13.9%～19.8%）：
| 指标 | 旧路由 | 新算法 | 变化 |
|---|---|---|---|
| TTFT p50 | 1,007 ms | 837 ms | 低 16.9% |
| TTFT p95 | 4,601 ms | 3,733 ms | 低 18.9% |
| 吞吐量 p50 | 62.4 tok/s | 72.6 tok/s | 高 16.3% |
| 每千次请求成本 | $1.25 | $1.32 | 高 6.0% |
| 每百万 token 成本 | $0.301 | $0.324 | 高 7.3% |
| 调用方 TTFT p95 | 6,032 ms | 4,504 ms | 低 25.3% |
| 整请求 p50（到最后一个 token） | 4.00 s | 3.24 s | 低 19.0% |
| 至少遇到一次 429 | 7.1% | 3.8% | 少 3.3 个百分点（约 46%） |
| 需要重试 | 10.4% | 6.9% | 少 3.5 个百分点（约 34%） |
| 每请求失败尝试耗时 | 349 ms | 242 ms | 少约 30% |
OpenRouter 强调，这组数字是在「提供商还来不及针对新算法做优化」之前测得的。变贵的部分博客 FAQ 写得直白：新路由有时会选更快、更可靠的提供商而不是最便宜的那家，所以成本可能上涨。
回复区的追问：「质量」到底量了什么
帖文发布后，回复区里简短的喝彩——如「finally!」（）和「love it」（）——与实质追问同时出现。Moriarty ：「表格里每一行都是速度或可靠性，每百万 token 的成本还涨了 7.3%。你们也会按提供商给输出质量打分吗？还是说这里的『质量』主要是延迟？」他说的 7.3% 与博客结果表中每百万 token 成本的涨幅一致；博客对「质量」的现行定义也以工具调用格式检查为主。
用户 ominoussage 的是眼下的体验：「请修一下你们的 TTFT 和路由开销问题。用你们的服务时任务要很久才能完成，直连单个提供商反而快得多。」也有人方向——「如果失败了还要重试，最便宜的那次调用就不便宜」——但想知道质量差距够大时更慢的一方是否还有机会；还有人：要是提供商们串通起来一起抬价呢？
截至发稿，这条公告帖显示 111 个赞、17 条回复、约 8,000 次浏览，讨论规模还不大。
这套评分也还在变动中。博客写明更多「质量」检查「正在增加」，但哪些检查、何时并入，文中没有说明；每并入一项，各提供商的 Routing Cost 和流量份额都会重排。