核心要点
负载均衡：能讲清 Top-K 路由导致的负载不均本质——每个 token 只激活 K 个专家，但路由分布偏斜使部分 Expert 过载、部分闲置，auxiliary loss 是训练侧的主手段但推理时无法动态调整
通信开销：能讲清 All-to-All 通信在跨节点 Expert 分发中的瓶颈——token 需按路由结果在节点间重分布，通信量随 Expert 数量和节点数增长，是推理延迟的主要来源
故障恢复：能讲清 Expert 级 checkpoint 与弹性恢复——Dense 模型按层切分 checkpoint，MoE 需按 Expert 粒度存储和恢复，单 Expert 故障不应触发全局重启
简要回答
Expert Parallelism 是 MoE 大规模部署的核心并行策略，三大工程挑战分别是：Top-K 路由导致 Expert 负载不均（需 capacity factor 和动态批调度应对）、All-to-All 跨节点通信成为推理延迟瓶颈（需分层并行和计算-通信重叠优化）、Expert 级 checkpoint 与弹性恢复比 Dense 模型更复杂（需 Expert 粒度异步 checkpoint 和热备副本）。
标准回答
一、负载均衡：Top-K 路由的结构性偏斜
MoE 的门控网络对每个 token 选择 Top-K 个专家，但路由分布天然不均匀——少数"热门"Expert 被高频选中，多数 Expert 利用率低。训练侧通过 auxiliary loss（负载均衡辅助损失）鼓励均匀分布，但推理部署时模型权重已固定，无法通过损失函数动态调整。
工程应对：
- 推理侧容量因子（capacity factor）：为每个 Expert 设置单批次处理上限，超出部分溢出到次优 Expert 或丢弃，避免单 Expert 成为瓶颈
- 动态批调度：按路由分布预估 Expert 负载，将路由相似的 token 聚合到同一批次，减少 Expert 间负载方差
- 无辅助损失路由（DeepSeek 路线）：用可学习的 Expert 偏置替代 auxiliary loss，直接动态调节路由概率，减小对主损失的干扰
判断均衡是否健康看两个指标：Expert 激活分布的熵和路由方差。
二、通信开销：All-to-All 是推理延迟的主要来源
Expert Parallelism 要求 token 按路由结果从当前 GPU 发送到承载目标 Expert 的 GPU——这是 All-to-All 集合通信。跨节点场景下，通信量与 Expert 数量 × 节点数成正比，在 100+ GPU 集群上容易成为推理延迟瓶颈。
工程应对：
- 通信优化库：Moonshot AI 开源的 MoonEP 提供完美平衡的 Expert 并行通信，是 Kimi K3 训练的配套基础设施；NCCL 的 All-to-All 原语也在持续优化
- 分层并行：节点内用张量并行（TP），节点间用 Expert 并行（EP），减少跨节点 All-to-All 频次
- 计算-通信重叠：将 All-to-All 与 Expert 前向计算流水线化，隐藏通信延迟
- Expert 合并/分组：将多个小 Expert 合并到同一 GPU，减少跨节点路由次数
排查顺序建议：先看 All-to-All 通信占推理总耗时的比例，再看 Expert 负载方差。
三、故障恢复：Expert 级 checkpoint 与弹性恢复
Dense 模型的 checkpoint 按层切分，故障恢复是全量重启或按层恢复。MoE 模型有数百到数千个 Expert，单 Expert 故障不应触发全局重启——需要 Expert 粒度的 checkpoint 和弹性恢复策略。
工程应对：
- Expert 级异步 checkpoint：每个 Expert 独立存储 checkpoint，故障时只恢复受影响的 Expert，其余 Expert 继续服务
- 冗余 Expert 与热备：为高频 Expert 维护热备副本，故障时自动切换，类似分布式系统的副本机制
- 梯度检查点 + Expert 恢复：训练时用梯度检查点减少显存占用，恢复时按 Expert 粒度重算丢失的梯度
- 弹性训练框架：支持动态增减 Expert 节点，故障节点退出后新节点接管其 Expert 并恢复状态
四、三个维度的关联
三个维度不是独立的：负载均衡影响通信量（路由越均匀，All-to-All 数据量越可预测）；通信瓶颈影响故障恢复时间（恢复后需重新同步 Expert 状态，通信带宽决定恢复速度）。工程上需要同时优化三者，不能只看单点。
常见误区
⚠️ 常见踩坑
误区一：以为 MoE 部署比 Dense 更省资源——MoE 省的是单 token 计算量（稀疏激活），但显存按总参数算（所有 Expert 常驻），通信开销远高于 Dense。部署门槛反而更高。
误区二：以为 auxiliary loss 能解决推理时的负载不均——auxiliary loss 是训练时的正则化手段，推理时模型权重固定，路由分布已确定，无法通过损失函数调整。推理侧需要 capacity factor 和动态批调度。
误区三：以为 All-to-All 通信可以用更快的网络硬件解决——硬件优化有帮助，但通信量随 Expert 数量和节点数增长的结构性问题，需要算法层（分层并行、计算-通信重叠）和架构层（Expert 合并）协同解决。
追问
追问 1：Kimi K3 2.8T 的 Expert Parallelism 有什么特殊之处？
Kimi K3 总参数 2.8T，是当前公开报道中参数规模最大的开源 MoE 之一。配套开源的 MoonEP 库提供完美平衡的 Expert 并行通信，是训练基础设施的核心组件。2.8T 若为稠密架构，开源生态的算力预算无法部署——总参数大、激活参数小是超大开源模型唯一可行的架构选择。MoonEP 的意义在于：Expert 并行通信优化成为 MoE 训练的第二战场，不只是模型架构本身。
追问 2：如何判断一个 MoE 部署的 Expert Parallelism 是否健康？
四个指标：1）Expert 激活分布熵——越接近均匀分布越好，熵低于阈值说明路由偏斜严重；2）All-to-All 通信占比——占推理总耗时的比例，超过 30% 说明通信成为瓶颈；3）Expert 利用率方差——各 Expert 实际处理 token 数的方差，方差越大说明负载越不均；4）故障恢复时间——单 Expert 故障后恢复到正常服务的时间，目标是从分钟级降到秒级。
追问 3：Expert Parallelism 和 Tensor Parallelism 如何配合？
分层并行是主流方案：节点内用 Tensor Parallelism（TP）切分单个 Expert 的计算，节点间用 Expert Parallelism（EP）分发不同 Expert。TP 减少单 Expert 的显存占用和计算延迟，EP 突破单卡 Expert 数量上限。两者配合的关键是减少跨节点通信频次——TP 在节点内高速互联（NVLink）完成，EP 的 All-to-All 只在节点间发生。选型判据：节点内 GPU 数和互联带宽决定 TP 度数，集群规模决定 EP 度数。
🔗 相似问题
同一考点的不同问法，换着练更稳
延伸学习
按主题分类的相关资源，便于系统复习