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

【踩坑记录】使用 Layui 框架时解决 Unity WebGL 渲染在 Tab 切换时黑屏问题

【踩坑记录】使用 Layui 框架时解决 Unity WebGL 渲染在 Tab 切换时黑屏问题

【踩坑记录】使用 Layui 框架时解决 Unity WebGL 渲染在 Tab 切换时黑屏问题 在开发 Web 应用时,尤其是集成了 Unity WebGL 内容的页面,遇到一个问题:当 Unity WebGL 渲染内容嵌入到一个 Tab 中时,切换 Tab 后画面会变黑,直到用户点击黑屏区域,才会恢复显示。 这个问题通常是因为 Unity 渲染在 Tab 切换时被暂停或未能获得焦点所致。 在本文中,我们将介绍如何在使用 Layui 框架时,通过监听 Tab 切换事件并强制 Unity WebGL 渲染恢复,来解决这一问题。 1. 问题描述 当 Unity WebGL 内容嵌入到页面中的多个

从2025看2026前端发展趋势

🎨 从2025看2026前端发展趋势 一、📌 核心前言(2025铺垫→2026展望) 2025年前端行业已完成“基础成熟化”:Vue3、React18成为主流,TypeScript全面普及,工程化流程趋于完善,AI工具开始渗透开发环节,但也暴露了痛点——开发效率不均衡、跨端体验不一致、AI与业务结合浅显、性能优化门槛高。 ✨ 核心趋势:2026年前端将从「基础成熟」走向「深度融合」,重点围绕「AI原生开发」「跨端统一」「性能极致」「工程化提效」四大方向突破,同时Node.js等底层工具的升级(如2026年Node.js新特性)将进一步推动前端向全栈化、平台化转型。 二、✍️ 五大核心趋势(手绘重点·结合2025现状) 1. AI原生开发:从“辅助工具”到“核心生产力” 🤖(最重磅) (1)2025现状 2025年,前端AI工具多为“辅助层面”

libwebkit2gtk-4.1-0安装失败时的备选库兼容性评估

当 libwebkit2gtk-4.1-0 装不上时,我们还能怎么走? 你有没有遇到过这种情况:在 Ubuntu 上编译一个依赖 WebKit 的桌面应用,一切准备就绪,运行安装命令却突然报错: E: Unable to locate package libwebkit2gtk-4.1-0 或者更让人头疼的: Depends: libgtk-4-1 but it is not installable 明明代码没问题,文档也照着做了,结果卡在一个系统库上动弹不得。这背后往往不是你的错——而是 Linux 发行版更新节奏、GTK 演进速度和软件包维护滞后之间的一场“错位”。 尤其是当你用的是 Ubuntu 20.04 或 Debian 11 这类以稳定性为优先的长期支持版本时, libwebkit2gtk-4.1-0 找不到或无法安装 几乎是家常便饭。

前端状态管理:别让你的状态变成一团乱麻

前端状态管理:别让你的状态变成一团乱麻 毒舌时刻 这状态管理得跟蜘蛛网似的,谁能理得清? 各位前端同行,咱们今天聊聊前端状态管理。别告诉我你还在使用 setState 管理所有状态,那感觉就像在没有地图的情况下寻宝——能找,但累死你。 为什么你需要状态管理 最近看到一个项目,组件之间传递状态需要经过 5 层,修改一个状态要修改多个地方。我就想问:你是在做状态管理还是在做传递游戏? 反面教材 // 反面教材:混乱的状态管理 function App() { const [user, setUser] = useState(null); const [posts, setPosts] = useState([]); const [comments, setComments] = useState([]); const [loading, setLoading] = useState(true); useEffect(() => { async function fetchData() { setLoading(