跳转至

现代大模型基座

LLaMA 系列模型采用了哪些结构选择？（如 RMSNorm, SwiGLU, RoPE）为什么？

LLaMA 系列（包括 LLaMA 1/2/3）作为现代 Decoder-only 模型，整合了一系列已被验证的高效架构改进，旨在提升训练稳定性、模型性能和推理效率。主要结构选择如下：

  • Pre-Normalization 与 RMSNorm
  • LLaMA 在每个子层输入之前应用归一化（Pre-Norm），而不是早期 Transformer 的 Post-Norm。Pre-Norm 有利于梯度的直接传播，使训练更稳定，尤其是深层网络。

  • 采用了 RMSNorm（Root Mean Square Layer Normalization），去除了 LayerNorm 中的减均值操作，仅用均方根进行缩放。RMSNorm 计算更简单，速度更快，被实验证明与 LayerNorm 效果相当，已成为大多数 LLM 的标配。

  • SwiGLU 激活函数

  • 前馈网络（FFN）的激活函数由传统的 ReLU/GELU 替换为 SwiGLU。SwiGLU 是 Swish 与门控线性单元（GLU）的结合：SwiGLU(x) = (xW_1 \odot \text{SiLU}(xW_2)) W_3。

  • 这种结构引入了门控机制，允许模型动态控制信息流。尽管增加了参数矩阵，但 PaLM 等工作证明，在同等算力预算下，使用 GLU 变体能显著提高性能。LLaMA 采用 SwiGLU 并调整 FFN 中间维度，以平衡计算量。

  • 旋转位置编码（RoPE）

  • 使用 RoPE 代替绝对位置编码或学习式位置编码。RoPE 通过旋转变换将位置信息融入 Q 和 K，使点积隐含地包含相对位置信息：Attention(Q, K) = (R_{\theta,i} Q_i)^\top (R_{\theta,j} K_j) = Q_i^\top R_{\theta,j-i} K_j。

  • RoPE 具有良好的外推性（可扩展长上下文），且随着序列长度增大，远程衰减特性使其自然地偏向局部注意力。LLaMA 及其后续版本均采用此方案。

  • 分组查询注意力（GQA，LLaMA 2/3）

  • LLaMA 1 使用标准 MHA，LLaMA 2 的大模型（如 70B）引入了 GQA，将查询头分组共享 Key/Value 头。LLaMA 3 全面采用 GQA（8 个键值头），以显著减少 KV 缓存大小，提升推理吞吐。GQA 在几乎不损失性能的前提下大幅降低了内存带宽压力。

  • 其它细节：

  • 使用 Bfloat16 混合精度训练，并采用 FlashAttention 等高效注意力内核（LLaMA 2/3）。
  • 激活前移（Pre-Norm）+ 残差连接，标准化位置嵌入等。

这些结构组合并非偶然，它们是社区在 Transformer 上的大量消融实验的精华，构成了现代高效 LLM 的基础。

LLaMA 的开源对社区产生了哪些影响？版本迭代中有哪些重要改进？

开源影响

Meta 开源的 LLaMA 系列（尤其是 LLaMA 1 的权重泄露与后续正式开源）直接引爆了大模型的平民化革命。其影响包括：

  • 催生了庞大的衍生模型和微调生态（Alpaca、Vicuna、Koala 等），推动了指令微调、量化、本地部署技术的爆发。

  • 奠定了 Decoder-only 预训练模型的开放标准，大量研究基于 LLaMA 架构展开，加速了对缩放定律、对齐技术、长上下文扩展的研究。

  • 构建了活跃的社区（Hugging Face 等），使得模型改进、应用分享形成正反馈循环，缩小了闭源与开源模型的差距。

版本迭代与重要改进

  • LLaMA 1（2023.02）：开源 7B-65B 四个规模。关键选择：Pre-Norm、RMSNorm、SwiGLU、RoPE。训练数据 ~1-1.4T tokens，远超 Chinchilla 最优，开创了“小模型+大数据”路线，性价比极高。

  • LLaMA 2（2023.07）：增加 GQA（70B 模型）、多轮对话对齐（RLHF）、更大上下文（4K）、幽灵注意力（Ghost Attention）改善多轮一致性。训练数据提升至 2T tokens，并开源了微调后的对话版本。

  • LLaMA 3（2024.04）：8B 和 70B 模型，训练数据暴增至 15T tokens，全面采用 GQA（8 个 KV 头）、128K 词表的 tiktoken 分词器、密集模型极致优化。引入更强的指令微调和安全对齐，性能逼近 GPT-4 量级。

  • LLaMA 3.1（2024.07）：首次推出 405B 稠密模型，支持 128K 上下文窗口，支持多语言、工具调用、代码，并开源了完整训练堆栈。标志开源模型达到顶级闭源水平。

每一代升级都聚焦于数据规模扩大、长上下文支持、推理效率提升（GQA）和对齐质量。

Chinchilla 缩放定律的内容是什么？参数和训练数据的最优配比是多少？

Chinchilla 定律由 DeepMind 于 2022 年提出，源于论文《Training Compute-Optimal Large Language Models》。其核心发现是：给定固定的训练计算预算 CC，模型参数量 NN 和训练 token 数 DD 应该等比缩放，才能实现最低的验证损失。

image.png

  • 具体配比：对于训练 Chinchilla 模型的特定算力，最优配置约为 70B 参数训练 1.4T tokens。这与之前“增大模型，数据大致不变”（如 Gopher 280B 只训练 300B tokens）的做法形成鲜明对比。

  • 更简化的经验法则：每个参数约对应 20 个训练 token（tokens = 20 × params）。例如 10B 模型用 200B tokens 训练。实际中这个比例随模型规模和架构有所不同，但作为指导被广泛接受。

定律意义：它揭示了之前的大模型（如 GPT-3）严重“训练不足”，可以通过在更多数据上训练较小模型来用更少推理成本达到同等甚至更好性能。

Chinchilla 定律对后来的大模型训练策略产生了什么影响？如 LLaMA 1 和 2 的调整。

Chinchilla 定律直接重塑了业界的大模型训练策略，主要体现为“小模型、大数据”的范式转移。

  • LLaMA 1：正是受 Chinchilla 启发，Meta 选择了在远大于“标准”的数据量上训练相对较小的模型。例如，LLaMA-13B 用 1T tokens 训练，远超同等模型之前的数据量，使其以 13B 参数超越了 175B 的 GPT-3 性能。这证明了计算优化训练的巨大潜力。

  • LLaMA 2：进一步增加数据至 2T tokens，针对 7B、13B、70B 模型，全面贯彻数据优先原则。70B 模型性能媲美甚至超过当时的 Chinchilla 70B。

  • 泛化影响：几乎所有主流开源模型（Falcon、Mistral、Qwen、DeepSeek 等）都采用了过度训练策略（训练 token 数远超过 20×params），以在较小参数下获得极强性能，从而降低推理成本。例如 Mistral 7B 用约 8T tokens 训练，性能突出。

  • 新定律扩展：人们逐渐发现 Chinchilla 定律仅针对单 epoch 训练（数据不重复）。当允许重复数据（多 epoch）或使用更高质量数据时，最优配比会变化。DeepMind 后续的 “Scaling Data-Constrained Language Models” 研究了重复数据的情况，指出数据受限时，重复 token 仍有收益，这进一步解释了 LLaMA 3 等用 15T tokens 训练 8B/70B 模型的合理性。

总之，Chinchilla 让业界从“堆参数”转向“堆数据”，极大提高了训练和推理的效率。

MoE（混合专家）模型的工作原理是什么？Top-k 路由如何选择专家？

MoE 工作原理

MoE 将传统稠密 FFN 层替换为多个并行的 专家网络（通常每个专家就是一个标准 FFN），并引入一个可学习的 路由器（通常是一个小型线性层 + softmax）。对于输入中的每个 token：

  1. 路由器输出该 token 针对所有专家的 logits。

  2. 使用 Top-k 选择，只激活 logits 最高的 k 个专家（通常 k=1 或 2）。

  3. Token 被发送到选中的 k 个专家，每个专家独立计算输出。

  4. 最终输出是这些专家输出的加权和，权重由路由器 logits 的 softmax 归一化后提供（仅对选中的 k 个专家）。

  5. 未被选中的专家不参与计算，其参数和计算量被节省。

Top-k 路由细节

image.png

这种条件计算使模型总参数量成倍增长（多个专家），而计算量仅增加约 k/Ek/E 倍，实现了参数与计算的解耦。

MoE 模型的负载均衡损失是怎么设计的？为什么需要辅助损失？

为什么需要负载均衡

Top-k 路由容易导致专家负载失衡：训练初期或训练过程中，路由器可能倾向于始终选择少数几个专家（赢家通吃），导致其它专家几乎不接收 token，造成“专家坍塌”。这不仅浪费了模型容量，还会使部分专家梯度稀疏、难以学习，并降低分布式训练的硬件利用率（部分设备空闲）。

负载均衡损失设计

常用的辅助损失激励每个专家接收大致均等的 token 数量。定义：

image.png

image.png

Mixtral 8x7B 模型是如何实现 MoE 的？它为什么能在推理时只激活部分参数？

Mixtral 8x7B 实现

Mixtral 是由 Mistral AI 开源的稀疏 MoE 模型。其名称“8x7B”表示总共 8 个专家，但每个 token 只激活 2 个专家（k=2）。每个专家的 FFN 大小相当于一个 7B 稠密模型的 FFN（实际中间维度 14336，非 7B 的精确映射，但总参数量等效）。结构上：

  • 每一层的 FFN 被替换为 8 个并行的 SwiGLU 专家。

  • 路由器是一个线性层，对输入 hidden state 输出 8 个 logits，Top-2 选择专家并计算加权和。

  • 总参数量约 46.7B，但推理时每 token 只激活 12.9B 参数（路由器和注意力 + 2 个专家），与单个 12B 稠密模型的推理计算量相当。

为什么能只激活部分参数

MoE 的条件计算特性：每个 token 根据路由器动态选择 k 个专家，其余专家不被执行。因此，在自回归解码时，可以仅加载被激活的专家到计算单元，大量不活跃的专家驻留在内存或可换出，从而达到“稀疏激活”。这大幅降低了每 token 的 FLOPs，使得大容量模型推理速度与同计算量的小稠密模型相近。

在分布式训练中，MoE 的专家并行与张量并行、数据并行如何结合？通信有什么特点？

在大规模训练中，通常采用三维并行：数据并行（DP）、张量并行（TP）、流水线并行（PP），并针对 MoE 增加专家并行（EP）。

  • 数据并行（DP）：每个设备拥有整个模型副本，分不同 batch 训练。MoE 中专家参数较大，单卡放不下全部专家，因此需要专家并行。

  • 专家并行（EP）：将多个专家分布到不同的设备上。每个 token 经过路由器后，通过 all-to-all 通信发送到对应的专家所在设备上，设备计算其负责的专家，再将输出发回。专家并行维度通常与 DP 正交：所有设备共同构成 EP 组，外部套 DP。

  • 张量并行（TP）：将单个专家的权重矩阵切分到多个设备，用于突破单个专家过大的情形。通常 EP 与 TP 可叠加，例如每个专家的 FFN 可使用 TP 分片。

  • 结合方式：在典型 3D 并行中，首先划分 EP 组（例如 8 卡一个 EP 组，每组存放全部 8 个专家），组内专家分布；然后在 EP 组内可对每个专家内部进行 TP；最后在不同 EP 组间进行 DP（跨节点）。也可以 DP 在前面。

通信特点

  • All-to-All 通信是 MoE 的显著开销。每一层 MoE 需要两次 all-to-all：一次将 token 发送到对应专家，一次将专家输出回收。通信量取决于每 token 选择的专家数和隐藏维度。

  • 通信延迟可能成为瓶颈，需要高速互联（NVLink、InfiniBand）。DeepSpeed-MoE 等框架通过融合通信、容量因子（预留容量防止专家过载）和交错训练来优化。

  • 负载不均衡会导致 all-to-all 中某些设备收发数据量不均，产生同步等待，因此负载均衡损失和容量因子机制至关重要。

MoE 模型在推理部署时面临哪些挑战？如专家负载不均、高显存占用。

  • 高显存占用：虽然每 token 仅激活少量参数，但所有专家的权重都需要保持在显存中，否则动态加载会带来严重延迟。因此总参数庞大，对显存总量要求高（如 Mixtral 8x7B 需要足够的显存放 46.7B 参数）。

  • 专家负载不均衡：实际推理中，某些专家可能被大量请求选中，成为热点，而其他专家空闲。这导致计算资源利用率低，延迟增加。需要动态批量处理或请求调度来缓解。

  • 批处理效率低：在 Continuous Batching 中，不同请求的 token 可能选择不同的专家，难以形成整齐的矩阵乘法批次，导致 GPU 利用率下降。

  • 网络通信：如果跨卡部署，all-to-all 通信引入延迟，不适合对延迟敏感的在线服务；常需尽量将专家放置在同一设备或通过高速 NVLink 连接。

  • 模型切分与推理框架支持：需要框架能高效地调度稀疏专家计算，vLLM、TensorRT-LLM 等正在增加对 MoE 的专门优化（如 expert-aware 调度、融合内核）。

对比 Dense 模型和 MoE 模型在给定相同计算预算下的表现和效率。

相同计算预算指相同训练 FLOPs 或相同推理 FLOPs per token。

  • 性能：在同等训练计算量下，MoE 模型通常显著优于稠密模型。因为 MoE 用更多的参数容量（更多专家）来吸收知识，而计算量通过稀疏激活保持较低。例如，Mixtral 8x7B 用 12.9B 的激活参数，性能超过 13B 稠密模型，匹敌或超越 70B 稠密模型，但训练计算量远小于 70B。

  • 推理效率：当比较每 token 计算量相同时，MoE 模型性能更优（更多总参数知识）。但若硬件显存足够，MoE 推理速度通常受内存带宽和专家切换开销影响，难以达到相同 FLOPs 的稠密模型的吞吐。不过，由于性能高很多，在保持相同延迟下，MoE 提供更高的质量。

  • 显存与吞吐的权衡：MoE 需要存储所有专家，显存占用大。如果服务需高吞吐，必须将多副本加载到多卡，显存成本高。因此，MoE 的“推理效率”是指用略高的硬件成本换取质量的大幅提升。

  • 总体：在给定推理硬件预算下，训练一个 MoE 模型用该预算推理，或训练一个稠密模型用该预算推理，MoE 往往能得到更低的困惑度。即，MoE 是用显存换取知识密度的策略。

为什么很多大模型选择在 FFN 上做 MoE，而不是在注意力上？

  • 参数占比大：Transformer 中 FFN 通常占 2/3 的参数。将 MoE 用于 FFN 能最有效地放大模型总参数量，带来显著的容量提升。

  • 计算独立性：FFN 是对每个 token 单独处理的，token 间无交互，天然适合条件计算（每个 token 路由到不同专家），并行实现简单。而注意力需要计算 token 间的交互，若对注意力做 MoE（如每个头是不同专家），需要复杂的 token 维度上的路由和通信，会破坏注意力矩阵的密集计算模式，实现难度和通信开销都更大。

  • 已有成功实践：从 GShard、Switch Transformer 到 Mixtral，FFN MoE 已经被充分验证有效且训练稳定。注意力 MoE 研究相对较少，收益不确定。

  • 负载均衡容易设计：FFN 上的负载均衡可以通过简单统计每个专家接收的 token 数来施加辅助损失。注意力上的均衡需要跨序列维度考虑，更复杂。

因此，FFN MoE 是参数量扩展的最直接、最高效的方案。

如何理解大模型的“涌现能力”？缩放定律能否完全预测涌现？

涌现能力

涌现能力指的是当模型规模、数据量或计算量跨越某个临界点后，模型突然表现出在较小规模下完全不具备的、非线性的新能力。典型如：

  • 算术推理（GPT-3 175B 突然能计算复杂数学题，而 13B 几乎为零）

  • 多步推理、上下文学习、翻译、代码生成等在某个规模突然出现，且性能随规模跃升。 这些能力无法通过简单外推小模型的性能曲线来预测。

缩放定律能否完全预测涌现

不能。标准缩放定律（如 Chinchilla 或 Kaplan 幂律）描述了验证损失随参数和数据平滑下降的趋势，损失本身通常是平滑的。但具体能力（如准确率）可能随损失的非线性映射而表现出突变。当损失降到某个阈值，模型正好学会了组合性推理，就涌现了能力。因此：

  • 缩放定律可以预测“损失”的改善，无法精确预测“能力”的涌现点。

  • 涌现也与任务复杂度、评估指标的敏感性相关。近期有研究认为，用更连续的指标（如正确 token 概率的积分）替代硬准确率，涌现现象会变得平滑，说明涌现可能部分源于非线性评估度量。但无论如何，能力的质变是客观存在的，缩放定律是必要条件而非充分预测工具。

在 LLaMA 类模型中，如何处理输入中的特殊标记（如 system prompt）？

LLaMA 类模型基于 Decoder-only 的聊天模板（Chat Template）来处理特殊标记。以 LLaMA 2/3 为例：

  • 专用特殊 token：使用 <<SYS>> 和 <</SYS>> 包裹系统提示，用 [INST] 和 [/INST] 标记指令轮次，用 <s> 和 </s> 标记序列开始和结束。LLaMA 3 则引入更简洁的 <|begin_of_text|>、<|start_header_id|>system<|end_header_id|> 等 token。

  • 模板化拼接：在预处理时，将系统提示、对话历史、当前指令按照特定模板拼接成一个连续的 token 序列。例如：

  • text

  • [INST] <>\n{System prompt}\n<>\n\n{User message} [/INST] {Assistant response} [INST] {Next user} [/INST]

  • 训练时的角色区分：在指令微调阶段，模型学习这些特殊 token 的语义，知道系统提示部分提供全局行为指导，而用户消息是任务。通过仅在助手 token 上计算损失（即仅对回复部分进行训练），模型学会区分提示与生成。

  • 推理时掩码与缓存：系统提示通常固定，可利用前缀缓存（Prefix Caching），只计算一次其 KV 缓存，后续多轮对话直接复用，极大降低首 token 延迟。

因此，处理特殊标记的核心是约定好的模板 + 微调时的角色损失掩码 + 利用缓存优化。

现在很多模型支持工具调用，从模型架构角度怎么实现？

工具调用（Function Calling / Tool Use）并不需要对底层 Transformer 架构进行根本改变，而是通过训练数据格式和特殊的 token 设计来教会模型使用工具。

  • 格式化输出语法：在训练数据中，将工具调用的请求和响应格式化为特定结构的文本。例如：
[TOOL_CALLS] {"name": "get_weather", "arguments": {"city": "Beijing"}} [/TOOL_CALLS]
[TOOL_RESULTS] {"temperature": 25} [/TOOL_RESULTS]

  • 模型学习生成 [TOOL_CALLS] ... 标记，并在之后接收结果继续生成。

  • 新增特殊 token：如 <function_call>、</function_call>、<function_response> 等，将其加入词表并微调，让模型掌握工具调用的边界。LLaMA 3 等使用 <|python_tag|> 等方式。

  • 构建细粒度损失：只在工具调用的部分计算损失，或者对整个工具交互循环进行训练，包括生成调用和给定结果后的继续生成。

  • 约束解码：推理时，通过 API 定义允许的函数签名，使用语法约束解码（如 grammars、logit masks）强制模型输出符合 JSON Schema 的有效调用，减少格式错误。

  • 与外部系统的交互：模型本身不执行工具。推理引擎检测到模型输出工具调用结束 token 后，暂停生成，将参数传递给外部执行器，获得结果后将其作为额外的上下文插入继续生成。整个循环由编排层管理。

因此，架构层面仅是增加了新的 token 类型，并在微调时赋予模型产生这些 token 的能力，其余靠推理系统的编排和约束解码保证可靠性。这种设计保持了模型结构的高度统一性。