大语言模型架构科普：从Transformer到三种核心模型选型

上篇文章聊完了大模型技术的整体图谱，这次专门把“大语言模型”这个东西拆开揉碎来讲。很多刚接触的朋友会有个困惑：大家都在说大模型、大语言模型，它到底是个什么玩意？“大”又体现在哪里？为什么架构还分好几种，搞不懂这些东西会不会影响用？

我的看法很直接：你要想进阶玩好微调、RAG、Agent这些上层应用，基础架构的认知是绕不开的分水岭。不懂架构的人用大模型就是“调接口”，懂了架构的人能判断出什么场景该用哪类模型、为什么某个模型在这个任务上表现好，这中间的差别，就是工具使用者与工程师之间的距离。

这篇文章会用相对通俗的方式，把大语言模型的定义、规模维度、三种核心架构一次性讲明白，顺带把选型逻辑也聊透。不管你是刚入门想建立体系认知，还是已经上手调用API但总感觉知其然不知其所以然，这篇内容都值得看完。

1. 大语言模型到底是什么：一句话定义与核心能力拆解

大语言模型（Large Language Model，LLM）不是个玄学概念。它本质上是一个参数量极大、在超大规模文本语料上训练出来的神经网络概率模型。这句话拆开看有四个关键点：神经网络、概率模型、参数量极大、超大规模数据训练。

1.1 “语言模型”的定义：它在做的其实是填空题

语言模型是NLP领域的老概念，远在大模型火起来之前就有了。核心任务只有一个：给定前文，预测下一个词的概率分布。类比来说，它就是一台“高级自动补全机”——你给它一个开头“今天天气真”，它能计算“好”“的”“不错”“热”等候选词出现的概率，然后挑最合理的继续接下去。

传统的n-gram语言模型基于统计计数，稀疏问题严重，无法捕捉长期依赖关系。2013年之后的Word2Vec、ELMo用向量表示缓解了一部分问题，但真正质的飞跃来自Transformer架构的诞生——它让语言模型能在大规模语料上高效训练，拥有捕获任意距离依赖关系的能力。

现代LLM做的事，本质上还是“预测下一个词”，但靠规模和训练方式的加持，这个简单任务推导出了令人惊叹的涌现能力：代码生成、数学推理、多轮对话、工具调用，都是建立在逐词预测这个根基之上的。这就是为什么有人把LLM称为“next word prediction machine”——听起来不起眼，实际威力巨大。

1.2 “大”的四个衡量维度：参数、数据、算力、上下文

所谓“大语言模型”，到底哪里大？新手最容易误解为“参数大就是一切”，实际上规模至少体现在四个维度：

• 参数量（Parameters）：模型的存储与计算规模，从几亿到几万亿不等。参数量大意味着模型“记住”复杂模式的能力强。
• 训练数据量（Data Scale）：现代LLM动辄在数万亿token上训练，相当于几十万本书、数十年阅读量的文本总量。
• 算力消耗（Compute）：训练一次前沿大模型需要数千到数万张GPU持续运行数月，对应数千万美元级别的成本。
• 上下文窗口（Context Window）：模型能一次处理的文本长度，从早期的2K、4K扩展到了如今常见的128K甚至更长。

一个好问题浮出水面：是不是参数越大就越好？答案是否定的。算力约束下，参数规模、数据规模、训练时长之间需要平衡。业界有一个Chinchilla法则（训练算力最优分配原则），它的核心结论是：在固定算力预算下，模型参数规模与训练token数应按约1:20的比例同步增长。换句话说，与其堆参数，不如把数据喂足——这是在资源配置层面的关键经验。

2. “大”在哪：从模型规模到数据规模的完整拆解

很多同学对“大模型为什么大力出奇迹”有模糊认知，但缺乏量化概念。我在项目交流中常遇到的困惑是：“为什么GPT系列每代能力突飞猛进？是不是就是参数多加了几倍？”实际情况复杂得多，下面从三个维度量化拆解。

2.1 参数规模的演进：从1亿到万亿的跨越

看一组代表性模型的参数规模变化：

参数量的增长曲线几乎是指数级。但注意两点：第一，GPT-4传言使用了MoE（混合专家）架构，1.8万亿是总参数，实际每次推理只激活一部分，这也揭示了“参数大”与“计算大”并非完全等同；第二，从GPT-3到LLaMA等开源模型的进步，很大程度上来自数据质量与训练策略的优化，而非单纯参数堆叠。

2.2 训练数据：质量与规模的赛跑

参数量只是规模的一部分。一个被低估的事实是：数据规模的扩张速度远超参数规模。GPT-2训练数据约40GB，GPT-3达到45TB文本，到了GPT-4时代，训练数据量级已经是数万亿token。更关键的是数据配比策略：

• 文本来源多元化：网页、书籍、论文、代码、对话数据混合配比
• 数据清洗：去重、去噪、去低质内容的标准化流水线
• 数据配比调优：不同来源按不同比例混合，直接影响模型下游能力
• 合成数据：用已有模型生成高质量训练数据，反哺下一代模型训练

我在做模型微调时最深的一个体感是：数据配比和清洗质量对最终效果的影响，常常大于模型参数规模的影响。给一个70亿参数的模型喂干净的高质量领域数据，在某些垂直任务上胜过直接用千亿参数模型base版本硬套，这也是“小模型+好数据”路线在业界一直有市场的原因。

2.3 训练成本与算力约束：规模背后的物理现实

训练大模型不是想堆多少堆多少。以LLaMA 13B参数模型的训练为例，在2048块A100 GPU上需要约21天，总计算量约4.6EFLOPS。到了千亿参数级别，成本直接跳到数千万美元量级。这种物理约束倒逼出两个技术方向：

第一，模型架构创新——比如Switch Transformer的MoE路线，用条件计算打破“每个token都必须经过全部参数”的约束。第二，分布式训练系统优化——包括张量并行、流水线并行、数据并行等策略的组合运用，解决显存装不下、单卡算力不够的问题。

所以“大”不是一个简单的形容词，它背后是一整套工程体系的支撑。理解了这层，你就明白为什么开源社区与大厂之间的差距主要体现在算力和数据基建上，而不是架构原理上——公开论文早已把所有技术细节摊开在桌面上。

3. 三种Transformer架构：Encoder-only、Decoder-only与Encoder-Decoder

这三条技术路线是大模型最核心的架构分野。很多文章讲这个讲得很学术，什么MLM、CAUSAL LM、Seq2Seq，新手一听就头大。我用“工作角色”的类比来拆解：架构中的Encoder（编码器）负责“阅读理解”，Decoder（解码器）负责“接句子”，两种角色排列组合出三种流派。

3.1 Encoder-only架构：深度理解的专家

Encoder-only架构的代表是BERT、RoBERTa、ELECTRA。这类模型在预训练阶段使用掩码语言模型任务：随机盖住文本中15%的词，让模型根据上下文猜被盖住的是什么。关键在于注意力机制是双向的——某个词既能看前面的词，也能看后面的词，所以捕捉上下文的能力极强。

用类比来说，Encoder-only像是语文考试里的“阅读理解”型选手：你说一句话，它能把每个词在语境中的含义琢磨得明明白白。这决定了它最适合的任务类型：

• 文本分类：判断情感正负、新闻归属类别
• 命名实体识别：抽出人名、地名、机构名
• 句间关系判断：两句话是否语义一致、是否蕴含
• 检索排序：计算文本相似度用于召回与重排

这套架构在实际工程中的老牌应用就是基于BERT的语义搜索和文本匹配系统。但它的致命短板也明显：因为训练目标不是“生成”，所以输出能力弱，不适合做文本生成。另一个限制是，早期的BERT系列参数规模停留在亿级，虽然后续的ERNIE 3.0也做到了百亿级，但在生成领域依然无法与Decoder-only模型抗衡。

你在做文本向量化、语义匹配、分类打标这些任务时，encoder-only模型依然是首选，尤其是需要低延迟、低成本的场景，一个轻量BERT或它的蒸馏版远比你部署一个LLM划算。

3.2 Decoder-only架构：生成领域的事实标准

Decoder-only架构是当下大语言模型赛道真正的主角。GPT系列、LLaMA、Qwen、DeepSeek、Mistral，清一色的Decoder-only。这类模型在预训练时执行的任务叫自回归语言建模：一个token一个token地预测下一个词，且只能看到当前词之前的内容——注意力是单向的（因果掩码）。

用类比解释，Decoder-only像“接话高手”：你给它上半句，它一本正经地接下半句，接的过程中只能依赖前面说过的话，不能“偷看”后面。虽然听起来比双向注意力受限，但恰是这种“顺着往下说”的模式，让它拥有了强大的文本生成能力。更关键的是，自回归训练目标简单高效，支持无限的任务适应潜力——因为几乎任何NLP任务都可以被重构成“给个指令，生成回答”的形式。

同样是70亿参数规模，LLaMA在代码生成、长文本续写、多轮对话上的表现，远远超过同规模的BERT系的生成能力。这也是2023年之后几乎所有行业大模型都转向Decoder-only的根本原因。业界从理论和工程两个层面已达成了方向共识：

• 扩展性（Scaling）：自回归模型的loss与参数量、数据量之间存在可预测的幂律关系，扩展边界足够大

• 通用性（Generalization）：指令遵循、上下文学习涌现能力在Decoder-only模型上体现最强

• 工程统一性：训练、推理链路标准化，KV Cache等优化技术天然适用于自回归解码

3.3 Encoder-Decoder架构：转换任务的老牌劲旅

Encoder-Decoder架构结合了前两者的思路：一个Encoder读入完整输入做双向理解，一个Decoder逐步生成输出、每一步还能通过注意力机制回头“看”输入的每个部分。T5、BART、Flan-T5是这一路线的代表。

类比的话，它像“专业翻译员”：先通读理解原文（Encoder），再组织语言译成目标语言（Decoder），翻译过程中随时可以回看原文对照。这种架构最擅长的是条件生成任务——输入和输出都是文本、且输出严格受限于输入：

• 机器翻译：源语言输入，目标语言输出
• 文本摘要：长文输入，精简摘要输出
• 文本改写：复杂句改简明句、风格迁移
• 表格到文本：结构数据转自然语言描述

T5当年有一句经典口号“Text-to-Text Transfer Transformer”——把所有NLP任务统一成“文本进、文本出”的格式，思想非常优雅。Flan-T5在T5基础上加了一堆指令微调，一度是学术界和中小企业的性价比之选。

但为什么Encoder-Decoder没有成为大模型时代的主流？一个关键原因是推理效率：每一步生成都要过一遍Encoder做计算，而Decoder-only只需自回归生成，在长文本场景下成本高出不少。再加上Decoder-only在扩展性、涌现能力上表现更优，Encoder-Decoder逐渐退居特定转换任务场景。这不代表它没有价值，反而是合适场景里的最优解之一。

3.4 三种架构横向对比：一张表看清取舍

我在做架构调研时常会做对比表，清晰度最高。这里直接分享核心对照：

用这张表你能快速建立判断：做语义搜索选Encoder-only，做对话生成选Decoder-only，做翻译摘要选Encoder-Decoder。当然，“是否用大模型”本身就是选型问题——很多简单的文本分类任务，用一个轻量级BERT模型高效又便宜，完全没必要上LLM。

理解了三种架构的分工，再去看当前大模型技术演进的主线就清晰了：所有关于Agent、多模态扩展、代码执行、工具调用这些能力，都是在Decoder-only框架上长出来的应用枝干。架构底座的统一，也给了上层应用生态足够稳定的基础。

4. 为什么Decoder-only成了主流：从实践中总结的三个核心原因

既然三种架构各有分工，为什么最后是Decoder-only统治了大语言模型时代？这个问题的答案对模型选型有直接影响。我结合项目实践谈谈自己的理解。

4.1 涌现能力与上下文学习：生成框架下的“意外收获”

研究普遍观察到，自回归模型在参数规模跨过某个阈值后，会出现上下文学习能力（In-Context Learning）和思维链能力（Chain-of-Thought）。这个阈值通常在数十亿到百亿参数之间——注意，这里的规模效应主要体现在Decoder-only的自回归任务上，Encoder-only因为预训练目标与生成模式不匹配，很难同等规模呈现这类能力。

上下文学习的价值怎么强调都不过分：给了几个示例，模型就能按示例模式推理，不需要调整任何参数。这意味着Prompt Engineering、Few-shot learning这些上层技术有了底层支撑——它们本质上是在调度Decoder-only模型的生成能力。我见过不少团队用Few-shot手法在通用大模型上解决专有场景问题，效果远超专门微调一个小模型——这就是“架构红利”。

4.2 任务统一与产品化便利：一个接口通吃

Decoder-only模型最“毒”的地方在于：任何任务都可以被翻译成“对话”或“续写”的形式。做分类？让模型输出JSON格式带标签。做抽取？让模型按规范输出实体列表。做翻译？直接给指令说“将以下内容译为英文”。这统一范式在产品和工程层面带来巨大便利——后端只需要维护一套推理服务、一套提示词模板库，而非为每个NLP任务各上一个专用模型。

相比之下，Encoder-only做分类任务要改输出头（在[CLS]向量上接一个分类器），Encoder-Decoder的格式虽然相对灵活，但性能上限受限于条件生成模式。产品化过程中“少维护一种模型服务”带来的运维成本下降，是很多团队转向Decode-only的隐性驱动力。

4.3 可扩展性与生态成熟度：终局优势

从更远的时间维度看，Decode-only架构的扩展路径最清晰：数据扩展到万亿级、参数扩展到万亿级、上下文扩展到百万级，都有成熟的理论支持和工程实践积累。而Encoder-only随着规模扩展会遇到注意力复杂度瓶颈，Encoder-Decoder则受制于训练目标的不统一。

生态成熟度也不可忽视：PyTorch、HuggingFace Transformers、vLLM、SGLang这些主流推理框架，对Decoder-only模型的支持是最优先的。开源社区的模型权重、微调脚本、量化工具、部署方案，几乎都围绕Decoder-only展开。当你的团队做技术选型时，“生态最全”本身就是实质性的效率优势，不用试错，不用趟坑。

5. 三种架构在当前技术生态中的应用地图

架构选型不是纸上谈兵。我在实际项目里见过不少选了错误架构导致返工的现象：有人用LLM做检索向量化，效果反而不如一个BERT模型；有人试图让T5写代码，写出来的东西基本不可用。下面整理当前技术生态中三种架构的典型落位，供参考。

5.1 Encoder-only的现代应用：RAG与向量检索的关键底座

大家都用RAG（检索增强生成），但RAG的召回环节用什么模型做向量化？多数人的答案是BGE、GTE这类Embedding模型——它们本质上就是Encoder-only架构的训练产物，只是输出层面做了池化和向量化的调整。

这个组合逻辑值得细品：召回阶段需要精准理解语义、快速计算相似度，Encoder-only的高效双向编码是最佳选择；生成阶段需要流畅产出语言，Decodeer-only天然胜任。两套架构各司其职——RAG的“检索”与“生成”双环节，本身就是一个混合架构的系统设计。你在搭建RAG系统时，不要试图用一种模型同时干两件事，效果和成本都不可控。

5.2 Decoder-only的生态版图：前打Agent、后撑多模态

当前大模型体系中，Decodeer-only的辐射范围已经远超纯文本生成：

• Agent架构：LLM作为大脑，调用工具、规划步骤、复盘执行（比如AutoGPT、LangChain核心）
• 多模态大模型：以LLM为文本底座，接入视觉、音频编码器做跨模态对齐（比如GPT-4V、LLaVA）
• 代码智能体：基于LLM的代码补全、仓库级理解与自动重构
• 企业知识库问答：ChatBI、私有知识问答系统，底层几乎全是Decoder-only

值得说明的是，多模态赛道里视觉编码器部分本质上用的是类似Encoder-only的结构，但“跨模态转换控制”由Decoder统一调度。所以当代多模态模型可以被理解为“Encoder-only做感知输入、Decoder-only做综合推理输出”的混合体设计。DeepMind一篇论文里提到的“靠语言蒙”现象（模型跳过视觉输入直接猜答案），恰好从侧面验证了Decoder底座在综合推理中占据的主导地位——语言能力在闭合过程中起了决定性作用。

5.3 中小团队实战选型建议：按任务分层配模型

结合我对大量项目调研的经验，给不同体量团队一个实用建议：不要只背一个“通用大模型”走天下，而是按“任务层”做架构分层：

6. 实操排查与避坑：我踩过的架构与选型坑

聊到实操环节，必须把血泪教训放到台面上。这里不灌鸡汤，纯分享我在真实项目中遇到过的问题和排查思路，尤其适合正在做大模型应用落地的朋友参考。

6.1 常见问题一：用Decoder大模型做向量化，效果为何不如老模型

有朋友用LLM做Embedding，发现相似度计算质量反而低于BERT，问我是不是参数不够大。原因很明确：Decoder-only模型的训练目标（自回归预测）并不天然产生好的句子级语义向量。虽然有一些“LLM-as-Embedder”的研究尝试，但工程上成熟方案依然是专用Embedding模型。

排查思路：先检查模型输出是token级别的特征还是做过专门的池化策略，然后和BGE等专用Encoder对比同一批数据上的召回率。大多数场景下，替换回专用Encoder模型后效果立竿见影。

6.2 常见问题二：Encoder-Decoder生成的内容不够“活”

有人拿T5做开放式对话，效果很僵硬，感觉像是在完成填空题。这其实是架构选错：T5这类模型的设计目标是“有约束的转换任务”，对输入的忠实度高，但自由发挥空间小。开放式对话需要的是Decodeer-only那种“天马行空”的自回归生成风格。

排查思路：检查任务是否属于强约束条件生成。如果是开放式生成，尽快换Decodeer-only模型做微调。T5在翻译、改写、结构化抽取这些“输出受输入严格约束”的场景中依然好用。

6.3 常见问题三：模型上生产环境后的速度与成本失控

这是一个工程向的典型坑：只关注模型效果指标，忽略了推理成本。Decoder-only模型是自回归逐token生成，输出长度直接决定耗时和成本。在实际项目里，很多团队栽在“模型对话很流畅但成本兜不住”的困境上。

我的建议是分层规划：高吞吐、高并发场景尽量用蒸馏后的小模型；效果敏感场景用大模型但不滥用长输出；RAG场景控制检索文本块的长度。以70亿参数模型为例，4bit量化后推理显存约6-8GB，但生成512个token约需数十秒甚至更长（依硬件而定），你必须在上线前就算好这笔账。

6.4 实操心得：微调与推理部署中的几个精细操作

最后分享几个微调、部署中的细节，这些通常不在官方文档里写：

• 微调时注意数据格式的一致性：Decoder-only模型的微调格式（如ChatML）需要严格保持，否则对话能力会劣化
• 用LoRA而不是全参微调起步：7B模型的LoRA微调一张消费级显卡即可运行，效果通常已能满足垂直场景需求
• 切换模型版本后先回归测试：不同版本的Tokenizer词表可能不同，直接替换模型权重而不重新运行测试脚本，很容易出现生成混乱
• 量化部署优先用GPTQ或AWQ：4bit量化损失较小，对生成质量影响可控，性价比最高

从我个人实际踩坑的经验来看，架构理解不是纯粹的理论学习——它直接决定了你在实际项目中的试错成本。先花半天时间搞懂三种架构的区别，再动手搭系统，远比你埋头调参快得多。理解这些底层机理的好处在于：当你面对一个全新任务时，至少能准确判断该往哪个方向去找模型、做配置，而不至于在第一步就选错研究对象，后面反复推倒重来。做技术选型，认知先行，剩下的都是执行层面的时间问题。