OpenRouter 的 BYOK 怎么计费：自带 key 也不是免费

有人把成本表算崩过一次：团队手里已经有某家模型厂商的企业合同，于是决定在 OpenRouter 上开 BYOK，自带上游 key。做预算的人搜到几篇中文文章，看到「每月一百万次请求免费」，顺手按调用次数估了一下，结论是这部分开销可以忽略。上线之后对账，OpenRouter 侧的余额在掉，而且掉的速度跟请求次数几乎没关系——跑的模型越贵，掉得越快。

问题不在于谁算错了乘法，而在于那篇文章引用的计费口径已经不是现行口径了。这件事值得单独写一篇，因为它是目前中文资料里错得最集中的一处。

一、BYOK 挪动的是签约关系，不是流量路径

先把 BYOK 做的事说准确。默认情况下，你在 OpenRouter 上花掉的是它的余额，由它去跟上游供货方结账——官方给供货方的接入文档里把这条写得很直白：For OpenRouter to use the provider we must be able to pay for inference automatically. 钱的方向是 OpenRouter 付给供货方，而不是你付给供货方。也就是说，在默认模式下，与上游签约的那一方是 OpenRouter，不是你。

BYOK 把这一段挪回你自己头上：你在账户设置里填入自己在某家上游拿到的 key（具体入口以控制台当前显示为准），推理的账由你和那家厂商直接结。

但请注意，挪走的只是签约与付款关系。请求仍然是发给 OpenRouter 的端点、由它转发，你客户端那套 OpenAI 兼容的调用方式不变，路由、统计、日志这些平台功能也还在链路上。这正是 BYOK 的价值所在——你保住了和厂商的直接关系（以及在那份合同里谈到的价格），同时不用把客户端拆成两套。关于这条链路本身怎么搭、和自建网关的区别在哪，可以看 自建网关与托管聚合的分界。

反过来，也正因为流量路径没变，很多人以为「自带 key 就等于绕过了平台，所以平台不该收我钱」——这个推论不成立，平台仍然在为这次调用提供转发、鉴权、计量和路由。

二、「一百万次请求免费」那套已经废弃

这是本文最想让你记住的一条。

早年的方案是按请求次数给免费额度，所以网上大量旧文（包括不少被反复转载的中文教程和翻译稿）到今天还在写「BYOK 每月一百万次请求免费」。按官方现在的 FAQ 口径，那套按请求计数的方案已经不用了，现行的免费额度是按金额算的，计量基准是 list price——也就是同一个模型在 OpenRouter 目录上挂出的应付价格。每月给一个按档位不同的免费额度，用超了才开始收费。

从「按次数」改成「按金额」，直觉是反过来的，这才是危险的地方：

• 旧口径下，单价越低的模型越划算，因为一百万次就是一百万次，你用最便宜的小模型可以近乎白嫖掉整个额度。
• 新口径下，次数根本不进公式。一个长上下文、高单价的模型，可能几千次调用就把额度吃完；而一个便宜的小模型，同样的额度能撑到你根本注意不到它存在。
• 更容易踩的是上下文长度的影响。金额口径意味着输入输出的 token 量直接决定额度消耗速度，所以「我请求数没涨啊」和「我这个月费用怎么涨了」可以同时成立——比如你只是把 RAG 的召回条数从三条提到了十条。

所以凡是看到用请求次数来估 BYOK 成本的文章，无论它写得多详细，这段估算都可以直接作废。本文也不给具体的额度金额和百分比，因为这类数字下个月就可能调整，一律以官方 FAQ 与你控制台上显示的为准。

三、超额之后按什么收：参照价是「同模型同供货方」

额度用完以后，收的是「这次调用如果走 OpenRouter 自己的渠道、应付价格的一个百分比」。这里有个容易忽略的细节：参照的不是这个模型的某个全局均价，而是同模型、同供货方在 OpenRouter 上的应付价格。

为什么要强调供货方？因为在这个目录里，同一个模型往往不止一家供货。开源权重的模型会被多家推理平台各托管一份，每家自己报价；而闭源旗舰通常只有厂商这一个入口。这套结构我在 目录构成篇 里单独拆过。对 BYOK 来说，结论是：你自带的那把 key 属于某一家具体的供货方，参照价就跟着这家走。两个团队跑同一个模型名、都开了 BYOK，因为 key 来自不同的托管方，收费基准也可能不一样。

顺带说一句，这跟 OpenRouter 默认模式的定价结构是配套的。它在 FAQ 里写得很清楚：We pass through the pricing of the underlying providers; there is no markup on inference pricing.——token 层面不加价，收入来自充值环节的百分比手续费。正因为 token 层面本来就不加价，BYOK 能省下来的不是「平台加价」那部分（那部分本来不存在），而是你自己的合同价低于挂牌价的那个差额。这条判断决定了后面的取舍，先记着。

四、自带 key 为什么还要留余额：你会收到两张账单

很多人配完 BYOK 就把 OpenRouter 的余额忘了，然后在某天遇到调用失败。

按官方 FAQ 的说法，超额产生的那笔费用是从 OpenRouter 余额里扣的。所以 BYOK 之后你的账其实分成两张：

1. 上游厂商直接开给你的推理账单——这是你想要的效果，合同价、发票主体、数据条款都在你自己名下。
2. OpenRouter 侧按上面那个百分比算出来的服务费，从余额扣。

这意味着余额不能清零，也意味着「自带 key 所以我不用再往这边充钱」是错的。还有一层容易被漏掉的成本叠加：这笔服务费要靠余额付，而余额是你充进来的，充值环节本身按官方口径要收一个百分比手续费（非加密与加密两种方式费率不同，非加密还有一个最低收费，所以小额多次充值的实际费率会显著高于大额一次充值）。换句话说，同一笔钱经过了两道口径，做预算时别只算一道。这类成本口径的坑在 成本路由篇 里也有相近的例子。

五、什么情况下 BYOK 值得开

结合上面的机制，判据其实很干净——只有当你自己那份合同拿到的价格明显低于挂牌价，或者你必须是签约主体，BYOK 才有意义。具体落到场景：

• 你已经有预付承诺或阶梯折扣。很多厂商的企业合同是按承诺消耗量给折扣的，不用就浪费。这时候走平台的挂牌价等于把已经买下的便宜额度扔在一边。
• 采购与发票主体必须是你。有些公司的报销、审计或数据处理协议要求发票和条款来自模型厂商本身，而不是中间的聚合层。这一条跟省钱没关系，是硬约束。
• 你已经跟厂商单独签过数据条款，希望这部分流量的责任边界落在那份合同里。
• 你想要的是厂商侧的专属配额或独占容量，这种东西通常只在直签关系里存在，聚合层的共享池给不了。
• 你只想保留统一入口。手里有三四家厂商的直签 key，但不想在客户端维护三四套 SDK 和三四个 base_url——这种「合同分开、调用统一」的形态是 BYOK 最自然的用法。基础概念不熟的话，先看 OpenRouter 使用与计费详解。

六、什么情况下不值得

• 量小的时候开了也白开。量小说明你大概落在免费额度里，看起来没成本，但收益同样是零——你并没有任何合同折扣可以兑现，白换来一把需要自己轮换、自己盯过期的上游 key。
• 你要的就是多供货方的自动回退。BYOK 把这个模型钉在你 key 所属的那一家供货方上，一旦那家出问题，原本可以切到同模型其他托管方的余地就没了。如果你选这个平台的主要理由是路由和回退，BYOK 会削掉一部分。
• 限速账要自己背。默认模式下你面对的是平台侧的配额，BYOK 之后你直接吃上游给你这把 key 的速率限制，容量规划与客户端限流策略都得按上游那份口径重做。
• 只是想省掉平台加价。上面说过，token 层面本来就不加价，所以这个动机不成立。
• 想拿 BYOK 当二次分发的通道。服务条款第 7 节禁止行为里有一条原文是 access the Site or Service for purposes of reselling API access to Models or otherwise developing a competing service，自带 key 不改变这条的适用。

七、条款上还要多看两眼

BYOK 会让你同时受两份约束，而且是两份都要守、以更严的那份为准：一份是 OpenRouter 的协议，一份是你跟上游厂商签的那份。

另外，OpenRouter 协议第 5.2 节把上游的模型条款往下传：You will require that all of your Authorized Users and customers access and use the Service and Models only in accordance with this Agreement, any documentation provided by OpenRouter on the Site and Service, and the applicable Model Terms. 也就是说，如果你的产品上还有下游用户，这些限制要由你写进自己的用户协议里。BYOK 并不能把这条绕过去，因为流量仍然经过这个平台。

还有一点别想当然：即使自带了 key，请求依然是经过平台转发的，所以「数据有没有被记录」这个问题不会因为 BYOK 自动消失。官方称对 prompt 与 completion 是零日志（除非用户主动开启），并提供隐私设置来避开有日志行为的供货方，但这属于你要自己去读设置页并确认的事，不是 BYOK 的附带效果。

如果你的负载本身以国内模型为主，也可以考虑在国内直接接。这里顺便说清我们自己的边界：力达云是独立第三方，与任何模型厂商都没有官方合作、代理或授权关系，第一期只接了 DeepSeek——所以你在 OpenRouter 上跑的是别家模型的话，我们给不了，这点写在 能力与边界说明 里，不用来回试。

八、上线前的自检清单

按顺序过一遍，基本能避掉开头那种对账事故：

1. 把你要开 BYOK 的每个模型，逐个记下它在目录上的挂牌价口径，和你自己合同价做差。差额为零或为负的，直接别开。
2. 用你真实负载的输入输出 token 比例去估额度消耗，而不是用请求数。至少分开算「短提示高频」和「长上下文低频」两种形态。
3. 确认 OpenRouter 余额上有留存与告警，别等到扣费失败才发现。
4. 算一遍充值手续费这一层，并决定充值节奏——按官方口径，小额多次的实际费率更高。
5. 确认你自带 key 所属供货方的速率限制，把客户端的并发与重试按这个重调。
6. 确认如果这家供货方不可用，你的降级路径是什么（BYOK 之后原来的同模型回退余地会变窄）。
7. 把 model id 与 base_url 收进配置，不要写死在代码里——这是所有此类切换的通用前提。
8. 读一遍你自己那份上游合同里关于转授权和下游用户的条款，跟 OpenRouter 第 5.2 节的要求对齐。

九、这套账最终得你自己算一遍

本文只写了机制，没有写任何具体的额度金额、收费百分比和手续费费率，这是刻意的——这些数字是官方随时可以调的，任何文章写下来的那一刻就开始过期，而拿过期数字做预算正是开头那个事故的成因。我也没有这些平台的企业合同，所以你的合同价与挂牌价之间有多大差额，只有你自己能算。

更诚实的说法是：BYOK 对多数团队并不是一个该优先打开的开关。它解决的是「签约主体必须是我」和「我手里已经有更便宜的合同价」这两类问题；如果你两条都不沾，它带来的额外 key 管理、额外账单口径和变窄的回退余地，往往比省下来的那点钱更贵。先确认自己属于哪一类，再决定要不要动。

至于额度和费率的当期数值，唯一可信的来源是官方 FAQ 与你控制台上当时显示的内容，本文与网上任何一篇教程都不适合当作报价依据。