先说明一下，这一篇是“大模型技术全景”系列的第三篇。前两篇咱们聊了深度学习的基础和Transformer的来龙去脉，今天终于轮到主角登场——大语言模型。文章会聚焦三个问题：大语言模型是什么、它到底“大”在哪、以及三种主流架构之间有什么区别。不管你是刚入行的开发、准备做AI应用的产品经理，还是单纯想搞明白ChatGPT这类东西背后原理的好奇人士，这篇都能给你一个清晰的框架。

如果你已经在用各种AI产品，但脑子里对“大模型”“大语言模型”“多模态模型”这几个词还是一团浆糊，那我特别建议你读完这篇。很多时候大家讨论的东西其实不是一个层面的：大模型是统称，大语言模型是其中最重要的一支，多模态模型又是另外的路线。把这层关系理清楚，后面看任何技术文章、选型方案，思路都会顺很多。

1. 大语言模型到底“大”在哪里

大语言模型的“大”，字面意思是参数量大，但实际拆开看，它至少体现在四个维度上：参数规模、训练数据量、算力消耗和上下文窗口。这四个维度共同决定了一个模型的“能力上限”，也决定了训练一张“大脸”背后需要烧多少钱。我一个个拆开说。

1.1 参数规模：衡量“知识容量”的尺子

参数是神经网络里可学习的权重，你可以把它理解成大脑里神经元之间的连接强度。连接越多，理论上能记住的模式就越多。早期的语言模型，比如Word2Vec，参数量只有几百万；ELMo大概几千万；BERT-large到了三亿多；GPT-2是15亿；GPT-3直接干到1750亿；现在主流的开源模型比如LLaMA-3是80亿和700亿两个规格，Qwen系列也有720亿的版本。

参数规模直接决定模型的“知识容量”。为什么GPT-3比GPT-2聪明这么多？不只是因为数据多，更因为1750亿的参数给了它足够大的“储物空间”去装下各种语法规则、事实知识甚至推理模式。有个特别有名的现象叫“涌现能力”——当模型规模跨过某个阈值，它突然就能做思维链推理、上下文学习这类小模型完全做不到的事。这个阈值没有一个精确数字，但普遍观察在百亿参数以上。

不过这里要泼一盆冷水：参数不是越大越好。参数越多，训练和推理的成本越高，而且到了一定规模后，继续堆参数的收益会递减。2024年之后行业里有个明显趋势，就是在同样参数规模下，把训练数据做得更精、更干净，效果比单纯增大模型更好。这就是为什么现在很多模型号称“小钢炮”，比如Qwen2.5-14B，参数不大，但很多任务上能打平老款的70B甚至更大模型。

1.2 训练数据：从GB到TB的语料“投喂”

光有参数不行，还得有数据“喂”进去。大语言模型的预训练数据量，这些年涨得比参数还猛。BERT当年用了约33亿词的维基百科加书籍；GPT-3用了约3000亿token；GPT-4没公布细节，但外界估算在数万亿token级别；开源的LLaMA用了1.4万亿token；到了LLaMA-3，直接干到15万亿token。

训练数据对大语言模型的塑造是决定性的。模型能聊星座、懂编程、知道历史事件，全是因为预训练阶段见过这些文本。数据质量的重要性怎么强调都不过分：喂进去的是垃圾，出来的就是垃圾。业内现在有个共识，高质量数据比海量数据更重要。所以你看各家大模型团队都在卷“数据清洗”，把重复的、低质的、有毒的内容滤掉，再通过“课程学习”的方式，让模型先学简单通用的语料，再学专业领域的语料。

这里有个容易忽略的细节：token不是“字”，也不是“词”，而是模型处理文本的基本单位。英文里一个token大约等于0.7个单词，中文大约是一个字到半个词。不同分词器对同样文本切出的token数量不一样，这直接影响训练和推理的算力成本。所以各家模型的tokenizer设计也是一门学问，做得好的分词器能让同样内容用更少的token表达，省下真金白银。

1.3 算力和训练成本：大模型的隐形门槛

训练一个1750亿参数的模型需要多少算力？我们可以用一个粗略公式估算：训练一个N参数模型、D个token，需要的计算量大约是6ND次浮点运算。GPT-3是1750亿参数、3000亿token，算下来约3.15E23次浮点运算。一块A100 GPU的FP16算力大约是3.12E14次每秒，理想情况下单卡要算大约3年。实际训练当然不是单卡，OpenAI当年用了上万张GPU集群，训练了几个月。

这笔账算下来，训练一个大模型的成本是千万美元级别。这也是为什么有能力从零训练大模型的公司全世界就那几家。普通团队要玩，基本只有两条路：一是用开源模型做微调，这个成本可以压到几万人民币甚至几千块；二是用API调用，按token付费，这个丰俭由人。

还有一个维度是上下文窗口。早期BERT只能处理512个token，相当于几段话；GPT-3是2048，差不多两页纸；现在的主流模型动辄32K、128K甚至1M。上下文窗口决定了模型一次性“看得见”多少内容，直接关系到长文档分析、多轮对话、代码仓库理解这类场景能不能落地。很多人误以为上下文越大越好，其实窗口越大，注意力计算的开销越高，显存压力也越大，这也是一个需要权衡的点。

2. 三种主流架构：BERT、GPT 与 T5 的底层逻辑

聊完了“大”，现在聊架构。大语言模型最核心的架构有三类：编码器架构（Encoder-Only）、解码器架构（Decoder-Only）、编码器-解码器架构（Encoder-Decoder）。三种架构长得相似，底层都是Transformer，但设计思路和适用场景差异很大。

2.1 编码器架构：双向理解的“完形填空大师”

编码器架构的代表是BERT。它的核心设计是“双向注意力”——读一个词的时候，上下文（左右两边）都能被看到。训练方式也很有特色：随机盖住句子中15%的词，让模型根据上下文猜被盖住的是什么。

用生活化的例子来理解：这就是“完形填空”。给你一句话“今天[blank]去公园散步”，你需要根据前后信息猜出空白处是“我”还是“他”。这种训练方式让模型对“理解”这件事特别擅长——它能捕捉到词语之间细微的语义关系，适合做文本分类、命名实体识别、情感分析、信息抽取这类判别式任务。

不过编码器架构的短板也在这：它天生不擅长“生成”。因为训练目标就是猜测被遮住的词，而不是从头生成一段新文本。虽然你可以强行在BERT后面接一个生成头，但生成质量和专门为生成设计的模型比，差得不是一星半点。这也是为什么BERT在生成式AI浪潮里渐渐淡出，但在很多垂直场景（比如搜索排序、文本向量化）里依然活跃。

补充一个实操细节：用BERT做文本向量化时，传统做法是取[CLS]位置的向量，但我在实际项目里发现，对长文本用“平均池化”或“最大池化”效果好很多，尤其是做语义相似度计算的时候。这是个容易踩的坑。

2.2 解码器架构：自回归生成的“成语接龙选手”

解码器架构是当前最火的路线，GPT系列、LLaMA、Qwen、DeepSeek、Gemini（主要版本）全都是这个架构。它的核心特点是“单向注意力”——预测某个词的时候，只能看它前面的词，不能看后面的。训练方式是“自回归”：给定前面的词，预测下一个词是什么。

用生活化的例子理解：这就是“成语接龙”。给你“大”，你接“大力”，再接“大力出”，最后生成“大力出奇迹”。模型每次只生成一个token，把这个token拼到已有序列后面，再继续生成下一个。ChatGPT流利对话的本质，就是一次接一个字的“成语接龙”，只不过接得足够丝滑，给人感觉是“理解”。

解码器架构最大的优势是“通用”。因为任何任务都可以被改写成“给定上文，预测下文”的形式：翻译就是“给英文，预测中文”，摘要就是“给长文，预测短文”，问答就是“给问题，预测答案”。这种统一的格式让解码器模型可以吸收海量数据，练出极强的通用能力，还涌现出上下文学习、思维链推理等小模型没有的本领。

但也有代价。自回归生成是逐token进行的，速度慢，而且推理时每个token都要重新计算前面所有token的注意力。好在业界有KV Cache这个优化技巧，把之前算过的Key和Value缓存下来，后面直接复用，这个后面再细说。另外，解码器模型彻底放弃了“看到后面”的能力，所以在某些需要全局理解的任务上，理论上不如编码器模型有优势——不过实际操作中，生成式模型靠海量数据和指令微调，把这种劣势弥补得差不多了，这也是为什么行业现在“清一色解码器”。

2.3 编码器-解码器架构：先看懂再回答的“翻译官”

编码器-解码器架构，也叫Seq2Seq架构，代表模型是T5和BART。这种架构分两段：编码器负责“读”输入文本，提取语义，生成一组隐藏表示；解码器负责“写”输出文本，基于编码器给的表示，逐步生成答案。

用生活化的例子理解：这就是一个“翻译官”。编码器像听对方说话并做笔记的人，解码器像看着笔记组织语言、原样输出的人。这种结构天然适合“输入和输出都是文本、但两者差异较大”的任务，比如机器翻译、文本摘要、问答——输入是一篇文章，输出是摘要，中间的语义转换交给编码器完成。

T5的设计尤其精巧：它把所有任务都统一成“text-to-text”，也就是输入文字、输出文字。分类任务也改造成“输入：这是正面还是负面？[内容]；输出：负面”。这个思路直接启发了后面对统一任务格式的研究，可以说是解码器架构大一统之前的过渡方案。

不过，编码器-解码器架构现在处境有点尴尬。它比纯编码器能生成，又不如纯解码器模型能打——现在GPT系列一个模型通吃所有任务，效果比T5还好。所以你会发现，近两三年新发布的模型里，Seq2Seq架构越来越少了。但它在翻译、摘要这类传统NLP任务里仍有价值，尤其是可控性要求高的场景，它对输入的编码是无损的，不像纯解码器把所有东西混在一起生成。

3. 三种架构的横向对比与场景选型

三种架构各有各的擅长区，选型没有绝对的“最好”，关键是看你的任务形态。

3.1 一张表看懂三种架构的能力差异

这个表格看下来，其实没有“全面全能”的架构。编码器理解强但生成弱，解码器生成强但理论上全局理解有短板，编码器-解码器两头都占但都不拔尖。所谓的“强”和“弱”，也要看具体任务和模型规模——一个700亿参数的解码器模型，在分类任务上通常比3亿参数的BERT强得多，因为规模碾压了架构差异。

3.2 为什么今天的生成式AI几乎全用解码器架构

这是近两年整个行业最明显的一个趋势：解码器架构一统天下。原因我觉得有三点。

第一，任务的统一性。解码器把一切任务都变成了“下一个词预测”，这让训练可以无差别地吞下任何文本数据——新闻、代码、书籍、对话，一股脑扔进去就行。编码器架构需要精心构造带标签的数据才能训练，数据利用效率差了一个量级。数据规模上去了，模型就厉害了，这是最朴素也最根本的规模效应。

第二，涌现能力的加持。上下文学习和思维链是解码器模型在规模扩大后自然出现的，而这两种能力在编码器架构里很难奏效。因为“看完整句再猜词”的训练方式，不利于模型学会按步骤推理。

第三，工程生态的倾斜。全行业都在围绕解码器架构优化推理引擎、微调框架、部署工具。你去看vLLM、TensorRT-LLM这些推理框架，优化重点全在自回归生成和KV Cache上。生态一旦形成，后来者再走其他路线，等于自己造轮子，成本高到离谱。

当然，这并不意味着编码器架构会消失。在需要高性能文本向量的场景，比如做RAG（检索增强生成）的embedding模型、做语义搜索的召回模型，BERT类架构依然是最优选，因为向量质量高、推理速度还快。

3.3 实际项目里怎么选：看任务、看预算、看场景

我自己的经验可以总结成一个简单的决策流程：

第一步，看任务类型。如果你的任务是“判断类”——分类、打标签、抽取实体，优先试解码器模型直接提示词调用。如果模型太大部署不动，或者延迟要求极高，再用编码器架构做蒸馏或微调。如果你的任务是“生成类”——对话、写作、代码补全，没二话，直接上解码器模型。

第二步，看部署条件。如果是在云端调API，那不用纠结架构，选服务商能力强的模型就行。如果要在本地服务器甚至边缘设备部署，就要精打细算：7B到14B的量化模型是甜点区，前提是显存能装下；编码器架构的模型则适合做检索、分类这类轻量任务。

第三步，看预算和人才储备。从零微调一个解码器模型，即使只调LoRA，也需要理解生成式模型的调参逻辑。如果团队之前没有相关经验，最稳妥的方式是先做Prompt工程和RAG，选型上直接挑最强的商用API，把业务跑通再考虑自建。微调不是万能的，大多数业务场景的瓶颈在于“模型不知道怎么用”，而不是“模型不够强”。

还有一个经常被忽略的点：架构选择会影响后续的迭代路径。选了纯解码器，你可以很快切换到更新的开源模型，因为接口逻辑一样；选了T5这类Seq2Seq，如果官方不再维护，后续升级就会很痛苦。所以除非有特别明确的翻译或摘要需求，我一般不建议新项目再选编码器-解码器架构。

4. 架构如何影响训练、微调与推理部署

架构不只是一个学术概念，它直接决定你在训练、微调、推理三个阶段会碰到什么问题。这一节聊的就是架构落地的那些事。

4.1 预训练和微调：架构决定能力底座

预训练阶段，模型通过海量文本学到语言规律和世界知识，形成“能力底座”。微调阶段，模型用少量高质量标注数据调整行为，学会做特定任务。这个“底座+调整”的思路，是理解大模型应用的关键。

不同架构的微调方式有差异。BERT类模型微调时，通常是在顶部加一个分类头或抽取头，把预训练学到的语义特征对接下游任务。这相当于在已经建好的房子上加一个门牌。解码器模型微调时，大多不改变模型结构，而是直接学“用自然语言输出答案”，比如指令微调（Instruction Tuning）就是用几十万条“指令-回答”对，教模型听懂人话、按指令行事。T5类模型微调则要保持text-to-text的格式，输入输出都写成文本。

这里要强调：微调改变的是行为，不是能力。如果模型底座根本没有相关知识，微调再多数据也白搭。好比让一个没见过汽车的人通过微调学写汽车评测，他能背下话术模板，但写不出发动机原理和驾驶体验。所以做微调前，先评估模型底座够不够强，方法就是直接用提示词测试，如果零样本效果就很好，那根本不需要微调；如果效果差得离谱，优先考虑的也应该是换更大模型或做RAG，而不是盲目微调。

4.2 解码器架构的推理瓶颈：KV Cache与自回归

解码器架构的推理有一个绕不开的性能问题。生成第N个token时，需要计算它和之前N-1个token的注意力。如果不做任何优化，每生成一个token都要重新算一遍前面所有token的注意力权重，计算量随序列长度呈平方增长。打个比方，写一篇文章，每写一个字都要重新通读一遍前面所有的字，那写到一千字就得读一千遍，效率极低。

业界标准的解法是KV Cache。思路很简单：注意力计算中用的Key和Value矩阵，在生成过程中只依赖于已生成token，不会变化。那我把每个位置的Key和Value算好存在显存里，生成下一个token时直接读取，不用重算。这是一个典型的空间换时间，效果拔群。但代价是显存占用：上下文越长，缓存的K和V就越多，显存就越大。这也是长上下文模型推理成本高的核心原因。

部署解码器模型时，最常见的瓶颈反而不是算力，而是显存带宽。模型参数要一点一点地从显存搬到计算单元上，这个“搬运”速度决定了首token生成延迟。所以你才会看到各种量化技术（8bit、4bit）被广泛使用，量化后模型体积变小，搬运的字节数减少，延迟随之下降。代价是模型精度轻微损失，实践中一般用4bit量化配合一定技巧，效果基本无损。

4.3 微调实操中的架构误区与省显存技巧

我见过不少同学在微调阶段踩坑，普遍有几个共同误区。第一个误区是“全参微调才是正道”。全参微调意味着更新模型所有参数，一个70B模型的权重就有140GB（FP16精度），训练时的优化器状态还要再占几倍空间，单卡根本装不下，多卡又会碰到同步通信瓶颈。实际上绝大多数场景用LoRA这类参数高效微调就足够了。LoRA的思路是冻结原模型，只训练插入的低秩矩阵，参数量可以少几个数量级，用一张消费级显卡就能微调大模型，效果在多数任务上接近全参微调。

第二个误区是忽略格式一致性。这特别常见于用解码器模型做“类BERT任务”的时候。解码器模型微调分类任务，训练的输入格式和推理时的输入格式必须完全一致，包括系统提示词、任务前缀、标点风格。有人训练时用“判断以下内容的情感”开头，推理时直接用“[内容]”，效果直接崩。这个坑，我建议你把模板做成全局常量，train和inference共用一份。

第三个误区是忽视基座版本。同样架构的模型，基座版本换了一个迭代，训练数据的差异会导致微调后的效果天差地别。所以微调前先花时间测试基座模型本身，如果基座在zero-shot下已经能满足业务需求的60%，微调才有意义；如果基座连基础任务都做不好，微调只会事倍功半。

5. 新手最容易踩的五个认知坑

最后整理几个我常被问到的问题，也是新手上路时最容易出现的误解。这里做一个速查表，帮你快速避雷。

关于“上下文窗口越大越好”这一点，我再多说两句。模型中设置1M token的上下文，等于让模型同时读10本小说。但你喂给它一篇100K token的论文，它很可能遗漏关键信息。根源在于注意力机制对位置的感知是有限的，太长的文本会让模型权重被稀释。实践中正确的做法是：把长文档切成段，先做检索，把与问题最相关的片段丢给模型。这也是现在RAG热度极高的原因。

还有个大模型与大语言模型的混淆也很常见。大模型是泛称，包含大语言模型、多模态大模型、Diffusion模型等多条线路。大语言模型顾名思义，只处理文本；多模态大模型则能处理图文混合内容，比如你发一张图片让它描述、发一段音频让它转写。多模态模型内部常有大语言模型作为“语言中枢”，但两者不是一回事。你的业务如果需要图片理解，选型时就得留意“多模态”标签，而不是只看它是“大语言模型”。

架构的这个话题，我自己从入门到现在也是踩了不少踶才理清楚。刚开始接触NLP时，我也一度迷信“BERT是万能的”，后来做了一阵子生成式应用才真正理解架构选型背后的逻辑：理解任务用双向，生成任务用单向，两头要兼顾就上Seq2Seq，但如今综合实力最强的是解码器这条线。

如果你现在还在起步阶段，我建议的学习路径是这样的：第一步，用API调用一个大模型，亲手写几个Prompt，感受一下它的“性格”，把指令遵循、思维链这些概念摸熟；第二步，找一份LLaMA或Qwen的量化部署教程，在自己电脑上跑起来，把上下文长度、KV Cache、量化精度这些参数亲手调一遍；第三步，再回来读代码，理解注意力机制和三种架构的实现差异。三步走完，你对大语言模型的认知会比很多整天刷新闻的人都扎实。

最后分享一个我的习惯：每接触一个新模型，先不看它有多少参数、什么架构，而是先跑一遍固定的“模型体检清单”——包括知识问答、推理题、长文本总结、指令遵循、意志坚定性五个小任务。几分钟测试下来，模型的真实水平就心里有数了。这套方法比盯着参数表和刷榜评测有用得多，也推荐你试试。