2.2 GPT、LLaMA 与 MOE:自回归模型与混合专家架构演进

2.2 GPT、LLaMA 与 MOE:自回归模型与混合专家架构演进

基于《大规模语言模型:从理论到实践(第2版)》第2章 大语言模型基础

爆款小标题:从 GPT 到 LLaMA 到 MOE,主流架构差异与选型一张表搞定


为什么这一节重要

大模型产品与开源生态里,最常见的就是「GPT 类」「LLaMA 类」和「MOE 类」模型。若不搞清楚它们在训练目标(自回归 vs 掩码)、架构细节(归一化、激活、位置编码)和使用场景上的差异,很容易出现「用 BERT 做长文本生成」或「用纯 GPT 做句向量」这类错配。本节基于原书第 2 章,系统讲清自回归解码器与掩码编码器的区别、LLaMA 的典型设计选择,以及混合专家(MOE)的「路由 + 专家」思想与效率取舍,并给出选型与部署时的实用要点。


学习目标

学完本节,你将能够:

  • 区分自回归与掩码模型:说明自回归语言模型(如 GPT、LLaMA)与掩码语言模型(如 BERT)在训练目标与「训练时看到的上下文」上的本质不同,以及各自更适合的下游任务类型。
  • 掌握 LLaMA 的典型设计:说出 LLaMA 在归一化(RMSNorm)、激活函数(SwiGLU)、位置编码(RoPE)等方面的选择,以及这些选择对训练稳定性与长上下文的影响。
  • 理解 MOE 的取舍:解释混合专家模型中「路由 + 专家」的工作方式、在参数量与激活量上的特点,以及部署时对显存与带宽的影响。

一、自回归语言模型 vs 掩码语言模型(原书第 2 章)

自回归语言模型(Autoregressive LM)

  • 训练目标:在给定上文的前提下,预测下一个 token(或下一个词)。损失通常是对整个序列的下一 token 交叉熵求和或平均。因此,训练时每个位置「只能看到」它左侧的 token,不能看到右侧(通过因果掩码保证)。
  • 典型架构解码器-only(Decoder-only),即只使用 Transformer 的解码器层:带因果掩码的自注意力 + 前馈网络,无「编码器」部分。
  • 使用方式:天然适合生成——自左向右逐 token 生成,直到结束符或达到最大长度。也可用于填空、续写、对话(把历史与当前问题拼成序列,让模型生成回复)。代表:GPT 系列、LLaMA、Qwen、DeepSeek 等。

掩码语言模型(Masked LM)

  • 训练目标:随机遮盖输入中的部分 token,让模型根据**上下文(含左右两侧)**预测被遮盖的内容。每个位置在训练时可以看到整句(除被 mask 的位置)。
  • 典型架构编码器(Encoder-only),即双向自注意力(无因果掩码)+ 前馈网络。代表:BERT、RoBERTa 等。
  • 使用方式:适合理解与表示——取 [CLS] 或整句的池化表示做分类、相似度、检索等。也可做「填空」式生成,但按 token 自回归长文本生成不是其设计重心,且通常没有因果掩码,直接用于生成会存在「看到未来」的泄露问题。

本质区别小结

  • 训练时看到的上下文:自回归只看左侧;掩码看两侧(除被 mask 处)。
  • 更适合的任务:自回归适合生成、对话、续写;掩码适合分类、抽取、句表示、检索。若要做「长文本生成」或「对话生成」,应选解码器架构;若要做「句向量」或「文本分类」,可考虑编码器或专门训练的嵌入模型,而不是把纯生成模型最后一层隐状态直接当向量用。

二、GPT 类与 LLaMA 的架构要点(原书第 2 章)

GPT 类(解码器-only、自回归)

原书第 2 章将 GPT 作为自回归解码器代表:堆叠 Transformer 解码器块,每块含因果自注意力 + 前馈;训练目标为下一 token 预测。适合生成与对话,也是当前 ChatGPT、开源对话模型的主流基座形态。

LLaMA 的典型设计(原书第 2 章)

LLaMA 在「用什么 Norm、什么激活、什么位置编码」上做了明确选择,被后续很多开源模型沿用:

  • RMSNorm:在 LayerNorm 基础上去掉均值项,只做缩放,计算更省、效果相当,训练更稳定。
  • SwiGLU:FFN 的激活函数采用 SwiGLU(及相应权重形状),相比原始 ReLU FFN 表达力更强,被多数新架构采用。
  • RoPE:位置编码采用旋转位置编码(RoPE),便于长上下文与长度外推,与绝对位置编码相比更利于扩展。

这些细节在阅读 LLaMA、Qwen、DeepSeek 等代码或配置时会反复出现;选型与微调时保持与基座一致(例如不要随意把 RMSNorm 换成 LayerNorm),可减少训练不稳定或效果异常。

工程上的对应:纯生成/对话优先选解码器架构;若需要「句向量」或「检索用嵌入」,应选编码器或专门训练的嵌入模型,而不是用生成模型的最后一层隐状态直接做相似度(未经对比学习的隐状态通常不适合做检索)。


三、混合专家模型(MOE)思想与取舍(原书第 2 章)

基本思想

在部分层中,不使用「一个大的前馈层」,而是引入多份专家(Expert)子网络(如多份 FFN),并增加一个路由(Router):对每个 token,路由决定它「走哪几个专家」(例如选 top-1 或 top-2),只对选中的专家做前向计算,最后按路由权重合并输出。这样,总参数量可以很大(很多专家),但单次前向激活的参数量只涉及被选中的少数专家,从而在相近效果下降低计算与显存。

典型数量关系(原书第 2 章)

例如某 MOE 层有 8 个专家,每个 token 选 2 个专家:则前向时该层「参与计算」的参数量约为「一个全连接 FFN」的 2/8 = 1/4 的专家参数量(若每个专家与原来单 FFN 同规模,则约为原来的 2 倍 FFN 参数量,但总参数是 8 倍)。因此,显存与计算更受「激活路径」影响,而总参数会明显增大,模型文件与加载时间会上升;推理时还要考虑路由负载均衡(避免总选同一两个专家)与通信/带宽(多卡时专家可能分布在不同设备)。

选型与部署注意点

  • MOE 模型(如 Mixtral)在相同激活预算下可容纳更大总参数,适合「要大能力又要控单次推理成本」的场景。
  • 部署时需关注:路由是否均衡、多卡下专家通信、以及框架对 MOE 的优化(如专家并行、通信重叠等)。不要仅凭「参数量大」就认为一定更慢——要看激活量与实现。

四、工程实战要点

1. 按任务选架构

  • 纯生成/对话:优先解码器架构(GPT/LLaMA 类)。
  • 需要句向量、检索、分类:用编码器或专用嵌入模型,不要用纯生成模型的隐状态直接当向量。
  • 既要生成又要理解:可考虑 Encoder-Decoder 或「生成模型 + 单独嵌入模型」的组合。

2. MOE 部署时关注路由与带宽

对 Mixtral 等 MOE 模型,要关注路由负载、显存占用与带宽;可结合官方或社区文档做 batch size、并行方式的调优。


五、常见误区与避坑指南

误区一:用 BERT 做长文本生成或用纯 GPT 做句向量

架构与训练目标不匹配会导致效果差或行为异常。避坑:生成用解码器、表示用编码器或专用嵌入模型。

误区二:认为 MOE 参数量大就一定更慢

MOE 通过「稀疏激活」控制实际计算量,推理时更吃带宽与路由实现。避坑:以实测延迟与吞吐为准,并关注框架对 MOE 的优化程度。

误区三:微调时随意改 Norm 或激活

与基座不一致的 Norm/激活可能带来训练不稳定或效果下降。避坑:与基座保持一致,除非有明确实验支撑。


六、小结与衔接

本节区分了自回归与掩码语言模型、梳理了 GPT 类与 LLaMA 的架构要点(RMSNorm、SwiGLU、RoPE),并介绍了 MOE 的「路由 + 专家」思想及在参数量与激活量上的取舍。下一节将进入解码器结构的实现细节:因果掩码、Pre-Norm 与 RMSNorm 在块中的位置,便于读源码与做修改。


课后思考题

  1. 自回归语言模型和掩码语言模型在「训练时看到的上下文」上有什么本质不同?各更适合什么类型的下游任务?
  2. 若某 MOE 层有 8 个专家、每 token 选 2 个专家,该层前向时参与计算的参数大约是全连接时的多少?这对显存和速度有什么影响?

Read more

全面的System Verilog教程:从基础到高级验证

本文还有配套的精品资源,点击获取 简介:System Verilog是用于系统级验证、芯片设计与验证以及FPGA实现的强大硬件描述语言。它扩展了Verilog的基础特性,支持高级语言结构,如类、接口、任务和函数,优化了验证流程。教程内容涵盖System Verilog的基础概念、结构化编程元素、并发与同步机制、现代验证方法学、UVM验证方法论以及标准库的应用。旨在教授学生掌握System Verilog语法和高级特性,实现高效、可维护的验证代码。 1. System Verilog概述及应用领域 1.1 System Verilog的起源与发展 System Verilog是作为硬件设计和验证领域的重要语言,由Verilog发展而来,随后被进一步扩展以满足现代电子设计自动化的需要。其发展始于20世纪90年代,目的是在原有Verilog HDL的基础上,提供更为强大的设计验证功能。 1.1.1 Verilog与VHDL的区别 虽然Verilog和VHDL都是硬件描述语言(HDL),但它们在语法和使用方法上存在差异。Verilog更接近于C语言,而VHDL的语法结构则更接近

ESP32 小智 AI 机器人入门教程从原理到实现(自己云端部署)

此博客为一篇针对初学者的详细教程,涵盖小智 AI 机器人的原理、硬件准备、软件环境搭建、代码实现、云端部署以及优化扩展。文章结合了现有的网络资源,取长补短,确保内容易于理解和操作。 简介: 本教程将指导初学者使用 ESP32 微控制器开发一个简单的语音对话机器人“小智”。我们将介绍所需的基础原理、硬件准备、软件环境搭建,以及如何编写代码实现语音唤醒和与云端大模型的对接。通过本教程,即使没有深厚的 AI 或嵌入式经验,也可以一步步制作出一个能听懂唤醒词并与人对话的简易 AI 机器人。本教程提供详细的操作步骤、代码示例和图示,帮助您轻松上手。 1. 基础原理 ESP32 架构及其在 AI 领域的应用: ESP32 是一款集成 Wi-Fi 和蓝牙的双核微控制器,具有较高的主频和丰富的外设接口,适合物联网和嵌入式 AI 应用。特别是新版的 ESP32-S3 芯片,不仅运行频率高达 240MHz,还内置了向量加速指令(

无人机低空智能巡飞巡检平台:全域感知与智能决策的低空作业中枢

无人机低空智能巡飞巡检平台:全域感知与智能决策的低空作业中枢

无人机低空智能巡飞巡检平台是融合无人机技术、AI 算法、5G/6G 通信、GIS 地理信息系统与物联网的一体化解决方案,通过 "空天地一体化" 协同作业,实现对 500 米以下低空空域目标的无人化、自动化、智能化巡检管理,彻底革新传统人工巡检模式,为能源、交通、市政、安防等多领域提供高效、安全、精准的巡检服务。 一、核心架构:端 - 边 - 云协同的三层体系 平台采用 "终端执行 - 边缘计算 - 云端管控" 的全栈架构,构建低空智能服务闭环: 终端层:工业级无人机(多旋翼 / 固定翼 / 复合翼)+ 智能机场(换电 / 充电式)

Flash Table实测:JAI赋能低代码开发,重塑企业级应用构建范式

Flash Table实测:JAI赋能低代码开发,重塑企业级应用构建范式

目录 * 🔍 引言 * 1.1 什么是Flash Table * 1.2 低代码平台的进化与FlashTable的革新 * ✨FlashTable背景:为什么需要新一代低代码平台? * 2.1 传统开发的痛点 * 2.2 低代码平台的局限 * 2.3 FlashTable的差异化定位 * 💻 FlashTable安装:Docker部署&Jar包部署 * 3.1 基础环境要求 * 3.2 Docker部署(推荐方案) * 3.3 Jar包部署(无Docker环境) * 3.4 常见问题 * 📚FlashTable功能深度评测:从案例看真实能力 * 4.1 数据孤岛?FlashTable 自动化匹配字段 * 4.2 FlashTable复杂表单的开发挑战 * 4.3