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安全:视觉提示词注入攻击代码/实战教学| 针对Hugging Face开源大模型Stable Diffusion Model

AI安全:视觉提示词注入攻击代码/实战教学| 针对Hugging Face开源大模型Stable Diffusion Model

本文链接地址 :https://blog.ZEEKLOG.net/weixin_47681965/article/details/158503719?spm=1001.2014.3001.5502, 转载请注明出处。 提到提示词注入(Prompt Injection),大家的第一反应往往是精心构造的文本越狱指令。 而在图生图任务中,输入图像在本质上扮演了视觉提示词的角色,与文本指令共同指导生成模型。 基于这一视角,本文展示针对视觉提示词的注入攻击:通过PGD对抗攻击算法对输入图像进行像素级微调,使其生成的违规图像能够绕过开源大模型的NSFW安全检测机制。 临近毕业,感觉市场对提示词注入比较感兴趣,因本人读博期间一直研究对抗攻击算法,所以决定尝试用对抗攻击的思路完成提示词注入攻击,误导开源模型生成违规图像。 完整代码链接:https://github.com/YujiangLi0v0/Injection_Attack_Inpainting.git 目录 * 一、 NSFW防线:开源模型的安全过滤机制 * 二、 攻击场景定义 (Threat Model) * 三、

“一天写完毕业论文?”:盘点2026年最炸裂的AI写作神器

“一天写完毕业论文?”:盘点2026年最炸裂的AI写作神器

“一天写完毕业论文” 在 2026 年已不再是天方夜谭。以下是 2026 年最炸裂、实测能大幅提速的 AI 论文写作神器,覆盖全流程生成、文献处理、降重润色、格式排版四大核心场景,帮你高效搞定毕业论文。 一、全流程王者:一站式搞定论文全链路(一天定稿首选) 这类工具覆盖从选题、开题、初稿、文献、降重到格式排版、答辩 PPT 的全流程,是赶 Deadline 的终极救星。 1. PaperRed(中文论文全流程首选,4.8 星) * 核心能力:选题→大纲→初稿→文献→查重→降重一站式;对接知网 / 万方,自动生成真实可溯源参考文献(GB/T 7714);AIGC

如何在VS Code中安装GitHub Copilot进行AI编程

如何在VS Code中安装GitHub Copilot进行AI编程

本文教您轻松在VS Code中玩转GitHub Copilot:从安装认证到实战网页开发,5分钟解锁AI编程神器,还能自由切换模型、实时调试代码! 在Visual Studio Code中搭建GitHub Copilot编程环境需要经过几个关键步骤,以下是详细指南: 环境准备阶段 1. 安装最新版VS Code(当前版本≥1.85)官网下载地址:https://code.visualstudio.com/ 2. 拥有有效的GitHub账户(建议启用双重验证) 注册地址:https://github.com/ 3. 稳定的网络连接(Copilot需实时云端交互) 安装流程 1、安装VS Code后,选择”Use All features with Copilot for free”。如果已经安装VS Code,可以打开VS Code扩展市场(

【混元AIGC+腾讯云智能体+首创Coze核心流思维导图MCP】:打造一个文思通-智能写作助手Agent

【混元AIGC+腾讯云智能体+首创Coze核心流思维导图MCP】:打造一个文思通-智能写作助手Agent

【混元AIGC+腾讯云智能体+首创Coze核心流思维导图MCP】:打造一个文思通-智能写作助手Agent 1.背景 作为一名长期关注人工智能发展的内容创作者,我经常需要撰写关于AI技术、应用趋势和产品体验的文章。然而,在实际写作过程中,常常会遇到灵感枯竭、结构混乱、表达不够精准等问题。有时候写到一半才发现逻辑断层,或者内容重复,甚至忘记了一些关键知识点。 为了解决这些痛点,我决定打造一个专属于自己的智能写作助手,取名为“文思通”——寓意“文思如泉涌,条理通达”。这个助手不仅要能帮我生成内容,更要具备结构化思维引导、逻辑梳理和语言润色的能力。 最近,我接触到一种创新的工具组合:以 Coze 平台为核心逻辑流,结合自研的思维导图 MCP 服务,可以实现从文本到可视化思维导图的自动转换。这正好解决了我在构思阶段缺乏条理的问题。而选择开发平台时,我注意到腾讯云智能体开发平台与腾讯混元大模型(Hunyuan AIGC) 的深度整合能力非常出色,支持工作流编排、插件扩展(MCP),并且提供稳定高效的推理服务。 最终,我决定采用“混元AIGC + 腾讯云智能体平台