上个月一个做产品的朋友跑来问我网上天天说大模型可他去查资料越查越晕——一会儿说 GPT 是行业标杆一会儿说本地部署个 7B 模型也是大模型这俩根本不是一回事怎么能放一起比我听完就明白了问题出在“大模型”是棵分类树不是一条直线。你问它“分几种”得先定好维度按架构分是一种答案按训练阶段分是另一种答案再按模态、交付形态、参数量去分答案又完全不同。光说“大模型”三个字就像说“动物”一样连猫和鸟都没分清楚。这篇文章我想用从业者的视角把这棵分类树拆开讲清楚彻底梳理“到底分几种”。看完之后你再看到一个陌生的模型名至少能快速判断它属于什么结构、处于什么训练阶段、能处理什么输入输出、能不能本地部署以及大概需要多少资源。这些对选型、做方案、自己跑实验都非常有用。1. 从底层架构分Decoder-only为什么成了默认答案在模型分类里最底层的一套分法看的是“模型内部结构怎么搭”。2018年到2021年之间Transformer 其实演出了三大流派。今天市面上几乎所有真正常挂在嘴边的大模型都属于其中一支另外两支并没有消失只是换了阵地。1.1 三兄弟各有各的绝活先说第一个流派Encoder-only代表作就是 BERT。这类模型的思路是双向编码一句话进来每个词都能看到前后上下文再去做预测。它像个特别认真的阅读理解考官擅长分类、排序、抽取类任务比如判断一句评论是好评差评、抽取出企业名称、给文档做搜索 embedding。但让它续写一句话、写一段文章它基本干不了。第二个流派是 Encoder-Decoder代表作是 T5 和 BART。它的设计是先让编码端把输入吃透再交给解码端一字一句吐出来。这个结构很像是“同声传译”前半段作曲后半段演奏。在机器翻译、文本摘要、结构化数据转文本这些“输入输出格式差异明显”的任务上它一直有稳定的发挥。第三个流派就是今天的主角Decoder-only代表作是 GPT 系列以及后来开源社区里的 LLaMA、Qwen、DeepSeek、Mistral。它的逻辑非常简单只留解码端这一个“人”给定前面已经写出来的所有内容去预测下一个最合理的词然后一个 token 一个 token 地续写下去。作者写小说就是这么干的写一句再写下一句。1.2 为什么最后是“只留半个 Transformer”赢了一个好问题为什么不是结构更复杂的 Encoder-Decoder也不是看起来很聪明的 Encoder-only而是这个看似“砍了一半”的 Decoder-only 胜出我理解的原因有四个层面。第一训练目标极度统一。在 Encoder-only 里每个任务都要单独设计一个输出头文本分类用分类头抽取用序列标注头每一种任务都是一套新的训练管线。而 Decoder-only 只需要一个目标预测下一个 token。不管你是对话、翻译、写代码还是做总结全都可以套进同一个“猜下一个词”的游戏里。这一点对大模型规模的优化极其关键它让所有任务共用同一条流水线。第二计算效率更顺手。Decoder-only 用的是单向注意力预测时天然是“从左往右”推理引擎可以搞 KV cache把历史计算缓存下来每次只算新 token。结构简单到几乎所有推理框架都先为它优化工程上少掉一大半烦心事。第三缩放定律更友好。大量实验数据显示Decoder-only 的模型在训练数据量、参数规模和算力预算增加时能力上升的曲线更好看。换句话说它的潜力在“越大越聪明”的路上更稳定可预期。第四生态被 GPT 的爆发带上来了。这不是纯技术上的赢而是整个工业界围绕 GPT 这个范式搭了太多工具Hugging Face 的 transformer 库、vLLM、SGLang、各种 LoRA 微调套件全都默认支持 decoder-only。哪怕有理论上更合适的架构团队维护成本也让人望而却步。顺便说一句现在学术界还在做非 Transformer 的尝试比如 Mamba、RWKV 这类线性注意力或状态空间模型。你可以把它们理解成“类 Decoder-only”但定位还比较前沿。你日常看到的商用模型包括国内外的各家主力几乎还是 decoder-only 的天下。1.3 遇到“非 Decoder-only”模型不用慌如果你在项目里看到一个模型不是 decoder-only也别觉得奇怪。BERT 系模型到现在仍然是很多搜索系统里 embedding 和 rerank 的默认选择因为这种判别式模型在短文本任务上又准又快参数量做小以后部署成本极低。T5 系模型在翻译、表格理解、摘要这类任务中也还有很多人在用。我的建议是理解这三种架构不是为了二选一而是为了选型时思路清晰。如果你想做开放式问答、写作、代码生成的产品无脑选 decoder-only 的生成模型几乎不会出错如果你要做的是文本分类、关键词抽取、语义检索那认真考虑一下 BERT 类模型可能用二十分之一的成本拿到更好的效果。2. 从训练阶段分Base、Chat、Reasoner是同一个模型的三副面孔架构只是骨架。一个模型翻开训练记录大致会经历几个阶段同一家公司发布的同名模型后缀不同往往是完全不同的“人格”。很多人踩过这种坑拿了一个叫 base 的模型去聊天被气得半死然后跑来骂模型烂——其实是没搞清它属于哪个阶段。2.1 Base 模型会说话但不会听话Base 模型也叫基座模型、预训练模型。它做的事情就一件在海量文本上做预测下一个 token通过几千亿个 token 的吸收把语言规律、世界知识全部压进参数里。经过这个阶段模型已经具备了很强的语言直觉你给它一个不完整的句子它大概率能补得非常自然。但它的致命弱点是“不会听话”。比如你让它写一封请假邮件它大概率只会顺着你的开头续写出一篇“散文”而不是一封结构规范的邮件。原因很简单它没有被训练成“回答用户指令”的形式它只是在做续写。拿 base 模型直接做客服或对话产品体验必然是灾难。2.2 Instruct/Chat 模型被“手把手教过”之后才可用为了让模型回应指令厂商会在预训练后面再加一道指令微调SFT。做法是构造大量“指令-回答”的样本让模型学习“当用户这么要求时你要这么回”。经过这一步的模型后缀一般叫 Instruct 或 Chat它才真正变成一个“会听话”的模型。指令微调的数据质量直接决定模型可用不可用。同样是几万条样本有的模型微调完逻辑清晰有的模型表面礼貌但内容犯傻差别往往就在数据覆盖、去重质量和答案标注水平上。大厂公开的 Chat 版模型通常已经过很多轮 SFT 和后续对齐可以直接进产品。2.3 对齐和推理增强从“会说话”到“说得对、会思考”对齐Alignment是比指令微调更靠后的一步。现在最常用的是 RLHF 或 DPO 这类偏好优化先让模型生成多个回答再由人类或自动化标注器打分排序让模型学着输出排序靠前的回答。对齐目标是安全、有用、无害。你可以这么理解SFT 教它“听懂指令”对齐教它“哪些话说出来更合适”。再往后这两年冒出来的推理增强模型Reasoner比如 OpenAI 的 o 系列、DeepSeek-R1、Kimi K2 这类是把“推理”变成一个显式过程。它们会在回答用户之前先产生一段内部思考链去分解问题、规划步骤、检查答案。这类模型在数学、代码、逻辑推理上明显更强但响应更慢、token 消耗更大并不适合所有场景。2.4 选哪个阶段要看你要干什么这个分类对实际项目的影响特别大。如果你要做领域微调比如让模型熟悉法律文书、医疗问诊、工控告警一般建议拿 base 或者 instruct 模型作为底模去做继续预训练或 LoRA别拿已经对齐得很彻底的 chat 版猛改因为改造空间小。如果你要快速接一个客服机器人直接用官方 chat 版加上 RAG 和提示词成本最低。如果你的核心问题是复杂推理比如代码审查、数学题、策略推理优先用 reasoner 类。判断一个模型属于哪个阶段最直接的方式是看名称带 base、foundation 的是基座带 instruct、chat、sft 的是指令微调带 reasoner、thinking 且特别强调推理强化的是推理增强模型。厂商在模型卡上一般都会写清楚用之前多看一眼能省很多事。3. 从感知能力分纯文本、多模态和Agent型是三种物种另一个常被混淆的维度是“模型能吃什么”。有的模型只认文字有的模型能看图能听声有的模型已经能直接调用工具替你干活。这一层分类在实践里比架构更能影响你的产品形态。3.1 纯文本模型大模型的“原教旨主义”纯文本大模型只处理文本输入一段文字输出一段文字。哪怕是图像你也要先转成文字描述比如 OCR 或人工标注才能让它处理。这类模型以 GPT-3、LLaMA-2、Qwen 系非视觉版本为代表。很多人觉得纯文本是不是太落后了其实不是。到今天企业里大多数场景仍然是文本密集型客服问答、合同审查、代码补全、报告生成、数据转文字。纯文本模型的优势是训练和推理成本都明显低于同规模多模态模型部署也简单。如果你的数据本来不需要图片没必要为了“多模态”三个字多花钱。3.2 多模态模型给大模型装上眼睛和耳朵多模态大模型通俗说就是给 LLM 加了视觉编码器、音频编码器等“感官”。输入可以是图片、音频、视频帧加上文本输出仍然是文本有的还直接回语音。代表作包括 GPT-4V、Gemini 系列、Qwen-VL、InternVL 等。这类模型的核心技术点在于“怎么把图像 token 化并和文本 token 融合”。早期做法是让视觉编码器抽取图像特征再通过投影层映射到文本 embedding 空间让模型能“看见”。近期进展主要集中在三块一是视觉 token 压缩减少图像带来的推理开销二是视频级理解不再只看单图而是在视频帧序列上做联合理解三是语音端到端不再是用 ASRLLMTTS 三段拼接而是直接训练能听语音输入的模型。3.3 视频生成大模型严格算生成模型不是传统 LLM搜索时经常看到“视频生成大模型”像 Sora、Vidu、可灵这类。它们确实也叫“大模型”但训练目标不是文本 token 的预测而是视频帧和像素的生成。你可以把它归入生成式多模态大模型这个大类别但要明白它和你在 API 里调的那种聊天大模型不是同一个物种。前者解决“给我一段视频”后者解决“回答我一个问题”。两者在底层网络结构、训练数据、部署代价上差别巨大。如果你要做一个文本分析系统完全不需要关注视频生成模型如果你在做创意内容工具那视频生成模型反而是主角文本模型只用来辅助写脚本和文案。3.4 Agent 型模型大模型不光会看会说还会动手再往下是这两年特别火的 Agent 型大模型。所谓 Agent指的是让模型能够执行“行动循环”理解任务、拆解计划、调用工具比如搜索、查数据库、执行代码、填写表单、根据工具返回结果再调整下一步行动。代表产品包括各种 AI 编程助手、浏览器智能体、企业工作流智能体。技术上怎么实现的核心是给模型加了 function calling 能力。模型在生成过程中不只会输出普通文字还会输出一个结构化的“函数调用请求”比如“搜索天气 city北京”。应用层收到这个请求后去执行 API再把结果返回给模型。模型继续生成直到任务完成。这类模型对上下文管理、指令跟随和错误恢复能力要求很高。你可以这样理解纯文本模型像只会聊天的朋友多模态模型像长了眼睛耳朵的朋友Agent 模型则是不仅看得见听得到还能动手帮你办事的朋友。实际项目里如果你做智能客服、流程自动化光有大模型还不够重点往往要放在怎么把工具编排和模型调用串成可靠稳定的工作流上。4. 从交付形态分闭源API、开源权重和本地部署谁适合谁“大模型分几种”还有一个非常现实的维度你拿到手的是什么形态。就算同一个模型通过 API 调用、下载权重本地部署、还是企业内网私有化部署对团队、预算、数据安全的要求完全不同。这个维度选错了项目大概率卡在半路。4.1 闭源 API 和免费 API上线最快的路子闭源 API 的代表是 OpenAI 的 GPT 系列、Anthropic 的 Claude、Google 的 Gemini国内也有通义千问、文心一言、DeepSeek、豆包等一批平台开放接口。选择这类服务的最大好处是省心不用准备 GPU、不用管推理引擎注册拿 Key 就能调用。对中小团队和产品原型期来说这是最合理的选型。成本角度多说一句API 是按 token 计费的长上下文的对话、批量归因分析、文档喂入都会让单次调用成本快速上涨。如果业务月请求量上百万用 API 的费用可能比你自己买显卡跑开源模型高得多。很多平台也有免费额度、限免活动甚至一些活跃开源社区会维护公益 API 聚合做学习、Demo、小流量验证完全够用但指望它支撑生产环境并发是不现实的。4.2 开源权重加本地部署入门走通只需要一个晚上开源权重模型这两年发展非常快Qwen、DeepSeek、LLaMA、Mistral 等都有可下载的开源版本本地部署的门槛已经被工具拉得很低。最容易上手的是 Ollama 和 LM Studio。Ollama 的体验几乎是一行命令的事。装好之后执行ollama run qwen2.5:7b它会自动去拉模型权重启动一个兼容 OpenAI 接口的本地服务。你在代码里像调 API 一样调用它就行。LM Studio 更偏向图形界面适合在个人电脑上加载 GGUF 格式模型边拖边试。如果团队要做高并发生产推理就该上 vLLM、SGLang 这类推理框架用连续批处理把吞吐量优化起来。这里有个核心提示下载开源权重时一定要确认来源正规渠道比如官方仓库、官方镜像并对模型文件做完整性校验。模型权重被植入后门、投毒的事这两年已经不是新闻了做企业项目尤其要小心。网上有关于大模型投毒测试的系统性研究和检测工具模型进生产环境之前先跑一组红队测试这是很值得的保险动作。4.3 企业私有化部署从技术选择题变成组织课题当企业面临数据主权、网络安全、合规要求时基本只剩下两条路要么找云厂商的私有化专区要么把开源模型部署到自己机房。后者要处理的问题更多GPU 集群规划、推理框架选型、模型更新机制、权限管控、监控告警以及跟企业现有系统的集成。我在一些行业案例里看到工业控制、金融、政务这类领域特别偏向私有化部署因为业务数据高度敏感而且往往要和知识抽取、告警分析甚至和工控安全系统联动。比如“数据中心运维告警”“车间设备日志”这类数据基本不允许出网。这种情况下把开源模型放进内网配合 RAG 和垂直场景微调比调用外部 API 稳妥得多。但私有化也很容易踩坑GPU 的调度、推理服务的可用性、模型的迭代版本管理都会突然变成需要自己扛的事情。如果没有专职的 MLOps 或运维人力做决定前要三思。4.4 交付形态选型一张表看懂为了方便直接抄作业我整理了一个对照表按使用阶段来判断。你的处境推荐形态核心理由需要警惕的坑产品原型、Demo、个人学习免费 API / 公益 API零成本快验证限流明显不能保证生产可用中小团队正式上线商用闭源 API省运维、效果稳定token 成本会随量级快速上涨有 GPU 但数据不太敏感开源模型本地跑Ollama / vLLM可控、性价比高需要会调推理参数和显存数据不能出内网私有化部署合规、数据安全算力和运维成本偏高工控、金融等强监管场景私有化 垂直领域微调定制强闭环安全需要完整的安全检测流程5. 从规模和性价比分参数大小、上下文长度和“够用就行”最后一个维度也是最常被人挂在嘴边的模型有多大。但“大”这个概念正变得越来越复杂——参数量只是其中一个变量上下文长度、量化方式、推理成本都在影响最终选择。5.1 参数规模梯度从手机模型到数据中心模型按参数量常见模型大致可以分四档。第一档1B 到 4B 的小参数模型。代表有 Phi-3-mini、Qwen2.5-1.5B/3B、Llama-3.2-1B。这个档位主打端侧和低成本场景手机上、嵌入式设备上都能跑延迟低、内存占用小。要说能力写个摘要、做基础问答、信息抽取够用但复杂推理和长文档理解基本别指望。第二档7B 到 14B这是个人本地部署最舒服的区间。一张 24GB 显存的显卡量化到 INT4 之后跑 7B 模型很轻松14B 模型在 16GB 显存上也能勉强运行。这一档是开源模型的主力普及区大多数独立开发者、小团队的第一台本地大模型都停在这里。第三档32B 到 70B这是企业级模型。像 Qwen-72B、Llama-3-70B 这类通常需要至少两张 80GB 显卡或者四张 24GB 显卡才能全精度推理量化以后门槛会低一些但仍然不是个人玩得转的级别。这个档位的能力明显上了一个台阶复杂任务、长文本、较多指令遵循都能扛住。第四档100B 到上千亿参数基本属于超大规模模型只会通过云 API 提供。个人和中小企业基本不用考虑自建直接调 API 更划算。这里再说一个显存估算的经验公式显存需求约等于参数量GB乘以精度字节数再留出 20% 的余量。以 7B 模型为例FP16约等于每参数 2 字节大约需要 7×2×1.2≈16.8GBINT4 量化约 7×0.5×1.2≈4.2GB。所以你会在教程里经常看到“7B 模型 4GB 显存就能跑”这是量化之后的数字没量化的模型一张 8GB 显卡是装不下的。5.2 上下文长度不是越大越好除了参数上下文长度是挑选模型时最容易踩坑的指标。上下文长度就是模型一次能“记住”的 token 数。早期模型只有 2K 到 4K现在很多模型宣称 128K、200K甚至上百万。上下文越长能一次性处理的书本、文档、对话历史越多这是硬需求。但宣传的上下文长度和实际可用上下文往往是两码事。很多模型在长文本尾部会出现“中间信息丢失”“前后矛盾”的问题。我的建议是不要只看模型卡上的最大长度而是拿一段真实业务文案把关键问题放在文段中部和结尾分别测试一遍。不同位置的信息召回率比参数表上的数字更有参考价值。另外上下文长度直接决定推理成本和速度。处理 128K 上下文的计算量远大于 8K长上下文对话没几轮API 账单就会让你心疼。所以业务上要尽量控制每次请求的 token 量能用 RAG 检索精准片段解决的问题别把整本文档喂给模型。5.3 综合选型先从场景反推不要被参数带偏把前面五个维度全部收拢到一起我日常选模型有一个固定动作先回答五个问题任务类型是开放式生成还是分类抽取这决定是不是要选 Decoder-only 的生成模型。输入输出需不需要图片、音频、视频、工具调用这决定是纯文本、多模态还是 Agent 型。数据敏感度数据能不能出域这决定走 API 还是本地部署。预算和硬件有没有 GPU接受不接受 token 费率这决定选多大参数量、什么部署形态。能力基线任务要求的是强推理还是简单问答即可这决定要不要上 Reasoner 类模型。把这五个问题回答完一个陌生模型到底“属于哪一类”也就基本落地了。它可能同时属于“Decoder-only Chat 多模态 开源 14B”不同的分类维度会交叉在一起单独拿一个标签说事都是片面的。5.4 一张表把“到底分几种”彻底收拢我用一张表把上面讲的五个维度汇总一下可以直接保存下来作为选型参考分类维度主要类型代表方向一句话判断标准架构Encoder-only / Encoder-Decoder / Decoder-onlyBERT系、T5系、GPT系生成任务默认 Decoder-only训练阶段Base / Instruct-Chat / Reasoner基座、对齐、推理增强直接聊天选 Chat推理难题选 Reasoner模态纯文本 / 多模态 / 视频生成 / Agent型文本LLM、VLM、视频生成、Agent看输入输出需不需要非文本交付形态闭源API / 免费API / 开源本地 / 私有化云服务、Ollama、内网看数据能否出域、团队运维能力规模1B-4B / 7B-14B / 32B-70B / 100B端侧、本地、企业、云端看硬件预算和任务难度这个表看着简单但把“大模型分几种”这个问题的答案基本扣全了。真正做项目的时候你会发现所有模型选型本质上就是这五行标签之间的组合题。最后再分享一个我自己的实践感受。我这两年经手的大模型项目无论是给客户做方案还是内部搭工具最后都发现同一个规律翻车的从来不是“模型不够大”而是“分类没分清”——拿着 base 模型去聊天开源模型私有化之后没人运维为了追求多模态白白烧经费在长上下文上被宣传参数骗了。这些都是拿着同一个“大模型”标签去套所有场景的下场。所以如果你想快速上手我的建议是先拿免费 API 把一个最小闭环搭出来验证业务再评估数据敏感性和预算决定要不要自己部署最后再考虑微调。不要一上来就追求千亿参数、全套多模态、各种私有化。把每一步的原因想清楚比盲目跑多少个模型都管用。