1. 大语言模型这个概念，到底该怎么理解

先把这个词拆开看：大语言模型，英文叫 Large Language Model，简称 LLM。它不是某一种具体模型的名字，而是一类模型的统称。现在大家张口闭口都在聊大模型，但真正把“大语言模型是什么”说清楚的人其实不多。简单来说，大语言模型是一个通过海量文本训练出来的深度学习模型，它的核心能力是理解自然语言、生成自然语言，并且在理解的基础上完成问答、翻译、摘要、推理、代码补全这类任务。

“大”是大语言模型最显眼的一个标签。很多人的第一反应是“参数多”，这没错，但不全面。参数量确实是个硬指标，GPT-3 有 1750 亿参数，后来的模型动辄几百亿、上千亿，参数规模呈指数级增长。但“大”还包括数据大、计算大和效果质变这三层含义。训练文本动辄几个 TB 甚至几十个 TB，训练过程需要上万张 GPU 连续跑几个月，电费和算力成本都是千万美元级别。更关键的是，当模型的规模跨过一个临界点之后，一些之前看不到的能力会突然涌现出来，比如上下文理解、逻辑推理、少样本学习甚至思维链推理，这就是所谓的“涌现能力”。这个才是“大”真正迷人的地方。

这篇文章是“大模型技术全景”系列的第三篇，前两篇聊了大模型技术演进的背景和整体的产业生态，这一篇把视角收回到模型本身，重点讲两件事：第一，大语言模型到底“大”在哪里，这个“大”是如何一步步形成的；第二，目前主流的三种架构——纯解码器架构、纯编码器架构、编码器-解码器架构——各自是什么原理、各自适合什么场景、为什么最后 GPT 那条路成了行业的主流。不用担心太学术，我会尽量用大白话把背后的逻辑讲清楚，让没有深度学习背景的读者也能读懂，同时把一些工程上实用的选型经验也一并分享出来。

如果你是做技术选型、研究方向判断或者只是想更深入地理解大模型的运作机制，这篇文章都值得读下去。如果你是刚入门的初学者，我建议先把 Transformer 的基本概念了解一下再来读这篇，会顺很多。当然，直接硬啃也没问题，我会在关键地方把前置知识补上。

2. “大”不仅仅指参数多，三个维度拆开看

2.1 参数规模：模型存储的“知识密度”

参数是模型内部的可学习变量，训练过程本质上就是在调整这些变量的值，让模型能够从输入映射到正确的输出。参数量越大，模型能够记住和抽象的模式就越复杂。这里有个容易踩坑的认知：参数多不等于一定聪明，但参数多是实现高智能的必要条件之一。就像一个图书馆，藏书多是知识丰富的必要条件，但如果书的内容全是垃圾，藏书再多也没有用。数据的质量和训练的方法同样决定模型的上限。

从工程角度来看，参数量直接决定显存需求。一个 70 亿参数的模型，用 FP16 精度加载，光权重就需要大约 14 GB 显存。如果是 1300 亿参数的模型，就需要 260 GB 左右，单张 A100 的 80 GB 显存也放不下，需要多卡并行。这就引出了分布式训练和推理部署的成本问题。所以很多人聊“大模型”，第一反应是参数规模，因为它是决定算力成本的最直接因素。

2.2 训练数据：大模型的“语料粮仓”

数据维度上，“大”体现在两个层面：一是总量，二是多样性。早期语言模型的训练集还停留在几百兆文本的规模，近几年的大语言模型直接用 TB 级别的数据进行预训练。GPT-3 的训练数据包含 Common Crawl、WebText2、Books1、Books2 和维基百科，总计大约 5000 亿个 token。一个 token 大约相当于一个单词或一个子词片段，你可以大概换算一下，整个英文维基百科也就几十亿 token，而大模型动辄吃下相当于几百倍维基百科的数据量。

多样性同样关键。训练数据如果只来自单一来源，模型的泛化能力会很差。理想的数据配比是网页、书籍、学术论文、代码、对话记录混合在一起，让模型接触到不同领域、不同文体、不同风格的语言表达。这也是为什么很多团队在做数据清洗时特别讲究配比。我在实际项目中就遇到过模型在代码任务上表现极差的情况，后来排查发现是训练语料里代码占比只有 2% 左右，加到了 15% 之后效果立刻改善。数据配比这个东西，看着不起眼，实际影响比很多调参手段都大。

2.3 计算开销与能力涌现：从量变到质变

OpenAI 在 2020 年发表的论文《Language Models are Few-Shot Learners》里就发现，当模型规模上升到一定量级，一些任务的表现会突然出现跳变，而不是平滑提升。这就是“涌现能力”现象。典型例子包括：多步推理、上下文学习、指令遵循等能力的出现，往往集中在百亿甚至千亿参数规模以上。

这种质变带来的工程影响非常深远：模型规模决定了你在实际应用中可以直接享受哪些能力，而不用专门训练一个任务模型。比如你有一个小规模语言模型，做问答可能需要专门微调；但当你用的模型够大时，直接给几个 few-shot 示例，模型就能学会你的问题的格式和逻辑，这就是所谓的“少样本学习”。所以对开发者来说，理解“大”的内涵，本质上是理解你用什么样的资源成本去换取哪些能力，这是一个非常现实的技术经济问题。

3. 三种主流架构的底层逻辑与演进脉络

3.1 Transformer：所有大语言模型的共同地基

在讲三种架构之前，有必要花一点篇幅说说 Transformer，因为大语言模型的架构区别本质上都是 Transformer 内部的模块排列方式不同。Transformer 是谷歌在 2017 年发表的论文《Attention Is All You Need》中提出的模型结构，核心组件有两个：自注意力机制和前馈神经网络。

自注意力机制可以这样理解：它在处理一个词的时候，会同时看整个句子里所有其他词，然后计算它们之间的相关性权重。比如在“小明把苹果放到了桌上，然后他离开了”这句话里，“他”指代什么？自注意力机制可以通过计算“他”和“小明”之间的注意力权重，把两者的关联建立起来。这种全局关联能力让 Transformer 比此前的 RNN（循环神经网络）更擅长捕捉长距离依赖，因为 RNN 在处理长文本时容易出现信息遗忘的问题，就像一个人听一段很长的录音，记不住 5 分钟前的内容一样。

Transformer 本身有两个子模块：编码器（Encoder）和解码器（Decoder）。编码器负责把输入文本转换成一系列向量表示，说白了就是“读”；解码器负责根据这些向量逐步生成输出文本，就是“写”。三种主流大语言模型的架构差异，本质上是这两者的组合方式不同。这就好比同样用钢筋水泥盖房子，有的人盖了公寓楼，有的人盖了独栋别墅，结构布局不同，适用场景就不同。

3.2 纯解码器架构：GPT路线为什么成了主流

纯解码器架构，英文叫 Decoder-only，是目前大模型圈子里最红的架构，OpenAI 的 GPT 系列、Meta 的 LLaMA 系列、国内的 Qwen 系列都是这个路子。它的特点是只保留 Transformer 的解码器部分，输入和输出共用同一个结构，通过自回归方式一个 token 一个 token 地生成结果。

自回归生成可以类比为一个人写文章：先写第一个字，然后基于第一个字写第二个字，再基于前两个字写第三个字，一直到整篇文章写完。GPT 的训练目标就是预测下一个 token，给定前文预测后续内容。这种简单的目标有一个巨大优势：训练和生成的方式完全一致，都是从左到右顺序处理，因此工程落地非常简单。

在 GPT 之前，业界其实更看好编码器-解码器架构和纯编码器架构，因为它们在理解和分类任务上表现更好。但 GPT 系列在 2020 年到 2022 年之间接连证明了一件事：只要模型足够大、数据足够多，纯解码器架构也能通过自回归训练“顺便”学会理解任务。BERT 当初需要在训练时专门设计“预测被遮住的词”这样的任务来培养理解能力，GPT 则简单粗暴得多——我只管预测下一个词，理解能力会在训练过程中自己涌现。这就是纯解码器架构最核心的逻辑。

为什么最后是这条路跑通了？一个重要原因是它在训练目标和任务目标之间没有额外的 gap。你训练模型写文章，最后用的时候也是让它写文章，这个一致性很高。另一个原因是软件生态成熟，从 GPT 时期开始，文本生成的代码栈就围绕解码器架构优化，推理框架如 vLLM、TGI 也都默认优先支持这类模型。工程上省事，性能上达标，生态上占优，综合下来就成为默认选项。

3.3 纯编码器架构：BERT路线为什么依然能打

纯编码器架构，即 Encoder-only，代表作是谷歌的 BERT 和 Meta 的 RoBERTa。它的特点是只保留 Transformer 的编码器部分，在处理一个词的时候，既能看它左边的词，又能看它右边的词，也就是双向上下文理解。这和 GPT 的做法完全相反，GPT 生成时只能看前面的词，BERT 则是整个句子一次性输入，每个位置都能同时感知全局信息。

BERT 的训练方式是“掩码语言建模”，也就是把句子里的随机一些词挖掉，让模型根据上下文推测被挖掉的词是什么。这就像完形填空。这种训练方式让 BERT 对文本的理解深度非常出色，所以在文本分类、情感分析、命名实体识别、语义匹配等理解类任务上，BERT 的表现在同等参数规模下通常优于纯解码器模型。

我在实际项目中做过对比测试：在语义相似度计算任务上，同样参数量级下，BERT 系模型在准确率上比 GPT 系模型高出不少。原因不难理解，双向上下文提供的信息量天然比单向上下文多，理解类任务本质上是“读完所有信息再判断”，BERT 的工作方式更契合这类任务。

所以虽然现在的风口是生成式大模型，但 BERT 这种架构并没有死，它在搜索排序、文本分类、结构化信息抽取等场景中依然是高性价比的选择。特点就是模型规模不需要太大，通常亿级参数就够用，推理速度也快，部署成本远低于生成式模型。

3.4 编码器-解码器架构：T5路线的平衡之道

编码器-解码器架构，即 Encoder-Decoder，最早是机器翻译的标准方案，代表作是谷歌的 T5 和 Meta 的 BART。它的结构是“一个编码器负责读，一个解码器负责写”。输入文本先由编码器读完整句，形成一个全局语义表示，解码器再基于这个表示逐步生成输出。

这种架构的优势在于：编码阶段可以获得完整的双向上下文理解，解码阶段可以保留自回归生成能力。所以它在“既需要理解、又需要生成”的任务上表现最好，比如文本摘要、机器翻译、问答系统、格式转换等。T5 的核心思想更有趣，它把所有 NLP 任务都统一成“文本到文本”的格式：输入是一段文本，输出也是一段文本。做分类时，输入是“情感分类：这部电影真好看”，输出是“正面”；做翻译时，输入是“翻译成英文：今天天气不错”，输出是“The weather is nice today”。这个设计让一个模型可以同时处理多种任务，体现出很强的通用性。

编码器-解码器架构也有它的烦恼：参数多，因为编码器和解码器各有一套参数；推理速度相对更慢；而且训练时要同时优化理解和生成两方面的能力，调参复杂度更高。在算力有限的情况下，你很难像训练同等规模的纯解码器模型那样把它训到最优。这也是后来很多团队转向纯解码器路线的原因之一——同样的预算，训纯解码器更容易出成果。

不过在实际工业应用中，如果你做的是一个特定的生成任务，比如电商平台的商品文案生成、法律文书的摘要、会议纪要整理，编码器-解码器模型往往是最适合的起步选择，因为它不需要像 GPT 那样把理解能力也一并训练出来，针对单一任务更容易发挥稳定。

4. 三种架构的分工与选型：哪条路更适合你的场景

4.1 一张表看懂三种架构的本质区别

这一节我用表格做一个直观对比，方便你在做技术选型时快速对照。

我对参数效率这个维度的解释再展开一些：纯解码器架构要达到好的理解效果，通常需要非常大的参数量，因为它在训练时只见过单向信息，理解能力要靠大量数据“喂”出来。而纯编码器架构因为双向上下文天生能拿到更多信息，小模型就能有不错的表现。编码器-解码器居中，但它多了一套编码器结构，参数总量自然就上去了。

4.2 实际选型的三条经验法则

做技术选型时，我习惯了先问自己三个问题：任务是偏理解还是偏生成？算力预算有多少？需要实时推理还是离线处理？

第一个问题的回答直接决定架构方向。偏理解、输出是标签或分类的任务，优先选纯编码器。偏生成、输出是长文本的任务，优先选纯解码器。既需要理解输入又需要生成新内容的任务，比如摘要和翻译，可以在这两者之间权衡：如果预算充足且想要最佳效果，选编码器-解码器；如果想要更通用的模型且不太在意额外消耗，直接用纯解码器也能覆盖。

第二个问题和第一个相关。如果算力紧张，又想快速上线一个分类系统，选 BERT 系是最务实的。想本地部署或者边缘设备上用，也是纯编码器的天下。大参数量的纯解码器模型需要好几张 A100 才能跑推理，不是所有团队都承受得起的。这里建议在选型时，先去 Hugging Face 上通过模型卡片查看参数量，估算一下最小显存需求，别等选完了才发现部署不起。

第三个问题决定你用 API 还是自己部署。如果任务实时性要求高，纯编码器在 CPU 上就能跑；纯解码器通常需要 GPU 加速，延迟会高一些。做离线批处理任务，比如批量生成商品描述、批量摘要文档，那就可以用慢一些但效果更好的编码器-解码器模型，不用太担心推理耗时。

4.3 微调实战中的架构差异，以文本分类和代码生成为例

两种典型场景下的架构选择可以放在一起对比。

文本分类任务：假设你要做一个客服工单自动分类系统，工单文本可能需要判断是退货、退款、咨询还是投诉。这时用 BERT 系模型的路径是：预训练模型加一个分类头，把最后一层的输出过一层全连接层，映射到四个类别的概率分布。一般训练几个 epoch 就能收敛，准确率很容易做到 90% 以上。如果用 GPT 系模型做这个任务，你需要设计提示词，比如“请判断以下工单属于哪一类：退货、退款、咨询、投诉。工单内容：…… 输出分类：”，然后拿模型输出的文本去解析。效果不一定差，但调用成本高、延迟也高，而且你需要处理文本解析的边界情况。为了一个四分类任务去用千亿参数模型，我认为性价比很低。

代码生成任务：这个场景纯解码器几乎是唯一选择。你给模型一段注释或者一个函数签名，让它把实现补全，或者根据需求描述生成完整函数体。GPT 系模型在代码补全上的能力是经过验证的，而 BERT 系模型基本做不了这种开放式生成任务，因为它在设计上就不是为了这块做的。编码器-解码器也能做，像 CodeT5 这样的模型效果也挺好，但社区生态和工具链丰富程度显然不如 GPT 系，特别是在大代码库级别的补全场景下，纯解码器优势非常明显。

5. 千亿参数的背后：训练过程如何塑造架构能力

5.1 预训练与微调的两阶段路线

大语言模型的训练过程一般分两步：预训练和微调（或者对齐）。预训练就是在海量无标注文本上训练模型，目标函数很简单——对纯解码器来说就是预测下一个词；对纯编码器来说就是完形填空；对编码器-解码器来说就是输入片段后预测输出片段。预训练的产物是一个“通用语言理解与生成模型”，它什么都不专精，但什么都会一点。

第二步是微调或对齐，目的是让模型学会遵循指令、符合人类偏好。典型的做法是用人工标注的问答对做监督微调，或者用 RLHF（基于人类反馈的强化学习）来调整模型的行为。很多开发者容易混淆一个概念：大模型不是天生就懂如何回答问题。你要是把一个没有经过指令微调的 GPT-3 直接拿来对话，它输出的东西更像完形填空，而不是像一个人在和你聊天。所以基座模型和应用型模型的差别非常大。

5.2 架构如何影响训练效率和数据效率

架构选择对训练效率的影响体现在几个维度：显存占用、训练吞吐量和收敛速度。纯编码器因为只有编码器，显存效率最高；训练时的 batch size 可以开得很大，吞吐量也高。解码器-纯解码器因为要顺序生成，训练效率相对低一些，但因为只需要输入一个方向，实现简单，所以在超大规模训练时反而是最省心的。编码器-解码器最贵，因为两套结构都要显存，计算量翻倍。

数据效率上，BERT 类模型在少数据下也能达到不错的效果，因为双向信息利用充分。GPT 类模型数据利用效率最低，但它靠大力出奇迹弥补了这个缺陷——数据海了去了，一个方向也能学到足够多的规律。这正好印证了大语言模型“大”的哲学：解决不了的问题，就用更大的模型、更多的数据去解决。这种思路简单、粗暴但有效。

5.3 训练中的三个核心参数

在训练过程中，有几个关键参数直接影响模型效果，我在调参时踩过一些坑，这里一并分享。

学习率过大，模型在训练后期会出现难以收敛的情况，表现为损失函数震荡不降；学习率过小，模型收敛太慢，训练成本直线上升。实际操作中一般使用预热加余弦衰减的调度策略：前几千步学习率线性上升，之后逐渐衰减。batch size 影响到梯度估计的稳定性，大 batch 训练时梯度噪声小，但显存压力大；小 batch 则相反。实践中需要根据硬件资源平衡。序列长度决定了模型一次能处理的上下文长度。对于纯解码器架构，序列长度和训练成本几乎线性相关，因为自注意力机制的计算量随序列长度平方增长，所以把序列长度从 2048 扩到 4096，训练成本不是翻倍，而是接近四倍。

这些参数之间的关联很微妙，真到实际操作中，往往要靠实验来找最优组合。这也是为什么现在有很多人建议直接使用已经训练好的开源模型，而不是自己从头训——从头训练的成本极高，而微调一张开源基座模型性价比高得多。

6. 大语言模型未来演进的技术方向与架构趋势

6.1 混合架构与稀疏注意力

当前纯解码器架构一家独大的局面，在未来很可能会被一些混合方案打破。一个明显的方向是混合专家模型，也就是 MoE（Mixture of Experts）架构。MoE 的思路是把一个巨大的模型拆分成多个“专家”子网络，每次推理时只激活其中一部分专家，而不是全部。这种做法相当于你有一个千人团队，但处理每个任务时只叫出其中最擅长的那几十个人来干活，既能保持大模型的容量，又能控制实际的计算消耗。DeepSeek、Mixtral 都是这条路线上的代表。

另一个方向是稀疏注意力。前面提到自注意力机制的计算量随序列长度平方增长，这使得处理超长序列非常昂贵。稀疏注意力会限制每个 token 只关注特定范围内的 token 或随机采样的 token，将计算复杂度降下来。比如 Longformer 和 BigBird 就是这类尝试。但这类设计也有代价：模型结构复杂度上升，训练难度增加，效果能否和全注意力持平还需要验证。

6.2 多模态与统一架构

大语言模型的边界正在从纯文本向语音、图像、视频扩展。多模态大模型不是一个单独的架构创新，而是在已有的语言模型基础上增加视觉/音频编码器，再通过一个投影层把多种模态的信息对齐到语言模型的表示空间里。目前主流的多模态模型几乎都是“视觉编码器 + 文本解码器”的混合体，语言模型部分仍然以纯解码器为主。这意味着理解纯解码器架构，仍然是理解多模态大模型的基础。

未来更大的可能是真正的统一架构：用一个模型直接处理任何模态的输入输出，不做模态专属编码器，就像人脑处理视觉信息和听觉信息用的是同一套神经元机制一样。目前这个方向还在探索阶段，但如果跑通了，三种架构的边界可能就不那么重要了，大家只需要一个统一的接口。

6.3 对开发者和研究者的建议

我对读者的建议其实很朴素：不要盲目追逐最新架构，而要始终从任务出发。如果手头的业务是知识问答、代码生成、通用助理，纯解码器模型是你的首选，直接用 Claude、GPT、Qwen 这类的 API 或开源权重即可。如果任务是分类、抽取这种偏理解需求，BERT 系小模型仍然是高性价比的选择，不要因为它“老”就觉得落后。如果要做专业领域的摘要或翻译，编码器-解码器模型很可能是效果最好、成本最优的选项。

另外一点想说的是：架构只是大语言模型的一个截面。数据质量、对齐方法、部署优化、评测体系、业务场景适配，每个维度都能做很多文章。一个模型效果不好，很多时候不是架构的问题，而是数据或者训练细节的问题。把这一点认知摆正，你在看各种大模型相关消息时，就不会轻易被带偏。

7. 我的一点实践体会

做了几年大模型相关的工作，我越来越觉得，架构选型其实是一个权衡的艺术。纯解码器架构如今占据绝对主流，有技术原因也有生态原因，但这不意味着另外两种架构就失去了存在意义。我印象很深的一次经历是给某个企业做工单分类系统，团队里年轻的工程师一上来就想用大模型 API 去解决，我坚持先用一个 3 亿参数左右的 BERT 模型打底，结果跑下来效果达标，响应速度飞快，成本几乎可以忽略不计。如果当时一窝蜂去调用大模型，不仅延迟高，费用也会让客户吃不消。

反过来也有一次，做智能客服的知识库问答，最开始用编码器-解码器模型做了检索式方案，效果不够理想。后来换成一个百亿参数的纯解码器模型做生成式问答，配合检索增强，效果马上上了一个台阶。这两个案例让我形成了一个习惯：不看“流行”选架构，而是先想清楚任务本质——这段数据进来之后，你是想让模型“读懂”并且给出一个判断，还是想让模型“接着写”出一段答案。判断选编码器，生成选解码器，又判断又生成就认真掂量一下预算和效果预期。

最后再分享一个小技巧。如果你不确定自己的任务更适合哪种架构，可以直接在 Hugging Face 上分别搜一个对应架构的预训练模型，用几百条标注数据简单做一次对比实验。选三到五个种子，两种模型各自微调一两个 epoch，跑一下验证集指标，很快就能看到差异。这个做法花不了多少钱，但能帮你在架构选型这件事上少走很多弯路，比看十篇评测文章都管用。