大模型通识 / 大模型理论基础
13. 稠密模型与 MoE：参数量究竟说明了什么
原文备份 · 第 14 / 20 篇 · 查看极客时间原知识库 ↗
本篇目录 · 12 节
来源：大模型理论基础
给笔记助手选模型时，你可能遇到两种介绍：一个模型有几十亿参数；另一个模型总参数多得多，却强调“每个 Token 只激活其中一小部分”。
这很容易引出三个疑问：后者到底算大模型还是小模型？只激活少量参数，是不是只需要那么多内存？它有很多“专家”，是不是会让几个专业助手分别回答，再投票选答案？
本篇把这些问题拆开。你将理解稠密模型与 MoE 的基本计算路径，手算一次专家路由，并区分模型保存的参数、单个 Token 使用的参数，以及设备实际承担的工作。
除明确引用的历史模型数据外，本篇向量、参数配置和调度例子均为教学构造，没有执行真实模型测试，也不构成硬件配置建议。
一、稠密模型：不同输入使用同一套主要计算模块
回到第 03 篇的 Transformer。一个块通常包含注意力计算和前馈网络 FFN：注意力结合上下文信息，FFN 对各位置的表示继续变换。
在常见的稠密模型，dense model中，不同 Token 会通过同一套主要层和权重。输入不同，中间值和输出当然不同，但不会在每一层先从许多套 FFN 中挑少数几套来用。
“稠密”不表示每个数字都必须非零，也不表示每个参数在每个时刻都产生同样的作用。例如嵌入表存在查找操作，激活函数也可能产生零值。这里讨论的是模型架构是否使用专家路由来稀疏选择计算分支，而不是逐个检查数值是否为零。
这也与上一篇的“哪些参数允许训练”不同。一个稠密模型可以用 LoRA 微调；一个 MoE 模型也可以有冻结或可训练参数。稠密/稀疏描述计算组织，全量/参数高效微调描述更新范围。
二、MoE：在模型内部选择部分子网络计算
MoE，Mixture of Experts，混合专家，把若干子网络作为“专家”，再通过路由机制组合它们。大模型中常见的是稀疏 MoE：对当前输入，只计算少数被选中的专家。
早期稀疏门控 MoE 研究就用可训练的门控网络选择少量前馈子网络，使参数容量能够增加，而不要求每次计算都遍历全部专家。《Outrageously Large Neural Networks》
在许多 Transformer MoE 架构中，变化主要发生在 FFN 部分：原来的一套 FFN 被多套专家 FFN 与路由器替代；注意力等部分仍然共享。不同模型可以只在部分层使用 MoE，不应认为整个模型所有模块都变成了专家。
Router，路由器，读取某个 Token 在当前层的隐藏表示，为专家分配分数，选出需要计算的专家，再汇合它们的输出。它处理的是模型内部向量，不是先读懂完整问题、写一份“人员分工方案”。
以 Mixtral 8×7B 的原始架构为例，每层有 8 个前馈专家，每个 Token 选择其中 2 个，结果按路由权重加权组合。《Mixtral of Experts》
flowchart LR
H[当前层的 Token 表示] --> R[路由器选择专家]
H --> E1[选中的专家 1]
H --> E2[选中的专家 2]
R --> W[组合权重]
E1 --> S[加权合并输出]
E2 --> S
W --> S
S --> N[继续后续网络计算]
图中没有画出的专家，对这个 Token 不执行专家前向计算；它们仍然存在于模型中，可能被其他 Token 使用。后续层可以重新选择专家，相邻 Token 的选择也可以不同。
“专家”不等于几个完整聊天机器人
常见 MoE 专家是模型内部的一组权重，输入、输出都是中间表示。它通常不独立接收用户消息，也不生成一整段回答再交给另一个模型评选。
你不能仅凭“专家”这个名字，就认定其中有一个数学老师、一个程序员和一个写作老师。训练可能形成某些分工倾向，但这些分工未必与人类职业或主题一一对应。
让多个完整模型分别作答、再投票或汇总，是另一类应用组织方式。MoE 的专家组合通常在一次模型前向计算的内部完成，层级和开销都不同。
三、手算一次 Top-2 路由
下面只演示一个 MoE 层对一个 Token 的处理。假设路由器给四个专家算出的归一化分数是：
| 专家 | 原始归一化分数 |
|---|---|
| E1 | 0.50 |
| E2 | 0.30 |
| E3 | 0.15 |
| E4 | 0.05 |
采用 Top-2，即选择分数最高的两个专家 E1、E2。本算例把选中分数重新归一化：
E1 的组合权重 = 0.50 ÷ (0.50+0.30) = 0.625
E2 的组合权重 = 0.30 ÷ (0.50+0.30) = 0.375
假设 E1 与 E2 对同一个输入分别输出：
E1 输出：[2, 0]
E2 输出：[0, 4]
那么这一专家组合的输出是：
0.625×[2,0] + 0.375×[0,4] = [1.25,1.50]
这个二维结果还会进入后续网络，并不是一段答案。路由权重 0.625 也不是“专家 E1 答对的概率为 62.5%”；它是在该计算中组合输出的系数。
不同架构的分数函数、归一化与选择方式可能不同。这里选择的是便于理解的 Top-k 加权形式，不是所有 MoE 都必须照此计算。Switch Transformer 就研究了每个 Token 只选择一个专家的简化路由。《Switch Transformers》
单个 Token 用两个，整段文本可能用到更多
假设同一层处理四个 Token，路由分别为：
| Token | 使用的专家 |
|---|---|
| T1 | E1、E2 |
| T2 | E2、E3 |
| T3 | E3、E4 |
| T4 | E1、E4 |
每个 Token 仍只使用两个专家，但这一组 Token 总共使用了四个专家，形成 8 次“Token—专家”分配。不能把“每 Token 激活两个”误读成“整个请求永远只用两个”。
这里的 T1—T4 是计算位置编号，不是中文词或实际分词示例。把批次扩大、同时处理更多请求后，专家使用的并集还可能扩大。
四、总参数与激活参数，要分别计算
总参数量描述模型保存的参数规模。激活参数量通常描述处理一个 Token 时，按该模型统计口径参与主要计算的参数规模。
为便于手算，构造一个只有一组路由专家的模型：共享部分约有 20 亿参数，包含路由器等共同计算；另有 8 个专家，每个 10 亿参数，每个 Token 选择 2 个。这里忽略统计细节，不对应任何实际模型。
总参数 = 共享部分 + 全部专家
= 20 亿 + 8×10 亿 = 100 亿
每 Token 激活参数 ≈ 共享部分 + 选中的专家
= 20 亿 + 2×10 亿 = 40 亿
如果只把专家数从 8 增加到 16，其他条件不变：总参数变成 180 亿，按这个简化口径每 Token 仍激活约 40 亿。专家部分的单 Token 计算量没有随总专家数翻倍，但路由、存储、通信等开销仍可能变化。
如果保留 8 个专家，却每次选择 4 个，则总参数仍为 100 亿，激活参数变成约 60 亿。
| 构造配置 | 总参数 | 每 Token 激活参数 |
|---|---|---|
| 8 个专家，选 2 个 | 100 亿 | 40 亿 |
| 16 个专家，选 2 个 | 180 亿 | 40 亿 |
| 8 个专家，选 4 个 | 100 亿 | 60 亿 |
这就是 MoE 的关键取舍：可以在较小的单 Token 专家计算预算下，容纳更大的参数容量。它没有保证这些新增参数一定学到有用内容；收益还依赖训练数据、路由与优化。
有些架构还包含始终使用的共享专家。DeepSeekMoE 的原始设计把共享专家与按输入选择的专家分开，意图让共享部分承担常见知识，减少路由专家之间的冗余。《DeepSeekMoE》 统计时，不能只数路由选中的专家而漏掉共享计算。
真实模型中的数字也需要读清口径
Mixtral 8×7B 原论文摘要使用约 47B 总参数、13B 激活参数的表述。B 代表十亿，因此分别约为 470 亿与 130 亿；型号里的“8×7B”不能直接当作 8 个完整 7B 聊天模型拼起来，得出 56B 总参数。Mixtral 原论文摘要
DeepSeek-V3 技术报告给出的则是 671B 总参数、每 Token 激活 37B，即 6710 亿与 370 亿。《DeepSeek-V3 Technical Report》
这些是对应论文模型的历史架构数据，用于理解统计方式，不表示当前所有同系列 API 都采用同一配置。也不能仅凭 37B 就断言它与某个 37B 稠密模型具有完全相同的速度、内存占用或能力。
五、激活少，不等于只保存被激活的参数
回到 100 亿总参数、40 亿激活参数的构造模型。假设全部权重用 16 位，也就是每参数 2 字节保存：
全部权重载荷 = 100 亿×2 字节 = 200 亿字节 = 20 GB
不能只按 40 亿×2=8 GB 来估计完整权重的存储需求。其他专家没有被这一个 Token 选中，不代表之后永远不用。
20 GB 也只是十进制权重载荷，不包括 KV cache、激活、工作区和其他开销。上一篇讨论的量化可以减少权重表示所需空间，但不会把“总量”和“激活量”这两个概念合并成一个。
实际系统可以把专家分散到多张卡，或使用 CPU 内存等存储并按需搬运。这样不要求全部专家永远放在一张 GPU 上，但完整模型仍要有地方存储、在需要时能访问；搬运也会付出时间成本。
专家并行，Expert Parallelism，就是把不同专家安排在不同设备上执行的一种方式。vLLM 的官方部署文档分别处理专家层与注意力层的分布，并提供用于专家间数据分发的通信后端。vLLM：Expert Parallel Deployment
当一个 Token 要去另一张卡上的专家处理时，需要传递相应中间表示，并把结果送回组合位置。算术工作减少的同时，设备之间的数据交换可能成为新的开销。
所以，“这次不用所有权重做矩阵乘法”与“可以不存储其余权重”不是同一件事。模型能否装下与模型跑得多快，需要分别评估。
六、路由负载与真实速度：少算并不自动等于快
四个专家、四个 Token、每个 Token 选两个，总共 8 次分配。第三节的分配表让每个专家各处理 2 次，比较均衡。
换一种路由：四个 Token 全都选 E1、E2。工作量就变成：
E1：4 次 E2：4 次 E3：0 次 E4：0 次
总分配数没变，却出现两个忙、两个闲。若专家位于不同设备，某些设备可能成为瓶颈。训练时也可能出现少数专家长期获得大量样本、其余专家学习不足的问题，因此需要考虑负载平衡与训练稳定性。
这不是要求每个短请求都精确平均分配。路由还要服务于任务效果，负载平衡通常是在训练批次或系统调度等范围内处理的取舍。
有些实现为每个专家设置处理容量，超出时需要专门处理；不能因此概括成“MoE 必然丢 Token”。MegaBlocks 的原始研究专门处理动态专家工作量，在其方法中避免丢弃 Token，说明这是系统实现问题，而非 MoE 定义中的必然要求。《MegaBlocks》
激活参数只是速度线索之一
处理一个 Token 所需的实际时间还受这些因素影响：
| 因素 | 为什么会影响体验 |
|---|---|
| 上下文长度与注意力设计 | 长输入和缓存访问仍然要计算或读写 |
| 专家路由与跨设备通信 | 分发、组合和数据交换需要时间 |
| 批量与专家负载 | 太零散或不均衡的工作未必能高效利用硬件 |
| 精度、算子与硬件支持 | 同样的架构在不同实现上表现可能不同 |
| 排队与服务调度 | API 等待时间不完全来自模型计算 |
对用户，还应区分看到第一个输出需要多久、后续生成速度，以及整段任务完成时间。一个服务可能同时处理很多请求的总吞吐量很好，但单次短请求不一定等待最少。
总参数不是 FLOPs，激活参数也不是秒数。FLOPs 是浮点运算数量的度量；将参数数目作为计算量的粗略线索可以帮助理解架构，却不能跳过注意力、路由和系统开销直接换算实际延迟。
七、把这些概念用在你的个人项目上
你的复习助手不需要因为 MoE 听起来先进，就把原来可用的模型换掉。架构信息帮助你理解资源与限制，最终仍要看自己的任务。
假设两个候选模型，一个稠密、一个 MoE。可以给它们相同的当前笔记、相同的问题与输出要求，检查：
- 能否把“周五改为周六”正确解析为周六。
- 面对没有资料的章节，是否会编出时间。
- 能否只输出约定字段，并提供支持判断的依据。
- 加入多条干扰笔记后，表现是否仍稳定。
同时记录输入与输出长度、首个输出等待、完整任务耗时和费用。若本地运行，还要记录权重格式、实际内存峰值及运行后端。这是一份比较方案，不是本篇已经做过的基准测试。
若 MoE 总参数更大，却在你的短文本提取任务上并无收益，不能仅凭“更大”推断它更适合。若某个稠密模型更快，也不能据此断言稠密架构永远更高效。训练质量、后训练、上下文能力和部署方式都在共同作用。
另一个常见误解是把 MoE 专家当成自己的知识库。专家权重不会因为你上传了一份笔记就自动收录它。需要当前私人资料时，仍要提供上下文或使用 RAG；要适应长期任务时，才讨论提示与训练。架构名称没有替代这些应用环节。
八、理解检查
1. 一个模型有 8 个专家，是不是等于 8 个完整聊天模型分别回答？
通常不是。常见 Transformer MoE 专家是内部 FFN 子网络，处理隐藏表示；共享注意力等部分仍属于整体模型，最终生成发生在完整网络中。
2. 路由分数 0.50、0.30、0.15、0.05，取前两项并重新归一化，权重是多少？
分别是 0.625、0.375。若两个专家输出 [2,0] 与 [0,4]，加权结果为 [1.25,1.50]。这些系数不是专家答对的概率。
3. 共享 20 亿参数、8 个各 10 亿的专家，每 Token 选 2 个，总量和激活量是多少？
按本篇简化口径，总量为 100 亿，激活量约 40 亿。把专家数改成 16、仍选 2 个，则总量 180 亿，激活量仍约 40 亿。
4. 上述 100 亿模型全部权重按每参数 2 字节存储，能否按激活量只准备 8 GB？
不能。全部权重载荷为十进制 20 GB，还没有计入缓存等。可以分布存储或按需搬运，但其余专家仍要可访问，不能凭激活量消除它们。
5. 每个 Token 只使用两个专家，为什么一个批次可能用到全部专家？
不同 Token 可以选择不同组合。第三节四个 Token 的选择并集为 E1—E4，共有 8 次分配，每个专家各处理 2 次。
6. 两个模型激活参数相同，是否意味着速度和效果相同？
不意味着。总容量、训练、注意力、路由、通信、精度、硬件与负载等都可能不同，应在相同任务与明确运行条件下比较。
读模型规格时，现在可以分别问：保存了多少参数、每个 Token 选择哪些计算、完整权重如何放置、实际任务需要多少时间。这样才不会把一个数字同时当作能力、内存和速度的答案。
下一篇《蒸馏、量化与推理优化：模型怎样变得更轻、更便宜》，继续讨论减少模型与服务成本的几条不同路径，以及各自需要验证的取舍。
上一篇：微调与 LoRA · 返回第二部分大纲