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与单片机之:STM32上运行AI大模型的四种方案!(含案例,建议收藏)

AI与单片机之:STM32上运行AI大模型的四种方案!(含案例,建议收藏)

前几天小编写了2篇文章 “为什么AI会改变单片机的未来?” 单片机上如何运行AI?单片机如何“学会思考”之TinyML崛起!(含案例,建议收藏), 引起了非常多的留言、关注和加群讨论。但是,仍然有读者朋友给小编留言,能否整理一些关于比较常用芯片比如STM32实用AI大模型的案例。为了满足粉丝朋友的诉求,小编整理了“在STM32单片机上运行AI大模型的”真实案例。 从粉丝的一个问题引出本文的思考:AI 模型能跑在 STM32 上吗? 一:先说结论 先说结论:不仅能跑,还一共有四种方案。 方案一:STM32官方提供的 STM32Cube.AI(X-CUBE-AI) 其实原理是我们把在 PC 上训练好的神经网络自动转换成可在 MCU 上运行的 C 库;然后在自己的软件/代码工程中调用已经编译产生的C库。 方案二:直接用 TensorFlow Lite Micro(TFLM)+ CMSIS-NN 在 STM32

AI风口劝退指南:为什么99%的普通人不该盲目追AI?理性入局的完整路径与实战建议(2026深度解析)

AI风口劝退指南:为什么99%的普通人不该盲目追AI?理性入局的完整路径与实战建议(2026深度解析) 摘要: 2026年,AI大模型热潮持续升温,但“全民学AI”的背后,是大量非科班、无基础、资源匮乏者陷入时间、金钱与心理的三重亏损。本文从认知偏差、能力错配、资源垄断、职业断层、教育泡沫五大维度,系统剖析为何多数人不应盲目追逐AI风口,并提供一条分阶段、可落地、高性价比的理性参与路径。全文包含技术原理详解、真实失败案例、实用代码示例、调试技巧及职业规划建议,全文约9800字,适合所有对AI感兴趣但尚未入局、或已深陷焦虑的技术爱好者阅读。 一、引言:当“AI=财富自由”成为时代幻觉 2026年3月,某技术论坛上一则帖子引发广泛共鸣: “辞职三个月,每天16小时啃《深度学习》《Attention Is All You Need》,结果连Hugging Face的Trainer都配置失败。存款耗尽,

Python 2026 年发展局势:AI 时代的 “通用基础设施语言”

2026 年的 Python 已从 “热门编程语言” 进化为全球数字生态的核心基础设施语言,其地位不仅稳固且进一步强化,同时也面临新的机遇与挑战,整体呈现 “一核多翼、优势固化、局部竞争” 的格局。 一、核心优势:AI + 全生态双轮驱动,地位无可替代 1. AI / 大模型领域的绝对霸主这是 Python 最核心的护城河。2026 年大模型落地、AI Agent 开发、多模态应用、低代码 AI 工具等场景中,Python 依然是95% 以上开发者的首选语言: * 生态垄断:PyTorch 3.0、TensorFlow 2.18、LangChain 2.0、Transformers 等核心框架均以 Python 为第一开发语言; * 效率优势:

2026年医疗AI的可信革命全栈实现(下)

2026年医疗AI的可信革命全栈实现(下)

9.3 向量索引构建示例 文档进入向量库前,应先清洗、切分、打标签、嵌入,再写入索引。以下示例展示一种最简流程,真实环境中可替换为Milvus或Qdrant SDK。 代码清单 9-2 文档切分与索引写入 from dataclasses import dataclass from typing import Iterable import hashlib @dataclass class Chunk:     chunk_id: str     text: str     metadata: dict def chunk_document(doc_id: str, title: str, text: str, source_type: str) ->