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

要成为AI的主人,而不是被它所绑架

要成为AI的主人,而不是被它所绑架

这两年,AI 编码工具确实给开发效率带来了很大提升。写脚本更快了,补测试更轻松了,搭原型更顺手了,连很多文档工作都被大幅压缩。笔者自己在持续使用 GPT-5.4 和 Claude 一段时间后,也真切感受到了这种效率红利。与此同时,随着使用越来越深入,笔者也开始经常在架构师论坛和技术社区里,围绕 AI 开发的安全性、保密性、稳定性、可控性等问题,与多位大厂架构师持续交流。讨论得越多、实践得越久,我越认同一个判断:小项目、低敏项目、单人维护项目,AI 基本没有大问题;但一旦进入多人协作、长期演进、涉及核心资产和生产责任的项目,AI 如果没有边界、规范和审计,就很容易从“效率工具”变成“失控放大器”。 很多人讨论 AI,还停留在“能不能更快把功能做出来”这个层面。但架构师的关注点从来不只是“能不能开发出来”,而是“

Unity+AI 用一句话制作完整小游戏:飞翔的牛马【AI纯添加-0手工代码】

Unity+AI 用一句话制作完整小游戏:飞翔的牛马【AI纯添加-0手工代码】

* 📢前言 * 🎮Unity+AI 用一句话制作完整小游戏:飞翔的牛马【AI纯添加-0手工代码】 * 一、准备工作 * 1.1 软件安装 * 1.2 使用Unity添加一个工程 * 二、需求描述 * 三、AI制作 * 四、问题反馈 * 五、游玩体验 * 六、图片素材填充 * 七、最终效果 * 八、心得体会 * 💡总结 📢前言 * 之前写过文章介绍怎样使用UnityMCP+Claude进行游戏辅助开发。 * 本文将使用Unity引擎+Claude制作一款 AI纯添加 - 0手工代码 的小游戏:飞翔的牛马。 * 切实上手体验一下 不用自己手敲任何代码 和 不在游戏引擎中进行任何游戏操作 来制作一款完整的小游戏。 🎮Unity+AI 用一句话制作完整小游戏:飞翔的牛马【AI纯添加-0手工代码】 一、

OpenClaw - Day 5 用 Skills 给你的 AI 装上一整箱工具:OpenClaw 技能系统深度实践指南

OpenClaw - Day 5 用 Skills 给你的 AI 装上一整箱工具:OpenClaw 技能系统深度实践指南

文章目录 * 一、从大模型到“能干活的助手”:为什么需要 Skills? * 二、Skills 系统到底是什么?从文件结构到运行机制 * 1. Skills 就是 AI 的 App Store * 2. Skills 的核心思想:脑子够用,缺的是工具 * 三、ClawdHub 与技能生态:给助手逛逛“应用商店” * 1. 社区维护的技能市场 * 2. 另一种浏览方式:GitHub 清单 * 四、从 0 到 1:安装你的第一个 Skill * 1. 方式一:从 ClawHub 一键安装(推荐) * 2. 方式二:手动 git

基于30年教学沉淀的清华大学AI通识经典:《人工智能的底层逻辑》

基于30年教学沉淀的清华大学AI通识经典:《人工智能的底层逻辑》

📚 引言:为什么你需要这本书? 在人工智能技术席卷全球的今天,你是否曾好奇: * 机器是如何"看见"世界的? * 算法是如何"理解"人类语言的? * 智能系统背后的基本原理是什么? 《人工智能的底层逻辑》正是为解答这些疑问而生!这本书由清华大学张长水教授基于30年教学与科研经验精心撰写,以通俗易懂的方式揭开AI技术的神秘面纱。 你对AI的好奇 《人工智能的底层逻辑》 理解AI基本原理 应用AI思维解决问题 参与AI技术讨论 基于30年教学沉淀的清华大学AI通识经典:《人工智能的底层逻辑》 * 📚 引言:为什么你需要这本书? * 🏛️ 书籍结构与内容亮点 * 📖 系统化的知识架构 * 🧩 独特的"四维解析"框架 * 🌟 特色教学方式 * 🎯 适合哪些读者? * 📊 为什么这本书与众不同? * ✨ 三大核心优势 * 🆚 同类书籍对比 * 🚀 实际应用案例 * 案例1:智能客服系统 * 案例2:医疗影像分析 * 📖 如何高效阅读本书? * 🔍 阅读路线建议 * 💡 学习