国内主流AI大模型平台清单

手上有个项目要接大模型，翻了一圈发现能选的国产平台太多：有的主打长文本，有的强在开源模型托管，有的自带算力和微调流水线。这篇按开发者视角把主流平台分成几类，讲清各自的特点、接入门槛和适合谁用，最后给一张按场景对照的挑选清单，让你少走弯路。

手上有个项目要接大模型，翻了一圈发现能选的国产平台太多：有的主打长文本，有的强在开源模型托管，有的自带算力和微调流水线。宣传语看多了容易懵，其实它们背后的定位差别挺大，搞清楚属于哪一类，选型就简单一半。

这篇按开发者视角把主流平台分成几类，讲清各自的特点、接入门槛和适合谁用，最后给一张按场景对照的挑选清单。具体到价格、跑分、模型列表这些会变的东西，一律指向站内页面，你自己按当时的数字核对，别听我在这儿背。

先把平台分成三类，再看名字

市面上名字不少，但按「谁提供模型、谁提供算力、谁提供入口」这三个问题拆，基本能归到三类里。同一家公司的不同产品线也可能横跨两类，所以先问平台属于哪一类，比背名字有用得多。

模型厂官方平台

模型和平台是一家，接口风格统一，适合只认某一家模型的团队，但基本只能用它自家的模型

云厂商大模型平台

把多家模型挂在一个入口下，好处是计费、鉴权、监控和云资源打通，换模型不用换账号体系

聚合与托管平台

主打开源模型托管和多模型切换，适合要试很多模型或不想绑死一家的团队

• 第一类：模型厂自己的官方平台，新模型往往这里首发，缺点是绑得死，想换家要重写调用层；
• 第二类：云厂商的大模型平台，好处是一套账单管所有模型，坏处是每家上的模型清单和更新节奏不一样；
• 第三类：聚合与托管平台，切换成本低，但要接受多一层转发、多一层故障点；
• 命名和定位经常变，别只看宣传语，先确认它属于哪一类，再决定要不要深入；
• 同一个平台可能同时提供官方模型和三方开源模型，看清楚你调的那条线归谁维护

接入方式对照：SDK、OpenAI 兼容与自研协议

接入方式直接决定你多久能跑通第一行代码，也决定以后换平台要改多少东西。三类平台的接入风格差异挺明显，接之前先用最小示例探一遍底，比读文档快。

• 兼容 OpenAI 协议的平台，迁移成本最低，已有代码基本只改 base_url 和 key；
• 自研 SDK 的平台往往在鉴权、流式返回、工具调用上有点差异，接之前先跑通最小示例；
• 关注是否支持流式、函数调用、结构化输出这三项，它们决定你能不能做 Agent 和表单类应用；
• 多模态和嵌入模型常常是另一套接口地址，别默认跟对话接口走同一个入口；
• 不管哪一类，先在测试环境把超时、重试、限流报错各触发一遍，心里有底再上生产

看模型清单要看什么，不看什么

模型清单是选型里最容易看花眼的部分。榜单更新快、名字带后缀、版本一堆，其实真正影响你能不能用的就那么几个维度。先把「有没有」筛一遍，再看「好不好」。

1. 第一步：筛模态先看有没有你要的模态类型：纯文本、图像理解、语音、嵌入、重排，缺一项就要考虑混用两家；
2. 第二步：看硬指标看上下文长度、是否支持推理模式、是否开源权重，这三项直接决定能不能本地兜底；
3. 第三步：固定版本模型名称后面的日期后缀代表快照版本，接入时要固定版本号，避免被静默升级搞崩线上效果；
4. 第四步：自测样本榜单分数和真实任务有差距，挑一批你业务里的真实样本自己跑，榜单结论可到 /benchmarks 对照着看

榜单告诉你谁在标准题上强，只有你自己的样本告诉你它在你场景里能不能用。

计费口径与额度：先算清再签字

计费这块最容易踩坑，因为各家口径不统一，有的按 token，有的按次，有的一口价套餐。别急着对比单价，先把计费模式归类，再按你的用量算总账。

输入输出常是不同单价，长上下文和图片会额外计费，具体数字到 /official-api 和 /tools/model-cost-calculator 按你当时的用量算。我在这儿写任何数字，过两天就过时了，反而误导你。

• 分清按 token 计费、按次计费和套餐制三种模式，套餐制要看清额度折算规则和有效期；
• 免费额度适合做前期验证，不要当成生产预算；限流和并发上限往往比价格更容易卡住你；
• 把「单价 × 预估日调用量」和「套餐月费 + 超额单价」两种账都做一遍，再决定走哪条；
• 问清楚失败重试、超时中断这些异常请求算不算费，很多平台的计费口径藏在这一层；
• 做预算时留一档余量，业务量上来后限流升级往往比涨价更烦人

合规、备案与数据流向

这一节不是给法务看的，是给你这个写代码的人看的，因为数据流向和备案要求会直接砍掉一部分技术方案。上线前先把红线摸清楚，省得写到一半发现方案不成立。

• 面向公众提供服务涉及备案要求，做之前先去 /safety 确认当前口径，别等上线才发现；
• 数据出不出内网是硬约束：金融、医疗、政企类项目通常要求私有化，这时候托管平台方案直接排除；
• 要看清平台是否拿你的请求数据做训练，条款里没写清楚的，按「会」来评估风险；
• 需要私有化又不想自己训模型，就去 /stacks/specialized-models 找支持私有部署的厂商；
• 跨团队协作时把数据流向画一张图，谁调用谁、数据落在哪，比口头约定靠谱得多

按场景挑第一家平台

没有「最好」的平台，只有和你当下阶段最匹配的平台。匹配错了两周后就得推倒重来，匹配对了能省下大量无谓折腾。下面按典型场景给个方向，不适用的情况我也标出来。

1. 先定约束把数据能不能出内网、要不要备案这两条先写死，不符合的直接划掉
2. 再定阶段想清楚现在是验证期还是生产期，验证期看免费额度和跑通速度，生产期看限流和账单可控性
3. 小范围试接挑一条非核心链路先接，跑两周看延迟和失败率，再去 /tools/speed-test 做一次基线记录
4. 再决定是否扩面数据满意再往核心业务铺，不满意的就直接走迁移清单

换平台前的迁移清单

换平台不是改一行 base_url 就完事，真正的坑在错误码语义、结构化输出格式和工具调用的细节差异上。把下面这张清单过一遍，能少掉不少头发。

• 先把调用封装成一层薄适配层，把 base_url、模型名、鉴权、错误码映射集中在一个文件里；
• 跑一批历史请求做回归，对比输出差异，重点看结构化输出和工具调用这两块；
• 准备好回退开关：新旧平台并行一段时间，出问题能一键切回去；
• 记录切换前后的延迟和失败率，到 /tools/speed-test 量一遍基线，别只凭感觉判断；
• 把两边的限流策略对齐，新平台并发上限更松不代表你能随便提，账单会说话；
• 留一份切换记录，写下为什么换、换的时候哪些行为变了，三个月后你会用到

迁移做得顺手的人，不是代码写得快，而是早就把平台相关的东西都关在了一层适配层里。