llm-atlas/research/MOE_RESEARCH.md

稀疏计算与 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 的专家容量定义为：

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 官方报告。

首版正文完成闸门

• 用一张图区分 total parameters、active parameters、FLOPs、weight traffic。
• 画出 route → dispatch → expert → combine 的两次 All-to-All。
• 让读者能手算 capacity factor 与 overflow。
• 把 aux loss、router z-loss、loss-free bias、Quantile Balancing 放在同一因果链。
• 单独重绘 DeepSeekMoE 细粒度与 shared expert。
• 单独推导 LatentMoE 的 d→ℓ→d。
• 交互实验室可切换 Switch、Mixtral、DeepSeekMoE/V3、LatentMoE 与 K3。
• 讲清 K3 的 RMSNorm、SiTU-GLU、QB 和 MoonEP，不把 Stable LatentMoE 缩成一行配置。
• 论文链全部指向一手来源。
• 类型、链接、交互、桌面/移动端和容器检查通过。