OpenRouter 几百个模型是怎么来的：开源权重乘多家供货方

做技术选型的人多半见过这样一张表格：横轴是几家聚合平台，纵轴第一行永远是「支持模型数量」。谁写的数字大，谁就在这一格赢了。我自己也做过这种表格，直到有一次被问住——「那四百多个模型，是跟四百多家谈下来的吗？」

当时我答不上来。后来把这个数字拆开看，才发现它的构成跟大部分人的想象差得很远，而拆开的过程恰好能解释聚合网关这层东西到底在做什么生意。

一、三行数据，解释了几百个模型是怎么堆出来的

先说清来源：下面这组数字不是我自己跑出来的，是同事在 2026 年 9 月 15 日 这一天，直接调 OpenRouter 官方 API 拉下来统计的。OpenRouter 有一个查单模型供货方的接口，形如 /api/v1/models/{id}/endpoints，给它一个模型 id，它返回这个模型在平台上所有可用的服务端点。逐个查下来，三个模型的结果是这样：

模型	供货方家数	具体是谁
deepseek/deepseek-chat-v3.1	8 家	DeepInfra、SiliconFlow、Novita、AtlasCloud、CoreWeave、Mara、Google、SambaNova
z-ai/glm-4.6	5 家	Venice、DeepInfra、Novita、AtlasCloud、Z.AI
qwen/qwen3-max	1 家	Alibaba

请把这张表当成某一天的快照读，不要当成长期结论。供货方名单是随时会变的东西——有平台上线新机型就会加进来，有平台下架某个模型就会消失。我给出具体家数不是为了让你记住「八家」这个数，而是为了让你看清前两行和第三行之间的结构性差别。

前两行是开源权重模型。权重公开发布，任何一家有 GPU 又有推理工程能力的平台，都可以自己拉下来起一份服务，然后把这个端点挂到聚合层上卖。第三行是闭源模型，权重不对外，只有模型厂商自己能提供推理服务，所以聚合层上就只能有厂商这一个入口。

一句话说完：平台目录里的模型总数，主要是「开源模型清单」乘上「愿意托管它的平台数量」堆出来的，不是几百份商务合同堆出来的。

二、目录总量的构成也印证了这一点

同一天的另一组统计，来自直接拉 /api/v1/models 这个公开目录接口：全量 445 个模型，分属 59 个厂商前缀，其中 22 个标价为零。中国团队发布的模型大约 124 个，占比接近三成，里面 qwen 系最多，其次是 deepseek、z-ai、minimax、moonshot、tencent、bytedance-seed、inclusionai 这几家。

再强调一次，这也是一天的快照。我写下这些数字的唯一目的是让你有个量级感：59 个厂商前缀对应 445 个模型条目，平均一个厂商前缀下挂七八个条目。而这 445 个条目里，还有相当一部分同名条目在不同供货方那里各有一份端点——目录里显示的是一个模型名，背后可能是八套互不相同的部署。

这就是为什么「支持模型数量」这个指标在横向比较里几乎不承载信息。它的增长有两条路径完全不同的来源：一条是开源社区又发了新模型、又有平台愿意托管；另一条是真的谈成了一家闭源厂商。第一条几乎是自动发生的，第二条才是难的。两者混在同一个数字里，这个数字就没法用来判断任何事情。

关于平台侧的整体接入与计费口径，OpenRouter 使用与计费详解里讲过一遍，本文只沿着「供给从哪来」这条线往下走。

三、为什么加一个开源模型的供货方成本很低

看过接入要求就明白了。OpenRouter 面向供货方的文档把门槛写得很具体，一家推理平台想把自己的端点挂进去，需要做到这些事：

• 实现一个 List Models 端点，返回带类型标注的输入/输出模态、能力、约束、定价和容量；
• 至少声明一种输入模态和一种输出模态；
• 用 USD 字符串声明输入、输出、请求这三个维度的价格；
• 声明自己的吞吐容量；
• 满足正常路由所需的可用率门槛；
• 支持性能指标采集，包括首 token 时延与吞吐。

这是一套自助入网规范，不是一场谈判。你把接口按规范实现好、价格和容量按格式声明清楚、可用率达标，就能成为供货方之一。对一家已经在跑开源模型推理服务的平台来说，这是几天的对接工作量，不是几个季度的商务周期。

还有一条容易被忽略但很关键——资金流方向。官方文档在接入要求里写得很直白：

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

也就是说，是 OpenRouter 付钱给供货方，供货方要能接受自动付款（自动充值或者走发票）。用户的钱进了 OpenRouter 的余额，OpenRouter 再拿这笔钱去买各家的推理。理解这个方向很重要：它解释了为什么平台有动力把同一个模型的供货方谈到很多家——供货方之间在同一个模型名下的价格与性能竞争，直接改善平台自己的采购成本与可用率。

也解释了为什么闭源旗舰不走这条路。让一家顶级模型厂商去实现别人定义的 List Models 规范、按别人的格式声明价格、接受被自动路由到的位置，这是商务问题不是技术问题。闭源模型能上架，靠的是另一套逻辑：聚合平台本身是发行渠道——新模型首日上架能吃到第一波流量，匿名模型可以放上来做盲测，用量榜单本身就是营销素材。据公开报道，这是不少厂商主动上架的动机。这条渠道价值跟「模型数量」是两件不同的事，堆不到一个数字里。

四、同一个模型名下有八家，对你的代码意味着什么

这是本文真正想让你带走的部分。当你在 OpenRouter 上调用一个开源模型名时，你调到的是那一刻被路由到的某一家供货方的部署，而不是一个唯一的、确定的服务。同一个权重在不同平台上，这些地方都可能不一样：

1. 量化与精度。各家自己决定用什么精度跑，输出质量的细微差别常常源自这里，而模型名完全相同。
2. 上下文上限。同一个权重，有的平台开满，有的平台为了吞吐砍短。
3. 限速口径。每家的并发与速率策略各按自己的来。
4. 日志与数据政策。OpenRouter 官方称对 prompt 和 completion 零日志（除非用户自己开启），并提供隐私设置来避开有日志行为的供货方——这条设置存在本身，就说明供货方之间在数据处理上是有差异的。
5. 可用率与时延。平台会采集首 token 时延和吞吐指标，这些指标的存在前提就是各家表现不同。

所以「换了个供货方，同样的 prompt 结果变了」并不是玄学，是这层机制的直接后果。如果你的业务对输出稳定性敏感，就不能只把模型名收进配置，还得把「允许哪些供货方」这件事也当成配置项管起来。按成本或按稳定性做路由的思路，多上游按成本路由那篇讲得更细。

顺着这一层再往下看一步会更有意思：这些供货方名单里出现的公司，本身也在做零售生意。你直接注册用的某家推理平台，很可能同时在给聚合层批发供货——硅基流动也是供货方那篇就是顺着这条实测名单展开的。零售和批发同时做，是这一层的常态。

五、那该比什么

如果「模型数量」不能用，选型时我会换成下面这几个问题去问。它们都能自己动手查，不用信任任何一篇文章的结论：

• 你真正要用的那几个模型，各有几家供货方。 一家都没有富余的（比如闭源旗舰只有厂商一个入口），意味着供货方层面没有任何回退空间——厂商那边出问题，聚合层帮不了你，它只是个转发。多家供货的模型才有真正的容灾价值。
• 路由能不能按你的标准选。 你是要最低价、最低时延，还是必须避开有日志的供货方？能不能锁定到指定的某一家？这个能力比目录长度有用得多。
• 锁定供货方之后还剩几家。 如果你因为合规要求排掉一半，剩下的还够不够撑住你的并发。
• 计费口径是不是随路由变。 不同供货方在同一模型下报价不同，这意味着你的单位成本会随路由结果浮动，做预算时要按区间算而不是按一个点算。
• 模型名里的变体后缀你搞清楚了没有。 目录里同一个模型常有多个变体条目，选错条目跟选错模型的后果是一样的。

关于自带上游 key 时这套账怎么算，OpenRouter 的 BYOK 计费是另一篇单独讲的——那里有个很多人踩的旧信息问题，按旧文估成本会算错。

六、几句得说清楚的话

第一，本文引的所有具体数字都是 2026 年 9 月 15 日那一天的快照，而且是同事用官方公开 API 拉的，我没有做任何压测，也没有验证过任何一家供货方的实际表现。数字明天就可能不一样，你要用就自己拉一遍——两个接口都是公开的，比读文章可靠。

第二，这篇文章解释的是机制，机制不能替代实测。知道一个模型有八家供货，不等于知道这八家在你的负载上表现如何。真正要下决定之前，用你自己的 prompt 分布、你自己的 token 长度比例，把候选供货方各压一遍，这件事没有捷径。

第三，如果你的实际需求是「只用一两个国产模型、要稳定的国内直连」，那这整套「多供货方路由」的价值对你可能并不高——你需要的是一条确定的链路，而不是一个可选择的池子。力达云做的就是后一种场景，但必须说清它的限制：一期只接 DeepSeek，如果你在 OpenRouter 上主要用的是别的模型，它给不了；它是独立第三方，与任何模型厂商都没有官方合作、代理或授权关系。这些边界写在身份与边界说明里，签约或者接入之前请先读那一页，别按本文的语气想象它的能力范围。

最后一句留给那张表格：下次再有人拿「支持模型数量」这一行来比聚合平台，你可以直接跳过它，把光标移到「我要的那几个模型各有几家供货」上。前者是营销口径，后者才是工程口径。