OpenRouter 与国内聚合网关的结构性差异

一个做海外工具的小团队开会定接入方案，讨论到一半有人把问题收成了一句话：「所以我们到底是用 OpenRouter，还是用一家国内的聚合网关？」当天没人能接住这句话，因为它把两样结构不一样的东西摆到了同一条比较线上——就像问「批发市场和便利店选哪个」，答案取决于你要买什么、买多少、以谁的名义买。

后来这个团队的实际做法是两边都留着：有几个模型只能从一边拿到，另外几个模型两边都有但条款不一样。这篇不比谁强，只把两类接入层在结构上到底差在哪儿逐条拆开，最后给一张你可以拿着自己去核的判据表。

需要先说明一件事：国内这一侧，我只拿硅基流动这一家做逐条比对，因为它的用户协议、充值协议和模型广场都是公开可查的原文。其他国内平台各家条款不同，本文不替它们说话；表格里凡是要落到某个具体平台的格子，我写的是「该去查哪一页」，不是给你一个答案。

一、两侧不是同一层的两个候选

先把定位摆正，后面五条差异才好理解。

OpenRouter 的角色是市场的组织者。它自己不托管模型推理，而是把一批推理平台组织成供货方，你调一个模型名，它把请求路由到某个供货方那里。它给供货方定了一套准入要求：必须实现 List Models 端点，返回带类型的输入/输出模态、能力、约束、定价和容量；至少声明一种输入与一种输出模态；用 USD 字符串声明输入、输出、请求这三个维度的价格；声明吞吐容量；满足正常路由所需的可用率门槛；还要支持性能指标采集（TTFT 与吞吐）。资金流方向也写在接入文档里，原文是：

For OpenRouter to use the provider we must be able to pay for inference automatically.

也就是说钱是 OpenRouter 付给供货方的（自动充值或走发票），不是你付给供货方。这一条决定了后面一连串的结构后果。

硅基流动这类国内平台的角色是货源本身，同时兼零售。按公开说明，它不是模型厂商，而是推理云平台／模型聚合器：把开源模型统一接入，由平台托管、做负载均衡与推理优化，用户不必自己在 GPU 上部署。你调它的 https://api.siliconflow.cn/v1，背后就是它自己那一份托管。

这两个角色不是对立的，证据很直接：我在 2026-09-15 用 OpenRouter 的 /api/v1/models/{id}/endpoints 接口查 deepseek/deepseek-chat-v3.1 这个模型，返回的供货方列表里就包含 SiliconFlow，同列的还有 DeepInfra、Novita、AtlasCloud、CoreWeave、Mara、Google、SambaNova。一家国内平台既可以直接零售给你，也可以作为货源出现在境外聚合层的供货名单里。所以「OpenRouter 还是国内网关」这个问法，有时候问的是同一份算力的两个购买路径。关于「接入层」这个概念本身有哪几种形态，可以先看中转站、官方直连与自建网关怎么选，这篇只谈聚合层内部的两种结构。

二、差异一：供给来源——多家竞供，还是自己托管

这是最根本的一条，其余四条差异基本都是它的推论。

在 OpenRouter 这一侧，一个模型名背后可能有多家供货方。还是 2026-09-15 那天逐个查 endpoints 接口看到的：开源权重的 deepseek/deepseek-chat-v3.1 有八家供货，z-ai/glm-4.6 有五家（Venice、DeepInfra、Novita、AtlasCloud、Z.AI），而闭源的 qwen/qwen3-max 只有 Alibaba 一家。这几个数随时会变，你读到这篇时大概已经不是这个数了——重要的不是数字，是这三行呈现出的形状：开源权重谁都能托管，于是同一个模型变成一个有多家卖家的品类；闭源旗舰只有厂商这一个入口，于是它是一个独家品类。

这个结构给你带来一件好事和一件麻烦。好事是同一个模型有备选供货方，路由层面有回退的余地。麻烦是「你调到的到底是谁托管的那一份」变成了一个变量：不同托管方的推理配置、量化方式、上下文上限、限速口径都可能不一样，而这些差异往你的 P99 延迟和输出稳定性上传导。选型时该问的问题从「这个模型行不行」变成了「这个模型在这条路上是谁托管的、我能不能把供货方钉死」。

在国内自营平台这一侧，结构是反过来的：一个模型名背后就是它自己那一份托管，没有「换一家供货方」这个概念。它自己承担托管质量，也自己承担容量波动。少了一层不确定性（你不必猜是谁在跑），也少了一层弹性（这家挤爆了就只能你自己在客户端切别家）。

一个容易被忽略的细节：硅基流动同一个模型有两种名字。按官方公告，命名规则是免费版沿用「厂商/模型名」，付费加速版加 Pro/ 前缀，请求示例里的模型名形如 Pro/deepseek-ai/DeepSeek-R1；带前缀的是付费加速版，不带前缀的免费版速率与并发更低。所以这一侧「同一个模型的不同版本」是靠模型名字符串区分的，而 OpenRouter 那一侧「同一个模型的不同来源」是靠供货方区分的。两种区分方式落到代码里完全不是一回事：一边你要管的是 model id 字符串，一边你要管的是路由偏好。

三、差异二：商业模式——不确定性被放在了不同的环节

OpenRouter 对 token 不加价，文档原文是：

We pass through the pricing of the underlying providers; there is no markup on inference pricing.

它的收入来自充值环节的百分比手续费。非加密与加密两种通道费率不同，且非加密那条有最低收费——这意味着小额充值的实际费率会显著高于大额充值。具体百分比和最低额我不写，因为这类数字下个月就可能调整，以它自己的页面为准。

这个模式的结构后果很有意思：它的收入跟你调多少 token 无关，只跟你充多少钱有关。 于是它没有动机把你往贵模型上推，但你的单位成本会随充值节奏变——同样花一万块，分二十次充和分两次充，摊进去的手续费不是一个数。所以在这一侧算成本，你要算的是「充值节奏」这个变量，不是「调用量」这个变量。很多人把手续费当一次性成本忽略掉，等到财务月结时对不上账，原因就在这儿。

BYOK 这个功能也要放在这个框架里看才讲得通。它允许你自带上游 key，把「谁跟厂商签约」这件事挪回你自己头上，于是你和厂商的直连关系与折扣能保住。但它不是免费的：按 list-price 口径给一个每月免费额度（按档位不同），超出后按「同模型同供货方在 OpenRouter 上应付价格」的一个百分比收费，从你的 OpenRouter 余额扣。这里有一个现在还在传的旧说法要纠正——网上大量文章仍写着「一百万次请求免费」，那套按请求计数的方案已经废弃了，现行方案是按 list-price 金额计。拿旧文估成本会直接算错一个量级。

国内自营平台这一侧，价格在模型广场上按模型公布（模型广场同时能看到模型、价格与限速），收入就来自推理本身。它的不确定性不在充值环节，在限速。 按官方公告，分层限速设六种用量级别（0 到 5），按账号的月度消耗金额划分，新用户注册后默认最低级，等级越高 RPM 与 TPM 越高；也可以通过充值「等级包」一步到位升级。也就是说你的可用速率不是一个固定规格，而是随你的消费额动态变的。具体各级的数值我一律不写，以它的限速文档与模型广场为准。

把两边并起来看，有一个共同点值得点出来：两边都拿「付过钱」当闸门，但闸门的变量不同。 OpenRouter 那边是「有没有充过一笔」——免费账号每日请求上限很低，充一笔小额之后每日免费额度会提升一个数量级，而且这笔钱同时变成付费余额；注意失败的请求也同样计入每日配额。硅基流动那边是「这个月消耗了多少」——是个连续变量，不是一次性动作。一个是台阶，一个是斜坡。你要做容量规划的时候，这两种形状要用完全不同的算法去估。关于成本口径和路由策略怎么一起算，网关的成本与路由里有更细的拆法。

四、差异三：条款结构——「可以往下传但必须传下去」与「默认别往下传」

这一节只引条款原文并说明它约束了什么现实做法，不做任何法律判断。

OpenRouter 的服务条款第 7 节禁止行为第 4 项，原文是：

access the Site or Service for purposes of reselling API access to Models or otherwise developing a competing service

一句话里并列了两件事：转售对模型的 API 访问，以及开发竞品服务。拿它当上游做一个自己的对外 API，这两条通常会同时被碰到。

更值得注意的是第 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.

这一条是条款下传：它要求你去要求你的授权用户和客户按本协议、按 OpenRouter 的文档、以及按适用的 Model Terms 来使用。换句话说，上游厂商的各种限制通过合同链条传到了你这里，你的用户协议里也得有对应约束。它的结构是链式的——允许你有下游，但把义务往下接的活儿是你的。

硅基流动的条款结构不是链式的，是边界式的。它的用户协议里，授权是「非排他性的、不可转让的」访问和使用权，仅用于个人使用或所代表公司/实体的内部业务目的，未明确授予的权利全部保留；同时明确未经事先书面同意，不得购买、出售或转让 API 密钥，也不得复制、出租、出售、贷款、转让、许可或意图转授、转售、分发本服务的任何部分或其知识产权。充值协议里还有一条独立的约束：用户如委托第三方代充值，须保证了解并信任该第三方；若平台被第三方告知该充值未经其同意，平台有权立即封禁账户，封禁期间暂停 API 请求等全部服务，并要求充值资金来源合法。

所以这两套条款的形状不同：一个说「你可以有下游，但必须把约束传下去」，一个用「内部业务目的」直接把范围划出来。你的业务形态如果涉及给外部客户提供访问，这两种形状要各自对照着看自己的协议文本。

有一条正向信息不该漏掉：「未经事先书面同意」这个措辞说明官方留了商务通道，而不是一条死路。前面那个实测已经证明它自己就在给境外聚合层供货，跟 DeepInfra、Novita 这些托管方并列出现在供货名单里——它显然有一套 B2B 的合作方式。所以真正的路径是去谈授权，而不是在条款边缘找空子。力达云自己的条款也摆在 /api-terms/ 上，同样的读法可以拿去对照。

这一节所有内容都只是条款原文的复述与它约束了哪些做法，不能替代法律意见。真要落到具体业务形态上，请找专业律师看你的实际协议文本和业务链条。

五、差异四：可达性与合规负担落在谁身上

这条最容易被简化成「境外／境内」四个字，但实际差别是责任的落点。

OpenRouter 那一侧，你面对的是一个境外主体，而资金最终流向多个境外供货方（那条自动付款的原文就是这个意思）。数据方面官方称对 prompt 与 completion 零日志（除用户主动开启），并提供隐私设置让你避开有日志行为的供货方——注意这句话的隐含前提：因为同一个模型有多家供货方，「选谁」本身就是一个需要你做决策的动作，平台把开关交给了你，责任也就跟着过来了。加上第 5.2 节那条下传义务，合规上你要管的东西是「一条链」。

国内自营平台那一侧，供给单一，托管方就是签约方，你面对一个主体，这一层比较简单。但代充值那条封号条款把另一类负担明确落在了你身上：谁来付这笔钱、这笔钱的来源，是你自己要担保的事。团队走代理采购、走朋友账号代充这类做法，在这条款下的风险由你承担。

说到这里得把力达云自己的位置讲清楚，不然这篇文章就成了单向宣传。力达云是独立第三方接入层，与任何模型厂商没有官方合作、代理或授权关系；一期只接 DeepSeek，也就是说你在 OpenRouter 上跑的 GPT、Claude、Gemini 这些，力达云给不了，这种情况本来就不该考虑迁。我们把公开的信息、能怎么被测、以及现在明确不占优的地方都写在了怎么验证我们这一页上。这一节的判据同样适用于我们自己：一个第三方接入层不能替你解决授权链条的问题，你能核的只有它披露了什么、以及你自己测出来什么。

六、差异五：模型广度的来源不同

两侧的「模型多」不是同一个意思。

OpenRouter 的广度主要来自开源权重乘以托管方数量：一个开源模型被多家推理平台各上架一份，目录条数就成倍地涨。这跟「谈下了几百个商务合同」是两件事。闭源旗舰是另一条逻辑——只有厂商自己那一个入口，能不能首日拿到取决于厂商愿不愿意把它当发行渠道用。而厂商确实有这个动机：新模型首日上架、匿名模型做盲测、用量榜本身就是营销。它的 rankings 页按真实 token 用量排名（prompt 与 completion 都计），按 UTC 日聚合、按模型变体分别排，另有 Trending 视图比较近七天与前七天的百分比变化，并设了最小 token 门槛以免小基数把百分比放大。一个第三方裁判位置，这是国内自营平台结构上没有的东西。

国内自营平台的广度来自它自己接进来的那张清单：开源模型统一接入、自己托管。国产闭源旗舰能不能在某家平台上调到，取决于那家平台有没有对应厂商的渠道，这个没法一概而论，只能一家一家去查它的模型页。几家国内平台在协议兼容面、额度机制和限流信息公开程度上的差别，国内推理平台横向比较里拆得更细。

由此得出一个我认为最实用的结论：比较聚合平台时数模型总数几乎没有意义。 该数的是你负载里真正要用的那三五个模型，各自在这条路上有几个可选来源、以及路由能不能按你的标准去挑。

七、判据表

维度	指向 OpenRouter 这类全球聚合层	指向国内自营聚合平台	你该怎么自己核
模型清单	负载里有闭源海外旗舰（GPT／Claude／Gemini 一类），或需要大量开源长尾做实验	负载集中在少数国产模型，且这几个在目标平台的模型页上能查到	把你实际在用的 model id 列出来，逐个去两边的模型页搜
供货冗余	需要同一模型有备选来源、要在供货方之间做回退	能接受单一托管方，回退逻辑自己在客户端实现	查一下这个模型在聚合层上有几个可选来源，以及能不能钉死其中一个
成本可预测性	能接受单位成本随充值节奏浮动，愿意把手续费摊进核算	希望单次调用的价格口径直接对应模型页，不想算充值摊销	按你真实的充值频次和月消耗额，分别算一次单位 token 的实际成本
速率确定性	能接受「有没有充过一笔」这种台阶式闸门	能接受速率随月度消耗额动态变，并愿意为等级做规划	上线前按自己的 token／请求比压一遍，别照抄任何文章里的数值
条款形状	你有下游用户，愿意也能够把上游约束写进自己的用户协议	你的用法落在「内部业务目的」范围内，不涉及对外分发访问	逐字读授权范围条款和禁止行为条款，把自己的业务形态套进去
付款主体	有合规的境外付款通道，能接受资金流向境外供货方	需要境内付款与发票，且能自己保证充值主体合法	先问财务能不能开票、能不能付，再问技术选型
数据流经方数	能接受请求经过聚合层再到某个第三方托管方，并愿意用隐私设置筛供货方	希望数据只经过一个主体	数清一次请求实际经过几个法人主体，逐个看它们各自的数据条款

这张表里每一行都是「按什么维度看」，不是「哪边得分高」。同一行里两侧都可能是对的，取决于你那一格的实际情况。

八、三种典型负载怎么落到判据上

做海外产品、主力是闭源旗舰。 清单那一行直接定生死：闭源旗舰只有厂商一个入口，国内自营平台给不了，讨论到这儿就该结束。剩下的问题不是选哪边，而是在全球聚合层内部怎么控成本——充值节奏怎么排、要不要上 BYOK 保住你已经谈到的厂商折扣。

国内业务、主力是一两个国产模型、要开票。 付款主体那一行先把范围收窄，然后清单那一行核一下这一两个模型在目标平台调得到，最后速率那一行按你的 token／请求比压一遍看等级够不够。全球聚合层在这种负载里不是不能用，但你为一个国内模型绕一趟境外聚合层，多付了手续费、多经过一个主体、还多了一层条款下传义务，换回来的是供货冗余——值不值得由你算。

两类都有，这是最常见的情况。 这时候正确的动作不是二选一，而是把 base_url、api key 和 model id 三样东西收成配置项，按模型分流。两边都是 OpenAI 兼容的调用形状（硅基流动的文档原话是「当前平台的大语言模型支持通过 OpenAI 库进行调用」），所以这件事的成本主要不在改代码，在于把散落在业务逻辑里对某一家平台特性的隐式依赖找出来。这一侧的具体接入形状可以参考OpenRouter 接入说明。

九、把话说清楚

这两类东西解决的问题不同，同时用不矛盾。全球聚合层解决的是「拿到尽可能多的模型来源、并在来源之间有选择权」；国内自营平台解决的是「一个主体、境内付款、协议边界清楚地拿到某几个模型」。它们在结构上不是竞争关系里的两个候选，更像供应链上不同位置的两种采购方式——真正该问的问题从来不是「选哪个」，而是「我的负载里哪些模型必须走哪条路」。

三件必须说明的事：

第一，本文所有涉及具体条款的段落都只是原文复述和它约束了什么做法，不构成法律意见，落地前请让专业律师看你的实际协议和业务链条。

第二，那几个实测数字（某个模型有几家供货方）是 2026-09-15 那一天拉接口拿到的快照，会变，而且大概已经变了。它们的价值在于呈现「开源权重被多家托管、闭源旗舰只有一家」这个形状，不在于数值本身。

第三，也是最重要的：托管方这一层的信息大多数平台并不公开，性能与稳定性的结论没法从文档里读出来，只能自己压。所以别把任何一篇横评当结论——包括这一篇。把你真实的 prompt 长度分布、并发形状、超时容忍度拿去两边各跑一周，那一周的数据比任何表格都作数。