专家并行负载均衡器 (EPLB)¶
概述¶
在LLM(大语言模型)服务中,对MoE(混合专家)模型进行专家均衡对于实现最佳性能至关重要。推理过程中动态调整专家会因全局停顿操作而对TTFT(首Token时间)和TPOT(每Token输出时间)产生负面影响。我们的解决方案旨在最小化该操作带来的负面影响。
vLLM Ascend 提供两种 EPLB 集成路径:
- 模型运行器 V2 (MRv2) 使用上游 vLLM EPLB 控制器、配置、默认策略、负载窗口、异步工作线程和重排生命周期。Ascend 增加了 Gloo CPU 暂存和
load_collection_phase扩展。 - 模型运行器 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。在生产部署前,请使用目标模型、拓扑和流量验证准确性和性能。
Important
Ascend 950 Products does not support using EPLB with quant type "W4A8MXFP4", "W4A16MXFP4". A2 does not support redundant experts.
模型运行器 V2 权重格式¶
下表描述了 MRv2 EPLB 代码路径。W8A8 具有树内模型级 NPU 回归测试。其他已启用的格式需要在使用前在目标硬件上进行模型级验证。
| 权重格式 | MRv2 EPLB | 备注 |
|---|---|---|
| BF16 / FP16 | 已启用 | 使用未量化的专家权重和偏置。 |
| W8A8 / W8A8 动态 | 已启用 | 使用持久的每专家权重和缩放张量。 |
| W4A8 | 已启用 | 使用持久的每专家权重、缩放和缩放偏置张量。 |
| W4A4 MXFP | 已启用 | Ascend 950 产品;保留原生 ND 专家张量。 |
| W8A8 MXFP | 已启用 | Ascend 950 产品;保留原生 ND 专家张量。 |
| W4A16 | 已拒绝 | 专家权重布局尚未完成独立的 EPLB 验证。 |
| W4A16 MXFP | 已拒绝 | 专家权重布局尚未完成独立的 EPLB 验证。 |
| W4A8 MXFP | 已拒绝 | 专家权重布局尚未完成独立的 EPLB 验证。 |
模型运行器 V1 量化与硬件¶
| 量化类型 | 支持的硬件 |
|---|---|
| W8A8 / W8A8-动态量化 | A2, A3 |
| W4A8(启用融合MC2) | A2, A3 |
| MXFP4 | Ascend 950系列产品 |
| MXFP8 | Ascend 950系列产品 |
使用建议¶
在以下场景中不建议使用EPLB,因为负载均衡的收益可能无法抵消其运行时开销:
- P node workloads with input sequences shorter than
1024tokens. - D node workloads where the number of experts per die is
> 8(> 16on 950DT), or where the per-die load is below128tokens.
Warning
Meeting the above conditions may lead to performance degradation. When there are around 8 experts per die, the EPLB benefit may be comparable to its overhead. Benchmark the actual workload and enable EPLB only after confirming a performance gain.
如何使用EPLB¶
模型运行器 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 字段:
| 参数 | 默认值 | 描述 |
|---|---|---|
window_size |
1000 |
用于专家负载记录的最近步数。 |
step_interval |
3000 |
专家重排之间的间隔。 |
num_redundant_experts |
0 |
冗余物理专家数量。 |
use_async |
true |
Ascend MRv2 始终以异步方式运行;false 会在告警后规范化为 true。 |
policy |
default |
上游 EPLB 放置策略。 |
log_balancedness |
false |
记录专家均衡度指标。 |
log_balancedness_interval |
1 |
均衡度日志条目之间的间隔。 |
communicator |
None |
保持未设置以自动选择 Gloo,或设置为 torch_gloo。 |
这些字段也可以通过 --eplb-config 以 JSON 形式一起传递。对于 MRv2,它们不能放在 --additional-config 中。
MRv2 负载收集阶段¶
load_collection_phase 是 additional_config.eplb_config 下唯一的 MRv2 EPLB 字段。它控制哪些批次阶段对上游负载窗口有贡献;它不会为不匹配的批次禁用路由或 MoE 计算。
| 值 | 行为 | 典型用途 |
|---|---|---|
all |
从每个批次收集负载。这是默认值。 | 通用和混合工作负载。 |
prefill |
仅从包含至少一个 prefill 请求的批次收集。 | 优化 prefill 均衡和 TTFT。 |
decode |
仅从包含 decode 请求且无 prefill 请求的批次收集。 | 优化 decode 均衡和 TPOT。 |
分类对每个批次执行一次。包含任何 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"}}'
Important
MRv2 supports asynchronous EPLB only and normalizes use_async=false to asynchronous Gloo movement. It rejects legacy dynamic_eplb, recording/static-map fields, DYNAMIC_EPLB, and EXPERT_MAP_RECORD, as
well as communicators other than Gloo. Validate the target model, topology, graph mode, and traffic independently before production use.
模型运行器 V1:传统 EPLB¶
传统 MRv1 EPLB 有三种使用模式:
| 模式 | eplb_config 中的配置 |
环境变量 |
|---|---|---|
| 动态EPLB | dynamic_eplb: true |
DYNAMIC_EPLB=true |
| 记录(生成专家映射) | expert_map_record_path |
DYNAMIC_EPLB=true 或 EXPERT_MAP_RECORD=true |
| 静态EPLB(加载预记录映射) | expert_map_path |
无需设置 |
Important
For Dynamic EPLB and Recording modes, the env variable acts as a safety guard: setting dynamic_eplb: true in config alone is not enough — the assertion requires DYNAMIC_EPLB=true or EXPERT_MAP_RECORD=true. Static EPLB (loading a pre-recorded map via expert_map_path) does not require an env variable.
动态 EPLB¶
我们需要添加环境变量export DYNAMIC_EPLB="true"来启用vLLM-Ascend EPLB。启用带自动调优参数的动态均衡。根据工作负载模式调整expert_heat_collection_interval和algorithm_execution_interval。在当前版本中,我们建议使用以下配置:SwiftBalanceEplb(2)策略。
| 参数 | 描述 | 默认值 |
|---|---|---|
| dynamic_eplb | 启用动态EPLB。 | False |
| expert_heat_collection_interval | 收集专家热度的间隔。 | 600 |
| algorithm_execution_interval | 执行均衡算法的间隔。 | 50 |
| eplb_policy_type | EPLB策略类型。 | 2 |
| num_redundant_experts | 冗余专家数量。 | 0 |
| eplb_heat_collection_stage | 用于收集专家热度的请求阶段。可选值:all、prefill和decode。 |
all |
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 参数选择动态专家重分配过程中使用的均衡算法:
| 值 | 策略 | 描述 |
|---|---|---|
0 |
随机 | 在rank之间随机交换专家。仅适用于基础测试。 |
1 |
DefaultEplb | 开源EPLB算法。为最热的专家添加冗余,通过带局部约束交换的均衡分配进行打包。 |
2 |
SwiftBalanceEplb | 针对低带宽环境优化。支持节点内和节点间专家冗余,联合优化专家放置。(推荐) |
3 |
FlashLB | 使用专家负载的滑动窗口均值/方差/协方差的统计方法。利用FlashTree分层搜索进行最优副本分配,并使用minimize_redeploy进行增量调整。最适合高频负载波动场景。 |
选择性专家热度收集¶
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的阶段:
| 值 | 行为 | 典型用途 |
|---|---|---|
all |
从prefill和decode迭代中收集专家热度。 | 通用工作负载;这是默认值。 |
prefill |
仅从被分类为prefill的迭代中收集专家热度。 | 优化prefill工作负载均衡和TTFT。 |
decode |
仅从被分类为decode的迭代中收集专家热度。 | 优化decode工作负载均衡和TPOT。 |
根据实际工作负载选择阶段。以下值可作为初始调优指导:
- 对于典型输入序列长度大于
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热度,请设置:
[!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"}
}'
关键注意事项¶
- 参数调优:
- 对于MRv2,根据目标工作负载调整
window_size和step_interval。对于MRv1,调整expert_heat_collection_interval和algorithm_execution_interval。 -
num_redundant_experts必须使(num_experts + num_redundant_experts)能被专家并行大小整除。 -
硬件要求:
- 确保所有NPU具有相同的内存容量和计算能力。
- 网络带宽必须支持专家重新分配流量(建议≥ 10 Gbps)。
-
容器需要挂载shm
-
监控与验证:
- 跟踪指标:在日志中搜索[Expert Hotness]。我们将计算不同rank上每层负载的峰值与平均值之比,然后找出它们的平均值和最大值。Current表示实际的峰值与平均值之比,update表示算法调整后估计的峰值与平均值之比。
- 使用vLLM监控器在运行时检测不均衡情况。
- 在加载前始终验证专家映射JSON结构(使用jq或类似工具进行验证)。