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 一张表看懂三种架构的本质区别这一节我用表格做一个直观对比方便你在做技术选型时快速对照。架构类型代表模型上下文方式核心优势典型任务参数效率纯编码器BERT、RoBERTa、ERNIE双向理解精准、推理快分类、NER、文本匹配、搜索排序高小参数量即可纯解码器GPT系列、LLaMA、Qwen单向自回归生成能力强、涌现能力对话、写作、代码生成、推理低需要大参数量编码器-解码器T5、BART、FLAN-T5双向编码单向解码理解与生成兼顾摘要、翻译、问答、文本改写中规模适中我对参数效率这个维度的解释再展开一些纯解码器架构要达到好的理解效果通常需要非常大的参数量因为它在训练时只见过单向信息理解能力要靠大量数据“喂”出来。而纯编码器架构因为双向上下文天生能拿到更多信息小模型就能有不错的表现。编码器-解码器居中但它多了一套编码器结构参数总量自然就上去了。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 混合架构与稀疏注意力当前纯解码器架构一家独大的局面在未来很可能会被一些混合方案打破。一个明显的方向是混合专家模型也就是 MoEMixture 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跑一下验证集指标很快就能看到差异。这个做法花不了多少钱但能帮你在架构选型这件事上少走很多弯路比看十篇评测文章都管用。
