10 月 28 日，OpenRouter 公布服务商路由更新，把价格、等待时间和服务表现一起纳入选择。对开发 AI 客服、编程助手和自动化工具的团队来说，只盯着每百万 token 报价，可能会漏算排队、重试和人工接手的代价。本文拆解这次变化，并给出一套比较路由策略的方法，帮助你判断应该优先省钱、提速，还是保留更多控制。

便宜的请求，贵在哪：大模型 API 路由概念图

原创 AI 概念配图，用分岔道路、时钟和天平表现请求选择，不是产品界面或实测数据。

[配图建议：同一个请求走向低价、等待、重试三条道路，最终汇入可用结果 + 现代科技杂志立体插画]

一、同一个模型，也有“由谁来跑”的问题

假设你的应用已经选定一个模型，接下来仍要决定把请求交给哪家推理服务商。不同服务商的部署、负载和价格可能不同。选模型解决“用什么能力”，选服务商解决“这次请求由谁提供推理”。 把两层选择混在一起，容易误把路由改进理解成模型本身变聪明了。

OpenRouter 这次更新的是后一层。按照官方说明，新的路由综合实际价格、首个 token 等待时间、吞吐和可靠性等信号，调整流量分配；显式指定排序或服务商顺序的请求，则有相应的控制方式。这意味着默认选择开始更重视一份可用回答的整体代价。来源：10 月 28 日官方公告

这里的“成本”首先是路由决策的衡量方法，不应理解成账单突然增加了“等待费”。对于开发者，更实用的启发是重新定义省钱：一次请求价格低，但用户等得太久又点了一次，或者结果无法被程序使用，还得补一次调用，整个任务的支出和等待都可能增加。

官方自报实验中，首 token 时间中位数下降 16.9%，每千次请求成本上升 6.0%。这是平台实验的汇总结果，不代表你的应用也会得到相同比例，更不是新增统一费率。它揭示的取舍很明确：更好的交互，可能需要接受稍高的单次推理支出。 来源：公告的实验结果

[配图建议：固定模型下连接多家服务商，分别标注价格、排队和输出状态，旁边展示任务总账 + 清晰的路由解释图]

二、用户感到“慢”，通常不止一种慢

可以把一次交互拆成两段：等回答开始，以及等回答完成。前一段常用 TTFT，也就是首个 token 时间衡量；后一段还受输出长度与生成速度影响。OpenRouter 的性能文档也按这两个阶段解释延迟，并指出失败后的备用尝试会增加等待。来源：官方延迟与性能文档

拿客服助手举例，用户只问“订单什么时候到”，几秒空白就可能让人误以为系统卡住。此时，提高长文生成速度未必解决主要问题。反过来，一份很长的报告即使马上开始输出，用户仍可能等很久才能拿到完整文件。

多步骤任务还会放大这种差别。助手先查资料，再调用内部工具，最后生成结论；每一轮模型调用都可能有一段等待。只测最终那段文字的生成速度，会漏掉中间反复发生的停顿。

因此，建议把产品任务分开看：

  • 短问短答：优先观察首次可见反馈，以及用户是否重复提交。
  • 长文生成：同时记录首字等待和整份结果完成时间。
  • 工具工作流：从任务开始计时到最后验收，把失败、修复和重试都算进去。

这些是本文建议的评估维度，不是某家服务商的排名。路由器能帮你分配请求，产品仍要自己判断“什么叫完成”：接口返回成功，不等于引用正确、工具调用合理，也不等于用户的问题已经解决。

[配图建议：短问答、长报告、工具工作流三条时间轴，区分首字等待与完整交付 + 简洁的编辑式时间线]

三、缓存和控制权，决定你能不能放心交给默认策略

多轮应用常会重复发送系统说明、工具定义或共同上下文。提示缓存有机会减少重复处理，但收益取决于实际命中情况。官方缓存文档说明，符合条件时，后续请求会尽量留在原服务商，以保留缓存；原服务商不可用时仍可能切换。来源：官方提示缓存文档

所以，不宜把“每一步都重新挑看起来最快的服务商”当成天然最优。对于共享长上下文的会话，切换可能改变缓存命中；对于一次性的独立请求，收益结构又不同。比较前，应分开记录首次调用与后续调用，而不是把它们平均成一个模糊的速度值。

同时保留几个明确的选择入口：

  • 希望价格优先：请求中的 provider.sort 可以设为 price。
  • 希望自己安排尝试顺序：检查 provider.order，不要以为它仍完全遵循默认算法。
  • 只接受部分服务商：用 provider.only 收窄候选，但可用的备用选择也会减少。
  • 依赖特定请求参数：核对 require_parameters，让不支持所需参数的服务商退出候选。

字段定义可查官方服务商选择文档；默认算法与显式设置的关系，以本次更新说明为准。已有应用应先查看实际发出的请求，客户端、网关或账号设置可能已经指定了偏好。

还有一个容易忽略的区别：更换同一模型的服务商，与失败后改用另一个模型，是两种机制。OpenRouter 的 models 备用列表可以触发后者，实际使用的模型也会影响计费与输出。来源：官方模型备用机制文档

对生产应用，服务商允许范围、所需能力和预算应先确定，再在可接受的范围内优化速度。候选越少，控制越强；遇到不可用服务时，恢复空间也可能更小。

[配图建议：先经过能力与服务商范围筛选，再进入价格、延迟和缓存的比较，备用模型另画分支 + 层次清楚的流程图]

四、今天就能做的比较：固定模型，改变路由

不要一开始就同时换模型、改提示词、改服务商和调整输出长度。可以先挑一个现有业务场景，保留模型、输入与验收条件，只比较两组：当前可用的默认路由，以及显式价格排序。设置一个试验预算，使用允许用于测试的材料。

先做小规模探索，确认记录方式正确，再扩大到不同时间段。测试集至少覆盖短请求、长输入和真实多轮流程；若业务不用某种形态，就删掉它，避免把不相关的平均值当成结论。

每次记录以下项目：

  1. 实际去向与配置：模型、服务商、排序方式、输出上限。
  2. 时间：首个可见输出、完整结果完成、整个任务结束。
  3. 费用与失败：实际账单、错误、重试次数及缓存使用。
  4. 验收：结构能否解析、关键事实是否正确、是否需要人工接手。

最后用“通过验收的任务”作分母，比较总费用和总耗时。失败任务产生的已计费用也应保留；用户自行重发的请求，则需要在应用侧关联到同一个任务，才能看见完整代价。

小样本适合发现明显问题，不适合宣布长期稳定提升。若默认策略在高峰期更顺畅、费用增加又在预算内，可以逐步扩大；若任务不赶时间，价格优先仍可能更符合需求。判断标准来自你的业务，而不是公告里的某个提升百分比。

[配图建议：两组相同任务进入不同路由，出口同时检查费用、等待和可用结果，不画虚构成绩 + 实验记录台风格]

总结：省钱，要算到任务完成那一刻

OpenRouter 的新路由值得交互式 AI 应用和多步骤工具团队关注；只做不赶时间的批处理，则可以继续评估价格优先。今天先找出应用是否显式指定了路由，再用同一批任务比较费用、等待和验收结果。你现在更难接受的，是单次价格略高，还是偶尔一次很长的等待？

[配图建议：账单、时钟与验收勾选共同落在一张任务完成单上 + 克制的杂志收尾插画]

资料核查：2026 年 10 月 29 日，北京时间；事件为官方 10 月 28 日路由公告。本文为资料分析，未调用 API 做性能测试；实验方法为作者建议，封面为 AI 生成概念图。