wuyang
160 lines
9.3 KiB
Markdown
160 lines
9.3 KiB
Markdown
# 稀疏计算与 MoE 研究账本
|
||
|
||
最后核验：2026-07-28
|
||
|
||
## 教学主线
|
||
|
||
MoE 不能只写成“更多参数、较少计算”。本专题固定拆成六张账单：
|
||
|
||
1. **容量**：模型一共存了多少参数。
|
||
2. **激活计算**：每个 Token 实际经过多少专家参数。
|
||
3. **路由**：谁决定 Token 去哪里，选择是 top-1、top-2 还是 top-k。
|
||
4. **负载**：专家收到的 Token 是否均匀，溢出时是否丢 Token。
|
||
5. **通信**：专家分散在不同设备后，dispatch / combine 两次 All-to-All 搬多少数据。
|
||
6. **稳定性**：硬路由、router logits、极稀疏潜空间链怎样影响训练。
|
||
|
||
核心因果链：
|
||
|
||
> 稠密 FFN 把容量与每 Token 算力绑死
|
||
> → 软门控专家学会分工，但所有专家仍可能参与
|
||
> → 稀疏 top-k 让条件计算进入大规模模型
|
||
> → Transformer MoE 把 FFN 专家分到设备上
|
||
> → 容量、掉 Token、负载和 All-to-All 成为新瓶颈
|
||
> → DeepSeek 细分专家、隔离共享知识，并限制跨设备路由
|
||
> → 无辅助损失 bias 把均衡移出主梯度
|
||
> → LatentMoE 压缩路由载荷与专家宽度
|
||
> → K3 在 896 选 16 的极稀疏区间进一步解决激活爆炸、bias 更新和执行不均。
|
||
|
||
## 本地一手材料
|
||
|
||
PDF 与文本只作本地研究缓存，受 `.gitignore` 排除；公开仓库仅提交本账本和 canonical URL。
|
||
|
||
| ID | 来源 | 本地页数 | 本轮用途 |
|
||
|---|---|---:|---|
|
||
| `1701.06538` | Sparsely-Gated MoE | 19 | Noisy Top-k 与现代稀疏门控起点 |
|
||
| `2006.16668` | GShard | 35 | Transformer MoE、自动切分与 Top-2 |
|
||
| `2101.03961` | Switch Transformers | 40 | Top-1、capacity factor、drop 与 EP |
|
||
| `2202.08906` | ST-MoE | 38 | router z-loss、稳定性与迁移 |
|
||
| `2202.09368` | Expert Choice | 14 | 专家选 Token 的负载均衡分支 |
|
||
| `2401.04088` | Mixtral of Experts | 13 | 社区可运行的 8 选 2 MoE |
|
||
| `2401.06066` | DeepSeekMoE | 33 | 细粒度专家与共享专家 |
|
||
| `2408.15664` | Auxiliary-Loss-Free Balancing | 14 | expert bias 与干扰梯度 |
|
||
| `2412.19437` | DeepSeek-V3 | 53 | 256 选 8、node limit、系统协同 |
|
||
| `2601.18089` | LatentMoE | 18 | 潜空间专家、带宽与通信 |
|
||
| `2607.24653` | Kimi K3 | 47 | Stable LatentMoE、QB 与 MoonEP |
|
||
|
||
补充复用：
|
||
|
||
- DeepSeek-V2 `2405.04434`：本地缓存位于 `research/sources/long-context/`。
|
||
- Kimi K3 原报告：`research/sources/kimi-k3/k3_tech_report.*`。
|
||
|
||
## 已核验的关键结论
|
||
|
||
### Switch：capacity factor 不是模型容量
|
||
|
||
Switch 的专家容量定义为：
|
||
|
||
```text
|
||
expert capacity = tokens per batch / number of experts × capacity factor
|
||
```
|
||
|
||
- 它是每个专家这一批最多能处理多少 Token，不是专家参数量。
|
||
- 大于 1 的 capacity factor 提供负载缓冲。
|
||
- 专家溢出时，Switch 跳过专家计算并让表示沿残差路径进入下一层。
|
||
- capacity factor 增大也会增加 padding、计算、激活内存和通信。
|
||
- 论文报告在其主要实验中 dropped tokens 通常低于 1%，不可外推为所有 MoE。
|
||
|
||
### ST-MoE：稳定不等于均衡
|
||
|
||
- Load-balancing loss 管“专家是否被均匀使用”。
|
||
- Router z-loss 管“进入 router softmax 的 logits 是否过大”。
|
||
- ST-MoE 的公式惩罚每个 Token router log-partition 的平方。
|
||
- 论文的稳定性研究使用训练 CF=1.25、评估 CF=2.0，并令 z-loss 系数 `0.001`。
|
||
- 因而 z-loss 不能被写成另一种负载均衡损失。
|
||
|
||
### DeepSeekMoE：同计算预算下切得更细
|
||
|
||
- 传统配置有 `N` 个专家、激活 `K` 个。
|
||
- DeepSeekMoE 把每个 FFN 专家沿中间维切成 `m` 个更小专家，总数成为 `mN`，激活数成为 `mK`，保持总专家参数与激活计算近似不变。
|
||
- 论文示例：`N=16, K=2` 只有 `C(16,2)=120` 种组合；切成 `64` 个小专家并激活 `8` 个后，组合数为 `C(64,8)=4,426,165,368`。
|
||
- Shared expert isolation 让共享专家始终执行，承载共性变换；路由专家更专注于差异知识。
|
||
- 2B 验证模型为 1 个共享专家 + 63 个路由专家，其中每 Token 激活 1+7。
|
||
- 禁用共享专家并多激活一个路由专家时，论文的 Pile loss 从 1.808 上升到 2.414；这是该实验设置下的证据，不是通用常数。
|
||
|
||
### Loss-Free / V3：selection 与 mixture weight 分开
|
||
|
||
- 原始 affinity score 为 `s`，expert bias 为 `b`。
|
||
- `s+b` 只用于决定 top-k；最终混合专家输出的权重仍来自原始 `s`。
|
||
- 因此 bias 调整 dispatch，不向语言建模参数引入 auxiliary-loss 的干扰梯度。
|
||
- 原方法按上一步负载以固定步长更新 bias；步长过小反应慢、过大会振荡。
|
||
- DeepSeek-V3：671B 总参数、37B 激活；每个 MoE 层 1 shared + 256 routed，激活 8 routed；每 Token 最多发往 4 个节点。
|
||
- V3 主要使用 auxiliary-loss-free 策略，但仍保留系数极小的 sequence-wise balance loss 防止单序列极端失衡。正文必须保留这个边界，不能简写为“完全没有任何辅助损失”。
|
||
- V3 报告称训练和推理都不 drop Token；这是其负载均衡与部署策略下的模型报告事实。
|
||
|
||
### LatentMoE：省下的是路由宽度与专家权重流量
|
||
|
||
- 标准 MoE 以模型宽度 `d` dispatch Token，并让 routed expert 在 `d` 宽度上计算。
|
||
- LatentMoE 先下投影到 `ℓ<d`，在 latent space dispatch、计算和 combine，再上投影回 `d`。
|
||
- 共享专家仍可保留全宽路径。
|
||
- 原论文称 routed parameter load 与 All-to-All traffic 可按 `d/ℓ` 比例降低。
|
||
- `ℓ-MoE_eff` 主要把节省换成更多总专家；`ℓ-MoE_acc` 同时扩大总专家数与 top-k，以近似固定推理成本换精度，论文推荐后者作为 Pareto 方案。
|
||
- 论文在 16B/2B active 与 95B/8B active 模型上验证，并把压缩比 `α=d/ℓ=4` 作为主要后续设置；“4× 可行”仍是该实验范围内的结论。
|
||
- 论文中万亿参数 Kimi-K2 serving 比较来自性能模拟器与 effective-parameter construction，不是真实生产 A/B 基准。
|
||
|
||
### K3：Stable LatentMoE 的“Stable”有明确内容
|
||
|
||
K3 报告给出的配置：
|
||
|
||
- 2.78T 总参数，104.2B 激活参数。
|
||
- 896 个 routed experts，每 Token 激活 16 个。
|
||
- 2 个 full-width shared experts。
|
||
- hidden dimension 7168，latent MoE dimension 3584。
|
||
- 每个 expert 的 MoE hidden dimension 3072。
|
||
|
||
从 LatentMoE 到 Stable LatentMoE 的三项增量：
|
||
|
||
1. routed expert 聚合后、上投影前加入 RMSNorm；
|
||
2. 用有界的 SiTU-GLU 抑制连续矩阵乘链中的内部激活爆炸；
|
||
3. 用 Quantile Balancing 替代固定步长 bias 更新。
|
||
|
||
Quantile Balancing：
|
||
|
||
- 每批 `m` 个 Token、`n` 个专家、top-k 时，目标负载为 `q=mk/n`。
|
||
- 先算 Top-(k+1)，第 `k+1` 个分数给出每个 Token 进入 top-k 的 cutoff。
|
||
- 对每个专家计算其 score 相对各 Token cutoff 的 margin，并取 `(1-k/n)` quantile 得到下一步 bias。
|
||
- 更新只在下一训练步生效，避免用当前批的未来 Token 改当前路由。
|
||
- 大规模实现不聚集全部 margin，而用每专家直方图 + 一次 all-reduce 估计全局 quantile。
|
||
- 最终 bias 在推理阶段冻结。
|
||
|
||
### MoonEP：算法均衡之后还有执行均衡
|
||
|
||
- QB 使专家层面的目标负载更均衡，但专家部署到 EP ranks 后仍要解决设备执行不均。
|
||
- MoonEP 为当前 micro-batch 与层在线规划 redundant experts。
|
||
- K3 报告证明每 rank 预留至多 `E/R` 个冗余专家槽即可保证存在平衡计划。
|
||
- 每个 rank 最终收到完全相同的 `S×K` Token 槽，形成 static shapes，消除每层 host sync。
|
||
- fused permute/unpermute 让 Token 直接进入远端 expert-grouped buffer，减少中间 copy。
|
||
- 这是模型路由、通信、内存与 kernel 调度的系统协同，不能只归功于 router 算法。
|
||
|
||
## 关键边界
|
||
|
||
- 总参数与激活参数口径可能是否包含 embedding、attention、shared expert；跨模型比较必须沿用各报告口径。
|
||
- “激活专家比例 K/N”不等于“激活参数比例”，因为 attention、共享专家、投影和 embedding 仍是稠密路径。
|
||
- 理论 FLOPs 不直接等于端到端延迟；小 batch 常受权重带宽限制，大 EP 常受 All-to-All 限制。
|
||
- `C(N,K)` 只展示组合空间上限，不证明模型真的学到同等数量的有意义专业化模式。
|
||
- Expert Choice 可实现专家侧固定容量，但对 causal LM 可能泄露同一 chunk 中未来 Token 对前面 Token 路由的影响；Loss-Free 论文给出明确讨论。
|
||
- K3 的 104B activated parameters 不应被误写成 16/896×2.8T。
|
||
- Grok CLI 只用于扩大候选论文与检查遗漏；以上机制和数字均回查原论文或 K3 官方报告。
|
||
|
||
## 首版正文完成闸门
|
||
|
||
- [x] 用一张图区分 total parameters、active parameters、FLOPs、weight traffic。
|
||
- [x] 画出 route → dispatch → expert → combine 的两次 All-to-All。
|
||
- [x] 让读者能手算 capacity factor 与 overflow。
|
||
- [x] 把 aux loss、router z-loss、loss-free bias、Quantile Balancing 放在同一因果链。
|
||
- [x] 单独重绘 DeepSeekMoE 细粒度与 shared expert。
|
||
- [x] 单独推导 LatentMoE 的 `d→ℓ→d`。
|
||
- [x] 交互实验室可切换 Switch、Mixtral、DeepSeekMoE/V3、LatentMoE 与 K3。
|
||
- [x] 讲清 K3 的 RMSNorm、SiTU-GLU、QB 和 MoonEP，不把 Stable LatentMoE 缩成一行配置。
|
||
- [x] 论文链全部指向一手来源。
|
||
- [x] 类型、链接、交互、桌面/移动端和容器检查通过。
|