MoE 让 「总参数（容量）」与「单 token 算力（成本）」解耦 ------它省的是 FLOPs，不是显存。
本质区别：稠密 = 每参数都算每 token；MoE = 每 token 只激活 top-k 个 expert（计算稀疏，非显存稀疏）
- 致命反直觉：MoE 不省显存------所有 expert 都得驻留显存，Mixtral-8x7B 显存 ≈ 47B 稠密
- 业界格局：DeepSeek-V3（671B/37B）、Qwen3-235B-A22B、Kimi K2（1T/32B）等大尺寸全转 MoE；小尺寸（<14B）仍以稠密为主
- router 真相：top-k 训练时固定不可调；expert 是隐式分工，与"医学/法律"语义角色无关；token 通常被多个 expert 加权处理
- 数据中心选 MoE 的本质：吞吐经济学（$/token 更低）+ 多租户摊销 + Expert Parallelism，不是因为「显存便宜」
- 本地部署经验：单卡消费级选稠密；多卡/服务器选 MoE；24GB 甜点是 Qwen3-30B-A3B 这类小激活参数 MoE
聊大模型架构时，下面这几个概念经常被混着说，但其实是不同维度的事情：
- 稠密 / 稀疏（Dense / Sparse） ------ 模型的架构形态
- MoE（Mixture-of-Experts） ------ 稀疏架构的具体实现
- 总参数 vs 激活参数 ------ MoE 引入的两个量
- router / top-k / expert 并行 ------ MoE 内部机制
这份文档把它们一次性串清楚。
稠密 vs 稀疏：架构层面的根本区别
2一句话定义
- 稠密 (Dense) ：模型的每个参数 都参与处理每个 token
- 稀疏 (Sparse / MoE) ：每个 token 只激活一小部分参数，其他参数当下"摆烂"
"稀疏"指的是计算稀疏------总参数全部加载到显存，但单次前向传播实际用上的参数稀稀疏疏。
想象一家咨询公司接到一个问题：
- 稠密模型 = 全员开会
公司有 70 个员工，不管什么问题，全部 70 个人都到场讨论，最后汇总意见。- 优点：每个人的知识都用上了，决策质量稳定
- 缺点：每次都得付 70 份工资（FLOPs）
- 稀疏模型 (MoE) = 派专家小组
公司有 256 个员工，但有个"前台"（router）会根据问题类型，每次只挑 8 个最对口的员工去会议室讨论，其他 248 个原地待命。- 优点：开一次会只付 8 份工资，但你的"人才储备"是 256 人
- 缺点：前台要是挑错人就翻车；248 个人虽然不开会，但工位还得占着（显存）
落到 Transformer 上
Transformer 一层 = Self-Attention + FFN(前馈网络)，FFN 占大头参数（约 2/3）。
稠密 FFN：
input → [一个大 FFN，比如 hidden_dim = 11008] → output所有 11008 个神经元都算一遍。
稀疏 FFN（MoE）：
input → router(打分) → 选 top-k 个 expert → 只算这 k 个小 FFN → 加权合并 → output
│
└─ Expert 1 (hidden_dim = 14336) ←─ 不激活
Expert 2 (hidden_dim = 14336) ←─ 激活
Expert 3 (hidden_dim = 14336) ←─ 不激活
...
Expert 8 (hidden_dim = 14336) ←─ 激活8 个并列 expert 总参数加起来比稠密 FFN 大很多，但每次只算 top-k 个。
关键直觉表
| 维度 | 稠密 | 稀疏 (MoE) |
|---|---|---|
| 总参数 | 全部参与计算 | "知识库" |
| 激活参数 | = 总参数 | ≪ 总参数 |
| 显存占用 | 按总参数算 | 按总参数算（一样大！） |
| 单 token 算力 (FLOPs) | 高 | 低 |
| 训练复杂度 | 简单稳定 | 难训（router 易崩、负载不均） |
| 小 batch 推理 | 利用率高 | expert 利用率低，吃亏 |
| 大 batch 服务 | 算力随 token 数线性涨 | 算力涨得慢，吞吐高 |
| 本地部署 | 友好 | 不友好（显存按总参数算） |
| 数据中心 | 一般 | 最佳选择（按 $/token 更划算） |
2.5 一个非常重要的反直觉点
MoE 不省显存，只省算力。
很多人以为 "MoE 激活 13B 那应该 13B 显存就能跑"------错。所有 expert 都得加载到显存里等着被 router 选中，所以 Mixtral-8x7B 跟 47B 稠密模型显存占用一样大。
省的只是 FLOPs（浮点运算次数）= 推理时间 / 训练算力。
这就是为什么：
- 数据中心爱 MoE：不是因为显存便宜（HBM 其实很贵），而是批量服务下 MoE 的 tokens/sec/$ 更高，且 expert 权重被多用户共享摊薄，而且关键的是这些成本早晚会收回来的，只是时间问题罢了，但是推理消耗的算力是固定成本，这个减少才是真正的节约。
- 本地部署反而稠密模型友好：24GB 显卡跑 13B 稠密 比跑 8x7B MoE 好得多（如果使用 MoE 架构单用户没有摊销机制，每个 expert 都得占着显存等你偶尔翻牌）
MoE 架构深入
核心机制
MoE 把 Transformer 每一层的 FFN 拆成 N 个并列的小 FFN（叫 expert），加上一个 router（路由器，也叫 gating network）：
- router 是一个轻量级网络（通常就是一层 linear），对每个 token 计算 N 个 expert 的得分
- 选 top-k 个得分最高的 expert
- 只让这 k 个 expert 处理这个 token
- 把 k 个 expert 的输出按 router 给的权重加权求和
总参数 vs 激活参数
这是 MoE 模型的两个关键指标：
- 总参数 (Total params) ：所有 expert 加起来的参数量，决定显存占用 和模型容量
- 激活参数 (Active params) ：单 token 实际经过的参数量，决定单 token FLOPs 和推理速度
典型表示法："Mixtral-8x7B" → 8 个 expert，每个约 7B；"Qwen3-235B-A22B" → 235B 总参，A22B 表示 Activated 22B。
常见的 MoE 模型对比图
| 模型 | 总参 / 激活 | top-k / 总专家 | 备注 |
|---|---|---|---|
| Mixtral-8x7B | 47B / 13B | 2 / 8 | Mistral，MoE 普及之作 |
| Mixtral-8x22B | 141B / 39B | 2 / 8 | Mistral 大版本 |
| DeepSeek-V2 | 236B / 21B | 6 / 160 + 2 共享 | 引入 fine-grained expert |
| DeepSeek-V3 / R1 | 671B / 37B | 8 / 256 + 1 共享 | 开源 SOTA，aux-loss-free balancing |
| Qwen3-235B-A22B | 235B / 22B | 8 / 128 | 阿里旗舰 |
| Qwen3-30B-A3B | 30B / 3B | 8 / 128 | 面向消费级显卡的轻量 MoE |
| Llama 4 Scout | 109B / 17B | 1 + 共享 / 16 | Meta 首次转 MoE |
| Llama 4 Maverick | 400B / 17B | 1 + 共享 / 128 | 同上 |
| Kimi K2 | 1T / 32B | 8 / 384 | 月之暗面，开源最大 MoE 之一 |
| MiniMax-M1 | 456B / 45.9B | 2 / 32 | MiniMax |
| GLM-4.5 | 355B / 32B | 8 / 160 | 智谱 |
| Hunyuan-Large | 389B / 52B | 1 / 16 + 1 共享 | 腾讯 |
| GPT-OSS-120B | 117B / 5.1B | 4 / 128 | OpenAI 开源 |
| GPT-OSS-20B | 21B / 3.6B | 4 / 32 | OpenAI 开源小版本 |
闭源（不准确，仅估计）：
- GPT-4 / 4o / 5 / Codex ------ 普遍认为是 MoE，OpenAI 不官宣（GPT-4 早期 SemiAnalysis 泄露 "8x220B、top-2"）
- Gemini 1.5 / 2.5 Pro ------ Google 官方论文明说 "Mixture-of-Experts Transformer"
- Grok-1 ------ xAI 开源时披露 314B / 8 experts / top-2
- Claude（Sonnet 4.5、Opus 4.5） ------ Anthropic 从不披露架构，业界没定论
还在坚持稠密的：
- Llama 3 全家（8B / 70B / 405B）------ Llama 4 才换 MoE
- Qwen3 稠密线（0.6B / 1.7B / 4B / 8B / 14B / 32B）------ 阿里同时维护两条线，小尺寸坚持稠密
- Mistral Small / Medium / Large（非 Mixtral 系）
- 绝大多数 <10B 的开源模型 ------ MoE 在小尺寸不划算
为什么大尺寸都转 MoE
一句话：同等推理 FLOPs 下，MoE 模型 loss 更低。 这是 Switch Transformer / GShard 论文以来反复验证的 scaling law。具体收益：
- 训练：固定算力，能塞下 10x 总参数 → 容量更大、知识更多
- 推理：激活参数小 → 单 token FLOPs 低 → 吞吐高、成本低
- 典型对比：DeepSeek-V3 总参 671B 但每 token 只算 37B，推理速度跟 30B 稠密模型一个量级，质量却接近 GPT-4 级别
代价是：
- 显存占用按总参数算，本地部署门槛高（DeepSeek-V3 fp8 也要 ~700GB）
- 训练不稳定（router 易崩、负载不均）------ DeepSeek 用 auxiliary-loss-free balancing 才搞定
- 小 batch 推理时 expert 利用率低，得靠 expert parallelism 凑 batch
top-k 是固定的，不能在推理时调
top-k 在训练时固定下来，router 学到的负载均衡是基于这个 k 的。推理时切 k 会破坏分布，质量直接崩------这是 MoE 架构的硬约束，不是工程实现选择。
expert 不是按"角色"分工，因此我们不能将其等价于不同的专家
很多人以为 expert 是"程序员、医生、律师"这种人类可解释的语义分工 ------完全不是。
- expert 是模型自学出来的隐式分工，没人告诉它"你负责代码、你负责诗歌"
- 训练完打开 expert 看权重，根本看不出它在干啥------可能 expert-1 处理"标点 + 数字 + 某种语法结构"，反人类直觉
- router 学到的是"这个 token 在这一层应该走哪几条路径让 loss 最低"，跟"这是医学问题"这种语义抽象没关系
与其说"医学问题派给医学专家"，不如说"router 在每个 token、每一层都做一次微决策"。同一句话里，"癌"字和"症"字可能走完全不同的 expert 组合。
一个 token 通常被多个 expert 共同处理
top-k 通常 ≥ 2（Mixtral top-2、DeepSeek top-8），意思是每个 token 同时走 k 条路径 ，最后按 router 给的权重加权求和：
token "癌" 进入 layer-5：
router 打分 → expert-3 (权重 0.6) + expert-7 (权重 0.4)
output = 0.6 × expert-3(token) + 0.4 × expert-7(token)DeepSeek-V3 还专门有 shared expert （每个 token 必经的公共专家），让通用知识被所有 token 共享。所以"分流后专家独占 token"的直觉是错的。
数据中心便宜的本质：摊销，不是并行
常见的错误因果链：
分流 → 并行 → 数据中心便宜 ❌
真实因果链：
jsx
expert 权重一份在显存里（成本高，但只付一次）
↓
1000 个并发用户的 token 全都路由到这些 expert
↓
每个 expert 同时处理来自不同用户的 token (batched expert computation)
↓
每个用户分摊到的"显存成本/算力成本"被 1000 摊薄
↓
$/token 降低并行不是 MoE 独有的------稠密模型也能 TP/PP/DP 并行批处理。MoE 真正省的是：
- 稠密：100 个用户来，每个都过完整 70B 参数 → 算 100 × 70B 次乘法
- MoE：100 个用户来，每个只过 13B 激活参数 → 算 100 × 13B 次乘法
- 同样的 GPU 时间能服务更多用户 → $/token 更低
MoE 多了一种专家并行 (Expert Parallelism)：把不同 expert 放不同 GPU 上。但 EP 的真正价值不是"能并行了"，而是：
- 单卡装不下整个模型时，把 expert 切到多卡
- 跨 GPU 通信开销（all-to-all）反而是 MoE 的瓶颈
本质 ：MoE 让"总参数"和"单 token 算力"解耦------数据中心可以堆很大的总参数（容量）但保持低算力（成本），这个解耦才是省钱的本质。
一句话总结
MoE 架构使用激活更少参数从而达到计算次数更少从而使其对应需要的