从 OpenRouter 迁到国内网关：迁移清单与差异点

有人把一张 OpenRouter 的账单和一段延迟曲线甩过来，问「整体搬到国内网关要多久」。这个问题问早了。先要回答的不是「多久」，而是「搬哪些」——因为在这次迁移里，决定可行性的不是你的代码结构，而是你调用清单里那几个模型分别属于哪一类。把这一步跳过去直接动手改配置的团队，通常在第二天发现有一半流量根本没有落脚的地方。

一、先把模型清单按「开源权重 / 闭源旗舰」分成两堆

这一刀是整件事的分水岭。

按我们在 2026-09-15 直接拉取 OpenRouter 官方模型接口做的一次快照统计：目录里有 445 个模型、59 个厂商前缀。这个数听着夸张，但逐个去查单模型的供货方列表就会看出它是怎么来的——deepseek/deepseek-chat-v3.1 这一个模型在当时有 8 家供货方（DeepInfra、SiliconFlow、Novita、AtlasCloud、CoreWeave、Mara、Google、SambaNova），z-ai/glm-4.6 有 5 家；而闭源的 qwen/qwen3-max 只有 Alibaba 一家。（以上都是那一天的快照，供货方名单随时会变，你自己查一遍才是当下的事实。）

这条机制直接翻译成迁移结论：

• 开源权重的模型，权重公开，谁都能托管一份，所以国内平台上通常能找到同一个模型的另一个入口。迁移是「换托管方」，语义上有对应物，具体有哪些落脚点可以对着国内推理平台横向对比那篇的口径去找。
• 闭源旗舰（GPT、Claude、Gemini 这一类），只有厂商自己一个入口。它在 OpenRouter 上只有一家供货方，在国内网关那边不存在同一个模型的另一条合法入口。这不是哪家平台努力不够的问题，是供给结构决定的。

所以如果你在 OpenRouter 上跑的主力是 GPT、Claude、Gemini，那么关于「迁到国内网关」这件事，力达云给不了，不必迁过来。我们一期只接 DeepSeek 一个上游，这一条写在怎么验证我们那一页的「我们现在明确不占优的地方」里，和其它几条减分项摆在一起——包括充值尚未开放、没有厂商官方授权、上线时间短。建议你先去那页看完再决定要不要花时间试，而不是先接进来再发现缺东西。

二、模型名不通用，这是最容易低估的一项

改 base_url 和 key 是十分钟的事，真正耗时间的是 model id。

OpenRouter 的命名是 厂商/模型 加变体后缀这一套。国内平台各有各的规则，而且不是简单的映射关系。举一个卡在细节上的例子：硅基流动的模型名形如 Pro/deepseek-ai/DeepSeek-R1，那个 Pro/ 前缀不是装饰——按官方说明，同一个模型带 Pro/ 前缀的是付费加速版，不带前缀的免费版速率与并发更低。也就是说同一个模型在那里有两个名字、两套速率行为。你从 OpenRouter 搬过去时，如果只做了「模型名字符串替换」，很可能把本该走付费档的流量落到了免费档上，而且从代码里看不出来。

结论是：model id 必须收成配置项，不能散落在各处的调用代码里。这一步做完，后面无论换到哪一家，改动量都收敛成一张映射表。base_url 同理，相关的收拢方式在base_url 怎么配那篇里写过。

顺带一句：这一步的价值不只是为了这次迁移。你把它做完之后，「按模型分流到不同上游」这件事才在工程上变得可能——这正是本文结尾要说的那个更划算的做法。

三、路由与自动回退是平台能力，迁走就没有了

上面那条「一个模型八家供货方」还有第二重含义：在聚合层上，某一家托管方抖动的时候，平台有别的地方可以落。这种能力是平台特性，不是你的代码写出来的，所以它不会跟着你一起迁走。

迁到一个单一上游的网关之后，这部分要你自己在客户端补：超时与重试策略、失败后切到哪个备选模型、以什么口径判定「这次不是模型的问题而是链路的问题」。力达云一期就是单一上游（DeepSeek 官方渠道接入），我们也明确不做「多家上游混调同一个模型名」这种事。这件事有两面：你少了一层自动回退，但同时「你调到的是谁托管的」这个问题不再含糊——而在多供货方的目录里，你其实很难知道这一次请求落到了哪家的机器上，同一个模型名在不同托管方那里的表现和限速口径都可能不一样。

哪一面更重要取决于你的负载。要在客户端做分流与降级的话，按成本做路由那篇里的判据可以直接搬过来用。

四、计费口径完全不同，别拿旧账单直接推算新账单

这一节最容易算错，因为两边的收入结构根本不在同一个位置。

OpenRouter 的官方说法是对 token 不加价，原文是 We pass through the pricing of the underlying providers; there is no markup on inference pricing.，它的收入来自充值环节的百分比手续费。这里有个结构性细节值得单独记住：非加密与加密两种充值方式费率不同，而且非加密方式有最低收费——所以小额充值的实际费率会显著高于名义费率。具体数值我不写，因为这类数字下个月就可能变，以官方页面为准。

国内网关这边通常是另一套：在上游定价基础上按倍率换算，收入体现在单价而不是充值环节。这意味着你不能拿 OpenRouter 的历史账单乘一个系数来估新成本，两边的成本函数形状不同——一边随充值批次大小变化，一边随 token 量线性变化。正确做法是拿你最近一段真实的输入/输出 token 分布，在两种口径下各算一遍。

还有一个专门的误算来源：BYOK。OpenRouter 的自带 key 方案现行口径是按 list-price 金额计一个月度免费额度、超出后按比例收费，但网上大量旧文仍在写「一百万次请求免费」，那套按请求计数的方案已经废弃了。照旧文估成本会算出一个不存在的数字。计费这一层的整体结构，OpenRouter 使用与计费那篇可以配合看，但里面出现的任何具体数字都要回官方页面核一遍现值。

计费规则本身的变动口径也要一并迁。力达云这边的写法是：可用模型的增减、计费规则与倍率的调整、频率限制的变化都以站内公告与控制台的模型列表为准，这条写进了网关服务条款。你在评估任何一家的时候都值得去翻这一条——「规则怎么变、从哪里通知」比当下的具体数字重要。

五、免费模型池与每日免费额度，没有对应物

OpenRouter 目录里有一批零价模型（那天的快照里是 22 个），另外免费账号有一个很低的每日请求上限，充一笔小额之后每日免费额度会提升一个数量级，而这笔钱同时还是你的付费余额。这里有个容易忽略的细则：失败的请求也计入每日配额，所以调试阶段配额消耗得比预期快是正常的。

这一整套东西在国内网关那边基本没有等价物。国内平台的免费策略通常是厂商各自的试用额度，形态不一样，不能当成同一种东西来规划。力达云一期更直接：只有注册赠送的试用额度，充值尚未开放——需要可持续付费额度的项目，一期的我们不满足要求，这一条同样列在怎么验证我们那页的减分项里。

如果你的用法里有一部分是靠零价模型跑的（批量清洗、离线标注、低价值分类这类），迁移时要给这部分单独想办法，别默认它会自动落地。

六、条款那一层也要重新读一遍

工程迁完了，合同没迁完，这种情况很常见。

OpenRouter 服务条款第 7 节禁止行为第 4 项的原文是：access the Site or Service for purposes of reselling API access to Models or otherwise developing a competing service。第 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.

这两条的意思是：如果你的产品对外提供了 API 形态的能力，那么你在 OpenRouter 上的用法本身就受这套条款约束，而且上游厂商的 Model Terms 会通过合同传到你的下游用户那里。换到新的上游之后，这套约束链条要整条重建——新上游有它自己的转售与分发限制（各家写法不同，有的要求事先书面同意），你的用户协议里对应的条款也得跟着改。

这里只是把条款原文和它约束的范围摆出来，不构成法律意见，你的具体做法是否合规请咨询专业律师。

七、一份可勾的迁移检查清单

按顺序过，每一项都要有明确结论而不是「应该没问题」：

1. 列出全部在用模型，逐个标「开源权重 / 闭源旗舰」，闭源那部分直接标记为不可迁。
2. 统计每个模型的实际流量占比，把占比小于阈值的长尾模型单独列出——这部分往往不值得为它迁。
3. 把 base_url 和 model id 全部收成配置，确认代码里再没有硬编码的模型字符串。
4. 建一张 model id 映射表，注明目标平台上该模型的完整名称，包括是否有付费档/加速档的前缀差异。
5. 找出所有依赖平台特有返回字段的地方（路由信息、供货方信息、平台自定义的用量字段），把这些依赖抽掉或加上兼容分支。
6. 重写客户端的限流与重试：新上游的速率口径是另一套，旧参数不能直接照搬。
7. 补上原本由平台承担的回退逻辑：主模型失败时切到哪里、切几次、什么情况下直接对用户报错。
8. 用最近一段真实 token 分布，在两种计费口径下各算一次成本，别用系数换算。
9. 把靠零价模型或每日免费额度跑的那部分负载单独拎出来另做方案。
10. 重读新上游的服务条款，尤其是转售与分发限制，以及规则变更的通知方式。
11. 小流量、非核心链路先跑一段时间，同时保留回切旧配置的能力。
12. 按你自己的方法测一遍身份与扣费，别信任何一方的自我声明，包括我们的。

第 3 步和第 4 步做完，这次迁移的大部分工程风险就已经消掉了；剩下的风险集中在第 6、7 两步——那是原本平台替你承担、现在落回你自己头上的部分。

八、所以大多数人不该整体迁移

写到这里，结论跟这类文章通常的走向相反：大多数人不该把负载整体迁走。

理由很直接。你的模型清单里只要还有闭源旗舰，整体迁移这个选项就已经不成立了——不是成本问题，是入口不存在。而对开源权重那部分，把它换个入口确实可能带来可达性和延迟上的改善，但这部分收益是按模型算的，不是按平台算的。

更划算的做法是把第 3 步那件事做彻底：base_url 与 model id 收成配置，然后按模型分流。哪个模型走哪条路，由那个模型自己的可达性、成本和条款约束决定，而不是由「我要用哪个平台」这个先入的决定支配。做到这一步之后，「迁移」就不再是一次性的大工程，而变成改一行配置——这也是它真正的价值所在。

对力达云来说，这句话的含义同样直白：我们一期只接 DeepSeek，所以最多只能占据你分流表里 DeepSeek 那一行，而且这一行值不值得给我们，你应该先把我们不占优的地方看完，再拿小流量自己测，然后自己下判断。如果你在 OpenRouter 上根本没用 DeepSeek，那这整篇文章对你的用处就只是前面那七节的迁移方法——这挺好，不必迁过来。