为什么需要专家容量呢？因为所有张量的形状在编译时是静态确定的，无法提前知道多少 token 会分配给每个专家，因此需要一个固定的容量因子
1️⃣ 考察意图
面试官想考察你对 MoE 架构底层工程实现的理解，而非仅仅背诵概念。核心是：为什么静态张量形状决定了必须引入专家容量？这背后是 GPU 编译执行与动态路由之间的根本矛盾。刁钻点在于，很多人只背了“容量因子 1.25”，却说不清为什么不能动态分配。答好了能展示你对分布式训练、计算图编译、负载均衡 trade-off 的硬实力，说明你不是只会调包，而是理解系统瓶颈。
2️⃣ 标准答
专家容量（Expert Capacity）是 MoE 中每个专家能处理的最大 token 数，定义为 (total_tokens / num_experts) * capacity_factor。其必要性源于 GPU 的静态编译特性与 MoE 动态路由之间的根本矛盾。
1. 静态张量 vs 动态路由：核心矛盾
- 静态编译：PyTorch 的
torch.compile或 XLA 在编译时，所有张量的形状（shape）必须确定。GPU 的 kernel launch 需要预先分配显存和线程网格，无法在运行时动态调整。 - 动态路由：MoE 中，每个 token 通过门控网络（gating network）被路由到 top-k 个专家，但每个专家实际收到的 token 数量是随输入变化的。例如，一个 batch 中“数学”类 token 可能集中涌向专家 3，而专家 7 可能只收到 0 个 token。
- 矛盾：如果每个专家不设容量，编译时无法知道其输入张量形状，导致编译失败或显存爆炸。因此，必须预设一个固定容量，让每个专家都接收一个形状为
[batch_size, expert_capacity, hidden_dim]的 tensor，即使部分位置是 padding。
2. 容量不足的代价：Token 丢弃（Drop）
- 当路由到某专家的 token 数超过其容量时，超出的 token 会被丢弃（drop）。这直接导致信息丢失，尤其对长尾 token（如罕见实体、复杂逻辑）影响大。
- 实际坑：在训练初期，负载极度不均衡，丢弃率可能高达 30%+，导致模型收敛慢或 loss 震荡。解法：引入 auxiliary loss（如 load balancing loss，系数 0.01）来惩罚路由不均衡，迫使门控网络更均匀地分配 token。
- 工程取舍：容量因子设为 1.0 时计算最省，但丢弃风险高；设为 1.25 时丢弃率通常 <1%，但 padding 浪费约 20% 计算。实践中，1.0-1.25 是常见区间，具体取决于负载均衡程度。
3. 容量过大的代价：Padding 浪费
- 容量因子 >1.0 时，每个专家 tensor 中会有大量 padding token（值为 0 的占位符）。这些 padding 虽然不参与计算（通过 attention mask 屏蔽），但仍需占用显存和带宽。
- 实际坑：容量因子设为 2.0 时，显存占用翻倍，且计算效率下降（因为 GPU 的 warp 利用率降低）。解法：使用 capacity-aware masking，在 expert 的 FFN 计算中跳过 padding 行，或采用 dynamic padding（仅对非 padding 行做矩阵乘法，但实现复杂）。
- trade-off：容量因子越大，丢弃率越低，但计算效率越差。最优值需通过实验确定，例如在 8 专家 MoE 上，1.25 通常是最佳平衡点。
4. 工程实现细节
- Top-2 路由：每个 token 被路由到 2 个专家，容量计算需考虑双重分配。例如，总 token 数 1024，专家数 8，容量因子 1.25，则每个专家容量为
(1024/8)*1.25 = 160，但实际每个 token 占用 2 个专家槽位，因此总容量需求为1024*2 = 2048，而总容量供给为8*160 = 1280，不足时丢弃。 - 负载均衡策略：除了 auxiliary loss，还有 Expert Choice Routing（ECR，如 Switch Transformer 的变体），让专家主动选择 token，而非 token 选专家，从而保证每个专家恰好填满容量，消除丢弃和 padding。
- 硬件适配：在 NVIDIA A100 上，专家容量需对齐到 8 的倍数（因 tensor core 要求），否则性能下降。例如，容量 160 需对齐到 168。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，GPU 静态编译要求所有张量形状在编译时确定，而 MoE 动态路由导致每个专家接收的 token 数不确定，因此必须预设一个固定容量。第二，容量不足会导致 token 丢弃，信息丢失；容量过大则引入 padding，浪费计算。第三，工程上通过容量因子（通常 1.0-1.25）和 auxiliary loss 来平衡，同时可考虑 Expert Choice Routing 等替代方案。总结一句：专家容量是静态编译与动态路由矛盾的必然产物，其设计本质是计算效率与信息完整性的 trade-off。”
4️⃣ 高频追问 & 应对
追问 1：如果容量因子设为 1.0，丢弃率很高怎么办？你有哪些具体手段降低丢弃率？
首先，调整 auxiliary loss 系数，从默认 0.01 提升到 0.05，强制门控网络更均匀分配。其次，采用 top-2 路由 时，可以引入 capacity-aware gating：在门控计算后，对每个专家按 token 的 softmax 分数排序，只保留前 capacity 个 token，丢弃分数低的。这比随机丢弃更优。最后，考虑 Expert Choice Routing：让每个专家从所有 token 中选择 top-k 个，保证容量满且无丢弃，但需额外通信开销。实际项目中，我曾在 16 专家模型上通过调 auxiliary loss 系数从 0.01 到 0.03，将丢弃率从 8% 降到 0.5%。
追问 2：专家容量和 batch size 有什么关系？如果 batch size 很小，容量因子还需要吗？
即使 batch size 很小，静态编译的矛盾依然存在。例如 batch size=1，token 数=128，专家数=8，容量因子 1.0 时每个专家容量=16。但路由可能让专家 1 收到 50 个 token，专家 2 收到 0 个，丢弃率仍高。此时容量因子可以适当降低（如 1.0），因为小 batch 下 padding 浪费更敏感。另外，小 batch 时可采用 token dropping with recomputation：丢弃的 token 在后续层重新路由，而非直接丢弃，但会增加训练时间。实践中，小 batch 下我倾向于用 Expert Choice Routing 彻底消除容量问题。
追问 3：专家容量在推理时和训练时有什么不同？推理时能否动态分配？
推理时，张量形状同样需静态确定，但推理的 batch size 通常固定（如 1），且路由模式相对稳定。因此，推理时容量因子可以设得更小（如 1.0），因为丢弃 token 的代价更低（可接受部分 token 被跳过）。但动态分配在推理时仍不可行，因为 GPU kernel 编译后形状固定。不过，推理框架（如 TensorRT）支持 dynamic shapes 的优化，但需要显式配置 shape range，且性能不如静态形状。实际部署中，我们通常用静态容量，并通过 batch padding 对齐到固定长度。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“专家容量是为了防止某个专家过载，导致显存溢出” → ✅ 正确切入：核心原因是 GPU 静态编译要求张量形状确定，而非显存溢出。显存溢出只是结果，不是原因。面试官想听的是编译原理层面的理解。
- ❌ 说“容量因子越大越好，因为丢弃率低” → ✅ 正确切入：容量因子过大会导致 padding 浪费，计算效率下降。需要 trade-off，通常 1.0-1.25 是最优区间，且需结合 auxiliary loss 和负载均衡策略。
- ❌ 说“丢弃的 token 直接忽略，不影响模型” → ✅ 正确切入：丢弃 token 导致信息丢失，尤其影响长尾 token 和复杂推理。实践中需通过 auxiliary loss 或 Expert Choice Routing 来最小化丢弃。
6️⃣ 简历呼应
- 如果你有 MoE 大模型训练项目：从实际调参经验切入，例如“我在训练 8 专家 MoE 时，发现容量因子 1.25 下丢弃率仍达 3%，通过调 auxiliary loss 系数到 0.02 并引入 capacity-aware gating，将丢弃率降到 0.1%”。展示你踩过坑并解决了。
- 如果你只做过传统 Transformer：用类比迁移，例如“传统 Transformer 中 attention 的 key/value 矩阵形状也是静态的，MoE 的专家容量类似地解决了动态路由的编译问题”。然后补充你理解静态编译与动态执行矛盾。
- 如果你是校招无项目：聚焦论文复现，例如“我复现了 Switch Transformer 的 MoE 层，在 C4 数据集上实验了不同容量因子（1.0, 1.25, 1.5），观察到丢弃率与 loss 的关系，并理解了为什么 Google 选择 1.25”。展示动手能力和论文理解。
- Switch Transformer: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity（Fedus et al., 2021）
- GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding（Lepikhin et al., 2020）
- Mixture-of-Experts with Expert Choice Routing（Zhou et al., 2022）
- 博客：The Illustrated Mixture-of-Experts（Jay Alammar）
- 工具：Megatron-LM 中的 MoE 实现（NVIDIA, 含 capacity factor 配置）