跳到主要内容

EPLB

两种放置策略各自适用场景、复制热门 expert 怎么拉平 GPU 负载

核心要点：

  • EPLB 解决的问题：MoE expert 在 GPU 间的放置与复制
  • 两种策略的触发条件：Hierarchical 与 Global 何时各自适用
  • Redundant Expert 机制如何拉平 GPU 负载
  • EPLB 与 DeepEP 的协作分工：placement 与 kernel 解耦
  • LMSYS 96 H100 上的实测加速比

EPLB (Expert Parallelism Load Balancer) 是 DeepSeek 在 2025 年 2 月开源的 MoE 负载均衡算法，通过决定 expert 在 GPU 上的放置和复制来拉平各 GPU 的 MoE 层时间。

前置阅读：

  • 通用名词 (Logical / Physical / Redundant expert, Expert group, Balancedness) → 8.1 总览 Glossary
  • EP 与 AllToAll 基本机制 → 8.1 总览
  • DeepEP 的 dispatch / combine kernel → 8.2 DeepEP

为什么需要 EPLB?​

MoE 推理中 expert 负载严重不均：少数热门 expert 持续承接大部分 token，多数 expert 长期空闲。在 EP 部署中这造成两个直接后果：

  • 木桶效应：MoE 层结束需要所有 GPU 完成 expert 计算并参与 Combine AllToAll。最慢 GPU 决定整层延迟，利用率随节点规模增大而下降[1]。
  • AllToAll 流量热点：热门 expert 所在 GPU 在 dispatch 阶段成为接收端热点，吃满本地 NIC，其他链路闲置。

EPLB 与 DeepEP 解决的问题正交：DeepEP 改 kernel （非对称带宽转发优化 AllToAll），EPLB 改 placement （复制热门 expert 拆分热点）。DeepSeek-V3 训练阶段采用了 redundant experts 策略，并把这套策略抽象成独立工具 EPLB 开源[2]。

Hierarchical 还是 Global：策略怎么选？​

策略选择只看一个条件：num_groups % num_nodes == 0 时用 Hierarchical，否则用 Global[3]。

维度HierarchicalGlobal
触发条件num_groups % num_nodes == 0其他情形
感知 expert group是 （利用 group-limited routing 限制跨节点流量）否
复制粒度先节点级装箱，再节点内复制并铺 GPU全局复制，直接铺到所有 GPU
推荐场景Prefill, EP 规模较小Decode, EP 规模较大
优化目标节点内 NVLink 承接 group 内流量，减少跨节点 RDMA大 EP 下 group 边界已失效，直接全局拉平

@tbl-eplb-01 Hierarchical 与 Global 两种策略对比

EPLB 以历史负载为输入 （各 expert 在过去若干 step 内承接的 token 数），输出三张映射表：每个 GPU 上的 physical expert 序列、每个 logical expert 对应的 physical 副本索引、每个 logical expert 的实际副本数。dispatch / combine 按这些表收发[3]。

Hierarchical：三阶段装箱​

Hierarchical 按"节点 → 节点内 → GPU"三层装箱，与硬件层次 （NVLink 域 / RDMA 域） 对齐，把高频路由约束在 NVLink 域[3]。

  • Stage 1 — Group → Node：把 expert group 视为不可拆分单元，按累计负载装箱到各节点。group 的存在保证一个 token 路由路径只穿过少数节点，减少跨节点 RDMA 压力。
  • Stage 2 — 节点内复制：在每个节点内部，按节点内 expert 负载分布决定复制配额。复制配额来自全局 num_replicas - num_logical_experts 按节点比例分配。
  • Stage 3 — Replicas → GPU：节点内的 physical expert （含复制副本） 装箱到节点内 GPU，目标是节点内各 GPU 累计 weight 接近。

硬件依据：节点内 NVLink ~160 GB/s，节点间 RDMA ~50 GB/s (数据见 8.2 DeepEP)。

Global：单阶段全局装箱​

Global 不分 node、不分 group，直接对全部 physical expert 做一次全局装箱到所有 GPU[3]。

适用场景是 decode 阶段大 EP。此时一个 EP 组本身已横跨多节点 （LMSYS 96 H100 实测取 EP=32 / 64），group-limited routing 已无法约束流量在单节点内，分层装箱失去意义，全局拉平更直接[1]。

冗余 expert 如何分配才能拉平负载？​

Redundant Expert 是 EPLB 的核心机制：给重载 expert 加副本，把热点拆分到多 GPU。

  • 预算：给定 num_logical_experts 个 logical expert，预算 num_replicas 个 physical expert (num_replicas > num_logical_experts)
  • 分配：多出来的 slot 给重载 expert 做副本 （LMSYS 部署用 256 logical + 32 redundant = 288 physical[1]）
  • 放置灵活性[1]:
    • 复制热门 expert：一个超热 expert 在多 GPU 上各有副本，dispatch 把该 expert 的 token 分散到副本，单 GPU 接收量下降
    • 冷热搭配同 GPU：中等负载 expert 与若干低负载 expert 同 GPU，累计 weight 接近平均值

dispatch 时，router 输出 top-K logical expert ID 后，通过映射表查出每个 token 要发到哪个 physical 副本。多副本情况下按负载或哈希选一份。

示例：12 logical + 4 redundant, 2 节点 × 4 GPU​

README 给出的示例输出 （每个 GPU 上 2 个 physical，共 16 个 physical = 12 logical + 4 redundant）[3]:

tensor([[ 5,  6,  5,  7,  8,  4,  3,  4, 10,  9, 10,  2,  0,  1, 11,  1],
        [ 7, 10,  6,  8,  6, 11,  8,  9,  2,  4,  5,  1,  5,  0,  3,  1]])

第 0 行 (layer 0) 中 logical expert 5、4、10、1 各出现 2 次 （高负载，被复制）；其余 expert 各 1 次。

第 1 行 (layer 1) 的复制模式不同 — EPLB 逐层独立优化：不同层的热门 expert 分布不同，复制策略也不同。

EPLB 和 DeepEP 怎么协同？​

EPLB 决定 placement, DeepEP 实现 kernel，两者解耦：

组件解决的问题输出
EPLBExpert 应该放在哪个 GPU 上、复制几份三张 placement 映射表
DeepEP给定 placement，如何用 kernel 高效完成 Dispatch / Combine AllToAllnormal kernel (prefill) + low-latency kernel (decode)

@tbl-eplb-02 EPLB 与 DeepEP 的职责分工

衔接点在 dispatch 阶段。router 输出 top-K logical expert ID 后，用映射表查出每个 token 要发到哪个 physical 副本，再交给 DeepEP 的 dispatch kernel 发送。Combine 阶段相反，physical 上的结果按原始 logical 归属聚合回去。

解耦的工程价值：placement 更新不需要重新编译 kernel。EPLB 只改路由表，DeepEP 的 kernel 不感知 expert 是不是副本，按 physical ID 收发即可[1]。

实测能带来多少加速？​

LMSYS 在 96 H100 （12 节点 × 8 GPU） 部署 DeepSeek-V3 + PD 分离 + 大规模 EP，开启 EPLB 相对未开启加速比：

  • Prefill: 1.49×
  • Decode: 2.54×

数据来源[1]。衡量指标是 Balancedness ratio = mean（MoE 层 GPU 计算时间） / max（同上），越接近 1 越均衡。

decode 加速比远高于 prefill 的原因：

  • decode 单 token 计算量小，单 GPU 拖慢 1 ms 直接体现在 TPOT 上，对负载均衡敏感度高
  • decode 阶段 EP 规模大 （跨多节点，实测 EP=32 / 64），group-limited routing 失效，没有 EPLB 时负载几乎完全随机
  • prefill 阶段 batch 内 token 数多 （数千），统计意义上负载自然均衡度本就更高，EPLB 提升空间小

EPLB 还有哪些未解决的问题？​

  • 依赖准确的负载统计：EPLB 假设未来 token 路由分布与历史接近。负载分布剧变时旧 placement 失配，需要重新计算并迁移 expert 权重。迁移代价 （拷贝 expert weight 跨 GPU） 在开源代码中未量化。
  • 重算频率未公开：README 未规定 placement 更新周期，LMSYS 部署博客也未给出生产环境 rebalance 触发条件 （每 N step / 每 M 分钟 / 负载方差阈值）。这是工程参数，需要权衡 placement 失配损失与权重迁移开销。
  • 与 group-limited routing 强耦合：Hierarchical 策略假设 DeepSeek-V3 的 group-limited routing。对不分 group 的 MoE 模型 （经典 Switch Transformer、Mixtral），只能用 Global 策略，丢失节点内 NVLink 优化机会。
  • 复制存储开销：副本各占一份 expert 权重显存。DeepSeek-V3 的 32 redundant expert 占 256 logical 的 12.5% 额外显存；副本比例进一步抬高时显存压力快速上升，README 未讨论上限。
  • 冷启动：服务刚启动时没有历史负载，无法运行 EPLB，只能用 round-robin 等启发式初始 placement。何时切换到 EPLB 优化结果由用户自行处理。

Takeaway​

知识点核心结论
EPLB 是什么MoE expert 放置算法，改 placement 不改 kernel
触发动机木桶效应 + AllToAll 接收热点
策略选择num_groups % num_nodes == 0 → Hierarchical，否则 Global
Hierarchical 三阶段Group → Node 装箱 → 节点内复制 → Replicas 铺 GPU
Redundant Expert在 logical 之外预算副本，复制热门 + 冷热搭配同 GPU
与 DeepEP 关系placement 与 kernel 解耦，副本 ID 对 kernel 透明
实测加速 (96 H100)Prefill 1.49× / Decode 2.54× (LMSYS)
主要局限依赖历史负载稳定性，重算频率与迁移代价未公开

@tbl-eplb-03 EPLB 核心知识点

参考资料​

  1. LMSYS Org, Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs, 2025-05-05. https://www.lmsys.org/blog/2025-05-05-large-scale-ep/
  2. DeepSeek-AI, DeepSeek-V3 Technical Report, arXiv:2412.19437, 2024. https://arxiv.org/abs/2412.19437
  3. DeepSeek-AI, EPLB: Expert Parallelism Load Balancer, GitHub README. https://github.com/deepseek-ai/EPLB

延伸阅读​