稀疏模型与 MoE
稀疏模型与 MoE
相关来源
- capability-density-research-2026-04
“稀疏/稠密"在现代 LLM 语境里几乎等同于 “MoE / 非 MoE”，不是传统 ML 里权重稀疏化那个意思。理解这个区分的关键，是把总参数量和激活参数量拆开看——两者对应完全不同的资源消耗。
稠密：三者绑死
Llama 3 70B、Qwen 2.5 72B、Mistral 7B 这些都是 dense 模型。每来一个 token，前向传播要把 70B 全部权重读一遍、算一遍。参数量 = 算力量 = 显存量，三者绑死。
这是最直观的情况：看到 70B 就知道每生成一个 token 需要约 140 GFLOPs（2× 参数经验公式），需要从显存读 70B × 2 bytes = 140 GB（FP16）。
稀疏 (MoE)：每个 token 只用一小撮参数
MoE 的思路是把 Transformer 里最胖的 FFN 层拆成很多并列的小 FFN（expert），前面加一个 router，根据当前 token 选 top-k 个 expert 来算，其他 expert 对这个 token 完全不贡献。
典型的参数标注是 总参 / 激活参：
| 模型 | 总参 / 激活 | expert 配置 |
|---|---|---|
| DeepSeek-R1 | 671B / 37B | 256 expert，每 token 选 8 |
| Qwen3-235B-A22B | 235B / 22B | — |
| Qwen3-30B-A3B | 30B / 3B | 后缀 A3B = Activated 3B |
| Mixtral 8×7B | 47B / 13B | 8 expert，选 2 |
这两个数字对应完全不同的资源：
| 资源 | 看哪个 |
|---|---|
| 显存（load 权重） | 总参数 |
| 每 token FLOPs | 激活参数 |
| 显存带宽（decode） | 激活参数 |
| 能力上限 | 跟总参数相关，但不是 1:1 |
DeepSeek-R1 671B 需要 ~1.3 TB 显存装权重（FP16），但每生成一个 token 的算力只相当于一个 37B dense 模型。它是一个"能力像 671B、算力像 37B、显存像 671B” 的东西。
几何平均：MoE 的隐性兑换率
tip: 关键经验公式 MoE 的能力 ≈ 一个参数量为 √(总参 × 激活) 的 dense 模型
直觉上会觉得 “MoE 应该能力接近激活参数规模”，实际不是。经验规律（来自 Switch Transformer、Mixtral、DeepSeek-V2 论文）是这个几何平均：
- DeepSeek-R1 671B/37B → √(671 × 37) ≈ 157B 等效 dense
- Qwen3-235B-A22B → √(235 × 22) ≈ 72B 等效 dense
- Qwen3-30B-A3B → √(30 × 3) ≈ 9.5B 等效 dense
- Mixtral 8×7B → √(47 × 13) ≈ 25B 等效 dense
对照实际 benchmark 看，这个规律相当准。Qwen3-30B-A3B 的综合分数就在 Qwen2.5-14B 附近——用 ~10B dense 的算力、30B dense 的显存，做出来 ~10B dense 的能力。
为什么 MoE 还是划算
既然 30B-A3B 只等效于 9.5B dense，为什么不直接训一个 9.5B dense？因为 training compute 和 serving cost 的口径不同：
训练便宜：MoE 训练 FLOPs 按激活参数算，30B-A3B 的训练成本只相当于 3B dense。用 3B 的训练成本，做到 9.5B 的能力——这是 3× 的 capability-per-training-FLOP。
解码快：解码是 memory-bound 的（见 arithmetic-intensity），每个 token 的延迟主要取决于把要用的权重从 HBM 读到 SM 的时间。MoE 每个 token 只读激活的 expert，所以单 token 延迟看起来像一个 3B dense。
Prefill 收益小：prefill 是 compute-bound 的，MoE 的节省不明显——多个 token 往往激活不同 expert 集合，最差情况接近把所有 expert 都用上。
warning: 反直觉：MoE 对本地部署反而不划算 MoE 的 sweet spot 是"训练便宜 + 解码快 + 但部署显存贵"。对大厂（显存充足）是明显胜利；对本地部署（显存稀缺）宁愿要一个装得下的 14B dense，也不要装不下的 30B/3B MoE。
代价：不稳定和通信
MoE 不是白捡的：
- 训练不稳定：router 会退化（所有 token 往少数 expert 跑），需要 load balancing loss、expert dropout、DeepSeek-V2 的 auxiliary-loss-free balancing 等一堆技巧。
- Batch 内 expert 分布不均：同一 batch 里不同 token 激活不同 expert，GPU kernel 要么 padding（浪费）要么做复杂的 all-to-all 通信。
- Expert parallelism 下的通信开销：token 要在 GPU 之间穿梭找自己的 expert，all-to-all 是 MoE serving 最大的 overhead 之一——moe-inference 详细讨论了 decode 阶段针对这个的 kernel 级优化。
趋势：Dense 正在变成小模型的专利
2025 年之后前沿开源模型几乎全是 MoE：Qwen3 系列把 MoE 当默认架构（30B-A3B、235B-A22B），只有 <14B 的型号保留 dense。原因是 dense 在小尺度下工程简单、训练稳定、serving 无 all-to-all 开销；但一旦参数量往上堆，MoE 的 training FLOPs 优势会碾压 dense。
对推理优化的含义：MoE 改变了 “memory-bound vs compute-bound” 的平衡点。Dense 的优化重点是 GEMM kernel 和 KV Cache 管理；MoE 多了两个新战场——router / dispatch 的 kernel 融合 和 expert parallelism 的 all-to-all 调度。SGLang 里 fused_moe 这条线的工作就是在解这个，详见 moe-inference。
和 Densing Law 的关系
MoE 是提升 智力密度的一个正交维度——它不在 Densing Law 原始拟合的模型池子里，但在 2025 年成了前沿模型继续压缩"每参数成本"的主要手段。
graph TD
A[MoE 模型] --> B[总参数]
A --> C[激活参数]
B --> D[显存成本]
B --> E[能力上限<br/>几何平均]
C --> E
C --> F[Decode 速度]
C --> G[训练 FLOPs]
E --> H[≈ √总参×激活<br/>的 dense 模型]