大语言模型架构详解：从BERT、GPT到T5，一次看懂三种主流路线

先说明一下这一篇是“大模型技术全景”系列的第三篇。前两篇咱们聊了深度学习的基础和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亿tokenGPT-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 一张表看懂三种架构的能力差异维度编码器架构BERT类解码器架构GPT类编码器-解码器T5类注意力方向双向全文可见单向只看上文双向编码单向解码训练任务完形填空MLM预测下一个词自回归输入输出变换理解能力极强强靠规模弥补强生成能力弱极强中上代表模型BERT、RoBERTa、ELECTRAGPT系列、LLaMA、QwenT5、BART、Pegasus擅长任务分类、NER、向量化对话、写作、代码、总结翻译、摘要、结构化生成推理速度快慢逐token生成中等这个表格看下来其实没有“全面全能”的架构。编码器理解强但生成弱解码器生成强但理论上全局理解有短板编码器-解码器两头都占但都不拔尖。所谓的“强”和“弱”也要看具体任务和模型规模——一个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模型的权重就有140GBFP16精度训练时的优化器状态还要再占几倍空间单卡根本装不下多卡又会碰到同步通信瓶颈。实际上绝大多数场景用LoRA这类参数高效微调就足够了。LoRA的思路是冻结原模型只训练插入的低秩矩阵参数量可以少几个数量级用一张消费级显卡就能微调大模型效果在多数任务上接近全参微调。第二个误区是忽略格式一致性。这特别常见于用解码器模型做“类BERT任务”的时候。解码器模型微调分类任务训练的输入格式和推理时的输入格式必须完全一致包括系统提示词、任务前缀、标点风格。有人训练时用“判断以下内容的情感”开头推理时直接用“[内容]”效果直接崩。这个坑我建议你把模板做成全局常量train和inference共用一份。第三个误区是忽视基座版本。同样架构的模型基座版本换了一个迭代训练数据的差异会导致微调后的效果天差地别。所以微调前先花时间测试基座模型本身如果基座在zero-shot下已经能满足业务需求的60%微调才有意义如果基座连基础任务都做不好微调只会事倍功半。5. 新手最容易踩的五个认知坑最后整理几个我常被问到的问题也是新手上路时最容易出现的误解。这里做一个速查表帮你快速避雷。误区实际情况建议“模型越大一定越聪明”规模只是其中一个变量数据质量和架构设计同样重要选模型时综合看评测指标别只看参数数量“解码器模型做不了理解任务”70B以上的解码器模型在分类理解上通常比小BERT更强先用解码器模型做测试再决定是否需要上BERT“所有大模型都是大语言模型”多模态大模型处理图像视频音频与语言模型是不同的技术路线购买或选型前先确认模型是否支持你需要的输入模态“微调可以解决所有业务问题”多数问题靠提示词工程和RAG就能解决微调成本高且有风险先Prompt再RAG最后才微调“上下文窗口越大越能处理长文”窗口大不等于效果好长文本中模型可能“迷失在中间”长文档场景要结合检索或摘要别把希望全押在窗口上关于“上下文窗口越大越好”这一点我再多说两句。模型中设置1M token的上下文等于让模型同时读10本小说。但你喂给它一篇100K token的论文它很可能遗漏关键信息。根源在于注意力机制对位置的感知是有限的太长的文本会让模型权重被稀释。实践中正确的做法是把长文档切成段先做检索把与问题最相关的片段丢给模型。这也是现在RAG热度极高的原因。还有个大模型与大语言模型的混淆也很常见。大模型是泛称包含大语言模型、多模态大模型、Diffusion模型等多条线路。大语言模型顾名思义只处理文本多模态大模型则能处理图文混合内容比如你发一张图片让它描述、发一段音频让它转写。多模态模型内部常有大语言模型作为“语言中枢”但两者不是一回事。你的业务如果需要图片理解选型时就得留意“多模态”标签而不是只看它是“大语言模型”。架构的这个话题我自己从入门到现在也是踩了不少踶才理清楚。刚开始接触NLP时我也一度迷信“BERT是万能的”后来做了一阵子生成式应用才真正理解架构选型背后的逻辑理解任务用双向生成任务用单向两头要兼顾就上Seq2Seq但如今综合实力最强的是解码器这条线。如果你现在还在起步阶段我建议的学习路径是这样的第一步用API调用一个大模型亲手写几个Prompt感受一下它的“性格”把指令遵循、思维链这些概念摸熟第二步找一份LLaMA或Qwen的量化部署教程在自己电脑上跑起来把上下文长度、KV Cache、量化精度这些参数亲手调一遍第三步再回来读代码理解注意力机制和三种架构的实现差异。三步走完你对大语言模型的认知会比很多整天刷新闻的人都扎实。最后分享一个我的习惯每接触一个新模型先不看它有多少参数、什么架构而是先跑一遍固定的“模型体检清单”——包括知识问答、推理题、长文本总结、指令遵循、意志坚定性五个小任务。几分钟测试下来模型的真实水平就心里有数了。这套方法比盯着参数表和刷榜评测有用得多也推荐你试试。