专家负载均衡 (EPLB)

专家负载均衡 (EPLB)#

概述#

在 LLM 服务中，为 MoE 模型进行专家负载均衡对获得最佳性能至关重要。在推理过程中动态切换专家可能会因全局阻塞操作而对 TTFT（首个 Token 时间）和 TPOT（每输出 Token 时间）产生负面影响。SwiftBalancer 提供异步专家负载均衡，并实现零开销专家迁移，确保服务无缝连续。

EPLB 效果#

  • 延迟降低：动态平衡专家负载，通过在专家间均匀分配工作量来最小化 TTFT 和 TPOT。

  • 吞吐量提升：优化 GPU 利用率，在高并发场景下提高生成 Token 的速度。

  • 零开销迁移：专家重分配异步进行，不会中断正在进行的推理请求。

  • 自适应扩展：在保持性能稳定的同时自动适应负载波动。

  • 容错能力：冗余专家配置确保在硬件故障期间系统的弹性。

支持场景#

支持模型：#

DeepseekV3/V3.1/R1、Qwen3-MOE

MOE 量化类型：#

W8A8-dynamic

EPLB 使用指南#

动态 EPLB#

需要添加环境变量 export PYTHONOPTIMIZE=1 以获取 vLLM 进程上下文。使用自动调优参数启用动态负载均衡。根据负载模式调整 num_iterations_eplb_update 和 num_wait_worker_iterations。

vllm serve Qwen/Qwen3-235B-A22 \
  --tensor-parallel-size 16 \
  --enable-expert-parallel \
  --additional-config '{
    "dynamic_eplb": true,
    "num_iterations_eplb_update": 400,
    "num_wait_worker_iterations": 30
  }'

静态 EPLB#

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

使用 expert_map_record_path 生成初始专家分布图，为后续部署创建基线配置。

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

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

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

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

关键注意事项#

  1. 参数调优：

    • num_iterations_eplb_update：稳定负载使用较高值（如 400+），波动负载使用较低值（如 100-200）。

    • num_wait_worker_iterations：应 ≥ 30，以避免启动期间过早触发负载均衡。

    • init_redundancy_expert：必须与张量并行大小匹配（如 16 个 GPU 对应 16），以确保有足够冗余。

  2. 硬件要求：

    • 确保所有 GPU 具有相同的显存容量和计算能力。

    • 网络带宽必须支持专家重分配流量（建议 ≥ 10 Gbps）。

  3. 模型兼容性：

    • 仅支持具有显式专家并行的 MoE 模型（例如 Qwen3-235B-A22）。

    • 确认模型架构支持通过 --enable-expert-parallel 进行动态专家路由。

  4. 门控配置：

    • 当 gate_eplb=true 时，验证门控机制能够在专家迁移过程中正确路由，无错误。

    • 在生产部署前使用合成负载进行测试。

  5. 监控与验证：

    • 跟踪指标：expert_load_balance_ratio、ttft_p99、tpot_avg 和 gpu_utilization。

    • 使用 vllm monitor 在运行时检测不平衡。

    • 在加载前始终验证专家映射 JSON 结构（可使用 jq 或类似工具进行验证）。

  6. 启动行为：

    • 首次平衡周期内，初始请求可能会经历更高的延迟（通常 1-2 分钟）。

    • 在预热阶段避免突然的流量峰值。

  7. 常见陷阱：

    • 张量并行大小与实际 GPU 数量不匹配 → 导致资源未充分利用。

    • 未先生成映射就使用 expert_map_path → 运行时错误。

    • 设置 init_redundancy_expert 大于可用 GPU 数量 → 系统故障。

目录