S12 · Balance the Hot Experts — 给热点专家安排副本与位置

整组前进的速度受最忙设备影响，平均负载好看还不够。

01为什么专家数量均匀，卡仍会不均匀

gate 的选择受输入影响，不同专家收到的 token 数可能差别很大。即便每张卡放相同数量的专家，热点也可能集中在一张卡上，其他卡只能等待。EPLB 根据历史路由计数，给热点 logical expert 增加 physical 副本，并重新安排副本位置；参数副本增加同时消耗额外存储。

s12_expert_balance.py

# Framework pseudocode for expert placement policy.
history, future = split_windows(expert_token_counts)
assert physical_experts % ep_size == 0
local_capacity = physical_experts // ep_size

placement, replicas, counts = rebalance_experts_global(
    history,
    num_physical_experts=physical_experts,
    num_local_physical_experts=local_capacity,
)

for name, layout in candidate_layouts(placement):
    # Equal sharing between replicas is an explicit proxy assumption.
    load = estimate_rank_tokens(future, layout)
    bottleneck = load.max(axis=-1).sum()
    imbalance = load.max(axis=-1) / load.mean(axis=-1)
    report(name, bottleneck, imbalance)

export_case(history, future, placement, policy_revision)

02历史窗口的互补性比总量更细

上游策略先决定冗余副本，再按历史各 step 的负载向量贪心放置，目标涉及每步最忙 rank 的负载之和。两个总量相同的专家可能同时忙，也可能交替忙，放在同一张卡的效果不同。因此只按历史总数平均分组会丢失时序信息；策略中的稳定排序和同分处理也影响可复现实验。

03策略输出怎样交给运行时

policy.py 根据历史计数提出副本分配与布局，运行时还要维护计数、通信、参数迁移和逻辑到物理映射。历史窗口中的热点不保证延续到下一窗口，因此要把策略输入、布局输出和后续路由分开阅读。最大 token 负载只是布局决策的一项代理信息，不等于整个框架的执行表现。

04请求负载均衡与 EPLB 管的是不同对象

官方生产设计：官方部署文章中的请求负载均衡决定请求交给哪组服务实例，在 prefill 与 decode 的服务副本之间分配工作。EPLB 则作用于专家执行内部，安排 logical expert 的 physical 副本及其位置。一条请求选中了服务副本之后，其中的 token 仍可能经过专家路由；这两层决策需要各自的状态与统计。 开源核对：rebalance_experts_global接收专家历史 token 计数，输出专家副本数与逻辑、物理映射，验证的是 EPLB 策略。README明确将 prefill 和 decode 的数据并行副本负载均衡列为未提供的服务基础设施。因此不能把公开的 EPLB 策略或单个引擎的 Scheduler 当作完整生产请求负载均衡器。

TRY IT YOURSELF

动手想一想

构造热点从专家 0 转移到专家 3 的两段流量。比较静态布局、随机布局和历史优化布局在后半段的负载，解释为何训练窗口上的最优布局可能不再占优。