专家负载均衡

专家负载均衡#

概述#

在 LLM 推理服务中，MoE 模型的专家均衡对于实现最优性能至关重要。由于“停顿整场 (stop-the-world)”操作的存在，在推理过程中动态更改专家可能会对 TTFT（首字延迟）和 TPOT（逐字延迟）产生负面影响。SwiftBalancer 实现了异步专家负载均衡，具备零开销的专家迁移能力，确保了服务的无缝连续性。

EPLB 的效果#

降低延迟：通过在专家之间均匀分配工作负载，动态平衡专家负载，从而最小化 TTFT 和 TPOT。
提升吞吐量：优化 GPU 利用率，提高高并发场景下的 Token 生成速度。
零开销迁移：专家重分布过程异步进行，不会中断正在进行的推理请求。
自适应缩放：自动调整以应对工作负载波动，同时保持性能稳定。
容错性：冗余的专家放置策略确保了系统在硬件故障时的恢复能力。

支持场景#

支持模型：#

DeepSeek V3 / V3.1 / R1、Qwen3-MOE

MoE 量化类型：#

W8A8-dynamic

如何使用 EPLB#

动态 EPLB#

我们需要添加环境变量 export DYNAMIC_EPLB="true" 来启用 vLLM 的 EPLB 功能。通过自动调优的参数启用动态平衡。根据工作负载模式调整 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#

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

我们需要添加环境变量 export EXPERT_MAP_RECORD="true" 来记录专家映射表。使用 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"
  }'

关键注意事项#

参数调优：
- num_iterations_eplb_update：对于稳定的工作负载，建议使用较高值（如 400+）；对于波动的流量，建议使用较低值（如 100-200）。
- num_wait_worker_iterations：应 ≥ 30，以避免在启动阶段过早进行平衡。
- init_redundancy_expert：必须匹配张量并行 (TP) 大小（例如 16 张 GPU 则设为 16），以确保足够的冗余度。
硬件要求：
- 确保所有 GPU 具有相同的显存容量和计算能力。
- 网络带宽必须支持专家重分布的流量（建议 ≥ 10 Gbps）。
模型兼容性：
- 仅支持具有显式专家并行支持的 MoE 模型（如 Qwen3 MoE 模型）。
- 通过 --enable-expert-parallel 验证模型架构是否支持动态专家路由。
门控 (Gating) 配置：
- 当 gate_eplb=true 时，需验证门控机制能够处理专家迁移且不发生路由错误。
- 在生产部署前，请先使用合成工作负载进行测试。
监控与验证：
- 跟踪以下指标：expert_load_balance_ratio、ttft_p99、tpot_avg 以及 gpu_utilization。
- 使用 vllm monitor 检测运行时的不平衡情况。
- 加载前务必验证专家映射表的 JSON 结构（使用 jq 或类似工具验证）。
启动行为：
- 在第一个平衡周期内（通常为 1-2 分钟），初始请求可能会经历较高的延迟。
- 避免在预热阶段出现突发流量高峰。
常见陷阱：
- 张量并行大小 (TP size) 与实际 GPU 数量不符 → 导致资源利用不足。
- 在未生成映射表的情况下使用 expert_map_path → 导致运行时错误。
- 设置 init_redundancy_expert 大于可用 GPU 数量 → 导致系统故障。