专家并行负载均衡器 (EPLB)¶

概述¶

在 LLM（大语言模型）服务中，对 MoE（混合专家）模型进行专家均衡对于实现最佳性能至关重要。在推理过程中动态调整专家会因 stop-the-world（全局停顿）操作而对 TTFT（首 Token 时间）和 TPOT（每 Token 输出时间）产生负面影响。我们的解决方案旨在最大程度地减少该操作带来的负面影响。

vLLM Ascend 提供两种 EPLB 集成路径：

• Model Runner V2（MRv2） 使用上游 vLLM EPLB 控制器、配置、默认策略、负载窗口、异步 worker 和重排生命周期。Ascend 增加了 Gloo CPU 暂存和 load_collection_phase 扩展。
• Model Runner V1（MRv1） 保留旧版 vLLM Ascend 的动态、记录和静态 EPLB 模式。

这两条路径使用不同的开关和配置模式。请勿将 MRv1 环境变量或旧版字段与 MRv2 EPLB 配置混合使用。

EPLB 效果¶

• 降低延迟：通过在专家之间均匀分配工作负载来动态平衡专家负载，从而最小化 TTFT 和 TPOT。
• 自适应扩展：自动适应工作负载波动，同时保持稳定的性能。

支持场景¶

模型¶

EPLB 仅适用于支持专家并行且其 MoE 量化方法暴露完整专家权重移动布局的 MoE 模型。支持情况还取决于所选的模型运行器和硬件代次。

旧版 MRv1 的性能主要已在 DeepSeek-V3.1/R1 上得到验证。最初的 MRv2 模型级验证使用 Qwen3-30B-A3B W8A8 搭配异步 EPLB。在生产部署之前，请使用目标模型、拓扑和流量验证准确性和性能。

Model Runner V2 权重格式¶

下表描述了 MRv2 EPLB 代码路径。W8A8 已在代码树中包含模型级 NPU 回归测试。其他已启用的格式在生产使用前需要在目标硬件上进行模型级验证。

Model Runner V1 量化与硬件¶

使用建议¶

在以下场景中不建议使用 EPLB，因为负载均衡的收益可能无法抵消其运行时开销：

• P node 工作负载的输入序列短于 1024 个 token。
• D node 工作负载中每个 die 的专家数 > 8（在 950DT Products 上为 > 16），或每个 die 的负载低于 128 个 token。

如何使用 EPLB¶

Model Runner V2：异步 EPLB¶

当模型或环境未默认选择 MRv2 时，请显式选择 MRv2。启用专家并行和上游 EPLB。Ascend 使用上游默认策略，自动选择 Gloo 通信器，并且仅支持异步迁移。

export VLLM_USE_V2_MODEL_RUNNER=1
unset DYNAMIC_EPLB
unset EXPERT_MAP_RECORD

vllm serve Qwen/Qwen3-30B-A3B \
  --tensor-parallel-size 16 \
  --enable-expert-parallel \
  --enable-eplb \
  --eplb-config.window_size 50 \
  --eplb-config.step_interval 50 \
  --eplb-config.num_redundant_experts 16 \
  --eplb-config.use_async true \
  --eplb-config.log_balancedness true \
  --eplb-config.log_balancedness_interval 1 \
  --additional-config '{"eplb_config":{"load_collection_phase":"all"}}'

MRv2 使用上游 EPLBConfig 字段：

这些字段也可以通过 --eplb-config 以 JSON 形式一起传递。在 MRv2 中，它们不能放在 --additional-config 中。

MRv2 负载收集阶段¶

load_collection_phase 是 additional_config.eplb_config 下唯一的 MRv2 EPLB 字段。它控制哪些批次阶段对上游负载窗口有贡献；它不会对不匹配的批次禁用路由或 MoE 计算。

分类每个批次执行一次。包含任何 prefill 请求的批次整体被分类为 prefill；否则为 decode。与 load_collection_phase 不匹配的批次在记录当前步骤时贡献零负载；它不会抑制共享 EPLB 窗口推进。这使负载窗口槽位、调度和通信在数据并行 rank 之间保持一致。

例如，仅收集 prefill 负载：

vllm serve Qwen/Qwen3-30B-A3B \
  --enable-expert-parallel \
  --enable-eplb \
  --eplb-config.use_async true \
  --additional-config '{"eplb_config":{"load_collection_phase":"prefill"}}'

Model Runner V1：旧版 EPLB¶

旧版 MRv1 EPLB 有三种使用模式：

动态 EPLB¶

需要添加环境变量 export DYNAMIC_EPLB="true" 以启用 vLLM-Ascend EPLB。使用自动调优参数启用动态平衡。根据工作负载模式调整 expert_heat_collection_interval 和 algorithm_execution_interval。在当前版本中，我们建议使用以下策略：SwiftBalanceEplb(2)。

graph TB
   A[start] --> B(collect_heat)
   B --> C(execute_algorithm)
   C --> D(update_layer one by one)
   D --> B
   D --> F[termination upon service termination]

# D node or colocation
vllm serve Qwen/Qwen3-235B-A22 \
  --tensor-parallel-size 16 \
  --enable-expert-parallel \
  --additional-config '{ "eplb_config": {
    "dynamic_eplb": true,
    "expert_heat_collection_interval": 600,
    "algorithm_execution_interval": 50,
    "eplb_policy_type": 2,
    "num_redundant_experts": 16
    }}'

# P node
vllm serve Qwen/Qwen3-235B-A22 \
  --tensor-parallel-size 16 \
  --enable-expert-parallel \
  --additional-config '{ "eplb_config": {
    "dynamic_eplb": true,
    "expert_heat_collection_interval": 50,
    "algorithm_execution_interval": 5,
    "eplb_policy_type": 2,
    "num_redundant_experts": 16
    }}'

EPLB 策略类型¶

eplb_policy_type 参数选择动态专家重分配期间使用的平衡算法：

选择性专家热度收集¶

eplb_heat_collection_stage 选项适用于 prefill-decode 聚合场景。Prefill 请求通常在一次迭代中处理许多 token，而 decode 请求通常处理较少 token。因此，两个阶段之间的专家工作负载分布可能不同。从两个阶段收集热度可能会掩盖你希望优化的延迟阶段的失衡。

[!IMPORTANT] 本节描述仅适用于 MRv1 的 eplb_heat_collection_stage 字段。 MRv2 使用如上所述的 load_collection_phase；这两个字段具有 不同的批次分类语义，且不可互换。

使用 eplb_heat_collection_stage 选择其专家热度贡献给 EPLB 的阶段：

根据实际工作负载选择阶段。以下值可作为初始调优指导：

• 对于典型输入序列长度大于 1024 个 token 的工作负载，先从 prefill 开始。
• 对于典型输入序列长度小于 1024 个 token 但并发数大于 1024 的工作负载，尝试 decode 或 all。
• 对于其他或混合工作负载，在选择设置之前，针对目标 TTFT 或 TPOT 对 all、prefill 和 decode 进行基准测试。

这些阈值是经验性的起点，而非严格要求。生产流量分布、并发、模型配置和硬件拓扑都可能影响最优阶段。

例如，要仅收集 prefill 热度：

export DYNAMIC_EPLB="true"

vllm serve Qwen/Qwen3-235B-A22 \
  --tensor-parallel-size 16 \
  --enable-expert-parallel \
  --additional-config '{ "eplb_config": {
    "dynamic_eplb": true,
    "expert_heat_collection_interval": 600,
    "algorithm_execution_interval": 50,
    "eplb_policy_type": 2,
    "num_redundant_experts": 16,
    "eplb_heat_collection_stage": "prefill"
  }}'

要仅收集 decode 热度，请设置：

{
  "eplb_config": {
    "dynamic_eplb": true,
    "eplb_heat_collection_stage": "decode"
  }
}

[!NOTE] 阶段选择适用于动态 EPLB 热度收集。在内部，vLLM-Ascend 通过将其填充后的已调度 token 数与 decode 迭代的最大预期 token 数进行比较，对每个前向迭代进行分类。高于阈值的迭代被视为 prefill；等于或低于阈值的迭代被视为 decode。因此，分类是按前向迭代执行的，而不是按单个请求执行的。

当某个迭代与所选阶段不匹配时，其专家负载不会被累积，也不会推进热度收集间隔。热度收集完成后，均衡计算和逐层专家权重更新将正常继续。

静态 EPLB¶

[!WARNING] 静态 EPLB 计划在 v0.25.1 中移除。

初始设置（记录专家映射）¶

需要添加环境变量 export EXPERT_MAP_RECORD="true" 以记录专家映射。使用 expert_map_record_path 生成初始专家分布映射。这将为后续部署创建基线配置。

vllm serve Qwen/Qwen3-235B-A22 \
  --tensor-parallel-size 16 \
  --enable-expert-parallel \
  --additional-config '{ "eplb_config": {
    "expert_map_record_path": "/path/to/eplb.json",
    "num_redundant_experts": 16,
    "expert_heat_collection_interval": 400,
    "algorithm_execution_interval": 30
  }}'

后续部署（使用已记录的映射）¶

加载预先记录的专家映射以获得一致的性能。这可避免在运行时重新计算分布。

vllm serve Qwen/Qwen3-235B-A22 \
  --tensor-parallel-size 16 \
  --enable-expert-parallel \
  --additional-config '{
    "eplb_config": {"expert_map_path": "/path/to/eplb.json"}
  }'

关键注意事项¶

1. 参数调优：
2. 对于 MRv2，针对目标工作负载调整 window_size 和 step_interval。对于 MRv1，调整 expert_heat_collection_interval 和 algorithm_execution_interval。

3. num_redundant_experts 必须使 (num_experts + num_redundant_experts) 能被专家并行大小整除。

4. 硬件要求：

5. 确保所有 NPU 具有相同的内存容量和计算能力。
6. 网络带宽必须支持专家重分配流量（建议 ≥ 10 Gbps）。

7. 容器需要挂载 shm

8. 监控与验证：

9. 跟踪指标：在日志中搜索 [Expert Hotness]。我们将计算不同 rank 下每一层负载的峰值与平均值之比，然后求取它们的均值和最大值。Current 表示实际的峰值与平均值之比，update 表示算法调整后的估计峰值与平均值之比。
10. 使用 vLLM monitor 在运行时检测不均衡。
11. 加载前始终验证专家映射 JSON 结构（使用 jq 或类似工具进行验证）。