GLM-5.3 推理全链路（六）：token 跨卡的那一段——MoE dispatch/combine 的模式、缓冲与重叠

前五篇把账算清了，这一段还没打开

前五篇沿着一条请求的路径走完了入口、调度、prefill、PD 分离和 vLLM 的 prefill 切分。每一篇都会在某个位置写下一句相同的话：MoE 层要做一次 DeepEP 的 dispatch，专家算完再做一次 combine。账本也算过两遍——第二篇按 192 个验证行、8 个专家、75 个 MoE 层，得出一条 decode step 的 all-to-all 往返约 2.8GB；第三篇按 32K 的 prefill chunk 算出单层 1.6GB 的 dispatch。

但“dispatch 与 combine”一直被当成一个黑盒。它到底把哪些字节搬到哪里、为什么 decode 和 prefill 要用两套完全不同的模式、固定缓冲区的容量从哪来、超额了会怎样、以及框架到底用什么办法把这段通信藏进计算——这些问题不回答，“通信占 50%”就只是一个数字，没法指导部署参数。

这一篇专门打开这一段。对象仍然是 GLM-5.3：78 层、前 3 层稠密、后 75 层 MoE、每层 256 个路由专家加 1 个共享专家、每 token 选 8 个。部署形态取 SGLang cookbook 的单机吞吐配方：--tp 8 --ep-size 8 --attn-dp-size 8 --moe-a2a-backend deepep，也就是注意力按请求分片、专家按卡切分。代码以 SGLang 的 layers/moe/token_dispatcher/deepep.py、layers/moe/moe_runner/deep_gemm.py 与 batch_overlap/ 两条路径为准；DeepEP 本身则以它当前的 EPBuffer 接口和 legacy 接口为参照。

先把结论摆出来，后面逐条证明：

• 一次 MoE 前向的跨卡动作不是一次 all-to-all，而是四段：DP Attention 的 gather、专家 dispatch、专家 combine、DP Attention 的 reduce-scatter。前两段与后两段的方向相反，中间夹着两段 grouped GEMM；
• decode 与 prefill 用的是两套数据布局：decode 走固定容量的 masked 布局，prefill 走变长的 contiguous 布局。这不是实现口味，而是由“batch 大小是否可预知”和“能否进 CUDA Graph”决定的；
• 低延迟模式的代价是缓冲区容量：num_max_dispatch_tokens_per_rank 在启动时就要定死，超过它直接报错，不会自动扩容；
• 重叠有三层：combine 与第二个 GEMM 用信号量重叠（SBO），两个子 batch 交替执行（TBO），以及 DP Attention 的 gather/scatter 与 MoE 通信在层间的自然交错。三层各有各的适用边界，TBO 在 decode batch 小于 64 时甚至会变慢。

四段通信，不是一段

先把这个容易混淆的地方定下来。在 --attn-dp-size 8 且 attn_tp_size = 1 的配置里，一次 decode step 的跨卡顺序是：

1. DP gather：每张卡只持有分给自己的请求的 KV 与 hidden，MoE 却要在全局 batch 上按专家路由，所以先把 8 张卡的 hidden 拼成一份全局 batch；
2. dispatch：按路由结果，把全局 batch 里每个 token 复制 8 份，发到持有对应专家的 rank；
3. combine：专家算完，把 8 份部分和按原路送回，并在发送端按路由权重求和；
4. DP reduce-scatter：全局输出按请求归属散回各卡，同时完成跨 rank 的求和。

这四段里，只有第 2、3 段是“按专家”的 all-to-all；第 1、4 段是“按请求分片”的集合通信。把它们混成一句“MoE 要 all-to-all”，会导致一个常见的估算错误：把 DP gather 的字节也算进专家通信，或者忘了 combine 之后还有一次 reduce-scatter。

1
def _dp_gather_via_all_gather(global_tokens, local_tokens, forward_batch, is_partial):
2
    use_world = world_dp_gather_enabled()
3

4
    if get_parallel().attn_tp_size == 1:
5
        if use_world:
6
            all_gather_single(global_tokens, local_tokens, group=torch.distributed.group.WORLD)
7
        else:
8
            get_parallel().tp_group.all_gather_into_tensor(global_tokens, local_tokens)
9
        return
10

11
    if not is_partial:
12
        if get_parallel().attn_tp_rank != 0:
13
            local_tokens.fill_(0)
14
    scattered_local_tokens = local_tokens.tensor_split(get_parallel().attn_tp_size)[
15
        get_parallel().attn_tp_rank
16
    ]
17
    get_parallel().attn_tp_group.reduce_scatter_tensor(scattered_local_tokens, local_tokens)
18
    ...
19
    get_parallel().tp_group.all_gather_into_tensor(global_tokens, scattered_local_tokens)

1
def is_dp_gatherv_active() -> bool:
2
    return (
3
        _USE_DP_GATHERV
4
        and not world_dp_gather_enabled()
5
        and get_parallel().attn_tp_size == 1
6
        and get_parallel().tp_size == get_parallel().attn_dp_size
7
        and not _DpGatheredBufferWrapper.is_dp_max_padding()
8
    )

路由结果如何变成一张发送清单

dispatch 不是“把 hidden 广播出去再让专家自己挑”。在真正搬字节之前，先要算出一张清单：每个 rank 会收到多少 token、每个专家会收到多少 token、某个 token 是否属于某个 rank。SGLang 的普通模式直接调用 DeepEP 的 get_dispatch_layout 完成这一步：

1
(
2
    num_tokens_per_rank,
3
    num_tokens_per_rdma_rank,
4
    num_tokens_per_expert,
5
    is_token_in_rank,
6
    previous_event,
7
) = buffer.get_dispatch_layout(
8
    topk_ids,
9
    self.num_experts,
10
    previous_event=previous_event,
11
    async_finish=self.async_finish,
12
    allocate_on_comm_stream=previous_event is not None,
13
)

四个输出各有用途：

• num_tokens_per_rank：每个目标 rank 应收到多少行，接收端据此分配输出缓冲；
• num_tokens_per_rdma_rank：跨节点时每个 RDMA rank 的量，用于决定 NVLink 段与 RDMA 段各发多少；
• num_tokens_per_expert：每个专家收到多少行，直接决定后面 grouped GEMM 的分组长度；
• is_token_in_rank：形状为 $[\text{tokens}, \text{ranks}]$ 的布尔矩阵，标记某个 token 是否要发往某个 rank。

这张清单是后面所有账本的基础。它也解释了为什么 dispatch 之前要做一次全卡可见的路由：topk_ids 是每张卡对自己的 token 算出来的，但“某个 rank 要收多少”必须所有 rank 一致，否则接收缓冲会对不上。

紧接着的一个细节是量化。GLM-5.3 的专家权重是 FP8，DeepGEMM 路径要求激活也按 128 一组量化后再发：

1
if deep_gemm_wrapper.ENABLE_JIT_DEEPGEMM and self.use_fp8:
2
    hidden_states = sglang_per_token_group_quant_fp8(
3
        hidden_states,
4
        128,
5
        column_major_scales=deep_gemm_wrapper.DEEPGEMM_SCALE_UE8M0,
6
        scale_tma_aligned=deep_gemm_wrapper.DEEPGEMM_SCALE_UE8M0,
7
        scale_ue8m0=deep_gemm_wrapper.DEEPGEMM_SCALE_UE8M0,
8
    )

逐行看这段量化：

• sglang_per_token_group_quant_fp8(hidden_states, 128, ...) 把每一行按 128 个元素一组切成 48 组，每组独立求最大值并映射到 E4M3 的 [−448, 448] 区间，输出 6144 个 FP8 字节加上 48 个 scale。分组而不是逐行，是因为 LLM 的激活在 128 维的块内分布远比整行平稳，逐行量化一个离群值会拖垮整行的精度；
• column_major_scales=True 让 scale 按列主序存放，形状是 [scale 组数, 行数] 而不是 [行数, 组数]。DeepGEMM 的 grouped GEMM 在遍历专家时，同一个专家的行是连续的，但不同专家的 scale 需要按“组优先”读取，列主序正好让同一组的 48 个 scale 相邻，TMA 一次搬运就能取到一段；
• scale_tma_aligned 与 scale_ue8m0 是 Blackwell 路径的开关：scale 的内存起始地址要按 TMA 的对齐要求补齐，scale 的数值要转成 UE8M0（只存 8 位指数、尾数固定为 1）。

为什么要三种标志一起开？因为它们服务于同一个目标：让 scale 也能被 TMA 直接搬运进 Tensor Core 的 MMA 指令。BF16 路径下，scale 要在 kernel 里逐元素乘回结果，这条路径只能走传统的逐元素指令；FP8 + UE8M0 + TMA 对齐时，scale 作为 MMA 描述符的一部分被硬件消费，反量化被并入矩阵乘本身。这正是 FP8 MoE 在 Blackwell 上比 Hopper 快出一截的原因——不只是 MMA 本身变快，而是反量化的开销从 kernel 里消失了。

对 dispatch 的字节账，这段量化有两层影响。第一层是负载减半：6144 维 BF16 的一行是 12KB，FP8 是 6KB。第二层是 scale 的额外开销，但它不是白发的——如果没有 scale，专家收到 FP8 的 hidden 就无法还原原始幅度，GEMM 的结果会整体偏小或偏大。48 个 FP32 scale 是 192 字节，占负载的 3%；如果按 UE8M0 以 8 位打包存储，48 个 scale 只要 48 字节，占比降到 0.8%。

把“先量化再发送”和“收到后再量化”放一起比较，差别不只是带宽：前者在发送端做一次，48 个 scale 随行发出；后者要在每个接收 rank 上对已经搬过来的 BF16 再做一次量化，不仅多一趟 2 倍字节的搬运，还会在每个 rank 上重复同样的量化计算。对 8 个 rank 的 EP 组，后者相当于把量化做了 8 遍。

清单与量化都准备好之后，才进入真正的 dispatch。而“真正搬”的方式，取决于选的是哪种模式。

两种模式：一张兼容性表背后的设计

DeepEP 提供两类内核，SGLang 用 DeepEPMode 枚举把它们暴露成三个选项：

1
class DeepEPMode(Enum):
2
    NORMAL = "normal"
3
    LOW_LATENCY = "low_latency"
4
    AUTO = "auto"
5

6
    def enable_normal(self) -> bool:
7
        return self in [DeepEPMode.NORMAL, DeepEPMode.AUTO]
8

9
    def enable_low_latency(self) -> bool:
10
        return self in [DeepEPMode.LOW_LATENCY, DeepEPMode.AUTO]
11

12
    def resolve(self, is_extend_in_batch: bool) -> DeepEPMode:
13
        if self != DeepEPMode.AUTO:
14
            return self
15
        if is_extend_in_batch:
16
            return DeepEPMode.NORMAL
17
        else:
18
            return DeepEPMode.LOW_LATENCY

AUTO 不是“自动调优”，而是一个按 forward 模式二选一的开关：这一步里有 prefill（is_extend_in_batch）就走普通模式，纯 decode 就走低延迟模式。它解决的正是同一个部署里 prefill 与 decode 对通信的需求完全相反的问题。

SGLang 团队在 2025 年 5 月那篇 96 卡部署 DeepSeek 的博客里给过一张兼容性表，把两类内核的边界列得很清楚：

这张表要横着读：

• 普通模式适合 prefill。prefill 一次几千到几万个 token，每层的发送量是 MB 级，带宽是瓶颈；它用 SM 参与数据搬运，按专家连续布局输出，正好喂给 contiguous 的 grouped GEMM。但它的接收形状随 token 数变化，进不了 CUDA Graph，也不适合 decode 那种每步只有几百行的场景——延迟会被 kernel 启动和 CPU 同步吃掉；
• 低延迟模式适合 decode。它预分配固定大小的缓冲，用 NVSHMEM 做单边写，接收形状固定为 [本地专家数, 容量, hidden]，可以进 CUDA Graph；代价是容量必须提前定死，且长输入会超出容量；
• Auto 与 DP Attention 不兼容，原因不是软件 bug，而是同一个通信组不能在 prefill 与 decode 之间反复切换缓冲布局。切换时要 clean_low_latency_buffer，把整个低延迟缓冲清空重建，这在同一个 step 里同时有 prefill 和 decode 时无法安全完成。

PD 分离正好解开了这个死结：prefill 实例只跑普通模式，decode 实例只跑低延迟模式，两个实例各自有独立的通信组，不需要在同一个组里切换。这也是第四篇里 PD 分离对 GLM-5.3 的真正价值之一——不只是把两个阶段的 GPU 利用率分开，还让通信模式可以各自最优。

1
if deepep_mode.enable_normal():
2
    hidden_bytes = hidden_size * param_bytes
3
    for config in (
4
        DeepEPConfig.get_instance().normal_dispatch_config
5
        or Buffer.get_dispatch_config(group.size()),
6
        DeepEPConfig.get_instance().normal_combine_config
7
        or Buffer.get_combine_config(group.size()),
8
    ):
9
        num_nvl_bytes = max(config.get_nvl_buffer_size_hint(hidden_bytes, group.size()), num_nvl_bytes)
10
        num_rdma_bytes = max(config.get_rdma_buffer_size_hint(hidden_bytes, group.size()), num_rdma_bytes)

低延迟模式：固定容量、masked 布局

低延迟模式的缓冲计算完全是另一套：

1
if deepep_mode.enable_low_latency():
2
    assert num_max_dispatch_tokens_per_rank != -1
3
    assert num_experts != -1 and num_experts % group.size() == 0
4
    if not _is_npu:
5
        _set_nvshmem_qp_depth(num_max_dispatch_tokens_per_rank)
6
    num_rdma_bytes = max(
7
        Buffer.get_low_latency_rdma_size_hint(
8
            num_max_dispatch_tokens_per_rank,
9
            hidden_size,
10
            group.size(),
11
            num_experts,
12
        ),
13
        num_rdma_bytes,
14
    )

这段启动逻辑用两个 assert 与一次 QP 深度设置划出了适用边界：

1. 容量必须给定，不能是 -1；
2. 专家数必须能被 EP 组大小整除——每个 rank 的本地专家数相同，缓冲才能按 num_local_experts 等分；
3. QP 深度随容量线性增长，_set_nvshmem_qp_depth 在启动时一次性设好。

QP 数的选择也不同。普通模式每 rank 的 QP 数等于 SM 数，低延迟模式则等于本地专家数：

1
if deepep_mode == DeepEPMode.NORMAL:
2
    num_qps_per_rank = DeepEPConfig.get_instance().num_sms
3
elif deepep_mode == DeepEPMode.LOW_LATENCY:
4
    num_qps_per_rank = num_experts // group.size()

框架按本地专家数配置 QP，意图是让每个专家有独立的接收队列，收到即处理，不需要像普通模式那样按 SM 分片再聚合。对 GLM-5.3 的 EP8，本地专家 32 个，QP 就是 32；如果改成 EP16，本地专家 16 个，QP 也降到 16。但 QP 按“专家”配置并不等于流量按专家均分：一个热门专家会收到远多于平均的 token，它背后的那条 QP 就成了瓶颈。这是 EP 变大时更容易被放大的问题——本地专家越少，单个专家承担的流量份额越大。

还有一个容易被忽略的上限：

1
# DeepEP internode_ll dispatch uses FINISHED_SUM_TAG=1024
2
# and the logic requires num-tokens-sent-from-one-rank-to-another-rank less than it
3
assert self.num_max_dispatch_tokens_per_rank <= 1024

这个 1024 不是随便定的，而是低延迟内核用一个固定的 sentinel tag 来判断“某个 rank 的 token 发完了”。如果单 rank 一次发的 token 超过 1024，计数会撞上 sentinel，接收端会提前认为发送结束。框架用 assert 把它挡在启动阶段，而不是等运行到一半出现数据错位。

对 GLM-5.3 来说，这条上限意味着 decode 的批不能无限加。每条请求 6 个验证 token，而一行 token 最多会被复制到 8 个专家所在的 rank；如果路由把多个专家集中到同一个远端 rank，单 rank 对单 rank 的发送量就是行数的数倍。1024 的容量按最坏情况折算，能容纳的请求远少于 170 条；DeepEP 文档给出的经验值是 decode 批不超过 256。要服务更大的并发放，只能加 DP rank 把请求摊开，或者降低投机验证的 token 数。

masked 布局：为什么 decode 的 GEMM 不是按行算的

低延迟模式的输出布局是理解 decode MoE 的关键。普通模式输出的是“按专家连续排列”的一维行集合，长度等于接收到的 token 总数，随 batch 变化；低延迟模式输出的是一个三维张量：

其中 num_max_tokens 就是 num_max_dispatch_tokens_per_rank。每个本地专家固定分到一段，段内前 masked_m[e] 行有效，其余是未定义数据。这样形状完全静态，CUDA Graph 才能捕获。

框架在 dispatch 之后拿到三个东西：hidden_states（三维）、masked_m（每个专家的有效行数）、expected_m（GEMM 的期望行数）。expected_m 的公式在 dispatch_a 里：

1
expected_m = (
2
    hidden_states.shape[0] * buffer.group_size * topk_ids.shape[1]
3
    + self.num_experts
4
) // self.num_experts

把它写成数学形式。设本地行数为 $T$（即全局 batch 的 token 数），EP 组大小为 $E$，每 token 选 $k$ 个专家，全局专家数为 $N$。分子是“所有 rank 一共会产生多少个 (token, expert) 对”，加上 $N$ 是为了向上取整；分母 $N$ 把它摊到每个专家上：

对 GLM-5.3、EP8、$T = 192$、$k=8$、$N=256$：

也就是平均每个专家 48 行；加 1 是为了在整除时也留出一行余量，结果 49。这个值不是精确的每专家行数，而是给 GEMM 选 tile 用的“期望 M”：DeepGEMM 的 masked grouped GEMM 会按 expected_m 选择 block 大小与并行粒度，再用 masked_m 逐专家屏蔽超出部分。真实分布由路由决定，热点专家可能收到 100 行，冷门专家 0 行；expected_m 只是一个平均基准，避免为最坏情况分配过大的 tile。

这也解释了 masked GEMM 的两个阶段。layers/moe/moe_runner/deep_gemm.py 的 _run_masked_gemm 里，第一段是 gate/up 投影：

1
num_groups, m, k = hidden_states.shape
2
n = w13_weight.size(1)
3
gateup_output = torch.empty((num_groups, m, n), device=hidden_states_device, dtype=torch.bfloat16)
4
deep_gemm_wrapper.grouped_gemm_nt_f8f8bf16_masked(
5
    (hidden_states, hidden_states_scale),
6
    (w13_weight, w13_scale),
7
    gateup_output,
8
    masked_m,
9
    expected_m,
10
    recipe_a=recipe_a,
11
    recipe_b=recipe_b,
12
)

第二段在 SiLU 与乘 gate 之后，再对 down 投影做一次同样的 masked GEMM。注意中间激活函数也不是逐元素跑一遍：_varlen_deep_gemm_silu_mul_quant 在同一个 kernel 里完成 SiLU、逐元素乘、按 128 分组量化，输出直接是下一段 GEMM 要的 FP8 激活与 scale。三件事合成一个 kernel，省掉两次全量读写。

对 GLM-5.3 的单层 MoE，第二段 GEMM 的输出形状是 $[32, 1024, 6144]$：32 个本地专家、每段最多 1024 行、输出 6144 维。即使实际只有 192 行有效，这个张量也要按满容量分配——固定布局的代价就是显存按最坏情况预留。1024 行的上限、6144 的宽度、BF16 输出，单个这样的张量是 32 × 1024 × 6144 × 2 = 402MB。SGLang 在分配失败时会打印一条很具体的错误：

1
Masked grouped-GEMM workspace allocation failed (num_groups=... m=... n=...).
2
If this happens under saturated dp-attention prefill, try SGLANG_OPT_DG_MASKED_M_CAP=1.

这条日志本身就是证据：masked 布局的显存开销与容量成正比，容量取大了，decode 还没开始就把显存吃光。num_max_dispatch_tokens_per_rank 因此不是“越大越安全”，而是要在并发、显存与 1024 上限之间取一个平衡。

combine 的语义：谁做加法，加法在哪做

dispatch 把 token 复制成 8 份，combine 要把 8 份部分和变回 1 份。这个“变回”包含两件事：按路由权重加权，以及跨 rank 求和。两件事发生在不同位置，混淆会导致对精度和带宽的误判。

在 SGLang 的路径里，加权发生在专家计算这一侧：每个专家算完自己的输出后，用该 token 对该专家的路由权重乘上去，再把结果交给 combine。combine 只负责把同一 token 的 8 份加权结果相加。DeepEP 的文档把这一点写得很清楚：combine 的输入必须是 BF16，recv_topk_weights 是展开成一维的、每行一个权重，专家计算在 combine 之前应用路由权重，combine 对供给的专家输出求和。

为什么加权要放在专家侧而不是 combine 侧？因为权重是 per-(token, expert) 的，而 combine 的接收端只看到“同一 token 的 8 份输出”，如果在那里加权，需要把 8 个权重也一起传回来——多一份 8 倍的小张量通信，还要在接收端做一次索引匹配。放在专家侧，权重在 dispatch 时已经随 token 一起发过去了，专家算完直接乘，combine 只做纯加法。

这也带来一个精度细节：combine 的输入是 BF16，8 份部分和相加。对 FP8 专家权重、BF16 激活的 GLM-5.3，单个专家的输出已经是 BF16，8 份相加的舍入误差在 $10^{-3}$ 量级，与注意力的 FP8 KV 误差同阶。如果再把 combine 也压到 FP8，误差会累加到 $10^{-2}$，这也是为什么 combine 始终保持 BF16 而不跟着 dispatch 一起量化。

1
if get_parallel().tp_size == get_parallel().attn_dp_size:
2
    get_parallel().tp_group.reduce_scatter_tensor(output, input)
3
else:
4
    scattered_local_tokens = input.tensor_split(get_parallel().tp_size)[
5
        get_parallel().tp_rank
6
    ]
7
    get_parallel().tp_group.reduce_scatter_tensor(scattered_local_tokens, input)

重叠的第一层：让 combine 和第二个 GEMM 同时跑

账本只能说明“有多少字节”，说明不了“这些字节有没有被藏起来”。decode 的通信之所以能占到 50% 而不把延迟拖垮，靠的是重叠。SGLang 里最细的一层叫 SBO（single batch overlap），它把 combine 的发送与 down 投影的 GEMM 放在两个 stream 上同时执行。

batch_overlap/single_batch_overlap.py 里的参数结构是这一层的全部契约：

1
@dataclass
2
class CombineOverlapArgs:
3
    # this "overlap" flag means overlapping with down gemm, not the general two-stream overlap
4
    overlap: bool
5
    stream: torch.cuda.Stream
6
    wait_event: torch.cuda.Event
7
    num_sms: Optional[int] = None
8
    signal: Optional[torch.Tensor] = None
9
    block_m: Optional[int] = 64
10
    threshold: Optional[int] = 0

每个字段都有明确分工：

• stream 是 combine 通信所在的旁路 stream，wait_event 让它在 down GEMM 开始后才启动；
• num_sms 给通信内核留出的 SM 数。代码里默认值是 Hopper 3 个、Blackwell 32 个：

  1
  communicate_num_sms = 32 if is_blackwell() else 3
  2
  compute_num_sms = total_num_sms - communicate_num_sms

• signal 是一块按“专家 × block”粒度分配的计数器，down GEMM 每完成一个 block 就把它对应的计数加一；
• block_m 与 threshold 决定“GEMM 推进到什么程度才允许 combine 发下一段”：block_m 是 signal 的计数粒度，Hopper 上不小于 64；threshold 是开始发送的门槛。

通信之所以能等 GEMM，是因为 combine 的发送对象是“已经算完的专家输出”。down GEMM 按 block_m 分块产出，每产出一块，combine 就可以把这块对应的行发走，而不必等整个 GEMM 结束。Hopper 路径下 threshold 取计算 SM 数，表示当累计完成的 block 数达到计算 SM 数时开始发送——这是一个经验值，既保证发送不会早到没有数据，又保证通信不会晚到成为尾巴。

1
@classmethod
2
def enable_combine_shared_two_stream_overlap(cls):
3
    return (
4
        is_sbo_enabled()
5
        and not cls.enable_dispatch_shared_one_stream_overlap()
6
        and not envs.SGLANG_BLACKWELL_OVERLAP_SHARED_EXPERTS_OUTSIDE_SBO.get()
7
    )
8

9
@classmethod
10
def enable_dispatch_shared_one_stream_overlap(cls):
11
    return is_sbo_enabled() and not is_blackwell()
12

13
@classmethod
14
def fuse_shared_experts_inside_sbo(cls):
15
    return (
16
        cls.enable_combine_shared_two_stream_overlap()
17
        or cls.enable_dispatch_shared_one_stream_overlap()
18
    )

1
@classmethod
2
def enable_combine_down_gemm_two_stream_overlap(cls):
3
    return (
4
        is_sbo_enabled()
5
        and (
6
            get_moe_runner_backend().is_flashinfer_cutedsl()
7
            or (get_moe_runner_backend().is_deep_gemm() and not is_blackwell())
8
        )
9
    )

重叠的第二层：两个子 batch 交替

SBO 重叠的是“同一层内 combine 与 down GEMM”。如果整层的通信量更大、单靠层内重叠盖不住，就需要 TBO（two batch overlap）：把一个 batch 切成两个子 batch，让子 batch A 的注意力与子 batch B 的 MoE 通信同时进行，反之亦然。

实现上最直观的证据是 dispatcher 的数量：

1
class MaybeTboDeepEPDispatcher(BaseDispatcher):
2
    def __init__(self, runner_backend=None, **kwargs):
3
        super().__init__()
4
        num_inner_dispatchers = 2 if is_tbo_enabled() else 1
5
        ...
6
        self._inners = [
7
            DeepEPDispatcher(runner_backend=runner_backend, **kwargs)
8
            for _ in range(num_inner_dispatchers)
9
        ]
10

11
    def _execute(self, name, tbo_subbatch_index: Optional[int] = None, **kwargs):
12
        return getattr(self._inners[tbo_subbatch_index or 0], name)(**kwargs)

两个 DeepEPDispatcher 实例，各自持有一份 handle 与 src2dst。这不是为了并发调用同一个通信组，而是因为两个子 batch 的 dispatch 与 combine 必须能独立追踪：子 batch A 的 combine 还没结束时，子 batch B 的 dispatch 不能覆盖 A 的 handle。

切分点由 compute_split_seq_index 决定，_is_two_chunk_split_enabled 负责判断“这条 batch 值不值得切”：

1
vanilla_split_seq_index = _split_array_by_balanced_sum(extend_lens)
2
left_sum = sum(extend_lens[:vanilla_split_seq_index])
3
overall_sum = sum(extend_lens)
4
threshold = get_tbo_token_distribution_threshold()
5
assert threshold <= 0.5
6
want_two_chunk = left_sum < overall_sum * threshold or left_sum > overall_sum * (1 - threshold)

默认阈值是 0.48。它的含义是：如果按“尽量均分”切出来的左半部分 token 数落在总量的 48% 以外（即严重不均），就改用“按序列边界切”的方式，让两个子 batch 的 token 数接近一半。阈值取 0.48 而不是 0.5，是为了给边界情况留一点余量，避免恰好 50/50 时反复摇摆。

对 decode 来说，extend_lens 不是 token 数，而是每条请求的行数——每条请求 6 个验证 token，所以两个子 batch 各有 $3b$ 行左右。这带出一个重要约束：TBO 在 DP Attention 下需要所有 rank 一致。TboDPAttentionPreparer 用一次全局 all-gather 收集各 rank 的 can_run_tbo，再取最小值：

1
local_can_run_tbo_aggregated = min(partial_global_info_cpu[:, 0].tolist())

只要有一个 rank 不能切（比如它这一步混入了 prefill），整个 DP 组就都不能切。原因很直接：TBO 改变了每一步前向的 token 顺序与 KV 槽位映射，如果某些 rank 按两个子 batch 跑、另一些按一个 batch 跑，DP gather 拼出来的全局 batch 顺序就对不上。

TBO 不是免费的：三个边界

SGLang 博客给出的实测数字，把 TBO 的适用边界画得很清楚：

• prefill：同一 token 数下吞吐提升 27%–35%；开启 TBO 后单卡可处理 16K token 而不 OOM，相比最优的非 TBO 配置再提升 40.5%；
• decode：batch 小于 64 时收益很小甚至为负，32 token/device 时是 -27%；256 token/device 时提升 25.5%，吞吐达到 22,310 tok/s；
• 模拟 MTP：128 条请求、每条生成 256 个 token 的 decode step 下提升 35%，吞吐 17,552 tok/s 对 12,929 tok/s。

为什么 decode 小 batch 会变慢？因为 TBO 把一次前向拆成两次，每次的 batch 更小，GEMM 的 tile 利用率下降、kernel 启动次数翻倍；当每步的注意力时间很短时，通信本来就能被自然盖住，再拆一次只是增加开销。博客里的判断标准是“注意力处理时间是否足够长”——TBO 的收益来自“用 A 的注意力时间盖住 B 的通信”，注意力太短就没有东西可盖。

GLM-5.3 的 decode 恰好落在有利的一侧：每条请求 6 个验证 token，batch 的有效行数是请求数的 6 倍；DSA 的索引器还要对全部历史打分，长上下文下单步注意力时间远大于普通模型。最保守地算，按 8K 上下文、32 条请求，192 个验证行里每条 DP rank 分到 24 行，仍在门槛以下，单看 token 数 TBO 未必划算；但这些 24 行共享同一段历史 KV，索引器要扫的 key 数是上下文长度而不是行数。上下文到 100K 时，索引器读取是每卡 8.9GB/step，注意力时间以毫秒计，远远超过 MoE 通信的百微秒级，TBO 有充足的遮盖空间。判断 TBO 是否开启，应该看“单步注意力时间”，而不是“每 rank 多少行”。

反过来说，短上下文、低并发、纯 dense 模型的小 batch decode，开 TBO 很可能亏。这也是为什么它只能作为显式开关，而不是默认开启。

1
def replay_prepare(self, batch, ...):
2
    tbo_split_seq_index, tbo_split_token_index = compute_split_indices_for_cuda_graph_replay(...)
3
    self._tbo_children_num_token_non_padded[...] = (
4
        TboForwardBatchPreparer.compute_tbo_children_num_token_non_padded_raw(
5
            tbo_split_token_index=tbo_split_token_index, ...
6
        )
7
    )

重叠的第三层：DP gather 与 MoE 的自然交错

除了 SBO 与 TBO，还有一层不需要显式开关的重叠：层的流水。一层里，DP gather 在注意力之后、MoE 之前；reduce-scatter 在 MoE 之后、下一层注意力之前。gather 的 2.36MB 与 dispatch 的 9.44MB 是两个独立的集合通信，前者完成后后者才能开始（dispatch 需要全局 batch），所以它们之间没有重叠空间。

真正能交错的是相邻两层：第 $l$ 层的 reduce-scatter 与第 $l+1$ 层的 A 投影、Q/KV 上投影可以并行，因为后者只依赖本卡的 hidden。SGLang 的层边界抽象（attn_boundary/ffn_boundary）就是为这件事准备的：finish 里发起 reduce-scatter，prepare 里做下一层的 RMSNorm 与投影，中间用一个 stream 等待把依赖接上。

这一层的收益在 prefill 里更明显：一个 32K 的 chunk，reduce-scatter 是 MB 级，下一层的投影是几十毫秒的计算，重叠能盖住大部分通信。decode 里每层的计算只有几十微秒，reduce-scatter 也是微秒级，交错的空间有限，更多要靠 SBO 与 TBO。

把三种重叠放在一张表里

三者不是替代关系。SBO 解决“一层内 combine 发得比 GEMM 算得慢”，TBO 解决“整层通信量大于单层计算能盖住的量”，层间流水解决“相邻层的独立计算能不能填住通信尾巴”。一个部署可以同时开 SBO 与 TBO，但要注意 SM 的竞争：SBO 已经给 combine 留了 3 或 32 个 SM，TBO 又要求两个子 batch 的通信与计算同时进行，SM 总数不变的情况下，留给 GEMM 的 SM 会更少。这就是为什么博客里强调“TBO 的收益取决于注意力时间”——注意力是纯计算、不抢通信 SM，它越长，越能盖住被压缩的 GEMM 资源。

从字节到毫秒：两套硬件下的账

前面的字节账只能给出带宽下限。真实的 dispatch 时间由延迟主导，尤其是在跨节点时。SGLang 博客给过一个实测：96 张 H100、9 个节点部署 DeepSeek，decode 阶段单层 dispatch 约 0.17ms，而单元测试里 DeepEP 的潜力是 0.06ms；两者之间的差距来自“通信内核在忙等数据”——发送端把 token 发走后，接收端的 kernel 在自旋等待，SM 被占住但没有有效工作。博客还提到一个反直觉的实验：在 send 与 receive 之间插入慢速 dummy kernel，反而把 dispatch 时间降到 0.09ms，因为 dummy kernel 让发送与接收的时间窗错开，减少了无效自旋。

这个数字对 GLM-5.3 的部署有直接含义。按 75 个 MoE 层算，单层 0.17ms 就是每步 12.75ms 的 dispatch 时间；如果 combine 同量级，通信会占到 decode 单步的绝大部分。单机 8 卡 NVLink 的情况好得多：单层 dispatch 每 rank 只发约 192 行、1.18MB，900GB/s 下带宽时间约 1.3 微秒，真正花掉的是 kernel 启动、屏障与同步，量级估计在 20–40 微秒；75 层约 1.5–3ms，与权重读取的 0.85ms、KV 读取的 0.70ms 同量级。

所以同一套模型在不同拓扑下的瓶颈完全不同：

这张表解释了为什么 GLM-5.3 的单机配方与 DeepSeek 的跨机部署在调参上几乎没有共同语言：前者要压的是每层几十微秒的固定开销，后者要压的是每层几百微秒的往返延迟。

失败模式：启动阶段与运行阶段各自会踩的坑

这一段列出部署时最常遇到的错误，以及它们对应的代码位置。

1
@classmethod
2
def set_dispatch_mode_as_low_latency(cls):
3
    state = cls._state()
4
    if state.dispatch_mode == DeepEPDispatchMode.NORMAL:
5
        cls.clean_buffer()
6
    state.dispatch_mode = DeepEPDispatchMode.LOW_LATENCY

1
Only use N SMs for DeepEP communication. This may result in highly suboptimal performance.
2
Consider using --deepep-config to change the behavior.

与站内几篇的关系

这一段把这篇放回整个知识网络里，方便按需延伸：

• dispatch/combine 的内核实现、NVSHMEM 细节与 DeepEP 的两类 kernel 设计，见 DeepEP 完全拆解；
• DP Attention 与 EP 的并行拓扑、EPLB 的放置算法，见 SGLang 源码完全拆解（十七）：DP Attention 与专家并行；
• 弹性 EP、故障恢复与专家布点重排，见 SGLang 源码完全拆解（十八）：弹性 EP 与故障恢复；
• MoE 层的路由、分组 GEMM 与前向拼装，见 vLLM 源码完全拆解（八）：MoE 层的前向执行 与 DeepInfer 源码拆解（三十五）：MoE 层的 MLP；
• 本系列的前五篇：入口与 SGLang 全链路见 第一篇，vLLM 的算子融合见 第二篇，prefill 的分块与 CP 见 第三篇，PD 分离见 第四篇，vLLM 的 prefill 切分见 第五篇。

换一个拓扑重算账：PD 分离的 decode 实例

前面的账本都建立在“单机 8 卡、全部在一个节点”的前提上。GLM-5.3 的生产形态更可能是 PD 分离：prefill 实例与 decode 实例各占若干节点，KV 与索引器缓存跨节点交接（见第四篇）。这时 MoE 的账本要重算一次，因为 EP 组跨了节点。

设 decode 实例为 4 个节点 × 8 卡，EP32，注意力保持 DP Attention（attn_dp_size = 32，attn_tp_size = 1）。GLM-5.3 的 256 个专家被切成 32 份，每卡 8 个本地专家。对 $b = 32$ 条请求、每条 6 个验证行、全局 192 行：

• 每 token 的 8 份：8 个专家均匀落在 32 个 rank 上。某个专家落在本节点 8 个 rank 内的概率是 $8/32 = 25\%$，所以每 token 期望有 2 份走节点内 NVLink、6 份过 IB，跨节点份额 75%；
• 本地专家只有 8 个：每卡的 masked 缓冲是 $[8, 1024, 6144]$，BF16 下约 100MB，比 EP8 的 402MB 少了四分之三。这就是 Wide-EP 换来的显存；
• 低延迟 QP 数降到 8：队列变少，单队列的消息更密，对端处理压力集中。

跨节点的代价要直接算清楚。dispatch 每层每行有 6 份 × 6144 字节走 IB，192 行约 7.1MB；combine 是 BF16，同样 6 份但每份 12288 字节，约 14.2MB。两者相加，每层约 21.2MB 过 IB，75 层约 1.59GB。按每节点 8 张 IB 网卡、单卡 400Gb/s（50GB/s）估算，单节点出口带宽 400GB/s，一个节点分担的份额约 $1.59\text{GB} / 4 = 398\text{MB}$，带宽时间约 1ms。但延迟才是主导：跨节点 RDMA 的往返是微秒级，单层 dispatch 在博客的实测里是 0.17ms，75 层就是 12.75ms。带宽账只有 1ms，延迟账却多出一个数量级——这正是 Wide-EP 部署必须靠 TBO 重叠的原因。

TBO 在这个形态下是否划算，取决于 decode 的注意力时间。8K 上下文时索引器读取每卡约 0.73GB，按 4.8TB/s 是 0.15ms；主注意力读取 3.35GB 约 0.70ms。一层注意力的 MoE 前计算约 0.85ms，而一层 MoE 通信约 0.17ms——注意力足够长，TBO 有遮盖空间。但如果 batch 很小（每条 DP rank 只有 4 条请求、24 行），注意力时间会缩到几十微秒，TBO 反而亏。这就是博客里“batch 小于 64 时 TBO 为负”的机制：不是 TBO 本身慢，而是没有足够长的注意力去盖住通信。

这也给出一个部署层面的结论：Wide-EP 与 TBO 应该成对出现。只扩大 EP 不开 TBO，跨节点份额增加但通信裸露，尾延迟会变差；只开 TBO 不扩大 EP，单节点内 EP8 本来就能靠 SBO 与层间流水盖住大部分，TBO 的额外切分收益有限。

精度口径：dispatch 用 FP8，combine 用 BF16

最后把量化口径单独说清楚，因为它直接改写上面的字节账。

SGLang 在普通模式的 dispatch_a 里对激活做 128 一组的 FP8 量化，低延迟模式则在 buffer.low_latency_dispatch 里传 use_fp8=self.use_fp8。两条路径的共同点是：发送的是 FP8，接收的是 FP8，量化发生在本地、反量化发生在专家 GEMM 内部。

DeepGEMM 的 FP8 grouped GEMM 接受 FP8 激活与 FP32/UE8M0 的 scale，在累加时统一按 FP32 处理，输出 BF16。也就是说，dispatch 环节的精度损失只有一次 128 组量化的舍入，误差量级约 $2^{-7}$（E4M3 的尾数位）。专家输出已经在 BF16 上，combine 再做 8 份求和，总误差与注意力 FP8 KV 的误差同阶，不会成为瓶颈。

如果要把 combine 也压到 FP8，需要额外传回每份输出的 scale，并接受 8 份求和时的二次舍入；DeepEP 目前的接口把 combine 输入固定为 BF16，正是为了避开这个问题。这条约束在调优时可以看作硬边界：dispatch 可以量化，combine 不可以。

对账单的影响：

从 BF16 到 FP8 dispatch，省下的是 0.7GB/step；从 FP8 dispatch 到全 FP8，理论上还能再省 0.7GB，但当前接口不支持，而且精度收益不值得。这就是为什么各家推理框架的 MoE 通信优化都集中在 dispatch 侧：它是唯一可以安全量化的那一段。

和 DeepEP 的 EPBuffer 接口对齐：两代接口的语义映射

前面引用的代码主要来自 SGLang 的封装。DeepEP 本身正在从 legacy 的 Buffer 接口向 EPBuffer 统一，几个概念值得记下来，因为它们决定了框架层的抽象：

• 统一接口：高吞吐与低延迟的 EP 操作共用一个 EPBuffer，初始化时直接给 MoE 参数（num_max_tokens_per_rank、hidden、num_topk、num_experts），SM 与 QP 数由 get_theoretical_num_sms(num_experts, num_topk) 解析估算，也可以每次调用时用 num_sms 覆盖；
• 延迟收尾：defer_epilogue=True 配合 async_with_compute_stream=True 时，调用直接返回 EventOverlap，wait() 时才在计算流上跑收尾并返回结果。SGLang 的 dispatch_a/dispatch_b 拆分，本质上是把这件事包得更显式；
• 不需要 CPU 同步的 decode：do_cpu_sync=False 时输出按容量分配，用 handle.psum_num_recv_tokens_per_expert 识别有效区间，这正是 masked_m 的来源；
• 对齐：expert_alignment 设成 grouped GEMM 的 token 对齐，DeepGEMM 用 deep_gemm.get_mk_alignment_for_contiguous_layout() 取值，SGLang 里写死 128，与前面代码一致。

这些概念在 legacy 与 EPBuffer 两套接口下名称不同，但语义一致。理解它们的对应关系，才能在看不同版本的 SGLang 或 DeepEP 代码时不迷路：dispatch_a/dispatch_b 对应 EPBuffer 的“发起 + 延迟收尾”，masked_m 对应 psum_num_recv_tokens_per_expert，expected_m 对应 GEMM 的 tile 选择参数。

小结

把这一篇压缩成几句话：

1. 一次 MoE 前向有四段跨卡动作：DP gather、dispatch、combine、reduce-scatter。只算中间两段会低估 15%–20% 的通信量，漏掉 gather 还会算错 batch 形状；
2. decode 与 prefill 必须用两套布局：低延迟模式的固定容量 masked 布局换来 CUDA Graph 与低延迟，普通模式的变长 contiguous 布局换来越长越省的带宽；Auto 模式在 DP Attention 下不能同时支持两者，PD 分离是解法；
3. 容量是硬约束：num_max_dispatch_tokens_per_rank 决定缓冲、QP 深度与 masked GEMM 的显存，协议上限是 1024，框架用 assert 把超限挡在启动阶段；
4. 重叠分三层：SBO 把 combine 藏进 down GEMM，TBO 用两个子 batch 互相遮盖，层间流水填补相邻层的通信尾巴；TBO 在 decode batch 小于 64 时是负收益，判断是否开启要看单步注意力时间：长上下文下索引器扫描让注意力以毫秒计，TBO 才有东西可盖；
5. 拓扑决定瓶颈：单机 NVLink 下 dispatch 是几十微秒的带宽与启动开销，跨节点 IB 下是百微秒级的延迟与忙等，调参重点完全不同。

下一篇会把这条链路里最后一个没打开的黑盒补上：采样之后，token 如何变成文本、stop string 与结构化输出如何截断流式响应，以及一次请求结束后 KV 页与前缀缓存如何回收。那一段决定的是“输出侧”的尾延迟，和这一篇的“输入侧通信”正好对称。

参考资料

1. GLM-5 技术报告（GLM-5.3 的模型结构与 DSA 设计，arXiv:2602.15763）
2. zai-org/GLM-5.3 模型卡（744B-A40B、FP8、78 层、256 专家）
3. SGLang GLM-5.3 Cookbook（TP8/EP8、DP Attention、MTP 的启动参数）
4. SGLang 官方博客：Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs（模式兼容性表、TBO 实测与 dispatch 0.17ms）
5. DeepEP GitHub 仓库（EPBuffer、normal/low-latency 接口与网络配置建议）
6. SGLang 源码：token_dispatcher/deepep.py（两种模式、缓冲计算与 overlap args）
7. SGLang 源码：batch_overlap/single_batch_overlap.py（SBO 参数与共享专家重叠）
8. SGLang 源码：batch_overlap/two_batch_overlap.py（TBO 切分、CUDA Graph 插件与双 dispatcher）
9. SGLang 源码：moe_runner/deep_gemm.py（masked grouped GEMM 与 combine overlap）
10. SGLang 源码：layers/dp_attention.py（DP gather/scatter 与 gatherv）
11. DeepGEMM GitHub 仓库（FP8 grouped GEMM 与 masked/contiguous 两种布局）
12. AMD ROCm《The vLLM MoE Playbook》（DP+EP 数据流图）