你可能刚被同事问到「现在主流的大模型有哪些」，打开一圈官网却越看越乱：名字一堆、版本后缀看不懂、有的能下载有的只能调接口。这篇不给你一份会过期的名单，而是给一套分组框架和核对路径——你照着走，就能自己列出一份当下有效的清单，并知道每一类各自适合干什么活。
你可能刚被同事问到「现在主流的大模型有哪些」，打开一圈官网却越看越乱：名字一堆、版本后缀看不懂、有的能下载有的只能调接口。这篇不给你一份会过期的名单——名单本身也不该由一篇文章来固定。给你一套分组框架和核对路径，照着走，你能自己列出一份当下有效的清单，并且知道每一类各自适合干什么活。
核心思路就一句：别按名字记，按「阵营—模态—开放程度」三个维度分组记。具体型号叫什么、现在收录了哪些，一律以站内模型库的实时数据为准，到 /models 核对当时的型号与价格，文章里出现的任何名字都只当分类举例，不当采购依据。
先按「家族」分堆，比按名字记更省事
主流大模型基本能归到几个大阵营：海外闭源系、国产闭源系、开放权重系，以及平台自研或垂类专供。先认阵营再认具体型号，记忆量少一半。同一个家族内部通常还分「旗舰—主力—轻量」三档，档位决定的是成本和延迟，不是能不能干活。每一档现在具体叫什么，到 /models 看当前收录。
| 阵营 | 典型特征 | 你要留意的点 |
|---|---|---|
| 海外闭源系 | 只能调接口，能力上限高 | 数据出内网、按量计费、版本随厂商节奏变 |
| 国产闭源系 | 接口形态接近，中文场景更贴 | 备案与合规口径、上下文长度差异 |
| 开放权重系 | 能下载权重自己跑 | 显卡、推理框架、运维都得自己扛 |
| 平台自研/垂类 | 绑在某个云或某个行业里 | 迁移成本高，先确认退出路径 |
- 别把厂商名当模型名：一家厂商往往同时挂着对话、推理、多模态、语音好几条产品线，混着记最容易出错。
- 看到「-mini」「-turbo」「-lite」这类后缀，先默认它是同族的轻量档，适合批量和低延迟场景，而不是能力缩水版。
- 同一阵营里挑型号，先看你手上任务的输入长度和输出格式，再看名字听起来强不强。
- 不确定某个名字是不是还在服役，去 /models 看它的收录状态，别信二手转述。
再按模态分工：文本、多模态、语音、生图各是一条线
纯文本对话与写作是最通用的一类，排行榜也最多。但只要你的输入里出现图表、截图、扫描件，就该换到多模态那条线，硬用纯文本模型会白烧 token。语音、图像生成、视频生成又是另外几套评价标准，跟对话模型的强弱没有可比性，别拿一套榜单横向比。
- 文本对话
- 通用写作、问答、摘要，入门第一站
- 多模态
- 输入里有图片、PDF 版式、表格截图时才有必要，分线去 /multimodal 看
- 语音
- 实时转写、语音交互，评价看延迟和口音鲁棒性，参考 /voice
- 生图与视频
- 另一套审美与控制力标准，入口在 /ai-nav/category/ai-image
判断该不该上多模态，只看一件事：你的输入里有没有非文字材料。没有，就别为多模态能力付溢价；有，也别指望文本模型凑合。至于某一类现在有哪些家在做、各自定价怎么走，到对应分线页面核对当时的数字。
第三刀切在开放程度：能下载权重，还是只能调接口
这一刀比前两刀更影响你的长期成本。闭源只能走官方或云厂商接口，省心、能力上限高，代价是数据要出内网、按量计费、版本节奏由厂商定。开放权重的能自己拉下来跑，可控性和单价有优势，代价是显卡、推理框架、扩缩容和值守都得自己管。
- 先问数据能不能出内网：不能，开放权重几乎是唯一选项；能，再往下比。
- 再问有没有人维护：没有专职运维，开放权重的隐性成本会超过省下的调用费。
- 许可证是分水岭：能不能商用、有没有用户量门槛、衍生模型怎么算，得逐条读，入口在 /open-weight-license-basics 这类站内页。
- 别只看仓库首页那句「开源」，模型权重、训练代码、数据往往三件事许可不同。
- 部署前先把显存和并发算清楚，/compute/sizing 和 /models/deploy 能给你一个量级参考。
开放权重省的是调用费，花的是人力和机器；算总账才算得清。
落地动作：四步自查，产出一份属于你的清单
- 写清任务是写代码、读长文档、做客服问答还是处理图片。任务类型直接决定你该看哪条产品线，别一上来就比总榜。
- 定量预估每天请求量和单次上下文长度，拿去 /models/deploy 和 /compute/sizing 算一遍显存与并发，别先买卡再想模型。
- 比价官方价格看 /official-api，同款模型的不同托管渠道看 /inference，套餐制看 /coding-plans，到这些页面核对当时的数字。
- 验证拿你自己的三条真实任务去测，而不是看榜单位置。榜单怎么读才不被带偏见，见 /benchmarks 与 /benchmarks/crowd-radar。
什么情况下不适用：如果你的任务已经被某个垂类模型明确覆盖，比如法律、医疗、代码补全，直接从 /stacks/specialized-models 挑，不必先在这张通用清单里绕一圈。另外，如果你的预算和合规边界已经卡死，那第一步该做的是排除，而不是继续加候选。
还有一点常被忽略：模型是会下线和改版的。今天选定的名字，过几个月可能被合并、改名或涨价。所以清单要留复查机制，建议每次换季度或每次接到新任务类型时，回到 /models 和 /price-watch 过一遍，看有没有变动。
下一步拿你手上最近的一个真实任务，按上面四步走一遍，然后在站内把候选型号和它们的当前收录状态对一遍。想省事的话，先看中转站可信度与价格追踪，能帮你判断哪些渠道的数字值得信。→常见问题
我需要把主流模型都试一遍吗？
不用。先按任务类型收窄到一条产品线，再从里面挑两三个同档位的对比。真正要比的是「你这三条任务上谁更稳、谁更便宜」，不是谁覆盖的榜单项目多。试太多反而把预算耗在无意义的横评上。
模型名字后面那串日期或后缀是什么意思？
多数是快照或别名标识，指向某一时刻的固定版本，用来保证你调用的东西不会悄悄变。别名一般跟着最新版走，快照锁死。选哪个取决于你要稳定还是想要新能力，具体规则可以到 /ai-dict 与 /models 对照着看。
怎么知道现在到底有哪些主流模型，而不是过期名单？
别信任何写死的名单，包括这篇。去 /models 看站内当前收录的模型库，去 /ai-rankings 和 /usage 看实际被用和被讨论的热度，两处交叉一下，基本就能拼出当下真正在跑的那批。
