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语音转换框架:Retrieval-based-Voice-Conversion-WebUI完全指南

跨平台AI语音转换框架:Retrieval-based-Voice-Conversion-WebUI完全指南 【免费下载链接】Retrieval-based-Voice-Conversion-WebUI语音数据小于等于10分钟也可以用来训练一个优秀的变声模型! 项目地址: https://gitcode.com/GitHub_Trending/re/Retrieval-based-Voice-Conversion-WebUI 项目概览 Retrieval-based-Voice-Conversion-WebUI是一款基于VITS架构的先进语音转换系统,它打破了传统变声工具的技术壁垒。这个开源框架最大的亮点在于其极低的数据需求——仅需10分钟语音素材即可训练出高质量的AI变声模型! 该项目采用检索式语音转换技术,通过top1特征检索机制有效防止音色泄露,确保转换后的声音既自然又富有表现力。无论你是内容创作者、开发者还是语音技术爱好者,都能在这个平台上找到适合自己的解决方案。 技术亮点解析 革命性的检索技术 该框架采用创新的特征检索机制,在推理过程中动态替换输入源特征为训

基于 Langchain + 开源模型的前端内容创作Agent详细设计方案

基于 Langchain + 开源模型的前端内容创作Agent详细设计方案

基于 Langchain 框架与开源模型,结合此前的全流程创作需求,以下设计一款 模块化、可复用、全链路自动化 的前端内容创作 Agent。设计核心围绕「Langchain 组件解耦 + 开源模型适配 + 全流程闭环」,从架构分层、模块实现、技术选型到部署落地,提供详细可落地的方案。 基于 Langchain + 开源模型的前端内容创作Agent详细设计方案 一、Agent 核心定位与目标 定位 一款 前端技术领域专属的全流程内容创作自动化Agent,基于用户输入的核心关键字,通过 Langchain 实现流程编排、工具调用与记忆管理,结合开源大模型完成「关键字拓展→创作Plan→逻辑框架→博客撰写→ZEEKLOG发布」的端到端闭环,无需人工干预各环节衔接。 核心目标 1. 技术适配:兼容主流开源大模型(Llama 3、Mistral、Qwen等),支持本地/

深入解析WebView的概念、功能、应用场景以及使用过程中的优势与挑战

深入解析WebView的概念、功能、应用场景以及使用过程中的优势与挑战

🤍 前端开发工程师、技术日更博主、已过CET6 🍨 阿珊和她的猫_ZEEKLOG博客专家、23年度博客之星前端领域TOP1 🕠 牛客高级专题作者、打造专栏《前端面试必备》 、《2024面试高频手撕题》、《前端求职突破计划》 🍚 蓝桥云课签约作者、上架课程《Vue.js 和 Egg.js 开发企业级健康管理项目》、《带你从入门到实战全面掌握 uni-app》 文章目录 * * 一、引言 * 二、WebView概述 * 三、WebView的功能与应用场景 * 四、WebView的优势与挑战 * 五、WebView的使用示例 * 六、总结 摘要: 本文详细介绍了App中WebView的概念、功能、应用场景以及使用过程中的优势与挑战。通过对WebView的深入剖析,帮助开发者更好地理解和运用这一技术,在App开发中实现更丰富的功能和更好的用户体验。 一、引言 在移动应用开发领域,为了在App中展示网页内容、集成Web应用或实现与网页的交互功能,WebView是一种常用的技术手段。它为开发者提供了一种在原生App中嵌入Web内容的