为什么现在的 LLM 都是 Decoder only 的架构？

为什么现在的 LLM 都是 Decoder only 的架构？ | 极客日志

为什么现在的 LLM 都是 Decoder only 的架构？

在我看来，Encoder-Decoder 架构和 Decoder-only 架构的主要区别，在于它们的灵活性和专业性有所差别。

Encoder-Decoder 架构的特点与局限

Encoder-Decoder 架构通常用于处理一些需要在输入和输出间建立精确映射的任务，比如机器翻译、文本摘要等。在这些任务中，理解输入的精确内容并据此生成特定的输出是非常重要的。基于这种架构训练出来的模型，一般只能应用于某种特定的任务，比如一个专为机器翻译训练的 Encoder-Decoder 模型可能不适合直接用于文本摘要或其他类型的任务。

经典的 Encoder-Decoder 结构包括左右两部分：左侧是编码器（Encoder），负责将输入序列编码为上下文向量；右侧是解码器（Decoder），负责根据上下文向量生成输出序列。这种结构在 BERT 之前的 NLP 时代非常流行，例如 Google 的 Transformer 原始论文中的 Seq2Seq 模型。

用一张动图来描述'中译英'的过程：首先，将中文句子中的所有词编码成一个向量列表，其中的每一个向量，表示到目前为止所有被读取到的词的含义（也就是编码过程）。一旦整个句子读取完成，解码器便开始工作，依次生成对应的每个英文单词。为了尽量生成正确的词，解码器重点'注意'与生成英语词最相关的编码的汉语向量的权重分布，也就是在其中起到重要作用。

其实了解了 Encoder-Decoder 架构的训练思路和过程后，就可以发现这种架构存在的几个最大的缺点：

数据预处理复杂：Encoder-Decoder 模型通常对于输入和输出之间的精确对齐要求非常严格，这也就意味着需要复杂的数据预处理过程。而且对于不同类型的输入和输出数据，可能需要用到不同的预处理方法，比如机器翻译中的双语对齐；比如图像字幕识别任务中的图像预处理和文本预处理等等。
输入数据难以获取：Encoder-Decoder 架构通常高度依赖于输入和输出之间的关系，这就要求收集到的输入和输出数据具备精确的映射关系，增大了数据收集的难度，大大减少了符合要求的数据量。
训练时间更长：由于结构的复杂性，Encoder-Decoder 模型可能需要很长的训练时间。尤其是处理长序列时，为了理解和编码整个序列的上下文，为了计算序列中每个元素与其他所有元素间的关系，为了储存更多的数据点和中间计算结果，仅在 Encoder 阶段，就需要消耗大量的时间和内存，增加训练难度。
模型应用受限：而最令人恼火的，还是费劲力气训练得到的模型，仅对特定类型的任务表现良好，比如谷歌翻译不能用于进行语音识别，每涉及到一种新的功能，便需要重新训练一个模型，耗时耗力，很不灵活。

Decoder-only 架构的崛起

而去年如雨后春笋般冒出来的各种大模型，一个重要的主打功能便是 Decoder-only 架构。也就是说，对于大模型的要求是，既能文字聊天，又能语音聊天；既能生成文本，又能画出美图；既能根据文字出音，又能根据文字做视频。

通过体验多模态 LLM 的聊天功能、图片生成、语音对话等，就可以发现 Decoder-only 架构的灵活性。不仅如此，Decoder-only 可以让模型构建和训练的各个步骤都显得更加便捷：

灵活的输入格式

由于 Decoder-only 模型本质上是根据给定的文本串生成输出，因此它们可以接受各种格式的输入。包括问题和回答、提示和续写、以及代码和其执行结果等。也就是说，无需特意对输入数据集进行'清洗'。

无需特定的任务架构

与 Encoder-Decoder 架构不同，不需要为不同类型的任务构建特定的 encoder 部分。也就是说，同一个模型可以在没有或仅需要少量修改的情况下，处理多种任务。这是通过统一的 Next Token Prediction（下一个词预测）目标实现的。

简化的预训练和微调过程

在预训练和微调阶段，没有繁琐的 encoder 过程，Decoder-only 模型可以更加容易地进入训练过程。此外，由于训练过程主要关注如何基于给定的上下文生成文本，因此既不需要用户提供复杂的输入输出编码关系，也不需要专门处理这些复杂的映射。

易于扩展性

由于结构的简单和统一，Decoder-only 模型通常更容易扩展到更大的模型尺寸，有助于提升模型的性能和适应性。这也就是去年涌现出的众多 LLM，参数数量能够不断攀上新高的主要原因之一。配合 FlashAttention 等技术，Decoder-only 架构在处理大规模数据时效率更高。

Decoder-only 的理论缺陷与应对

当然，Decoder-only 架构理论上也是存在一些缺点的：

理解能力限制：Decoder-only 架构通常只能基于先前的文本来生成新文本，在理解某些复杂输入方面可能不如 Encoder-Decoder 架构那么强大，因为它缺乏双向注意力机制。
长序列依赖问题：Decoder-only 模型在处理长序列时可能面临长期依赖的问题，在长文本中维持上下文一致性和相关性可能表现不佳。
幻觉问题：Decoder-only 模型更易出现'幻觉'，因为模型在生成新文本时主要依赖于先前生成的文本，而不是直接从原始输入中提取信息，因此输出结果的可靠性可能不如 Encoder-Decoder 模型。

但是随着算力的不断提升，数据的不断丰富以及模型结构的日益复杂，Decoder-only 架构的相关缺点可以在一定程度上得到克服：

算力提高：算力的提高可以加速模型的训练和推理过程，即使处理规模更大、复杂程度更高的数据集时，也显得游刃有余。
结构优化：更强的计算能力允许模型拥有更大、更复杂的结构，可能有助于改善模型在长期依赖方面的表现，以及一定程度上改善'幻觉'问题。例如引入 RoPE（旋转位置编码）和 KV Cache 技术。
数据完善：越来越完善的数据集可以提供更加多样化和覆盖面更广的信息，帮助模型学习到复杂的语言模式和上下文关系，从而提升生成内容的质量。
微调策略：基于 RLHF（人类反馈强化学习）等方法，针对不同类型的任务进行微调，可以显著提高模型的泛化能力和适应不同任务的能力。

总结与展望

不过任何一种特定结构的模型，都有其上限，简单的增加模型大小和数据量并不总是解决问题的最佳途径。未来大模型发展到一定阶段，可能面临和优化困难等问题。到时候想要得到突破，恐怕还是需要各领域专家灵光一现，从模型基本架构的角度实现突破。

目前来看，Decoder-only 架构凭借其强大的通用性和可扩展性，已成为当前大语言模型的主流选择。随着技术的演进，我们或许会看到更多混合架构的出现，但 Decoder-only 的核心地位在可预见的未来仍将稳固。

为什么现在的 LLM 都是 Decoder only 的架构？