走 OpenRouter 还是官方直连？成本结构差异与切换判断方法

数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。

结论先放这里：OpenRouter 和官方直连的差别，几乎不在模型 token 的单价上。 官方 FAQ 写得很直白——它把底层供应商的定价原样透传，不做加价（原文用的词是 without any markup），所以同一个模型你在 OpenRouter 上付的费率和直接找那家供应商是一样的；它赚钱的位置是你充值额度的时候收一笔费用。真正会让两条路算出不同账的，是另外三层：充值那一层的手续费与额度规则、路由层（同一个模型可能被分到不同供应商）、以及数据与合规约束。所以「该走哪条」不是比单价，而是把这三层各自的成本和风险摆出来，对着你自己的调用画像算。下面按这个顺序拆。

第一层：推理价是透传的，差价在充值那一步

官方 FAQ 的 Pricing and fees 一节说了两件事：购买额度时收取一笔费用；底层模型供应商的定价原样透传，你付的是和供应商挂牌价一样的费率。加密货币支付另有一档单独的费率。这两句话合起来的意思是——OpenRouter 的抽成发生在充值动作上，而不是发生在每一次推理上。

这个设计的实际后果，是它的成本劣势会随着你充值频次和方式变化，而不是随着调用量线性变化。你要估自己的差额，需要的输入只有三个：一段时期内的实际推理花费、这段时期充了几次值、用的是哪种支付方式。三个数乘一乘就出来了，不需要去猜什么”综合费率”。具体费率数字官方放在定价页，会调整，这里不复述，估算方法见 OpenRouter 充值手续费是怎么产生的。

还有两条容易被忽略的规则，直连那边没有对应物：

• 未使用的额度不是永久有效的。官方 FAQ 里写明，按其服务条款保留在购买后经过一段期限作废未使用额度的权利（原文用的是 reserve the right to expire unused credits，具体期限以官方条款当前版本为准）。也就是说预充的钱带着时间成本，一次性大额预充在这里不是纯赚。
• 官方目前不提供批量优惠。FAQ 里明确写了 does not currently offer volume discounts，特殊场景可以发邮件沟通。而直连大客户能不能谈到更好的商务条件，取决于你和那家供应商的关系——这一条是直连侧真实存在的、OpenRouter 侧官方说没有的差异。

还有一点会影响财务流程：官方 FAQ 明确写了额度体系的基础货币不是人民币（原文 the base currency is US dollars），站点和 API 上的定价都按这个货币标注。这件事本身无所谓优劣，但如果你的对账口径要求按本币逐笔核对，就会多出一步汇率换算的工作量，这笔工作量该记在哪条路线的账上，取决于你直连的那家供应商用什么货币结算。

第二层：你买的其实不是价格，是”合并”

官方对”为什么该用 OpenRouter”的回答里有一句关键的：它提供统一 API 访问主流模型，让用户把账单归拢到一处、用分析面板统一看用量；同时它把各家供应商的可用性汇集起来（原文用的是 pooling their uptime），配合 fallback 机制，所以你拿到的是同样的价格加上更好的可用性。

把这句话翻译成决策语言：你多付的那笔充值费用，买的是”少维护 N 套账号、N 套 key、N 张账单”，以及一套现成的故障切换。 直连省掉了这笔费用，但这些活得你自己干——每加一家供应商就多一套注册、风控、额度、账单和限流规则要跟。

可用性这块官方还有更细的说明：某家供应商返回错误时，OpenRouter 会自动落到下一家，这个过程对调用方是透明的。模型层面还有 models 参数，接受一个按优先级排列的模型 ID 数组，主模型的供应商挂掉、被限流、或者因为内容审核拒绝回复时，自动去试下一个模型。这类跨厂商的兜底，直连方案里只能自己写。

所以第二层的判断题其实是：你的团队愿不愿意自己养这套多供应商的接入与兜底代码？ 愿意且已经养了，OpenRouter 的这部分价值对你就会缩水；不愿意养，那笔充值费用就是在买人力。

第三层：路由层——直连根本没有的一层，也是最容易算漏的

直连只有一个供应商，请求去哪儿是确定的。OpenRouter 不是。官方 Provider Routing 文档写明，默认行为是跨供应商做价格优先的负载均衡，具体三步：先排除最近 30 秒内出现明显故障的供应商；在稳定的供应商里挑低价候选，按价格的平方倒数加权随机选一个；剩下的作为 fallback。

这一条值得停下来想一秒——同一个模型 ID，两次请求可能落到两家不同的供应商上。你在直连时代形成的那些直觉（响应格式的细枝末节、参数支持度、数据留存策略）在这里都不再是单一变量。

请求体里的 provider 对象就是用来管这件事的，官方文档列出的字段包括 order、allow_fallbacks、require_parameters、data_collection、zdr、only、ignore、quantizations、sort、preferred_min_throughput、preferred_max_latency、max_price（字段清单以官方文档当前版本为准）。挑几个和”要不要切”直接相关的说：

• sort 有三个取值：price（低价优先）、throughput（高吞吐优先）、latency（低延迟优先）。一旦设了 sort 或 order，负载均衡就被关闭，路由器改成按你给的顺序依次尝试。想要”最像直连”的确定性，代价就是放弃默认的价格加权分配。
• allow_fallbacks 关掉之后，请求只由排在最前的那家供应商服务。这等于主动交回了上面第二层买到的可用性红利，权衡要自己做。
• require_parameters 默认是关的。默认路由下，不支持你请求里某些参数的供应商照样可能收到这个请求，只是把不认识的参数忽略掉——这是从直连迁过来最阴的一个坑，参数悄悄失效而不是报错。置为 true 后，这类供应商压根不会被路由到。文档另外说明，即使它是 false，tools、response_format（含结构化输出）、verbosity 这几个参数会作为软偏好参与选择：同一模型里有的供应商支持、有的不支持时，只路由到支持的那些；如果一家都不支持，请求仍会发出去而参数被忽略。
• max_price 接受一个对象，用来声明你能接受的最高供应商定价，可以分别限制 prompt 与 completion 两侧；部分供应商支持按请求计价时可用 request 属性，还有按图计价的 image。文档给的典型用法是和 sort 组合，表达”在不超过某个价格上限的前提下选吞吐最高的那家”。

模型页上会展示各家供应商的首 token 延迟与吞吐指标供你自己判断，这些数值我们没有跑过也不复述。

中间那条路：BYOK（用自己的供应商 key 走 OpenRouter）

很多人把这题当成二选一，但官方给了第三个选项。BYOK 文档说明：OpenRouter 既支持用它的额度，也支持你带自己的供应商 key 进来；用它的额度时，各供应商的速率限制由 OpenRouter 管理，而用自己的 key 则是由你在供应商账户那边直接控制限流与成本，key 会被加密保存并用于所有路由到该供应商的请求。

计费上，BYOK 请求按”同模型同供应商在 OpenRouter 上正常花费”的一个比例收费，从你的 OpenRouter 额度里扣。这里有个容易读错的细节：免费额度是按套餐给的，而且是按挂牌推理成本（list-price inference cost）来度量，不是按请求条数度量。具体比例和各套餐的额度见官方定价页。

行为上有几条硬机制值得记：

• BYOK key 分Prioritized和Fallback两段。前者在回落到 OpenRouter 端点之前按顺序尝试，后者只在 OpenRouter 端点都试过之后才轮到。两段之间可以在供应商详情页拖动调整。
• 默认情况下，两段里所有 key 都遇到限流或失败时，会回落到 OpenRouter 的共享端点。每个 prioritized key 有一个 Shared capacity fallback 设置控制这件事，三档由弱到强：默认的”使用共享容量”；“仅对该 key 不适用的模型使用共享容量”（在 key 的 Models 过滤里选中的模型永不回落，代价是 key 耗尽时可能直接吃到限流错误）；“该供应商上永不使用共享容量”（这家要么走你的 key，要么被跳过）。
• BYOK 和 provider ordering 组合时，BYOK 端点永远排在最前，不管那家供应商在你的 order 里排第几；BYOK 端点全部用尽后才按你指定的顺序走共享容量。文档明说目前没有办法改这个行为。

对”该不该切”来说，BYOK 的意义是：它把”要不要放弃与供应商的直接商务关系和限流控制”和”要不要用统一接口”这两个问题拆开了，你可以只要后者。

绕不开的一条：数据与合规

这条在成本表里看不见，但常常才是真正的决定项。

• OpenRouter 官方对自身定位的描述是代理：把你的请求转发给模型供应商完成。请求元数据（时间戳、用到的模型、token 数）会被记录，prompt 和 completion 默认不记录，即使出错也不记录，除非你主动开启。开启是可选的，换取用量成本上的优惠，具体口径见官方隐私设置页。
• 供应商侧的策略由 data_collection 控制：allow（默认）允许使用可能非临时存储用户数据、并可能用于训练的供应商；deny 则只用不收集用户数据的供应商。同样的开关在账户隐私设置里有账户级版本。会记录 prompt 的供应商在模型页上带 Data Policy 标记，官方也说明这不是第三方数据政策的权威来源，只是他们已知的最佳信息。
• 还有一条报错机制要提前知道：如果你在请求里指定了 provider routing，但没有任何一家供应商满足你账户设置里的隐私等级，请求会直接报错而不会完成。
• 官方还明确写了，你不得违反为 OpenRouter 提供模型的第三方供应商的服务条款与政策。也就是说走中转并不会把供应商侧的合规义务转移掉。

如果你的合规要求是”数据必须只落在某一家指定供应商、且有可审计的直接合同关系”，那基本就不是成本题了，直连或 BYOK 是唯二能谈的形态。

切换判断：把三个数量出来，而不是拍脑袋

不给”谁更好”的结论，因为它取决于你的调用画像。但官方接口足够你把这题变成算术题：

1. 每次请求的实际成本。文档说明用量信息现在无需额外参数，默认就随每次响应返回，流式请求放在最后一个 SSE 消息里。usage 对象里有 prompt_tokens、completion_tokens、total_tokens，成本相关的是 cost（记到你账上的总额）和 cost_details.upstream_inference_cost（上游供应商实际收取的部分）；缓存相关的是 prompt_tokens_details.cached_tokens（从缓存读取的 token 数）和 cache_write_tokens（写入缓存的 token 数，只有支持显式缓存并对写入计价的模型才返回）。这里有个坑：通过 generation ID 事后查询时，upstream_inference_cost 只对 BYOK 请求有值，其他请求是 0 或 null。
2. 按供应商聚合的分布。Activity 页可以按模型、供应商、API key 过滤历史用量。想知道”如果我直连某一家，能覆盖我多少流量”，这里就能看出来。
3. 账户余额与剩余额度。除了控制台，官方还提供 credits API 返回余额与剩余额度的实时信息，适合接到你自己的监控里。做法可以参考 API 成本监控的通用做法。

有了这三个数，判断框架就很朴素了：流量高度集中在一两家供应商 + 团队愿意自己维护兜底 + 有合规硬约束 → 直连的理由变强；模型选型还在频繁变动 + 要跨厂商做 A/B 和兜底 + 不想养多套账号 → 统一接口的理由变强；两边都想要 → 看 BYOK。

真要切，改动量比你想的小

官方 FAQ 说 OpenRouter 实现了 OpenAI 的 API 规范（/completions 与 /chat/completions），并且是 OpenAI 的 drop-in 替代品，任何原本支持 OpenAI 的 SDK 都能用。官方给的 Python 示例里，客户端初始化只改了两处：base_url 指向 https://openrouter.ai/api/v1，api_key 换成 OpenRouter 的 key；model 用带厂商前缀的 slug；HTTP-Referer 和 X-OpenRouter-Title 两个头是可选的，用于在 OpenRouter 榜单上展示你的应用。OpenRouter 独有的参数（比如上面那个 models 回退列表）通过 extra_body 传。

改动小意味着这个决定的可逆成本也低——切过去发现不合适，退回直连同样是改 base URL 那一层。这一点应该纳入你的判断：可逆的决定不值得纠结太久，先按小流量跑一段，用上面第一节的算法核对账单再定。反过来，如果你打算从直连往这边切，切换前的清单可以对照 换厂商迁移清单过一遍。

最后，几个真会栽的坑

• 只比 token 单价。单价是透传的，比了等于没比。差异在充值那一层的费用、额度过期规则、以及路由到了哪家供应商。
• 默认路由的不确定性。价格加权负载均衡意味着同一模型可能换供应商，参数支持度和数据策略会跟着变；想要确定性就得动 order / only / require_parameters，而这些一开就放弃了默认的价格优势。
• 关掉 fallback 之后别再拿”可用性更好”当理由。这是自己交回去的。
• BYOK 的优先级不可调。BYOK 端点永远先于共享容量被尝试，文档说明目前无法改变。
• 余额为负时免费模型也可能跟着失败。官方限额文档的措辞是「可能会看到错误，包括免费模型」，把余额补回零以上才能恢复——这条在你压着余额跑的时候会突然咬人，付费与免费的边界见 OpenRouter 额度管理。