闭源模型有哪些

团队要上大模型，先翻榜单容易挑花眼：闭源模型到底有哪几家、各自走哪个平台接、按什么口径收费，经常没人说得清。这篇不排名次，也不替你拍板，只把闭源阵营按厂商—接入通道—计费方式列成一张可核对的表，再给一套从需求到验货的顺序。价格和规格这类会变的数字，一律到站内对应页面查当时的数。

团队选型时最容易犯的错，是把「谁最强」当成第一个问题。更实用的顺序是先问「闭源模型到底有哪几家、各走哪个口子接、按什么口径收费」。这篇不排名次也不替你拍板，只把闭源阵营按厂商、接入通道、计费方式拆成可核对的条目，再给一套从需求圈定到小流量验货的顺序。凡是会变的数字，价格、额度、型号清单，一律到站内对应页面看当时的数，别信别人截图里的旧数据。

先说清一个前提：闭源不等于不好用，开源也不等于免费。判断两条线得分开——一条看权重是否公开，另一条看接入通道是否可替换。很多团队纠结半天，其实卡在第二点上：能不能换通道、换的时候改配置还是改代码，比模型名字本身更影响长期成本。

先分清：什么叫闭源模型，哪些算

判断标准不是「有没有 API」，而是权重不公开：只能通过官方或授权云厂商的接口、订阅产品调用，拿不到权重文件自己部署。所以「能不能本地跑」不是开源判据，有些模型权重开放但许可证有限制，有些模型官方只给你托管接口，这两类要分开看。

• 官方托管接口型：只有 API 和网页产品，权重完全不对外，典型是各家旗舰对话模型
• 权重开放但许可证受限型：文件能下载，商用条款、署名要求、衍生限制各不相同，接之前读许可
• 聚合平台上的第三方模型：背后可能是开源权重被别人托管，接入前先确认上游是谁，别默认它是闭源

什么情况下这篇不适用：如果你的硬约束是数据不出内网、必须自持权重，那闭源这条路直接排除，先去看私有化部署相关的页面，别在闭源名单里浪费时间。

主流闭源阵营：按厂商分几组看

海外主线大致是 OpenAI、Anthropic、Google、xAI 这几家，各自都有官方 API 和消费级订阅两条口子，区别在长文本、多模态、推理型能力侧重不同。国内主线是百度、阿里、腾讯、智谱、月之暗面、MiniMax、阶跃、讯飞等，多数同时提供官方 API 和云厂商托管版本，接入路径比海外更分散，选的时候要连通道一起考虑。

第三类和第二类差在「同一个模型、不同买法」。云平台能跟已有云账单、合规体系合并，代价是模型更新往往滞后，参数命名也和原厂文档不一样。这些差异点可以在 /official-api/providers/azure 和 /official-api/providers/amazon-bedrock 对照着看。名字别背，各家的清单都在变，到 /models 模型库按厂商筛当期在架的型号更靠谱。

接入方式对照：官方直连、云托管、聚合平台

官方直连拿原厂 key，参数和限流最接近原厂文档，缺点是结算单一币种、部分地区开户有门槛、一个 key 只能调一家。云厂商托管的好处是能跟已有云账单和合规体系合并，代价是模型版本更新滞后、接口字段有差异。聚合与中转适合先横向试，但可用性和计费口径得自己验。

1. 确认上游点开你要用的模型名，查它是哪家原厂、版本对不对，别只看聚合页上的展示名
2. 量延迟与稳定性用真实业务请求跑一轮，接口延迟基线可以先在 /tools/speed-test 量一遍，别用 ping 代替
3. 验计费口径确认它按输入、输出、缓存哪几项算，是否含图片或音频单位，再看 /sites 中转站目录里的实测记录
4. 留备用通道同一个模型至少准备两条路，核心链路用官方直连保稳定，边缘任务和试新模型走聚合

混合策略很常见：核心链路走官方直连，试新模型和低优先级任务走聚合，别把鸡蛋放一个通道里。中转到底靠不靠谱，选之前先走一遍 /tools/verify 的实测口径，再对照 /sites 里的记录，比自己拍脑袋判断强。

价格与额度怎么核对，别被单价骗

闭源模型的计费至少看四项：输入价、输出价、缓存命中价、图片或音频等非文本计费单位。只看「每百万 token 多少钱」会算错，尤其是长上下文、多轮对话、带缓存复用的场景，四项权重完全不同。同一个模型在不同平台的单价可以不同，促销期和常规期也不同，具体数字到 /official-api 官方 API 价格和 /price-watch 价格变动追踪核当时的值。

输入价

你送进去的提示词与上下文按这个口径算，长文档场景占比很高

输出价

模型生成的 token 口径，通常比输入贵，写作类任务要重点看

缓存命中价

同一段前缀反复复用时可能走折扣价，多轮客服场景受益明显

非文本单位

图片、音频、视频往往按张或按秒算，和 token 不是一个口径，不能直接相加

订阅制产品是另一套账：月费换的是额度而非无限量，折算方式见 /coding-plans 编程套餐目录，按团队人数和日均调用量算人均成本。什么情况下不适用：调用量很小、以人工交互为主的场景，额度型订阅往往比按量更划算，但反向结论不成立——量大到一定程度，按量或专线议价通常更可控。

选型动作清单：四步从需求走到验货

下面这四步是给选型中的团队用的排查顺序，每一步都有明确的淘汰标准，别跳步。跳步最常见的后果是拿榜单排名代替需求，选完发现数据出不了内网，或者换模型要改代码。

1. 第一步 圈硬约束数据能否出内网、要多模态还是纯文本、上下文要多长、是否要求国内备案。任一条不满足的厂商直接划掉，不进入比价环节
2. 第二步 拉候选并对齐口径到 /models 按任务类型和厂商筛出两三家的当期型号，再用 /official-api 对齐计费口径，不要跨口径比价，比如拿含缓存折扣的价去比不含的
3. 第三步 小流量试跑用真实业务样本而不是公开题，跑一批看延迟、格式遵循和中文表现，尤其看结构化输出是否稳定
4. 第四步 做回退方案确认换模型时改的是配置还是代码，留一条备用通道，验证与回退的检查项参考 /model-upgrade-migration-checklist 的思路

最后提醒一句：这套顺序的前提是团队已经有明确业务场景。如果还在探索期、连任务形态都没定，先别做正式选型，拿几个候选各跑一批真实样本，比开会讨论快得多。

闭源模型选型不是挑最强的那个，是挑约束最少、通道最多、口径最清楚的那个。