粗粒度 MoE 用少量大 expert 和 top-2；fine-grained MoE 把每个 expert 切小、把 top-k 调大，在同样的专家参数与计算预算下扩大组合数；shared expert 把公共知识从 routed experts 里剥出来；latent experts 则先把 token 投影到低维潜空间，再在潜空间里放更多 expert 与更大的 top-k。三条路线都在回答同一个问题：总参数、激活参数、显存与通信，哪一笔账可以先动。
MoE 把 FFN 换成 E 个 expert，router 为每个 token 选 K 个。总参数看 E，每 token 计算看 K，显存看总参数而不是激活参数。Mixtral 8x7B 是 47B 总参数、13B 激活，激活占 27.7%；DeepSeek-V3 是 671B 总参数、37B 激活，激活占 5.5%。
Fine-grained 的核心不是“更多 expert”，而是“同样预算下更多组合”。把每个 expert 的中间维切成 1/m，expert 数变成 mN，top-k 变成 mK，专家参数与激活计算可以保持不变。DeepSeekMoE 给的例子是 C(16,2)=120 对 C(64,8)=4,426,165,368；shared expert 则把 K_s 个 expert 设为恒开，routed 的激活数相应减 K_s，把公共知识从 routed experts 中剥离。
Latent experts 换的是维度。LatentMoE 先把 token 从 d 维投影到 ℓ 维，expert 在潜空间里计算；把 expert 数 N 与 top-k K 同时乘 α=d/ℓ（ℓ-MoE_acc 的做法；ℓ-MoE_eff 只扩 N），通信与总专家权重可以保持同一量级。95B 模型上，ℓ-MoE_acc 用 8.44B 激活参数拿到 MMLU Pro 34.91，baseline 是 29.26。代价是 down/up 投影的额外计算，且 router 与 shared 仍在 d 维；α=4 是实验选出来的，不是免费参数。
读完这节你应该知道：为什么“总参数 / 激活参数 / 显存”是三笔不同的账，以及粗粒度 MoE 为什么会逼每个 expert 学太多东西。
dense Transformer 的 FFN 对每个 token 都用同一组权重，参数量、计算量与显存大致同向增长。MoE 把 FFN 换成 E 个 expert，router 只为每个 token 选 K 个，于是总参数按 E 增长，每 token 的激活计算只按 K 增长。Mixtral 8x7B 是这条思路的粗粒度版本：8 个 expert、top-2，总参数 47B、激活 13B，总参数约为激活的 3.6 倍。
这三条式子给出三个方向：显存看总参数，计算看激活参数，通信看每个 token 要被复制到几个 expert、每个副本有多宽。MoE 让第二项变小，却不会自动让第一项变小。Mixtral §3 写得很直接：13B 激活只决定推理计算成本，服务 Mixtral 的显存成本按 47B 稀疏参数计；SMoE 的额外开销来自 routing 与“一张卡上放多个 expert”时的内存读取，更适合有 batch 的工作负载。
粗粒度的另一个问题是专家 specialization。DeepSeekMoE §3.1 的观察是：expert 数有限时，分到某个 expert 的 token 更可能覆盖多种知识，这个 expert 就不得不在同一组参数里学差异很大的东西；如果每个 token 能路由到更多 expert，知识才有机会被拆到不同 expert 里分别学习。Mixtral §5 的路由分析则给了一个反例式的提醒：在它的 8 个 expert 上，按主题看没有明显路由模式，连续 token 反而常被分到同一个 expert，这种局部性在 expert parallelism 下容易让某些 expert 过载。
未被选中的 expert 也要常驻。EP/TP 降低的是每卡 expert 权重，不是总权重；attention、embedding 与 KV cache 另算。
激活 FLOPs 约为 dense FFN 的 K/E；但 decode 的 batch 小，算术强度低，省下的 FLOPs 不一定等比例换成延迟。
每个 token 产生 K 份 expert 输入；专家不在本 rank 时，这份输入要跨卡。EP 的 all-to-all 体积与 K、hidden 维度同向。
所以“专家该多细”不是审美问题，而是预算分配问题：expert 越少，每个 expert 越难专精；expert 越多，路由、负载均衡与跨卡通信越贵。后面的 fine-grained、shared、latent 三条路线，都是在固定“总专家参数 + 激活计算”这件事上做交换。
读完这节你应该知道：粗粒度 MoE、fine-grained MoE、shared expert 各自解决了什么，又留下了什么；以及为什么 OLMoE 的受控实验会给出与 DeepSeekMoE 不完全相同的 shared 结论。
Mixtral 的每个 expert 是一个标准 FFN；对每个 token，router 在 8 个 expert 里选 2 个，输出按 gate 权重相加（§2.1）。这套配置的组合数是 C(8,2)=28（OLMoE §4.1.2）。28 并不大：在 32 层里每层只有 28 种 expert 组合，模型很难靠“换组合”表达很细的知识分工。Mixtral 的 §5 也报告，按主题看 expert 选择没有明显模式，只有 DM Mathematics 的分布略有不同；连续 token 常选同一个 expert，这种局部性在 EP 下可能造成过载，但也能被缓存利用。
DeepSeekMoE 的做法是把每个 expert FFN 的中间维缩到 1/m，于是 expert 数从 N 变成 mN；为了保持计算不变，激活的 expert 数也从 K 变成 mK（§3.1）。总专家参数不变，但组合数从 C(N,K) 变成 C(mN,mK)。论文给的例子是 N=16、K=2：原始 top-2 只有 120 种组合；每个 expert 切成 4 份后，64 个 expert 选 8 个，组合数为 4,426,165,368。
DeepSeekMoE 的验证模型是 1 shared + 63 routed、1+7 激活、每个 expert 为 0.25 倍标准 FFN（Table 7、§4.2）；16B 模型是 2 shared + 64 routed、2+6 激活（§5.1.2）；144.6B 模型（论文称 145B）是 4 shared + 128 routed、4+12 激活（Table 7）。专家越切越细，但 routed 的 top-k 也在变大，这正是组合数增长与通信/均衡成本同时上升的来源。
DeepSeekMoE 在 fine-grained 之外再隔离 K_s 个 shared expert：不管 router 怎么选，每个 token 都确定性地经过这些 shared expert；为了保持计算不变，routed experts 的激活数从 mK 减到 mK−K_s（§3.2）。直觉是：不同 token 都需要一些共同知识；如果这些知识只能由 routed experts 各自学一遍，就会产生参数冗余。shared expert 把这些公共部分集中起来，routed experts 可以更专注于差异。
DeepSeek-V3 沿用这套结构：每个 MoE 层 1 个 shared expert + 256 个 routed experts，每个 token 激活 8 个 routed（§4.2）。它的 gating 从 softmax 改成 sigmoid，并在 top-k 选择时给每个 expert 加一个 bias b_i；bias 只参与“选哪些 expert”，实际权重仍用无偏的 si,t（§2.1.2）。这是后文 aux-loss-free 均衡的核心。
但 shared 不是所有模型的共识。OLMoE 在相同激活/总参数与 FLOPs 下做了受控对比：32 routed、激活 4 的组合数是 35,960；改成 31 routed + 1 shared、激活 3，组合数只剩 4,495。论文的报告是 shared 版本 “performs slightly worse”，并认为把 1 个 routed 改成 shared 消除了近 90% 的组合（§4.1.3）。这与 DeepSeekMoE §4.4 的 shared 消融方向相反，后文会把两边数字并列。
LatentMoE 把 token 从模型 hidden 维 d 投影到潜维 ℓ：W↓ 做 down-projection，routed experts 在 ℓ 维里计算，最后 W↑ 投回 d 维；shared experts 与 router 仍在原维度（§3 Eq.1）。因为 expert 权重与 dispatch 的激活都在 ℓ 维，通信与专家权重按 d/ℓ 缩小；论文把 expert 数 N 乘 α=d/ℓ；ℓ-MoEacc 再把 top-k K 乘 α，把省下的预算换成更多组合。两个变体：ℓ-MoEeff 保持 K、降低通信与权重（准确率目标是对齐 baseline）；ℓ-MoEacc 把 K 也乘 α、保持通信与总专家权重同一量级，用更多组合换准确率（§3 Eq.2、Table 1）。
表 2-1：五种 MoE 架构的关键配置。Mixtral 行见 §3/Table 1；DeepSeekMoE 行见 §5.1.2/Table 7；DeepSeek-V3 行见 §4.2/§2.1.2；OLMoE 行见 §2；LatentMoE 行见 Table 2/Table 3/§3。激活占比与 BF16 权重由表内参数推算；BF16 权重按总参数×2 的十进制 GB 估算，不含 KV cache、激活与通信缓冲。LatentMoE 的 512/24 由 α=4 与 Table 2 的 128/6 推算（推断）。
| 模型 | 总参数 | 激活参数 | 激活占比 | 专家（shared+routed） | routed top-k | 路由 / 均衡 | BF16 权重 |
|---|---|---|---|---|---|---|---|
| Mixtral 8x7B | 47B | 13B | 27.7% | 0 + 8 | 2 | softmax top-k；论文未展开均衡损失；§5 未观察到按主题的明显路由 | 94 GB |
| DeepSeekMoE 16B | 16.4B | 2.8B | 17.1% | 2 + 64 | 6 | expert-level balance loss（§5.1.2 设 0.001）；训练不 drop token | 32.8 GB |
| DeepSeek-V3 | 671B | 37B | 5.5% | 1 + 256 | 8 | aux-loss-free bias + 序列级补充损失；不 drop token；每 token 最多 4 个节点 | 1342 GB |
| OLMoE-1B-7B | 6.9B | 1.3B | 18.8% | 0 + 64 | 8 | dropless token-choice；load balancing loss + router z-loss | 13.8 GB |
| LatentMoE 95B（acc） | 94.8B | 8.44B | 8.9% | 2（d 维）+ 512（潜空间） | 24（潜空间） | aux-loss-free + load balancing loss；α=4 | 189.6 GB |
这张表里最容易被误读的是“激活占比”。它只说明每 token 计算量的相对大小，不说明显存。DeepSeek-V3 的 5.5% 很低，但 671B 总参数仍要占 1342 GB 的 BF16 权重；Mixtral 的 27.7% 更高，但 47B 总参数只要 94 GB。反过来说，LatentMoE 的 8.9% 也不是“显存只要 8.9%”，它仍然要放 94.8B 总参数。
读完这节你应该知道：fine-grained 如何保持计算不变而扩大组合数，shared expert 如何改路由集合，latent experts 如何用低维投影换更多专家与 top-k。
设原始 MoE 有 N 个 expert、每个 expert 的 FFN 中间维为 mf，每 token 选 K 个。把每个 expert 的中间维缩到 mf/m，就得到 mN 个 fine-grained experts；为了保持激活计算不变，top-k 变成 mK。输出写成：
N 个标准 FFN，激活的非零 gate 数从 K 变成 mK。关键不是“expert 数量”本身，而是组合空间：原始 top-2 在 16 个 expert 里只有 C(16,2)=120 种组合；切成 4 份后，64 个 expert 选 8 个，组合数是 C(64,8)=4,426,165,368（§3.1）。专家参数与 FLOPs 没变，但每个 token 可以调到更细的“知识组合”。这也是为什么 fine-grained 通常伴随更大的 top-k：如果只切小而不增大 top-k，激活计算会下降，但组合数并不会按同样方式扩大。
代价也在同一处：top-k 变大意味着每个 token 要复制更多份 expert 输入，routing 与 all-to-all 的 token 数按 K 增长；expert 变小则单 expert 的 GEMM 变小，batch 小时更容易掉进权重读取主导的低算术强度区间。DeepSeekMoE 16B 明确说没有采用更细的粒度，原因是“excessively small expert sizes”可能降低计算效率（§5.1.2）。
在 fine-grained 的基础上，DeepSeekMoE 再隔离 Ks 个 shared experts。每个 token 确定性地经过这 Ks 个 expert；router 只在剩下的 mN−Ks 个 routed experts 里选 mK−Ks 个。输出是：
mK，只是其中 Ks 个固定。DeepSeek-V3 的版本把 gating 改成 sigmoid，并在选择时加 bias：
bi 只用于路由选择；门控值仍来自无偏的 si,t。shared expert 的输出直接加到 routed 输出上。shared expert 的收益在 DeepSeekMoE §4.4 有一个很直接的数字：去掉 shared、改为多激活 1 个 routed expert，Pile loss 从 1.808 升到 2.414，计算量不变。论文据此称 shared expert 捕捉了 routed experts 不共享的基础知识。反过来，OLMoE §4.1.3 在相同激活/总参数与 FLOPs 下报告 shared 版本 “performs slightly worse”，并把原因归到组合数减少：35,960 种组合变成 4,495 种。两边的模型、数据与训练预算不同，页面只并列数字，不合并成“shared 一定有用/没用”。
LatentMoE 的 routed expert 不在 d 维工作，而是在潜维 ℓ 工作。token x ∈ ℝd 先乘 W↓ ∈ ℝℓ×d，每个 routed expert 的权重是 WFC1, Wgate ∈ ℝm×ℓ 与 WFC2 ∈ ℝℓ×m，输出再乘 W↑ ∈ ℝd×ℓ 投回原维度；shared experts 与 router 仍在 d 维（§3 Eq.1）。
N′=αN、K′=αK、α=d/ℓ；shared experts 仍在 d 维。router 的分数 p′=Softmax(W′rx) 也在 d 维计算。为什么这能保持成本？routed 的 dispatch 体积与 K·d 同向；把 d 换成 ℓ 后乘 α 倍的 K，得到 K′·ℓ = (αK)·(d/α)=K·d，通信量回到同一量级。专家权重也类似：单个 expert 从 d·m 变成 ℓ·m，但 expert 数乘了 α，总专家权重可以保持同一量级（Table 1）。ℓ-MoEeff 不乘 K，所以通信与权重下降到 1/α，目标是对齐 baseline 准确率；ℓ-MoEacc 乘 K，把省下的预算换成组合数，目标是同成本下更高准确率。
实验选的压缩比是 α=4：16B 模型 d=2048、ℓ=512；95B 模型 d=4096、ℓ=1024（§4.1、Figure 5、Figure 6）。论文说压缩比 α≤4 时质量保持；α 再大，任务相关的特征秩 reff 可能被压掉。这个下界是任务相关的，没有一个通用值。
读完这节你应该知道：三笔账各自的公式，capacity factor 与 aux-loss-free 各自在哪一侧介入，以及为什么 LatentMoE 要把“专家数、top-k、维度”一起调。
表 2-1 已经给出五个模型的总参数、激活参数与 BF16 权重。把它们按同一口径拆开：总参数决定权重显存，激活参数决定每 token 计算，二者之差由 routed expert 中“没被选中”的部分构成。Mixtral 的 47B/13B 差 34B，DeepSeek-V3 的 671B/37B 差 634B；这些差额不是“免费”的，它们仍要占显存。显存估算只乘 2 字节，不含 KV cache、激活、通信缓冲与量化 scale；真实部署还要加上这些。
激活占比也不能直接当加速比。DeepSeek-V3 的 5.5% 说明每 token 只算一小部分参数，但 decode 的 batch 小，expert 权重读取与 all-to-all 固定开销会主导延迟；Mixtral §3 也提醒 SMoE 更适合有 batch 的工作负载。把 27.7%、5.5%、8.9% 放在一起排“谁更高效”，会忽略分母不同（模型规模、batch、序列长度、并行配置）。
EP 下每个 token 的 K 份 expert 输入要送到专家所在 rank；每份输入的宽度是 hidden 维 d。所以 dispatch 体积与 K·d 同向，combine 再来一遍。LatentMoE 的 ℓ-MoEacc 把 d 换成 ℓ、把 K 乘 α，K′·ℓ=K·d，通信量保持同一量级；ℓ-MoEeff 不乘 K，通信量降到 1/α，但准确率目标只是对齐 baseline（Table 1）。
DeepSeek-V3 的通信账还有拓扑约束：集群里 NVLink 约 160 GB/s，IB 约 50 GB/s，相差约 3.2 倍；因此每个 token 最多送到 4 个节点，跨节点走 IB、节点内走 NVLink，并用 20 个 SM 做通信（§3.2.2）。这说明“专家数 × top-k”不是通信账的全部，节点布局与网络带宽同样会改变结论。
Switch 式 MoE 用静态 capacity 控制每个 expert 处理多少 token：
DeepSeek-V3 走的是另一条路：不 drop token，用 aux-loss-free bias 调负载。每个 step 结束后，如果某个 expert 过载就把 bi 减 γ，欠载就加 γ；γ 在最初 14.3T token 取 0.001，最后 500B token 取 0.0。另外还有一个极小的序列级补充损失，α=0.0001，只用于防止单条序列内极端不均（§2.1.2、§4.2）。Table 5 的 228.7B 模型消融里，aux-loss-free 的 Pile BPB 从 0.656 降到 0.652，GSM8K 从 70.7 升到 74.5，但 MMLU 从 68.3 降到 67.2；论文的总结是“most benchmarks”，不是每一项都更好。
DeepSeekMoE 用的是显式 balance loss：expert-level 损失按每个 expert 的 token 比例与平均亲和度相乘，device-level 损失按每组设备的负载聚合（§3.3）。16B 模型因为所有 expert 放在同一设备，device-level 损失不用，expert-level 因子设得很小（§5.1.2）。OLMoE 则用 dropless token-choice、load balancing loss 与 router z-loss（§2）。三种做法的共同点是：均衡是训练目标或路由偏置的一部分，不是模型架构里自动成立的。
默认值来自 DeepSeek-V3 §4.2（256 routed、top-8、1 shared）；P=2.55B（见 LEDGER）由 §4.2 的 hidden 7168、expert intermediate 2048 与 MoE 层配置推算。把 N、P、top-k、S 调成 Mixtral 的 8、5.64、2、0，可得到仅专家 FFN 的 45.12B/11.28B/22.56 GFLOPs；与论文 47B/13B 的差为 attention/embedding 与取整（推断）。计算量按 2 FLOPs/激活参数/token 的常用估算；读数只算专家 FFN，不含 attention、embedding、LM head、KV cache 与通信缓冲。
组 1：N=256、P=2.55B、top-k=8、S=1。
总专家参数 = (256+1) × 2.55 = 655.35B；
每 token 激活 = (8+1) × 2.55 = 22.95B；
计算 = 2 × 22.95 = 45.90 GFLOPs；
BF16 权重 = 655.35 × 2 = 1310.70 GB。
JS 在同参数下输出 655.35 / 22.95 / 45.90 / 1310.70。
组 2：N=8、P=5.64B、top-k=2、S=0。
总专家参数 = 8 × 5.64 = 45.12B；
激活 = 2 × 5.64 = 11.28B；
计算 = 2 × 11.28 = 22.56 GFLOPs；
BF16 权重 = 45.12 × 2 = 90.24 GB。
JS 输出 45.12 / 11.28 / 22.56 / 90.24。
简化与未覆盖。只算专家 FFN：不含 attention、embedding、LM head、KV cache、router 与通信缓冲；P 是跨所有 MoE 层的单 expert 参数量，假设每层 expert 同构。DeepSeek-V3 的 37B 激活与 671B 总参数还包含 attention/embedding/dense 层，所以 655.35B/22.95B 只对应专家部分，不等于论文的 671B/37B。Mixtral 的 45.12B/11.28B 同理，论文 47B/13B 含 attention/embedding。未覆盖 shared expert 在不同 rank 的放置、EP 的 dispatch/combine、capacity factor 与 token drop。
读完这节你应该知道：三种架构在数据流上改的是哪一步，以及 shared / latent 两条支路如何绕开或改变 router 的选择集合。
把这张图落到一次前向，可以拆成五步：
bi（§2.1.2）。d 维。三种架构改的步骤不同：粗粒度改的是第 1–2 步的 E 与 K；fine-grained 改的是第 2 步的选择集合大小；shared 改的是第 2 步的“哪些 expert 不参与选择”；latent 改的是第 4 步之前插入一次 down-projection、之后插入一次 up-projection。负载均衡则发生在第 5 步之后：DeepSeek-V3 更新 bias，DeepSeekMoE/OLMoE 更新辅助损失。
读完这节你应该知道：哪些数字支持 fine-grained/shared/latent，哪些结果并不一致，以及为什么这些数字不能直接横向排榜。
DeepSeekMoE 的 2B 验证模型把总参数与激活参数对齐到 GShard：两者都是 2.0B 总参数、0.3B 激活；DeepSeekMoE 是 1 shared + 63 routed、1+7 激活，GShard 是 top-2。Table 1 的结果如下（差值为 DeepSeekMoE − GShard，Pile loss 越低越好，其余越高越好）：
表 6-1：DeepSeekMoE 2B 与 GShard 的验证结果，均训练 100B token。数字来自 Table 1；差值为本页按表内数字计算。
| 指标 | GShard | DeepSeekMoE | 差值 |
|---|---|---|---|
| Pile loss | 1.867 | 1.808 | −0.059 |
| HellaSwag（0-shot） | 50.5 | 54.8 | +4.3 |
| TriviaQA（5-shot） | 10.2 | 16.6 | +6.4 |
| HumanEval（0-shot） | 3.7 | 4.9 | +1.2 |
这组数支持“同预算下更细的组合可以更好”，但它只覆盖 2B/100B token 的验证规模。16B 模型换了更大的数据与训练预算：总参数 16.4B、激活 2.8B，每 4K token 的 FLOPs 是 74.4T；DeepSeek 7B dense 是 6.9B 激活、183.5T，按 Table 3 的 74.4T/183.5T 计算为 40.5%（Table 3 标题写 40.5%，正文多处写 about 40%），达到 comparable 性能。Table 3 里 Pile BPB 是 0.74 对 0.75，HellaSwag 是 77.1 对 75.4；这些是具体任务数字，不是“全面超过”。
DeepSeekMoE §4.4 的 shared 消融是这页最强的单点数字：去掉 shared、改为多激活 1 个 routed expert，计算量不变，Pile loss 从 1.808 升到 2.414（差 0.606）。这说明在这个 2B 模型里，shared expert 捕捉到的知识不能由多选一个 routed expert 替代。
OLMoE §4.1.3 的受控实验给出相反方向：在相同激活/总参数与 FLOPs 下，32 routed、激活 4 与 31 routed + 1 shared、激活 3 的表现相近，shared 版本 “performs slightly worse”；组合数从 35,960 降到 4,495。论文认为 shared 把 1 个 routed 从选择集合里拿走，消除了近 90% 的组合，这个损失可能抵消了“集中公共知识”的收益。两篇的模型规模、数据、训练预算与 shared 比例都不同，页面并列，不合并成单一结论。
LatentMoE 在 95B 总参数、8B 激活的模型上比较 baseline 与两个变体；三者的总参数都在 94.4B–94.8B，ℓ-MoEacc 的激活参数是 8.44B，baseline 是 8.47B。Table 3：
表 6-2：LatentMoE 95B 模型在 300B token horizon 的下游准确率。数字转录自 Table 3；Code 为 HumanEval/HumanEval+/MBPP/MBPP+ 平均，Math 为 GSM8K CoT/MATH-500 平均，Commonsense 为 RACE/ARC-Challenge/HellaSwag/Winogrande 平均（表注）。
| 模型 | 激活参数 | 总参数 | MMLU Pro | MMLU | Code | Math | Commonsense |
|---|---|---|---|---|---|---|---|
| Baseline | 8.47B | 94.4B | 29.26 | 58.95 | 40.33 | 64.39 | 74.32 |
| ℓ-MoE_acc | 8.44B | 94.8B | 34.91 | 62.23 | 41.50 | 64.88 | 75.18 |
| ℓ-MoE_eff | 5.62B | 94.8B | 34.75 | 61.06 | 40.68 | 63.61 | 73.72 |
相对 baseline，ℓ-MoEacc 的绝对差是：MMLU Pro +5.65、MMLU +3.28、Code +1.17、Math +0.49、Commonsense +0.86。这些是分数点差，不是相对百分比；且 active 参数只差 0.03B（8.44 对 8.47），所以不能把增益归给“激活了更多参数”。ℓ-MoEeff 用 5.62B 激活也拿到 MMLU Pro 34.75、MMLU 61.06，说明“降通信/降权重”与“同成本提准确率”是两个不同变体，不能把两者的收益相加。
OLMoE §4.1.2 把 expert 数与 FFN 维一起调，保持激活/总参数与计算不变：8 个 expert、激活 1 个，组合数 8；16 个 expert、激活 4 个，组合数 1,820；32 个 expert、激活 4 个，组合数 35,960；64 个 expert、激活 8 个，组合数 4,426,165,368。论文报告 8→32 时 HellaSwag/MMLU 约 10% 的改善，32→64 只有 1–2%（原文未说明相对/绝对口径），页面照原文并列。这说明粒度有收益，但边际收益递减。
特化方面，Mixtral §5 在 8 个 expert 上没有观察到按主题的明显路由模式；OLMoE §5.3 重新分析 Mixtral 也报告“little domain specialization”，而 OLMoE 的 64 个 expert 里有明显高于/低于随机基线的领域专家（例如 arXiv 在第 0 层的第一个 expert 接近 100% 特化）。两篇的模型、专家数与分析方法不同，页面只并列观察，不把“专家更多”直接等同于“特化更强”。
不要把 5.65、4.3、10% 放在一起比。5.65 是 LatentMoE 95B 的 MMLU Pro 点差；4.3 是 DeepSeekMoE 2B 的 HellaSwag 点差；10% 是 OLMoE 在 130B token 附近的改善（原文未说相对/绝对）。三者的模型、数据、指标与训练预算都不同，页面并列是为了说明不同层面的收益，不是排一个加速榜。
读完这节你应该知道：这些架构在什么条件下会把收益吐回去，以及哪些结论只有单一来源。
DeepSeekMoE 16B 没有采用更细粒度，原因是“excessively small expert sizes”可能降低计算效率（§5.1.2）。top-k 变大还会增加 dispatch/combine 的 token 数。
DeepSeekMoE §4.4 的 shared 消融很强；OLMoE §4.1.3 的受控实验里 shared 略差。模型、数据与 shared 比例不同，不能把一边的结论直接搬到另一边。
LatentMoE 的 95B 结果来自一篇 v1 技术报告；α≤4 是实验结论，潜维下界 reff 取决于任务。摘要称已被 Nemotron-3 Super/Ultra 采用，本页未独立验证这条采用声明。
latent experts 已纳入，但边界要写清。本页用 LatentMoE（arXiv 2601.18089 v1）作为“Latent Experts”的一手来源：它的 Eq.1–2 定义了 down-projection、潜空间 routed experts 与 up-projection，Table 1 给出成本口径，Table 3 给出 95B 下游数字。它不是在 Mixtral/DeepSeekMoE 上做的一个小改动，而是另一套参数化；页面没有把它的 95B 数字外推到更小或更大规模。α=4 是论文在 16B 与 95B 上验证的选择，不是所有模型的默认值；若 ℓ 低于任务的特征秩 r_eff（即压缩到 r_eff 以下），压缩会丢信息。
capacity factor 与 token drop 是训练与推理共用的容量机制。Switch §2.2 Eq.3 的静态容量公式按 batch 与 expert 数算出每个 expert 的容量，超出的 token 经残差跳过；§2.2 同时写明 routing decisions 发生在 training and inference，所以这套容量机制不是训练侧独有。是否 drop 取决于具体实现：DeepSeek-V3 明确训练与推理都不 drop token（§2.1.2），DeepSeekMoE 16B 也写训练不 drop（§5.1.2）。不要把 Switch 的容量/丢弃行为直接套到这些模型的推理上，也不要把“不 drop”当成所有 MoE 的默认行为；不同训练框架与并行策略可能不同。
显存仍然看总参数。表 2-1 的 1342 GB、189.6 GB 只是 BF16 权重的十进制估算，不含 KV cache、激活、通信缓冲、量化 scale 与冗余 expert。EP/TP 降低每卡权重，但不降低总权重；attention 与 KV cache 不随 expert 数按比例缩小。判断“一张卡能不能放下”时，必须把这几项一起算，不能只看激活参数占比。
路由特化的证据并不一致。Mixtral §5 在 8 个 expert 上未观察到按主题的明显模式；OLMoE §5.3 在 64 个 expert 上报告了明显的领域特化，§5.4 报告了词表特化，并认为 Mixtral 的领域特化较弱。两篇的专家数、训练数据与分析口径不同，页面只并列观察；不能据此断言“fine-grained 一定带来更强特化”，也不能断言“粗粒度一定没有特化”。
最后，别把不同表的收益相加。DeepSeekMoE 的 40.5% 在 Table 3 标题直接给出，也与 16B/2T token 的 74.4T/183.5T 复算一致；LatentMoE 的 +5.65 来自 95B/300B token 的 Table 3；OLMoE 的 ~10% 来自 130B token 的粒度消融；Mixtral 的 27.7% 只是 13B/47B 的激活占比。它们的分母、模型规模、训练预算与评测协议都不同，页面并列是为了拆账，不是为了横比。