2.2 GPT、LLaMA 与 MOE：自回归模型与混合专家架构演进

优质文章学习记录

— 8 min read

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

QtCreator配置AI辅助编程插件github copilot保姆级教程

QtCreator配置AI辅助编程插件github copilot保姆级教程

文章目录 * 概要 * 配置流程 概要 Free版‌免费使用，每月限额 2000 次代码补全 + 50 次聊天交互‌集成于 VS Code，支持跨文件编辑、终端协助及自定义指令‌ ‌ Pro版‌‌个人用户‌：10 美元/月 或 100 美元/年‌ ‌特殊群体‌：学生/教师/热门开源维护者可免费使用 Pro 版‌ ‌ Business版‌19 美元/月/用户，按月计费‌面向组织或企业中的团队订阅‌ ‌ Enterprise版‌39 美元/月/用户，按月计费‌企业可按需为不同组织分配 Business 或 Enterprise 订阅‌ 官方地址

终极免费语音转文本神器：OpenAI Whisper完整使用指南

终极免费语音转文本神器：OpenAI Whisper完整使用指南 【免费下载链接】whisper-base.en 项目地址: https://ai.gitcode.com/hf_mirrors/openai/whisper-base.en 想要将会议录音、学习讲座、播客内容快速转换为文字吗？OpenAI Whisper作为当前最先进的语音识别模型，能够高质量完成语音转文本任务，支持多语言识别，特别适合个人用户和中小团队使用。这款开源免费的语音转文本工具让每个人都能享受专业的语音转录服务，无需复杂的配置，只需简单几步即可开始使用。 为什么选择OpenAI Whisper语音识别？ 完全免费开源优势：Whisper完全开源，无需付费订阅，让每个人都能享受高质量的语音转文本服务。无论是个人用户还是商业项目，都可以免费使用这个强大的语音识别引擎。 多场景适用性： * 会议记录：自动生成会议纪要，提高工作效率 * 学习笔记：将讲座内容转为文字，方便复习整理 * 内容创作：播客、视频字幕生成，简化后期制作 * 个人助手：语音备忘录文字化，让记录更便捷 技术实力保障：
无脑通过github上copilot学生认证的方法(无需校园网，无需学生证)

无脑通过github上copilot学生认证的方法(无需校园网，无需学生证)

最近在家尝试通过github上的copilot的学生认证，总是不能过。好在经过了12次尝试后，终于总结了一套无需校园网，无需学生证的目前有效的无脑通过方法，希望能对不方便的同学们有所帮助。（注：本文旨在帮助有需求却因为种种情况难以被识别成功的同学，对非学生人士的认证情况概不负责） 一、注册github账号 这里就不细说了，想要通过copilot的大部分都有github账号，如果没有的话可以去网上搜一下。 二、2FA认证通过 认证网址 不是本文的重点，在此引用其他博主的内容： 从0开始的github学生认证并使用copilot教程（超详细！）_github copilot-ZEEKLOG博客 或者一个博客： [Git] 一次搞定：Github 2FA(Two-Factor Authentication/两因素认证) - 千千寰宇 - 博客园 特殊情况 值得注意的是，我在申请2FA时，发生了一个特殊情况——github上的二维码全是白色，没有显示出来，那就不要扫码，下面有一行字：unable to scan……，直接点里面的setup key链接就好了。 三
【原创】使用 Whisper + Transformers 自动生成中英文双语字幕（Python 实战）

【原创】使用 Whisper + Transformers 自动生成中英文双语字幕（Python 实战）

本文将教你如何使用 OpenAI 的 Whisper 语音识别模型，结合 HuggingFace Transformers 翻译模型，实现从视频中提取音频、识别语音、生成中英双语字幕的完整流程。 支持自动语言检测、进度条显示、以及自动生成 .srt 字幕文件。 🧰 一、环境准备 在开始之前，请先安装所需依赖包： pip install openai-whisper transformers pydub librosa tqdm torch ffmpeg-python modelscope ⚠️ 需要提前安装 FFmpeg（Windows 用户请到 ffmpeg.org 下载并配置环境变量） 🧠 二、项目功能概述 本项目实现的流程如下： 1. 提取视频音频（使用 FFmpeg） 2. 验证音频文件是否可用（使用 pydub） 3.