Q：推理时 Expert Parallelism 和训练时有什么区别？**
P2 · llm_training
🏷 标签：expert-parallelism, moe, training, inference, distributed
1️⃣ 考察意图
面试官想考察你对 MoE 模型分布式并行策略在训练与推理两个阶段差异的深度理解，而非简单背诵概念。刁钻点在于：训练时 EP 是“计算-通信-计算”的流水线，需处理梯度同步和激活存储；推理时 EP 则变成“动态路由+负载均衡”的实时调度问题。答好了能展示你对分布式系统、内存管理和工程取舍的硬实力，比如能说出训练用 all-to-all 通信梯度、推理用 token 分发收集，并点出负载不均衡的坑。
2️⃣ 标准答
Expert Parallelism（EP）在训练和推理中的核心差异在于目标不同：训练追求高吞吐和梯度同步，推理追求低延迟和动态负载适应。下面从通信模式、内存管理、负载均衡、部署优化四个维度展开。
通信模式
- 训练时：每个 token 经门控网络路由到 top-2 专家，前向需 all-to-all 通信分发 token，反向需 all-to-all 通信聚合梯度。通信量巨大，因为每个专家需同步其参数梯度（如 Mixtral 8x7B 每层 8 个专家，每个专家 7B 参数，梯度 all-reduce 需跨所有专家卡）。实际中常用分组 all-to-all 优化，但通信开销仍占训练时间的 30-50%。
- 推理时：仅前向，无需梯度同步。通信模式简化为：门控网络将 token 分发到对应专家（all-to-all），专家计算后结果收集回原卡（all-to-all）。通信量小得多，因为只传输 token 嵌入（如 4096 维），而非梯度。但需注意：动态路由导致每批 token 分布不同，通信模式不可预测，需用异步通信（如 NCCL 的 P2P）减少等待。
内存管理
- 训练时：必须存储中间激活（如 attention 的 QKV、FFN 的中间层输出）用于反向传播。例如，Mixtral 8x7B 每层专家 FFN 的中间激活约 2.5GB（batch=1, seq=4096），8 个专家并行时总激活达 20GB。这迫使使用激活重计算（activation recomputation）或混合精度训练（FP16/BF16）来节省显存，但会增加计算开销。
- 推理时：无需反向传播，中间激活可即时释放。显存主要被模型权重和 KV cache 占用。例如，推理时每个专家权重约 14GB（FP16），8 个专家共 112GB，但通过专家卸载（expert offloading）可将不活跃专家移到 CPU，仅保留活跃专家在 GPU，显存占用可降低 50% 以上。
负载均衡
- 训练时：通过辅助损失（auxiliary loss）强制门控网络均匀分配 token 到各专家，确保每张卡计算负载相近。例如，Switch Transformer 使用 load balancing loss，系数设为 0.01，避免某些专家过载。但训练初期仍可能出现专家坍塌（expert collapse），即少数专家处理大部分 token，需用专家容量（expert capacity）限制每个专家最大 token 数，超出的 token 丢弃或重路由。
- 推理时：无法依赖辅助损失（因为模型已固定），负载完全由输入分布决定。实际中常遇到热点专家（hot expert），如“the”这类高频词集中路由到同一专家。解法包括：动态专家复制（dynamic expert replication），将热点专家复制到多张卡；随机路由（random routing），以概率将部分 token 路由到次优专家，牺牲精度换取负载均衡。
部署优化
- 训练时：关注吞吐量，常用流水线并行（PP）与 EP 结合，如 DeepSpeed-MoE 将专家分布在多个节点，每个节点内用 PP 减少通信。训练时专家权重静态分配，每张卡固定负责几个专家，便于梯度同步。
- 推理时：关注延迟和吞吐的平衡。常用专家放置（expert placement）优化，将高频专家放在同一张卡以减少跨卡通信；或用缓存（如 vLLM 的 prefix caching）缓存专家输出，避免重复计算。实际落地坑：动态批处理（dynamic batching）中，不同请求的 token 路由到不同专家，导致 GPU 利用率波动，需用请求调度（request scheduling）合并相似路由的请求。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从通信模式、内存管理、负载均衡三个层面回答。通信上，训练需 all-to-all 同步梯度，推理只需 token 分发收集；内存上，训练要存中间激活，推理可释放；负载上，训练用辅助损失强制均衡，推理需动态复制热点专家。总结一句：训练 EP 是计算-通信流水线，推理 EP 是动态路由实时调度。”
4️⃣ 高频追问 & 应对
追问 1：推理时如何解决热点专家导致的负载不均衡？
应对策略：核心是动态复制和随机路由。动态复制：监控每个专家的 token 数，当某专家超过阈值（如平均值的 2 倍），将其权重复制到空闲 GPU，并用一致性哈希分配 token。随机路由：以 5% 概率将 token 路由到次优专家，牺牲 0.1% 精度换取负载均衡。实际中，DeepSpeed-MoE 推理用专家容量限制，超出的 token 回退到 dense 层，但会增加延迟。更优解是请求级调度，将路由到同一专家的请求合并成 batch，减少跨卡通信。
追问 2：训练时 EP 的通信瓶颈如何优化？
应对策略：主要瓶颈在 all-to-all 通信。优化方法：1）分组 all-to-all，将专家按拓扑分组（如 8 卡一组），组内 all-to-all，组间 all-reduce，减少跨节点通信。2）计算-通信重叠，在专家计算时预取下一批 token，如 DeepSpeed 的 MoE 使用异步 all-to-all，将通信与计算流水线化。3）梯度压缩，对专家梯度用 1-bit 量化（如 1-bit Adam），通信量减少 90%，但需额外解压缩开销。实测在 64 卡上，这些优化可将通信占比从 40% 降到 15%。
追问 3：训练和推理的 EP 在显存分配上有什么具体差异？
应对策略：训练时，显存分为模型权重（14GB/专家）、优化器状态（Adam 需 28GB/专家）、中间激活（20GB/层）。推理时，显存主要为模型权重（14GB/专家）和 KV cache（如 8GB/请求）。关键差异：训练时需预留梯度缓冲区（14GB/专家），推理时可释放；训练时中间激活是动态分配的，推理时只需静态分配 KV cache。实际中，训练用ZeRO-3将优化器状态分片到多卡，推理用专家卸载将不活跃专家移到 CPU，显存节省 60% 以上。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“训练和推理的 EP 只是有没有反向传播的区别” → ✅ 正确切入：除了反向传播，通信模式（梯度同步 vs token 分发）、内存管理（激活存储 vs 释放）、负载均衡（辅助损失 vs 动态复制）都有本质差异，需分维度对比。
- ❌ 说“推理时 EP 不需要考虑负载均衡，因为模型已固定” → ✅ 正确切入：推理时负载由输入分布决定，热点专家会导致 GPU 利用率不均，必须用动态复制或随机路由处理，否则延迟会飙升。
- ❌ 说“训练时 EP 的通信开销可以忽略” → ✅ 正确切入：训练时 all-to-all 通信占 30-50% 时间，需用分组 all-to-all 和计算-通信重叠优化，否则吞吐量会大幅下降。
6️⃣ 简历呼应
- 如果你有 MoE 训练项目：从训练时 EP 的通信优化切入，比如“我在 64 卡上部署 Mixtral 8x7B 训练，用分组 all-to-all 将通信占比从 40% 降到 15%”，并对比推理时动态负载的挑战。
- 如果你只做过传统分布式训练（如 DDP/FSDP）：用 DDP 的梯度同步类比训练 EP 的 all-to-all，再对比推理 EP 的 token 分发，强调 MoE 的“动态路由”特性。
- 如果你是校招无项目：聚焦论文复现，比如“我复现了 Switch Transformer 的 EP 实现，在 8 卡上对比了训练和推理的通信开销”，并给出具体数字（如训练时通信 30ms vs 推理时 5ms）。
7️⃣ 延伸阅读
- 《Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity》
- 《GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding》
- 《DeepSpeed-MoE: Advancing Mixture-of-Experts Inference and Training to Power Next-Generation AI Scale》
- 《Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM》
- 《vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention》