openrouter 价格

成本与用量

拆解 OpenRouter 这类聚合网关的价格构成:平台加价、上游模型成本、路由与缓存各占哪一块,教你在下单前把花费结构对清楚。

用聚合网关接入多个模型确实省事,但账单出来常常比预期高:同一段代码换个模型价格差好几倍,上游涨价也不会提前通知你。这篇不讲某家模型具体多少,而是把 OpenRouter 这类网关的花费拆成几块——平台服务费、上游模型成本、路由与回退、缓存与长上下文——每块给出核对位置和判断标准,让你知道该盯哪几项。

用聚合网关接多个模型确实省事,但账单出来常常比预期高:同一段代码换个模型价格差好几倍,上游调价也不会提前通知你。问题的根源是很多人只盯着「模型单价」这一个数,却忽略了网关这层自己的花费结构。

这篇不列任何具体金额,只把 OpenRouter 这类聚合网关的花费拆成几块——平台服务费、上游模型成本、路由与回退、缓存与长上下文、充值与汇率——每块给出核对位置和判断标准,让你知道自己该盯哪几项,下单前把结构对清楚。

先分清两层价:平台价和上游价不是一回事

聚合网关的报价通常是上游模型官方价再叠一层平台服务费,两层的口径不一定一样:上游大多按 token 量计价,网关可能再按比例抽成或加固定服务费。不把两层分开看,你永远不知道多花的钱是模型贵还是通道贵。

  1. 取原厂口径先到 /official-api 查看你打算用的模型在原厂的计价方式与单位,记下输入、输出各自的计费口径。
  2. 跑同一样本用同一段提示词、同样输出长度,分别走网关和原厂各跑一次小样本,量要小到不心疼。
  3. 算差额用「网关总花费 ÷ 原厂总花费」得出倍数,这个倍数就是平台这层的实际成本,而不是页面上写的比例。
  4. 验证是否稳定换一个模型再跑一遍,若倍数一致说明是统一抽成,若差异大说明是分模型定价,比价时要逐个看。

如果只想知道网关侧最近有没有动过价,可以直接到 /price-watch 看变动记录,比每次自己跑样本省事。两层价分清之后,下一步才是看路由这层怎么把钱悄悄改掉。

路由、回退和批处理:看不见的加价在哪

请求被路由到哪个上游、失败后自动回退到哪个模型,会直接改变单价。最典型的情况是你以为在用便宜模型,实际因为失败重试或自动择优,一部分请求落到了更贵的上游,账单自然跳。

  • 优先锁定具体模型,而不是选「自动择优」;锁定后价格可预测,自动模式省钱但不可控
  • 检查是否开启失败自动重试,重试次数没有上限时,一次失败可能触发多次计费
  • 批处理或低优先级通道通常比实时通道便宜,但延迟代价要按你的任务容忍度评估,交互类场景不适用
  • 按模型和通道把用量明细分组,看同一批任务被分给了几个不同上游
  • 把「通道」当成和「模型」同级的成本维度来看,不要只看模型名
配置项对花费的影响建议
模型选择直接决定上游单价锁定具体型号,不选自动
失败回退失败转到更贵模型时成本上升设置回退上限,或关闭自动回退
通道类型批处理便宜、实时贵非实时任务走批处理通道
重试策略一次请求可能被计费多次限制重试次数并记录失败原因

判断标准很简单:把同一批任务在不同路由配置下各跑一次,比较总花费差多少。差得明显就说明路由层在替你花钱,值不值得省这笔接入复杂度,由你自己权衡。

用量字段怎么读:哪几项会影响你付多少钱

网关的用量明细通常不止输入和输出两项。至少要关注四项:输入、输出、缓存写、缓存读。缓存读一般单价更低,长对话反复携带同一段上下文时,差出来的钱相当可观。

字段什么时候产生容易踩的坑
输入每轮提交的提示词长上下文整段重算,不是只算新增
输出模型生成的内容输出单价通常高于输入,长回答更贵
缓存写首次把上下文写入缓存写了但没命中,等于白付一次
缓存读命中缓存后复用上下文命中率低时省不下钱,要单独看这项

长上下文任务最容易出现成本突增,原因是整段上下文被重算,而不是只算新增部分。把一次任务的四项数量乘各自单价再求和,和账单对一对,差得远就说明有没看到的计费项,得继续往下查。

换算和量级判断可以借助站内工具:到 /tools/token-price-calculator 做单价换算,到 /usage 看用量榜,判断自己的消耗算多还是算少。数据本身以页面当时显示为准,别用旧印象做决策。

充值、额度与汇率:到手成本还要再算一步

网关大多采用预充值额度制,扣减顺序(赠送额度、余额、自动续充)会影响你实际掏出去的钱。外币结算的网关还会叠一层汇率和手续费,比价时不换算到同一币种,等于白比。

  • 把赠送额度和自付余额分开记,赠送部分不该按原价摊进你的到手单价
  • 确认自动续充有没有开关,忘记关可能在低峰期被扣一笔
  • 外币结算时,用当天实际入账金额除以消耗用量,得到的就是真实到手单价
  • 连续几个周期记录同一个指标,才能看出趋势,单次快照说明不了问题

不适用的情况是:额度包里含大额赠送时,这部分按原价摊进单价会严重失真,必须单独扣出来再算。比价前先把这一步做掉,后面的比较才有意义。

一套五分钟就能跑完的核对流程

  1. 看走量确认这批调用分别走了哪几个模型和通道,把用量明细按这两个维度分组。
  2. 拆字段把用量按输入、输出、缓存写、缓存读四项分别求和,别混在一起看。
  3. 算两遍用原厂口径和网关口径各算一遍总额,差额就是平台层成本。
  4. 做判断把这个差额和你省下的接入、切换、维护成本放一起看,值不值由你的团队规模和调用量决定。
  5. 定复查节奏建议按月对一次;价格和计费口径会变,一次性的结论不能用太久。

这套流程不依赖任何具体数字,你随时可以照着跑一遍。真正的难点不在算,而在坚持定期复查——网关和上游的定价都不是静态的。

比价不是比谁的模型便宜,而是比谁的花费结构对自己透明。
下一步想先看行业里各家网关的实时价格变动和可信度记录,直接到 /price-watch 和 /sites 核对当时的数字,再回头套上面这套核对流程。

常见问题

OpenRouter 会比直接开原厂账号贵吗?

多数情况下会多一层平台服务费,换来的是多模型统一接口和切换便利。但要看具体模型:有的上游在网关侧有折扣,反而更便宜。判断方法是用同一段请求两边各跑一遍,比较单位用量的实付金额,别只看标价。

同一段代码换个模型,账单为什么差这么多?

差异来自三处:模型本身单价不同、输入输出比例不同、以及是否命中缓存。长上下文加高输出比例的任务差距最大。建议把任务按输入输出和上下文长度分组,分别算钱,而不是拿整体平均单价判断。

怎么核对网关账单有没有算错?

按模型和通道分组导出用量,把输入、输出、缓存读写四项分别乘单价求和,再和账单比。差额稳定说明是平台层加价,差额忽大忽小则要看是不是有回退、重试或未预期的模型被调用。

本文依据各平台公开文档与官方公告整理,只做中文归纳;具体做法、参数与限制以官方文档为准。