SGLang 分布式集群模式概览

本文已于2025.09.14 发表于知乎和公众号。

计算加速是推理系统优化的终极目标，并行计算是实现该目标的核心手段，而分布式集群则是支撑并行计算落地的底层基础设施。本文概括性的介绍 SGLang 支持的多种分布式集群。

1. 六种分布式集群

SGLang 有多种分布式集群计算加速手段，可以分为三种类型。

1.1 基础并行

• 张量并行（TP，Tensor Parallelism），主要在矩阵计算阶段做拆分，将张量拆分到多个 GPU 卡上并行计算。
• 流水线并行（PP，Pipeline-Parallelism），对模型层次做拆分，将层分布到不同的 GPU 卡上计算，单个请求串行在多个卡上执行，而多个请求可以同时在多个卡上执行不同的阶段。
• 数据并行（DP，Data Parallelism），对一批输入请求做拆分，将请求分布到不同的 GPU 卡上并行计算。

1.2. 局部计算并行

• 注意力数据并行（DP Attention），主要用于 MLA 模型结构，将一批请求拆分为多个小批次，每一小批请求由部分 GPU 执行注意力计算，FFN 的计算和 TP 一致。
• 专家并行（EP Expert Parallelism），主要用于 MoE 模型结构，将专家的计算分布到部分 GPU 上，而不是全部 GPU。

注：这两种模式主要是为 DeepSeek V2/V3 模型结构定制的。

1.3. 计算时序分离并行

• PD 分离，基于请求推理时序，将一个请求的 prefill 阶段和 decode 阶段拆分到不同的 GPU 上执行。

2. SGLang 的核心模块

在了解 SGLang 分布式集群之前，我们先来了解 SGLang 包含的核心模块。SGLang 使用 python 实现，python 的 GIL（Global Interpreter Lock）设计使得一个 python 进程最多只能使用一核 CPU，因此基于 python 的复杂计算系统通常会使用多进程来使用多核 CPU。SGLang 的多进程设计也是系统的顶层架构设计，顶层架构如下：

系统的核心逻辑实现在 Scheduler 进程，也是我们介绍的分布式集群的载体。

3. TP 模式

TP 模式主要将模型中的权重张量按行/列拆分到多个 GPU 卡，每个 GPU 卡处理部分计算任务。SGLang 实现的 TP，支持多机多卡，结合计算阶段的特点做任务拆分，譬如：embedding 按词表分段拆分，attention 计算的权重矩阵按 HEAD 拆分，attention 的结果投影按行拆分。

TP 模式进程视角

上图展示 tp_size=16 的进程结构，有 16 个 scheduler 进程作为 TP rank 0～15，其中 TP rank 0 负责获取请求，然后将请求转发给其他 TP rank。

TP 是基础并行模式，其他的并行模式如：PP、DP、DP Attention 都可以在局部 GPU 组里使用 TP。

4. PP 模式

PP 模式将模型中的多个层拆分到不同的 GPU 上，使得集群可以承载更大的模型。

PP 模式进程视角：

每个 PP rank 负责部分模型层的计算。 PP rank 层间包括两部分通信：

• 请求和控制信息，在不同 PP rank 的 TP rank 0 之间传递。
• hidden state，这部分是 PP 层间所有 TP rank 的点对点传输，每个 TP rank 只传输自己负责的部分分片数据。

hidden state 只传输部分分片，而不是完整的 hidden state，这尽量的减少 PP rank 层间的通信量，后续层内再通过 all_gather 收集完整的 hidden state。这个设计将 hidden state 传输拆分为两步，第一步是 PP rank 之间，第二步是 PP rank 内的 TP rank 之间，相比在所有的 TP rank 上一次性将 hidden state 传输到位，这个设计可以减少 PP rank 之间的通信量，当 PP rank 处于不同的网络节点下时，可以大幅度降低跨节点通信量，整体通信耗时更短。

服务配置为 --pp-size，和 --tp-size 协作时，总 GPU 数为：ppsize * tpsize。ppsize 表示模型层拆分为 ppsize 个阶段，tpsize 表示每一个阶段内并行计算组的大小。每一个阶段的 tpworker 都需要和下一个阶段的 tpworker 通信，所以这里也会建立 tpsize 个通信组。

5. DP 模式

DP 模式将 GPU 拆分为多个小组，同时将一批请求拆分为多个小批次，每个 GPU 小组处理一个小批次。注意：只支持单机部署。

DP 模式进程视角：

DP 模式下，不同 GPU 组是隔离的，不同小批次的请求处理也是隔离的，只有计算之外的入口进程和 detokenizer 进程是共享使用的。我们也可以通过部署多套集群来实现和 DP 模式一样的效果，再考虑到 DP 模式的路由机制较为简单，未考虑容灾处理，因此 DP 模式实用价值较小。

DP 模式的一些特点：

• 仅支持单机部署

server_args.py 代码中有断言：multi-node data parallel is not supported unless dp attention!

assert not (
            self.dp_size > 1 and self.nnodes != 1 and not self.enable_dp_attention
        ), "multi-node data parallel is not supported unless dp attention!" 

data_parallel 进程在做 RoundRobin 分发时，将收到的请求发到某个 dp rank 下的 tp rank 0 zmq，因为是单机部署，采用的是 ipc 通信，不占用网络端口。

• sglang_router 比 DP 更好

如前面说的，DP 模式的实用价值较小，是数据并行的 demo 实现，而 SGLang 也提供了更好的工业化实现：sglang_router，它在数据并行的基础能力上进一步支持了多机部署和其他周边功能：容错、动态扩缩容、多种路由策略等。

参考文档：https://github.com/sgl-project/sglang/blob/main/docs/advanced_features/router.md

• 和 dp_attention 的差异

DP 和 DP Attention 是两种并行策略，但它们有两点联系：一、它们都使用 --dp-size 参数配置。但这个配置在两种并行策略下有不同的含义（这是不好的设计），DP 集群的 TP 节点数为： dpsize * tpsize，而 DP Attention 的 TP 节点数为 tp_size。二、它们复用了少量的外围代码，譬如：使用相同的 data-parallel 进程以及相同的请求分发逻辑。

6. DP Attention 模式

DP Attention 模式在注意力计算阶段将 GPU 拆分为多个组，同时将一批请求也拆分为多个小批次，每一组 GPU 处理一小批请求，在其他计算阶段 GPU 还是作为整体以 TP 的方式做计算。这种模式主要用于 DeepSeek V2/V3 模型，适用于它们的 MLA 结构，可以降低集群整体的 KV Cache 显存占用以及减少潜在表示在多 TP 间的重复计算。

DP Attention 模式进程视角：

DP Attention 模式一些特点：

• 请求的 RoundRobin 分发，所有 dp rank 下面的 attntprank 0 节点都会从 dp rank 0 的 data_parallel 进程获取请求，每个通信链路使用一个 zmq，因此 node 0 会占用 dp size 个端口。
• FFN 层的协作计算，所有的 tp 都使用相同的 nccl_port，它们会协作完成计算。
• 整个集群的 TP 节点数为：tp_size，这和 DP 模式不同。

每一个节点都会启动 DataParallelController 进程，但只有 0 号节点会进入事件循环负责接收 tokenizer 的请求，其他节点的 DataParallelController 在启动 Scheduler 进程之后就进入等待 Scheduler 进程退出的 join 中。

7. EP 模式

EP 模式专用于 MoE 结构的模型。EP 模式和 DP Attention 模式很像：将 GPU 卡分为多个 EP rank，每个 EP rank 负责一部分专家的计算（DP Attention 是每个 DP rank 负责一部分请求的计算）。相比 TP 模式，EP 模式可以让专家数量变得可线性扩展，体现在两方面：（1）TP 模式要求每一个 GPU 卡都有全部专家的权重分片，随着专家数量的增加，GPU 卡也需要增加，但在专家数量很多而激活很稀疏的场景下，全部 GPU 卡都需要参与计算和通信，性能较差，并且无法为热点专家分配更多的 GPU 卡。（2）TP 模式的专家数会遇到单机的显存瓶颈，而无法继续增加专家。

注：DeepEP 是 DeepSeek 团队开源的，对 EP 的一种优化实现。

EP 模式计算过程示意图：

MoE 模型，EP 和 TP 的对比：

• TP 模式：

1、每一个 TP rank 都会有所有专家的权重分片。

2、推理时，每一个 TP rank 都需要获得全部 token 的 hidden state，然后做计算。

3、计算完成之后再 all reduce 让每个 TP rank 都有完整的输出 hidden state。

• EP 模式：

1、每个 EP 组下的 TP rank 只有部分专家的权重分片，一个专家的权重分片只分布在一个 EP 组里；

2、推理时，每一个 TP rank 只获得部分 token 的 hidden state 做专家计算，这部分 token 通过 All to All Dispatch 获得，在专家计算完成之后，再通过 All to All Combine 将结果传给原 TP rank；

• 通信量对比：

1、TP 模式在注意力计算完成之后需要 all-reduce，在 FFN 完成之后需要 all-redcuce；两次 all-reduce；

2、EP 模式在注意力计算完成之后，FFN 层每个 TP rank 只需要部分 token hidden state，因此注意力层的结果变到 FFN 层的输入是采用 scatter（reducescatter或者dpscatter）；FFN 计算时需要两次 all-to-all 通信，一次是 hidden state 传到做计算的 TP rank 上，一次是计算完之后结果传回原 TP rank；最后再有一次 all gather 让每一个 TP rank 上都有完整的 hidden state，以便下一层做注意力计算。

为 FFN 准备数据的 scatter

EP 虽然是 FFN 层的并发策略，但因为 FFN 层的输入来自注意力层的输出，注意力层不同的并行策略会导致给到 FFN 层的输入有不同的格式，这导致 FFN 层的输入数据准备会采用不同的处理函数，可能是 reduce-scatter，也可能是单纯的 dp-scatter。

8. PD 分离模式

除了上面基于计算并行的分布式，我们还可以将其推理过程拆分为两个阶段：prefill 和 decode，这两个阶段可以分别设计分布式集群。

其中 prefill、decode 实例可以是前面提到的几种分布式集群，但 prefill、decode 实例在部分模型结构下还不支持异构部署，主要是因异构会导致 KV Cache 需要更复杂的实现，部分模型还未支持。

9. 展望未来

我们从更高的层面来看待这些并行模式，可以发现各种并行模式是从大模型推理的不同视角去设计并行的：

• 时序视角，不同阶段做并行——PD 分离
• 批量请求视角，请求做并行——DP
• 模型层次视角，模型层次做并行——PP
• 矩阵计算视角，矩阵计算做并行——TP

我们可以更系统的列出来，如下：

从上到下看逐步深入底层，从左往右看逐步下钻，上图中的部分并行模式 SGLang 还未实现，但业内已有提出这些想法，如果继续下钻，也可能会想到更多的分布式和并行设计。

上图中文章未涉及的是 overlap，它本质上是不同硬件的并行，来让瓶颈硬件持续工作，这在分布式集群下很常见：减少网络通信阻塞的 GPU 计算时长。

当无数的并行模式被提出来时，哪种模式适合我们的业务场景，而我们又应该怎么去开发实现？是非常费力的工作，从工业化效率考虑，也许未来会有一种“任务流架构”，把每个请求内的多个矩阵计算作为一个个的任务，这些任务在满足数据依赖的前提下，通过任务流架构自由的选择执行的 GPU、执行的顺序、是否融合，同时任务流架构可以自动的根据业务场景给出最佳的组合，来满足业务的 SLA，可能是 TTFT 优先，也可能是 TPOT 优先，又或者是两者都有阈值，系统能自动的调配资源，使得满足耗时 SLA 的情况下达到最大吞吐，最少成本。

10. 参考文档

在本文的总结过程中，除了查看源代码，也阅读以下文档辅助理解

• https://deepwiki.com/sgl-project/sglang
• SGLang 后端代码解析
• scheduler 整体概览

 

本文：https://www.cnblogs.com/cswuyg/p/19319132
知乎：https://zhuanlan.zhihu.com/p/1950702248284894524
公众号：https://mp.weixin.qq.com/s/7g472bLmKr9JyrMuJgPWJw