跳转至

Expert Parallel 推理

推理专家并行 (Expert Parallel, EP) 将 MoE 专家分布到设备，并处理 token 的跨卡路由。与训练不同，推理阶段更关注请求时延和吞吐，尤其是 all-to-all 通信与专家负载不均对尾延迟的影响。

推理专家并行与训练版本同源，都来自 GShard、Switch Transformer 与 DeepSpeed-MoE 对 MoE 的分片方案，但目标函数不同：训练优化单步吞吐，推理优化目标并发下的首 token 时延 (Time To First Token, TTFT)、逐 token 时延 (Time Per Output Token, TPOT) 与尾延迟。由于推理没有反向，每个 MoE 层只有 dispatch 与 combine 两次 all-to-all，但其发生在请求的关键路径上，对延迟更敏感。

快速开始

监控专家负载和 all-to-all 延迟，在真实请求分布上压测。建议步骤：

  1. 部署 MoE 模型时，把专家按设备分布，记录路由后各设备的 token 数量分布。
  2. 测量每次 all-to-all 的耗时及其随 batch 大小、并发数的变化。
  3. 用真实流量（而非合成均匀流量）压测，观察热门专家是否造成排队。
  4. 记录 P50、P99 等分位延迟，重点关注尾延迟而非平均值。

验证成功：在目标并发下 all-to-all 延迟可控，专家负载基本均匀，P99 延迟满足服务水平要求。

案例

高峰流量下，某热门专家被大量请求命中而饱和，导致其所在设备队列变长、尾延迟升高。处理思路如下：

  1. 调整路由容量，限制单专家可接收的请求上限，超出的 token 回退到其他专家或被丢弃。
  2. 对热门专家增加副本，把它复制到多个设备上，分散负载。若某专家复制 \(R\) 份，其每副本负载约降为原来的 \(1/R\)。
  3. 比较调整前后的吞吐和生成质量：若质量明显下降，说明容量限制过紧或副本路由破坏了专家分工，需回退部分调整。

推理专家并行的优化目标是「吞吐与质量共同改善」，不能只压通信时间而牺牲生成效果。

相关主题