国内大模型聚合平台有哪些

你可能已经决定不自己跑模型，也不想注册一堆厂商账号，就想找一个地址、一个 key 调遍国内主流模型。但真去搜「聚合平台」，跳出来的大多是二手转卖，价格、模型版本、限速都写得含糊。这篇不给你排名，给一套分类方法和接入前的核查动作，让你自己能判断哪些平台值得试、哪些直接跳过。

你可能已经决定不自己跑模型，也不想注册一堆厂商账号，就想找一个地址、一个 key 调遍国内主流模型。但真去搜「聚合平台」，跳出来的大多是二手转卖，价格、模型版本、限速都写得含糊，有的连模型清单都是一年前抄来的。

这篇不给你排名，也不替谁背书，给一套分类方法和接入前的核查动作。你看完应该能自己判断：哪些平台值得先拿个小项目试，哪些看一眼就该跳过。前提是你手上有个能跑通的最小调用脚本，不然下面的验证动作没法做。

先分清：什么算聚合平台，什么只是转卖

聚合平台这个词被用得太泛。严格说，只要你能用一套协议、一个凭证，调到多个不同来源的模型，就算聚合。但背后的资源来源差别极大，决定了它的稳定性、价格和风险完全不同。按背后资源分，市面上的东西基本落在四类里。

云厂商自营多模型广场

云厂商自己谈下来的模型合作，同一控制台里选不同模型，计费和工单在同一体系内。

开源模型托管平台

主打托管开源权重模型，按算力或调用量计费，模型来源可查。

协议转换网关

自己不做模型，只做接口协议转换和路由转发，把请求打到上游厂商或别的池子。

二手转卖中转站

没有明确上游关系，靠账号池或批量采购转售，价格看着低，来源说不清。

判断方法只有一个：看它能不能说清模型来源和计费口径。凡是问「这个模型是谁提供的」「怎么计量的」就绕开话题的，基本可以归到第四类。四类各有各的适用场景，混在一起比价格没有意义，因为比的可能根本不是同一个东西。

不适用的场景也要提前说清：如果你要的是稳定生产环境，第一类和第二类更靠谱；网关类更适合当备用通道或内部工具；二手转卖类只适合拿来验证一个想法，别把业务压上去。

接入前必须核对的四件事

宣传页写得再漂亮都不算数，接入前拿下面四件事逐一过一遍。这四件事不需要什么高级工具，一个能发请求的脚本加一点耐心就够。任何一项卡住，先别充钱。

1. 查模型清单是否实时拿一个最近新出的模型名去搜，看它在不在列表里、有没有标注可用状态。只有一份静态表格、连更新时间都找不到的，多半是抄来的。
2. 看计价单位是否写清输入和输出是分开计还是打包计，缓存命中怎么算，图片是按 token 还是按张。只写一个单价、不写计量单位的，先当成没写。
3. 找限速与并发说明是每分钟请求数还是每分钟 token 数，超限是排队等待还是直接报错，有没有并发上限。这些写在文档哪一页，让客服指出来。
4. 跑一遍在线实测到 /tools/verify 中转站真假在线实测 发真实请求，看连通性、响应结构和报错行为，比看宣传页有效得多。

官方渠道和聚合平台的价差从哪来

很多人第一次接触聚合平台，是因为它看着比官方便宜。但便宜本身不是问题，问题在便宜的来源。搞清楚来源，才知道这个便宜能不能长期用、会不会突然断。

• 批量采购折扣：平台跟上游谈量拿到的价，属于正常商业行为，通常最稳。
• 共享账号池：多个用户共用上游账号，便宜但可能互相挤占额度，掉线是常事。
• 开源模型顶替闭源模型：收闭源的钱，背后跑的是开源权重，这是最需要警惕的一种。
• 赠送额度冲量：前期用补贴把价格压低，补贴停了价格就变，别把补贴价当常态。

比价时不要拿官方价和聚合价直接相减，先确认两边调的是不是同一个东西、计费口径是不是一样。具体数字去 /official-api 官方 API 价格 和 /price-watch 价格变动追踪 看当时的记录，别记别人截图里的旧数。

不适用的情况：如果你的用量很小，价差本身对你影响有限，这时候更该关注的是稳定性和对账方便，而不是单价差那一点。

怎么确认调到的真是那个模型

模型身份是聚合平台最容易出问题、也最难发现的地方。你看到的模型名是平台自己填的，不代表后端就是那个模型。所以需要一套自己的验证办法，而不是信页面上的标签。

最实用的方式是自己准备一组固定的测试题，每次换平台、换时间段都跑一遍，对比官方渠道的回答。下面这些信号值得记下来，出现任意一条就要多留个心眼。

留意同一 key 在不同时间段返回质量是否波动。波动大往往说明背后是池化调度，你的请求被分到哪个后端不确定。识别方法和排查顺序可以参照 /tools/verify#probes 探针原理，按那个顺序走一遍比零散试探高效。

计费口径里最容易吃亏的几种写法

计费口径的坑不在于单价高低，而在于你按 A 理解、平台按 B 计量。接入前把下面几种写法对照自己的业务场景过一遍，能省掉后面很多扯皮。

• 只写单价不写计量单位，实际按字符而不是按 token 计，长英文文本吃亏明显。
• 把输入缓存和新建上下文混在一档价里，多轮长对话场景成本被放大。
• 赠送额度有有效期和并发限制，按量付费和赠送额度可能不是同一个资源池。
• 按次计费但单次有隐藏长度上限，超出部分走另一档价，账单才看得出来。

对账办法很简单但必须做：接入第一个月按天记录用量，月底和账单核对一次。差得多就说明口径对不上，早点换比拖到量大了再换省事。对账模板和常见口径说明可以到 /price-watch 价格变动追踪 配合着看。

数据走谁的路上云，这一步别省

这一步很多人直接跳过，等出问题才想起来问。你发出去的请求里可能带着用户输入、内部文档片段或者业务数据，走了谁的服务器、留多久，是需要提前问清的。

要问的问题不复杂，但要求对方给出明确答复：请求是直连模型厂商，还是先落在平台自己的服务器上再转发。后者意味着多一个数据经手方，多一层需要评估的风险。

• 能不能提供调用日志导出，出问题时有据可查。
• 数据留存策略写没写清楚，留存多久、谁能访问。
• 涉及用户个人信息或企业数据的场景，优先选能给出书面说明的平台。
• 对方说不清数据流向、或者拒绝给出任何书面材料的，直接排除。

接入怎么写才不至于被绑死

聚合平台的价值之一是方便，但如果你把平台特有的接口写进业务代码，方便就变成绑死。写法上做几件小事，将来换平台就是改配置的事。

1. 统一走兼容协议优先选支持 OpenAI 兼容协议的平台，换平台时只需改 base_url 和 key，业务代码基本不动。
2. 把变量抽到配置层模型名、超时时间、重试次数都放配置文件或环境变量，不要在业务逻辑里写死。
3. 准备降级链路配一个备用地址，主平台不通时自动切换。切换逻辑提前写好，别等出事再临时改。
4. 按三步验证每次换平台按「连通性—模型身份—用量对账」的顺序验一遍，三步都过再切正式流量。

# 换平台后先跑最小连通性检查，再验模型身份，最后对一天用量
curl -s -X POST "$BASE_URL/chat/completions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"MODEL_NAME","messages":[{"role":"user","content":"你的版本信息是什么"}]}'

哪些情况别用聚合平台

前面讲的都是怎么选、怎么验，这一节反过来讲什么时候干脆别用。聚合平台有它的位置，但不是所有场景都合适，硬套上去反而给自己找麻烦。

结论是：聚合平台适合拿来试模型、跑内部工具、做备用通道，不适合当唯一的生产入口。判断标准不是平台好不好，而是你的场景能不能承受那多出来的一跳。