专家并行 (Expert Parallelism)

专家并行#

SGLang 中的专家并行 (EP) 将混合专家 (MoE) 模型中的专家权重分布在多个设备上，解决了内存瓶颈，并实现了高性能推理的高效扩展。这对于服务大规模 MoE 模型尤为重要，因为在这些模型中，Token 会被动态路由到分布在不同 GPU 上的专用专家。通过利用优化的 All-to-All 通信和分组矩阵乘法 (GEMMs)，EP 能够降低延迟、提高吞吐量并减少 GPU 空闲时间。SGLang 的 EP 框架具有极强的可扩展性，其模块化设计允许在不重构核心逻辑的情况下无缝集成自定义算子、后端和优化方案，支持多种硬件和量化方案。

受支持的后端及选择指南#

SGLang 的 EP 集成了针对不同场景的多种高效后端，允许对性能权衡进行细粒度控制。用户可以通过命令行参数指定后端：

  • --moe-a2a-backend：选择 All-to-All 通信后端。

  • --moe-runner-backend：选择 MoE 计算后端。

All-to-All 通信后端#

后端

描述

应用场景

none (默认)

禁用 EP 的 All-to-All 模式。使用 All-Reduce 或 All-Gather 进行 Token 分发。

EP 和 TP 混合设置。

deepep

DeepEP，一个用于 MoE 模型中高效 Token 打乱 (Shuffling) 的通信库。

大规模 EP 部署。

mooncake

Mooncake，DeepEP 的扩展版本，用于弹性推理，利用 RDMA 实现高性能数据传输。

弹性 EP 推理服务。

DeepEP 和 Mooncake 后端支持两种 Token 分发模式：normal 模式（针对高吞吐量的 Prefill 工作负载优化）和 low_latency 模式（针对低延迟和 CUDA Graph 兼容的 Decode 工作负载优化）。建议用户设置 --deepep-mode auto 以在运行时启用自动分发模式切换。设置 --deepep-mode normal 或 --deepep-mode low_latency 则适用于调试或开发目的。

目前，DeepEP 和 Mooncake 仅支持 ep_size = tp_size 的情况。对于混合 EP 和 TP（即 ep_size < tp_size），仅支持 none 后端（基于 All-Reduce 或 All-Gather 的分发）。

MoE 计算后端#

后端

描述

应用场景

auto (默认)

根据模型架构、硬件（如 NVIDIA 的 Ampere、Hopper、Blackwell 架构）、量化方案（如 FP8、FP4）和运行时条件自动选择最佳后端。

通用部署；无需用户干预即可确保兼容性和性能。

triton

基于 Triton 实现的分组 GEMM。为了获得更高性能，强烈建议创建 调优配置 (tuned configurations)。

自定义算子开发或需要 Torch 编译支持的高可扩展性场景。

deep_gemm

DeepGEMM 后端，专为 MoE 矩阵乘法优化，支持 Prefill 的连续布局和 Decode 的掩码布局；通常采用 JIT 编译以提升性能。

采用 FP8 块级量化的大规模 EP 部署。

cutlass

基于 CUTLASS 的高效 GEMM 后端。

支持 CUTLASS 的 NVIDIA 架构。

flashinfer_trtllm

FlashInfer 与 TensorRT-LLM 集成，用于加速 MoE 计算，支持 FP4 通信算子和高性能 GEMM。

配备 TRT-LLM 的 Blackwell 架构。

flashinfer_cutlass

FlashInfer 结合 CUTLASS，用于 MoE 层中的高性能分组 GEMM，高效处理 FP4/FP8 量化。

使用 FP4/FP8 模型的 Blackwell 架构。

flashinfer_mxfp4

针对 MoE 运行器中的 MXFP4（混合 FP4）量化优化的 FlashInfer 变体，专注于内存高效的低精度推理。

使用 MXFP4 的低精度模型。

flashinfer_cutedsl

带有自定义 DSL 的 FlashInfer，用于灵活高效地生成 MoE 算子，并集成了 ModelOpt FP4 量化。

使用 NVFP4 的低精度模型。

示例#

配合 DeepEP 和 DeepGEMM 启动 DeepSeek-V3

python -m sglang.launch_server --model-path deepseek-ai/DeepSeek-V3 --moe-a2a-backend deepep --moe-runner-backend deep_gemm --tp 8 --ep 8

可扩展的 EP 框架#

SGLang 的 EP 框架提供模块化抽象，便于集成自定义算子、后端和优化。它将 MoE 前向传播解耦为多个阶段（分发 → 预排列 → 核心运行器 → 后排列 → 合并），从而在不重构核心逻辑的情况下实现无缝扩展。

框架概览#

该框架以 FusedMoE 为统一入口点，形成单一且可扩展的结构。关键组件包括：

  • Dispatcher (分发器)：管理 DeepEP 等后端的分发/合并（实现 BaseDispatcher 子类）。

  • MoeRunner (运行器)：通过 MoeRunnerCore 实现类（如 TritonRunnerCore）协调分组 GEMM 执行。

  • PermuteMethodPool (排列方法池)：自动注册布局转换（例如，通过 register_pre_permute 和 register_post_permute 用于动态模式，或通过 register_fused_func 用于静态且兼容 torch.compile 的融合操作）。

  • TopK Router (TopK 路由)：与后端无关的专家选择逻辑。

此设计通过 --moe-a2a-backend 和 --moe-runner-backend 支持多个后端，并通过标准化的 apply() 方法集成量化。计算流程确保了模块化：

[input_hidden_states]
          |
          v
     TopK.forward -> select_experts / triton_kernels.routing / bypass
          |
          v
     [TopKOutput]
          |
          v
   FusedMoE.forward -> Dispatcher.dispatch -> DeepEP / bypass
          |                     |
          |                     v
          |              [DispatchOutput]
          |                     |
          |                     v
          |             quant_method.apply -> MoeRunner.forward
          |                     |              |
          |                     |              v
          |                     | pre-permute + grouped_gemm + post-permute
          |                     |              |
          |                     |--------------
          |                     v
          |               [CombineInput]
          |                     |
          |                     v
          |            Dispatcher.combine -> DeepEP / bypass
          |                     |
          |---------------------
          v
[final_hidden_states]

详情请参阅 MoE 重构路线图。

实现新后端#

若要添加新后端：

  1. 对于新的 All-to-All 分发器，实现一个带有 dispatch 和 combine 方法的 BaseDispatcher 子类。

  2. 对于新的 MoE 运行器后端，为核心操作（如分组 GEMM）定义一个 MoeRunnerCore 子类。

  3. 为分发器或模型运行器定义新的输入/输出格式（例如 RunnerInput, RunnerOutput）。

  4. 注册排列/逆排列方法以确保兼容性：

    • 融合模式 (Fused Mode)（静态，兼容 torch.compile）：使用 register_fused_func 处理端到端操作。

    • 排列模式 (Permute Mode)（动态）：注册 register_pre_permute 和 register_post_permute 以支持灵活布局。

请参阅 MoE 重构实现 PR 了解完整更改，包括类型提示和配置扩展。

示例#

有关实现示例，请参阅 moe_runner/triton.py，该文件展示了通过注册融合和排列函数实现的基于 Triton 的分组 GEMM。

计算与通信重叠#

SGLang 的 EP 采用了先进的重叠技术，将通信延迟隐藏在计算之后，从而最大化 MoE 层中的 GPU 利用率。

双批次重叠 (TBO)#

TBO 将请求拆分为微批次 (micro-batches)，交替执行注意力计算与分发/合并操作。执行图中的屈服点 (Yield points) 允许在重叠时暂停，从而在不产生峰值内存激增的情况下提高整体吞吐量。

operations = [
    self._forward_attn,
    YieldOperation(),  # Overlap with dispatch of prior micro-batch
    self._forward_dispatch,
    self._forward_mlp,
    YieldOperation(),  # Overlap with combine
    self._forward_combine,
]

用户需要指定 --enable-two-batch-overlap 来开启最高 2 倍的吞吐量提升。详情请参阅 大规模 EP 博客。

单批次重叠 (SBO)#

SGLang 为单批次重叠 (SBO) 引入了分发器挂钩 (dispatcher-hook) 系统，允许在单个批次内重叠操作（例如将共享专家计算与通信重叠），同时通过去中心化逻辑增强模块化。这些挂钩在 dispatch 和 combine 操作前后执行，无需修改核心 MoE 模块。这种设计简化了接口，降低了耦合性，并提高了可扩展性。有关实现细节以及共享专家与 DeepEP 合并操作重叠的示例，请参考 PR #13327。用户可以设置 --enable-single-batch-overlap 来启用此功能。

负载均衡器#

SGLang 集成了 DeepSeek 的 专家并行负载均衡器 (EPLB)，以解决 MoE 模型中的路由不平衡问题。通过分析专家激活统计数据，EPLB 计算出最佳的专家排列方案，策略性地放置或复制专家，以最大限度地减少 GPU 利用率差异，减少空闲周期并增强可扩展性。

要启用 EPLB，请使用参数 --enable-eplb true --load-balance-method eplb。为了获得最佳性能，请增大批次大小以稳定激活统计数据，并配置定期重新平衡（例如每 1000 个请求一次）以适应变化的工作负载。模拟结果显示，负载均衡度（平均计算时间与最大计算时间之比）显著提高，这与吞吐量的提升高度相关。

更多详情请参考 大规模 EP 博客中的 EPLB 章节 以及 EPLB 仓库。

EP 与投机采样#

在 MoE 架构上结合 MTP (Multi-Token Prediction) 使用投机采样时，可以使用 --speculative-moe-runner-backend 和 --speculative-moe-a2a-backend 参数为草稿模型 (Draft model) 自定义 MoE 层行为。虽然它们默认继承目标模型 (Target model) 的设置，但当目标模型和草稿模型的精度不同时，用户可以分别进行设置。

例如对于 nvidia/DeepSeek-R1-0528-NVFP4-v2 模型，目标模型使用 NVFP4 精度，而草稿模型使用 BF16。为了在目标 MoE 层应用 flashinfer_trtllm 算子，同时在草稿 MoE 层回退到 Triton 融合 MoE 算子，用户可以按如下方式设置参数：

...
--moe-runner-backend flashinfer_trtllm \
--speculative-moe-runner-backend triton \
...
目录