企业官网建设流程全解析

这两年做大模型相关工作的朋友应该都有同感：预训练模型的架构选择，已经从前几年的“百花齐放”快速收敛到一条路上——Decoder-only。无论是商用API背后的主力模型，还是开源社区里能拉到本地跑的各种尺寸模型，几乎清一色是“只做自回归、只预测下一个token、只用因果注意力”的结构。反倒是当年横扫各类NLP任务的BERT，以及当时很多人看好的Encoder-Decoder方案，在真正的大模型时代慢慢退到了聚光灯之外。

这篇文章想把这件“大家好像都已经默认了”的事情讲清楚：为什么最后赢的是Decoder-only？它不是谁的审美偏好，而是一套由任务统一、训练效率、扩展能力、推理成本共同作用下的必然结果。如果你刚入门，想知道架构选型背后到底差在哪；或者你已经在训练、微调、部署模型，想给自己手头的工作找个说得通的依据，这篇文章都值得花几分钟读完。

1. 先把三条技术路线摆清楚：Encoder-only / Encoder-Decoder / Decoder-only

1.1 从BERT到GPT：架构到底差在哪

要聊“为什么转向”，得先知道“从哪转过来”。很多人一提到预训练模型只知道BERT和GPT，其实背后是三种完全不同的结构写法：

• Encoder-only（编码器专用）：代表作是BERT类模型。它把文本同时从左往右和从右往左各看一遍，每个位置都能看到整个句子，也就是“双向注意力”。预训练目标是把被掩盖的token猜回来，产出的是“对输入的理解”。
• Encoder-Decoder（编码器-解码器）：代表作是T5类模型。输入先由编码器处理成一个上下文表示，再由解码器基于这个表示逐字生成输出。编码器通常是双向的，解码器是自回归的，中间通过交叉注意力连接。
• Decoder-only（解码器专用）：代表作是GPT系列。它只有一个解码器，输入和输出拼在一起，从头到尾做因果注意力——每个位置只能看当前位置以及之前的位置，目标非常简单：预测下一个token。

表面上看，Decoder-only似乎是“最弱”的，因为它连双向的视野都没有；但恰恰是这个看起来最受限制的结构，在大规模数据和算力面前展现出了最强的适应力。

1.2 一个简单直白的对比

我经常用下面这张表给人讲三条路线的差异：

这张表后面每个点都会展开，但先记住一个核心印象：Encoder-only赢在“理解”，Decoder-only赢在“生成+统一”，Encoder-Decoder理论上两头都占，实际操作里却两头都打折。

1.3 这次转向不是学术圈的自嗨，而是工程选择

有个容易被忽略的背景：大模型时代之前的NLP领域，大家默认“不同任务需要不同模型”。做分类就微调一个带分类头的BERT，做抽取就用序列标注结构，做翻译就用Seq2Seq。任务和模型结构绑定得很死。

到了真正的大模型阶段，大家发现反过来才更有价值：保持模型结构不变，把任务本身“翻译”成同一种形式——给模型一段文本，让它接着写。这个“翻译”的过程就是后来的指令微调、少样本提示等方式。一旦你接受了“所有任务都是文本续写”这个大前提，Decoder-only就是最自然的那个结构选择。这不是纯理论推导出来的优美结论，而是被大规模实验反复验证过的工程事实。

2. 为什么Decoder-only能赢：五个核心原因拆解

2.1 任务统一：所有任务都被改写成“预测下一个token”

先说最根本的一点：Decoder-only把“做AI”这件事简化到了一个几乎不能再简化的目标——给定上文，预测下一个词。

这个简化有多重要？举个例子。假设你要让模型做翻译，Encoder-Decoder的思路是专门设计一套“读一句、写一句”的流程；Encoder-only的思路是你得给它头上接个分类器或其他输出结构。而Decoder-only的思路是，把“请把下面这句话翻译成英文：你好” 和 “Hello” 拼在一起，让模型接着写就行。

训练时、微调时、部署时，模型干的是同一件事。这个“同一件事”带来的连锁好处非常多：

• 预训练和下游任务的gap最小化，模型不会因为目标不一致而“分裂”；
• 指令微调和后面的对齐训练可以直接在同一个模型上继续做，不需要动结构；
• 数据可以统一成“文本片段→续写文本片段”的格式，不需要为每种任务写不同的loss；
• 模型的通用文本能力可以无损耗地迁移到几乎所有具体任务上。

对比之下，Encoder-only的结构天生就只会理解、不会生成，想做生成得外接解码器，等于给房子加一层永远不协调的阁楼。所以要聊为什么转向Decoder-only，第一个原因就是：大模型要的是通用性，而通用性首先要求目标统一。

2.2 因果掩码：看似约束，实则给了模型最稳定的学习信号

很多初学者会问一个问题：Decoder-only的注意力只会往左看，不是天生理解力就差吗？单看“理解”确实可以说它损失了右边的信息；但放到预训练目标里看，因果掩码的存在并不是缺点，而是让“每个位置都有学习信号”的关键。

为什么这么说？因为语言生成本质上是一个从左到右的决策过程。你写一句话，写下“今天”的时候，未来还没发生。“今天”这个单词之所以有意义，恰恰因为它只能由之前的上下文决定。因果掩码把生成过程的因果性直接编码进了结构里，让模型在训练时做的每一步判断，和推理生成时做的每一步判断完全一致——训练和部署之间没有gap。

另外一个特别容易被忽视的点是训练信号的密度。BERT用的MLM目标，一般只掩盖15%的token，意味着一次前向传播中，模型只在15%的位置上获得学习信号；在剩下85%的位置上，虽然也会参与注意力计算，但不会对参数产生直接的梯度改进。Decoder-only的因果语言模型目标是“预测每一个token的下一个token”，一条长度为L的序列能产生L-1个有效的预测监督。同样的算力配置下，训练信号的密度高了一个数量级。

有人可能会说“那我提高BERT的掩盖比例不就行了”，实际操作中把掩盖比例提到较高水平会导致训练不稳定，下游任务表现也会变差，这背后是双向模型难以对“被掩盖”和“未被掩盖”位置建立稳定学习信号的系统性问题。比起在结构上拧巴半天，因果自回归天然就解决了这个问题。

2.3 Scaling性质好：同样的算力，Decoder-only的收益更稳

大模型不是小模型的简单放大，Scaling规律是做过之后才总结出来的经验。但为什么Decoder-only在Scale up的过程中表现格外好？我理解有几个看得见的原因。

第一是参数更集中。Encoder-Decoder结构里，同等参数预算要分给编码器和解码器两部分，中间还有交叉注意力。参数被拆散到两个模块里，每个模块的有效容量反而被稀释。Decoder-only则是一整块同质的Transformer堆栈，每一层结构完全一致，容量使用非常“密实”。

第二是计算图更规整。Decoder-only的每一次前向传播，都是同一套因果注意力在重复堆叠。这种规整的计算图对优化器十分友好，梯度传播路径统一。反过来，Encoder-Decoder里编码器产生的中间表示要通过交叉注意力再进解码器，多了一层翻译环节，梯度传播路径变长，训练稳定性更难控制。

第三是涌现能力更明显。虽然业界对“涌现”这个概念还有争议，但一个公认的宏观观察是：当Decoder-only的模型规模超过某个量级后，零样本指令跟随、上下文学习、链式推理这些能力会以非线性方式出现。这些能力的共同点是“让模型自己顺着上下文写下去”，这正好就是Decoder-only的训练目标本身。模型规模越大，越是把这件事做到极致，能力就越强。

2.4 上下文学习：只有自回归结构接得住

如果说Scaling是工程维度，那上下文学习（In-Context Learning）就是能力维度上最关键的胜负手。

所谓上下文学习，简单说就是：你不需要微调模型，只要在prompt里给几个示例，模型就能照着这个示例的模式完成任务。当GPT系列模型把这个能力展示出来之后，大家都意识到这条路走通了；而BERT、T5都很难有这样的表现。原因也很直白：Decoder-only的预训练目标就是“根据上面所有已生成的文本决定下一个词”，所以当你把几个示例拼在它面前时，续写下去的“模式延续”行为，恰好是它训练中做了几万亿次的事。

如果模型是双向的Encoder-only，示例和问题同时被“全看到”了，模型并不存在一个“先读示例再作答”的顺序，也就难以在结构上逼它做模式匹配。Encoder-Decoder虽然能通过编码器拿到示例，但编码器和解码器的职责割裂，示例信息需要被压缩进中间表示里再传给解码器，这种“压缩-重建”的瓶颈也让它做上下文学习相对笨拙。

站在今天的视角看，上下文学习是打开通用AI大门的那把钥匙，而这把钥匙的形状，就是Decoder-only的自回归结构。

2.5 推理高效：KV Cache和流式输出都是为自回归量身定做的

除了训练，部署成本在大模型时代同样致命。Decoder-only在推理端的优势，甚至比训练端还要明显。

自回归解码的过程是逐个生成token，生成第i个token时需要用到之前所有token的注意力中间结果。Decoder-only的做法是缓存一个KV Cache，把之前算好的Key和Value留在显存里，下一步只需要对新的Query做注意力计算，省掉大量重复计算。

在Encoder-Decoder结构里，情况就要复杂得多。每来一个生成请求，编码器都要先把输入重新编码一遍；解码器的每一个token都要同时做自回归注意力和对编码器输出的交叉注意力。交叉注意力的计算开销不小，而且它让解码器的每一步都依赖一整条编码器输出，流式输出和KV Cache的友好度都打了折扣。

还有一个工程上很实际的问题：Decoder-only是单塔结构，整条模型就是一个同质的Transformer堆栈。这意味着可以做非常干净的张量并行、流水线并行、显存换入换出策略；而Encoder-Decoder的两个模块使得并行调度、显存分配、甚至推理框架的算子编排都要分成两套，工程成本显著上升。在大规模集群训练和部署的体量下，这种“省心”本身就是巨大的优势。

3. 从训练和推理两个角度看实际操作差异

3.1 训练侧：为什么预测每一个token比掩盖位置更划算

我实际跑训练时对比过不同方案的梯度信号密度，这个真的不是纸上谈兵。BERT式MLM训练里，一条512长度的样本，通常只随机掩盖约77个位置作为监督；即便加上下一句预测之类的辅助目标，整体监督密度依然很低。模型前向计算时让所有token都参与注意力了，但后向时大部分位置的梯度接近于零，算力利用率天然偏低。

Decoder-only的做法完全不同：序列上每一个位置都要为“预测下一个token”输出一个分布，并与真实下一个token计算交叉熵。一条长度L的样本产生了L-1份独立的监督压力，模型在每一个位置都在被“教育”。这个差别在单条样本上看起来不大，但乘上几万亿token的数据规模，就是数量级上的差距。

我随手算过一个更直观的例子：训练一条2048长度的样本，Decoder-only会在2047个位置上都计算交叉熵损失；而一个典型MLM配置按15%掩盖比例算，同样长度只有约307个位置有监督信号，两者相差接近6.7倍。如果算力相同，Decoder-only等于在同样的训练步数里，获得了几倍以上的有效语料覆盖。

还有一个训练细节值得一提：Decoder-only的量级估算非常直观。你要知道“多少数据配多少参数”，直接根据序列长度、batch size、参数量就可以推算；而Encoder-Decoder因为前后两段计算量不同，很难找到一个简单公式去预算训练成本，这在做大规模算力规划时是非常头疼的事。

3.2 推理侧：KV Cache与自回归解码的实际意义

推理侧的KV Cache，说起来一句话，但真正做过线上部署的人才懂它有多重要。

假设一个中等规模的Decoder-only模型要生成1024个token，如果不缓存KV，每次生成新token都要重新算一遍前面所有token的注意力，复杂度是O(n²)级别，拖慢的不仅是速度，显存占用也会快速膨胀。加了KV Cache之后，绝大多数重复计算被消掉了，生成阶段每步只需要取出历史KV，配合当前token做一次增量计算。这个优化之所以在Decoder-only上实现得如此干净，是因为因果掩码决定了每一步只用关注前i个token的KV，缓存逻辑极其规整。

我实测过类似规模模型：同一个7B级别的模型，开KV Cache之后单请求的生成延迟能降低一个数量级，这在对话类产品里是体验的天壤之别。反过来看Encoder-Decoder，解码器的每一层都要额外对编码器的全部输出做一次交叉注意力，这部分计算是不可避免的，而且由于KV来自编码器，还不好做“异步流式”的提前计算。很多老团队从Seq2Seq迁移过来之后，第一反应都是“延迟怎么降了这么多”，其实就是省掉了交叉注意力那一整套开销。

3.3 并行与显存：单塔结构带来的工程便利

最后是很少有人专门讲、但实际做大规模训练时特别要命的点：并行策略和显存管理。

Decoder-only是纯粹的“一层接一层”，每一层都是同样结构的注意力加前馈网络。这种同质性让流水线并行变得非常优雅：可以把模型按层切成多个Stage，每个设备只负责其中一段，Stage之间的通信模式是固定的。张量并行也同理，不需要区分“编码器部分”和“解码器部分”各自怎么切。

Encoder-Decoder的并行就没这么省心：编码器和解码器的计算图不一样，显存占用不一样，梯度同步点也不一样，很多时候你为了配合两个模块的差异，会牺牲很多流水线效率。对做推理框架的人来说，Decoder-only的算子也更少，内核可以统一化和深度优化；而Encoder-Decoder的交叉注意力算子、独立的编码器前处理算子，都属于“额外定制”的范畴。

做工程的人都知道，一项技术如果在单卡上只是稍好，在千卡万卡集群上就是决定性优势。Decoder-only在并行上的天然优势，是它最终被整个行业默认选择的隐形推力。

4. 那些被淘汰的路线到底差在哪：对比与反思

4.1 Encoder-only：理解能力强，但生成能力先天缺失

BERT类Encoder-only模型，在理解类任务上确实强：文本分类、情感判断、语义相似度，当年都是一骑绝尘。但它的目标函数决定了它非常难做好生成。

不是说不能生成——你可以在Encoder后面强行接一个随机初始化的解码器，搞成Encoder-Decoder；你甚至可以直接拿BERT生成一段话。但这些路子都别扭，本质上是“为了生成而临时造一个结构”，完全不通用。真正的通用模型应该是“给定任何输入，都能顺着逻辑往下写”，这是Encoder-only结构上做不到的事。

另外，Encoder-only的掩码预训练只能对少量被掩盖的位置提供监督，这是它的先天属性。到了大模型时代，数据量从GB涨到TB，算力从单卡涨到集群，监督密度不够这个短板被无限放大。这也是为什么后来连做embedding任务，很多人也倾向从Decoder-only模型的中间层抽取特征，而不是专门去训一个双向Encoder。

4.2 Encoder-Decoder：理论很美，工程和扩展性吃亏

Encoder-Decoder在一段时间里被很多人认为是“理论最优结构”——毕竟编码器负责理解，解码器负责生成，职责清晰，看起来很符合直觉。T5类模型在多个学术基准上也确实很强。但它在真正的大模型竞赛里掉队了，核心问题出在那本“两头通吃”的资产负债表上：

• 结构复杂：编码器、解码器、交叉注意力三套组件都要维护，训练目标、损失函数、推理流程天然更复杂；
• 表达能力冗余：两个模块之间需要一种内部语言来沟通，而这种语言和真实语言并不是一回事，多了一层浪费；
• 参数和算力效率低：同等参数规模下，拆成两块总会有一块在“摸鱼”，整体表达效率并不占优；
• 难以复用流行工具链：主流训练框架、推理引擎、量化工具，几乎都在围绕Decoder-only优先生态，Encoder-Decoder在很多环节需要自己造轮子。

当然，Encoder-Decoder并没有完全消失。在译文质量要求较高的机器翻译场景、一些需要显式分离“理解”和“生成”的受控文本生成任务里，它仍然有一席之地。但它的复杂度与收益在通用大模型场景下不成正比，因此被慢慢边缘化，是非常合理的市场选择。

4.3 三条路线关键权衡一览

我把实践中最看重的几个维度整理成一张速查表，方便做技术选型时直接对照：

这张表不是为了说Decoder-only在每一个维度都第一——单纯比推理成本它未必比Encoder-only便宜——而是说它在“通用AI”这个核心目标上，所有维度的综合得分最高。

5. 常见误区与Decoder-only的边界

5.1 误区一：Decoder-only“只看左边”，所以理解能力差

这个误解流传很广。事实上，因果注意力虽然只让每个token看到历史信息，但模型在每一层都不断把“历史”提炼成更抽象的表示，层数越深，能综合的“历史上下文”范围越广。理解“这句话里某人是谁”，并不需要看到未来的词，需要的是对过去所有词的综合推理。Decoder-only在这方面的能力完全够用，实测中很多用Decoder-only模型做分类、抽取、语义匹配的效果，都能达到甚至超过同量级双向模型。

唯一的真实差异是：在某些“必须看到全文才能判断”的局部任务上，比如判断一个词在句子里的词性，双向模型可能稍微占优。但大模型的实际使用场景里，这类细粒度局部理解需求极少，而且完全可以通过设计prompt来弥补。为了这一点点局部优势，牺牲掉生成能力和任务统一性，非常不划算。

5.2 误区二：Encoder-Decoder在“复杂任务”上一定更强

还有人说，像摘要、翻译这种“输入长、输出长”的任务，Encoder-Decoder比Decoder-only更强。这个说法在高资源场景下基本不成立。现在的Decoder-only模型直接用“prompt加输出续写”的方式做摘要、翻译，效果完全不输，而且还能借助指令微调把多任务一起做。真正的差异来自模型规模和数据量，而不是那层交叉注意力。

如果在一些非常专门的低资源任务上，Encoder-Decoder通过精心设计，可能会比裸的Decoder-only略稳一点。但你需要在“加一层专门结构带来的收益”和“牺牲掉通用性带来的损失”之间做权衡。通用性在大模型时代是压倒性的，这也是最终大家集体选择Decoder-only的原因。

5.3 Decoder-only本身也有一堆麻烦

说完了优点，也必须承认Decoder-only不是万能药。我实际使用中感受最深的几个问题：

• 自回归误差累积：生成过程中一旦出了一个错token，后面的内容会被带偏，这种“一步错步步错”的问题在长文本生成时尤其明显；
• 长上下文处理成本高：因果注意力在长序列上的显存和算力开销按平方增长，虽然现在有各类稀疏注意力、位置编码优化，但工程复杂度跟着上来了；
• 纯概率式输出导致幻觉：因为训练目标是最小化逐token交叉熵，模型本质上是“很会接话”，而不是“很会查资料”，所以胡编乱造的问题难以根除；
• 因果掩码确实有信息利用的上限：一万个事实摆在模型面前，它只能按顺序慢慢消化，不像双向模型那样一次能全盘读取。

这些边界并不意味着Decoder-only选错了，而是提醒我们：架构选择解决的是“大部分任务能不能通用”的问题，具体任务的顽疾——幻觉、误差累积、长上下文——还得靠数据、训练技巧、推理策略、外部工具去补。理解了这些边界，你在实际工程里才不会被一句“Decoder-only最强”忽悠住。

6. 实操经验：技术选型和面试里怎么聊这个话题

6.1 选型时不要盲从：什么时候Encoder-only仍然更能打

虽然Decoder-only是大势所趋，但落到具体业务上，我始终建议做选型的人先问三个问题：

• 你核心任务是不是生成类？如果业务几乎全是分类、检错、相似度匹配，且对实时性要求极高，一个适配备道的Encoder-only或直接抽取向量做检索，可能比拖一个几十B的Decoder-only模型便宜得多；
• 你有没有训练和部署整套Decoder-only的工程资源？Decoder-only的优势要在大规模训练和部署时才能充分兑现，如果你只是用开源权重做小规模微调，很多优势感知并不明显；
• 你的任务有没有特别强的生成约束？比如法规条文生成、代码补全这种要求精确符合模式的任务，Decoder-only仍然是首选，但你可能需要针对性地做后处理校验，而不是指望结构本身解决一切。

我的建议是：如果是做通用AI产品，直接拥抱Decoder-only；如果是做小型专用模块，先把embedding、小模型、规则方案算清楚，再决定要不要上“大而全”。

6.2 面试中被问到“为什么是Decoder-only”怎么答

这个问题我面试新人时经常问，判断标准其实不是“背不背得出原因”，而是“有没有真的理解模型”。我建议的回答框架：

先承认这个结论是被大规模实验验证过的工程事实，不是纯理论推导；然后从三个层面展开——目标统一（所有任务都变成下一词预测）、训练效率（监督密度高、结构规整、并行友好）、推理部署（KV Cache自然、单塔简单）；最后补一句边界意识：它不是没有缺点，幻觉、误差累积、长上下文成本都还在，只是相对其他架构的缺点更小、更可控。

这样答，既体现深度，又能展现工程视野。如果是做架构设计岗位，还可以补一段自己在训练成本估算、推理优化上的实测对比，那就更加分了。

6.3 我个人踩过的几个坑

最后分享一点我自己的实操教训。

第一个坑：早期我为了做一个“既能理解也能生成”的模型，真的尝试过自己拼一个Encoder-Decoder结构。结果就是训练时间翻倍、显存翻倍、下游效果并没有比同参数Decoder-only更好。后来我彻底放弃了这个心态，老老实实把所有任务都改写成“prompt加续写”，效果和开发效率都显著提升。

第二个坑：直接套用别人训练的Decoder-only做业务时，我一开始完全没意识到“自回归误差累积”的杀伤力。有一次生成一段长报告，前面第三句话翻了一处事实错误，结果后面整段顺着这个错误越编越离谱。后来加了后端的规则校验和人工干预，才算控制住。这件事提醒我：架构选对了，并不等于工程问题就消失了。

第三个坑：最初做推理部署时，我天真地以为只要把模型装到GPU上就能快跑，结果被KV Cache的内存曲线狠狠上了一课。长上下文的KV Cache会占掉相当可观的一部分显存，如果不做显存规划和动态释放，实际并发量会比预想低很多。这个经验后来帮我省了不少钱，也希望能帮到正在开始做部署的朋友。

7. 写在最后：一点个人体会与一个实用判断技巧

这篇文章写了不少，最后说点我从自己的训练和部署实践中得到的体会。

我在很长一段时间里，对“Decoder-only一统天下”这件事是有疑惑的，总觉得一个只会往左看的结构，凭什么打败了理论更完备的Encoder-Decoder。后来自己动手跑数据、跑训练、看损失曲线、看线上延迟，才逐渐明白：在大模型这个领域，结构的美观和理论的完备，远不如训练信号的密度、计算图的规整、推理阶段的工程友好来得实在。Decoder-only赢的，不是一个漂亮的证明，而是十几轮大规模试错之后剩下的那个最优解。

所以如果你也在纠结“要不要上Decoder-only”，我建议别只听结论，最好自己跑几组对比实验，亲眼看一看不同结构在同样的数据和算力预算下，损失下降快慢和下游任务的差距。看得多了你就会发现，这个选择题的答案并没有那么玄学，它就是工程实践给出的答案。

最后再分享一个小技巧：判断一篇关于大模型架构的文章能不能信，可以先看它有没有真的讨论过推理成本和训练信号密度，很多讲得天花乱坠的文章，连这两个最基本的维度都不提。这个细节，可以帮你过滤掉不少噪音。