DeepInfer 源码拆解（十三）：DP Attention 与 Wide-EP——不做张量并行的四轴并行拓扑

TP 到底切了什么

张量并行把一个线性层的权重矩阵按列或按行切开。以 Y = XW、W 形状 [K, N] 为例，列并行把 W 按 N 切成 W_1 ... W_p，每个 rank 算 Y_i = XW_i，输出按列拼接；行并行把 W 按 K 切，每个 rank 算部分和 Y_i = XW_i，最后 all-reduce 求和。Megatron-LM 的经典做法是 attention 的 QKV 投影用列并行、输出投影用行并行，MLP 的 gate/up 用列并行、down 用行并行，于是一个 Transformer 层里有两处 all-reduce：

all-reduce 的耗时不只取决于字节数。按经典的 α-β 模型，一次 ring all-reduce 的延迟约为：

其中 $p$ 是并行度，$\alpha$ 是单次消息的固定延迟，$\beta$ 是链路带宽，$S$ 是要规约的字节数。第一项与数据量无关，只与 rank 数和网络延迟有关；第二项才是带宽项。decode 阶段每步的 token 数很少（比如 60 个并发序列、每 rank 每步 60 个 token），$S$ 很小，TP 的代价几乎全部落在第一项上：40 层、每层两次 all-reduce，就是 80 次全局同步。即使每次只要 10–20 μs，也会给一个本已压到毫秒级的 step 增加 1 ms 量级的固定开销。

MoE 的账本正好相反

DeepSeek 系列模型的主体参数在 MoE 专家里。V4.1-Flash 的配置是 hidden_size=5120、moe_intermediate_size=2304、n_routed_experts=384、num_experts_per_tok=6、num_hidden_layers=40。单个专家的参数量约为：

三个矩阵分别是 gate、up、down；按 FP4 权重每元素 0.5 字节计，一个专家约 17.7 MB。384 个专家合计约 6.8 GB/层，40 层约 272 GB——这才是模型权重的大头。相比之下，一层注意力的 Q/KV 低秩投影、输出投影加起来只有千万级参数。

于是两种切法的收益完全不同：

• TP 切注意力：每层省下的权重读取量有限，却要付出每层两次 all-reduce 的固定延迟；而且 V4.1-Flash 的 num_key_value_heads=1，KV 只有一个头（MLA 的低秩 latent），按头切分根本切不出并行度，只能把 latent 本身切开再做聚合，复杂度更高。
• EP 切专家：每卡只读 physical / EP 个专家，权重读取量按 EP 线性下降；通信只发生在 MoE 层，且只搬“被路由到的 token”，不搬整层激活。

官方部署文档把这两点总结得很直接：prefill 用 EP2–8 / DP2–8，“用 HBM 允许的最小 EP/DP”；decode 用 EP64–128 / DP64–128（Wide-EP），“用可用 GPU 允许的最大 EP/DP”，并且明确写着 “TP and CP are not used for now”。这不是一句省略，而是这套模型结构下的最优解。

一个容易误读的地方：DP 不等于“复制整个模型”

严格说，DeepInfer 的 DP rank 复制的是注意力与稠密部分，不是全部权重。MoE 专家由 EP 切分（EP 组的构成见下一节），因此每个 DP rank 的显存账单是：

这正是“DP Attention + EP MoE”这个组合的含义：注意力按请求复制，专家按权重切分。它和 DeepSeek-V3/R1 在线系统的“MLA/共享专家 DP、路由专家 EP”是同一套思路，本站此前拆过的 DeepSeek-V3/R1 推理系统 给过生产口径的对照：prefill 是 EP32/DP32，decode 是 EP144/DP144。

（图源：AMD ROCm vLLM MoE Playbook 中的 DP + EP 部署示意。这张图解释了为什么“DP 复制注意力”与“EP 切分专家”可以同时成立：两者切的是不同的东西，通信只发生在 MoE 层的 token 搬运上。）

全局 rank 的编号规则

进程组的 rank 不是随便排的。worker/base.py 里写得很清楚：

1
self.dp_rank = parallel_config.data_parallel_rank        # engine_rank % dp_size
2
self.global_rank = parallel_config.engine_rank * parallel_config.context_parallel_size + cp_rank

而 config.py 里 data_parallel_rank = engine_rank % data_parallel_size。把两者合起来看，全局 rank 的布局是：

也就是先排 DP、再排副本、最内层排 CP。用 einops 的记号就是 (replica dp cp)：CP 是内层，DP 是中层，replica 是外层。选这个顺序不是随意的：同一个 CP 组内的 rank 必须落在同一台机器、同一个 NVLink/scale-up 域里，因为 CP 的 all-gather 每层都会发生；而 DP 副本之间本来就没有逐层通信，放在外层最安全。

四类组的切法

1
ranks = torch.arange(max(enp_size, dp_size * cp_size))
2

3
# World：全部 rank 一个组
4
self.world = _split_group([ranks.tolist()], ...)
5

6
# Local：每个 rank 自成一组
7
self.local = _split_group(ranks.unsqueeze(-1).tolist(), ...)
8

9
# DP 组：固定 (replica, cp)，沿 dp 维建组
10
dp_ranks = rearrange(ranks, "(replica dp cp) -> (replica cp) dp", dp=dp_size, cp=cp_size)
11

12
# CP 组：固定 (dp)，沿 cp 维建组
13
cp_ranks = rearrange(ranks, "(dp cp) -> dp cp", cp=cp_size)
14

15
# EP 组：连续的 ep_size 个 rank
16
ep_ranks = rearrange(ranks, "(edp ep) -> edp ep", ep=ep_size)
17

18
# ENP 组：固定 replica，沿 enp 维建组
19
enp_ranks = rearrange(ranks, "(replica enp) -> replica enp", enp=enp_size)
20

21
# EP-in-DP：同样是连续 ep_size 个 rank
22
ep_in_dp_ranks = rearrange(ranks, "(edp ep_in_dp) -> edp ep_in_dp", ep_in_dp=ep_size)

逐个解读：

DP 组。

对某个固定的 CP rank 来说，DP 组成员是 rank 间隔为 cp_size 的一组 rank。DP 组只用于控制面（后面第“集合通信账本”一节会看到），不参与逐层前向。

CP 组。 (dp cp) -> dp cp 的切法让 CP 组是所有相邻的 cp_size 个 rank。结合全局 rank 公式，这正好是同一个 engine 内部的 cp_size 个 worker：一个引擎进程加若干 worker-cp{n} 子进程。llm_engine.py 的 _init_workers 印证了这一点：driver 占 local_rank=0，其余 CP worker 用 cp_rank % ngpus 作为本机 GPU 号——一个引擎覆盖 cp_size 张卡，而 DP/EP 的并行度来自“有多少个引擎”。

EP 组。 (edp ep) -> edp ep 是最朴素的做法：把全局 rank 按 ep_size 连续分段，每一段是一个 EP 组。这意味着：

• 默认 cp_size = 1 时，一个 EP 组恰好就是一个引擎的全部 rank，EP 组和“实例”重合。
• cp_size > 1 时，一个引擎内的 cp_size 个 rank 仍然在同一个 EP 组里，每个 rank 切走 physical / EP 个专家。
• 当 ep_size 小于 world_size 而 dp_size = world_size 时，多个相邻的 DP rank 也会被划进同一个 EP 组——这正是 benchmark.py 直接令 ep_size = world_size、dp_size = ep_size // cp_size 的原因：在这种写法下，所有 rank 同属一个 EP 组，DP 组退化为“每个 rank 自己”。

这一步是理解“EP 组和 DP 组是两套不同切法”的关键：DP 组沿 cp_size 为步长跨 rank 取，EP 组沿连续区间取。 生产上官方取 #DP = #EP，两者是同一个 rank 集合，只是两种视角；一旦两者不等，两组就交叉，代码允许这种配置，但部署文档说明 prefill 的 EP/DP 总是成对给出。

ENP 组。 切法与 DP 相同，只是步长换了。world_size = max(DP×CP, ENP)，所以当 ENP > DP×CP 时，world_size 会比“模型副本数 × CP”更大，多出来的 rank 只用来分 Engram 表。

一个容易被忽略的初始化细节：子组必须“预热”一次

init_device_groups 的 docstring 写了一句很典型的工程注释：默认进程组改成 CPU/gloo 后端之后，NCCL/HCCL 子组失去 eager 初始化，全部变成 lazy——“必须先跑一次 collective 才会真正建 comm”。

1
for value in self.__dict__.values():
2
    if not isinstance(value, ProcessGroup) or dist.get_backend(value) not in ("nccl", "hccl"):
3
        continue
4
    ...
5
    dist.all_reduce(torch.zeros(1).cuda(), group=value)

注释还特别点明：单 rank 组也不能跳过，因为 Engram 的 DeepEP 会通过 backend._comm_ptr() 复用这里建出的 communicator，空指针会导致段错误。这类细节不写进文章很容易被当成废话，但它恰好说明 DeepInfer 的通信层是“薄封装 + 直接触碰 NCCL 内部状态”的风格——nccl_memory.py 会直接遍历 c10d._world.pg_map 并读取每个组的 memory_stats()["total"]，定期打印每个 communicator 占用的显存。

CP 组顺带开了一条 gloo 通道

1
self.cpu_dp_group = _split_group(dp_ranks.tolist(), backend="gloo")
2
self.cpu_cp_group = _split_group(cp_ranks.tolist(), backend="gloo")
3
...
4
if cp_size > 1:
5
    self.mq = MessageQueue.create_from_process_group(self.cpu_cp_group, 1 << 20, 10)

CP 组额外建了一条 CPU 侧的 MessageQueue（1 MB 缓冲、10 个队列），用于 cp_broadcast_object：CP 内 driver 把 Python 对象（比如 InputMetadata 里的非张量字段、调用名和 kwargs）广播给其余 worker。为什么不用 NCCL？因为 NCCL 只能传张量，而 broadcast_tensor_dict 需要同时传“字典的结构信息”——它把张量元数据（dtype、size）和普通 Python 值经共享内存广播，再对张量本身做 dist.broadcast。这种“结构走 CPU、数据走 GPU”的拆分在任何支持 CP 的框架里都会出现，DeepInfer 的实现是把它收进一个 MessageQueue。

从 384 到 448：冗余专家不是“额外加几个”

V4.1-Flash 的 n_routed_experts=384，num_experts_per_tok=6。如果 EP=64，直接除不尽：384 / 64 = 6，其实整除；但 EPLB 还要加冗余副本。model_loader._configure_moe_redundancy 调用 resolve_num_extra_experts：

1
padding = -(num_routed_experts + min_num_extra_experts) % ep_size
2
return min_num_extra_experts + padding

假设冗余下限是 1（decode 的官方起点是“每 GPU 1 个冗余专家”，取整后总数可被 EP 整除）：

1
padding = -(384 + 1) % 64 = 63
2
extra   = 1 + 63 = 64
3
physical = 384 + 64 = 448
4
local    = 448 / 64 = 7

所以官方 Q&A 说 EP64 下“每 GPU 7 个专家（不含共享专家）”。“每 GPU 1 个冗余”不是一个固定的小数目，而是一个下限：当 logical + min 不能被 EP 整除时，resolve_num_extra_experts 会把冗余数补齐到下一个整除点——EP64 时补到 64，EP8 时则刚好补到 8。在这个模型上 384 恰好能被常见 EP 整除，于是补齐后的冗余数也落在 EP 的整数倍上，每个 rank 拿到的物理槽位数量完全一致——这是后面 grouped GEMM 能按 physical / EP 等分的前提。EP 越小，physical/EP 越大，每卡要扛的专家越多，这正是 Wide-EP 的反面。

参数容器：expert-major 的打包矩阵

FusedExperts 里每个 rank 只建自己的专家：

1
self.ep_group = PG.expert_parallel_group()
2
self.ep_size = self.ep_group.size()
3
self.n_local_routed_experts = self.n_routed_experts // self.ep_size
4
self.linear1 = ParallelRoutedLinear(
5
    cfg.hidden_size, self.hidden_dim * 2, self.n_local_routed_experts, ...
6
)
7
self.linear2 = ParallelRoutedLinear(
8
    self.hidden_dim, cfg.hidden_size, self.n_local_routed_experts, ...
9
)

ParallelRoutedLinear 的 docstring 说得很清楚：形状是 (n_local_experts * h_in, h_out)，也就是把多个专家的 gate/up 权重沿输入维拼成一个大矩阵，供 grouped GEMM 一次处理。运行时 process_moe_weight 再把它重排成 [E, K, N]：

1
deepinfer_w = src_w.view(n_experts, -1, src_w.shape[1]).mT.contiguous()

.mT 交换最后两维，让权重按 [expert, in, out] 排列。DeepGEMM 的 grouped GEMM 用连续布局（contiguous layout）按专家分段，配合每个专家的 token 数前缀和 psum_num_recv_tokens_per_expert，一次 kernel 把所有本地专家的矩阵乘做完。

共享专家和门控则是复制的：

1
self.shared_gate_up_proj = _replicated_linear(shared_expert.linear1.weight)
2
self.shared_down_proj = _replicated_linear(shared_expert.linear2.weight)
3
self.gate = ReplicatedLinear(..., weight=moe_module.gate.Wgate.weight)

共享专家只有 1 个，参数量小，复制到每个 rank 反而省掉一次通信；门控必须看到全部 384 个逻辑专家才能做 top-k，也天然是复制的。“哪些参数复制、哪些参数切分”不是拍脑袋，而是由“这个参数是否需要全局视图”决定的：门控需要全局专家分数，所以复制；路由专家只需本地计算，所以切分。

前向的两条路径：标准 DeepEP 与 MegaMoE

DeepseekMoE.__init__ 里有一个条件决定走哪条路：

1
self.use_mega_moe = (
2
    (PLATFORM.is_gpu or self.mma_type == "fp8xfp4")
3
    and self.mma_type in ("fp8xfp4", "fp8xfp8", "bf16xbf16")
4
    and PG.is_within_nvl_domain(PG.expert_parallel_group())
5
)

is_within_nvl_domain 的判断是：

1
if PLATFORM.is_npu:
2
    return True
3
return group.size() == 1 or group.size() <= deep_ep.get_physical_domain_size(group)[1]

也就是说，MegaMoE 只在 EP 组整体落在同一个 NVLink/scale-up 物理域内时才启用。EP64 跨节点时，组会超出单机 NVLink 域，只能走标准路径：

1. dispatch：self.ep_buffer.dispatch(...) 把每个 token 的 hidden state 按 top-k 路由发到目标专家所在 rank，同时把 top-k 权重和 EPLB 统计一起带过去；use_fp8_dispatch 让传输用 FP8，do_expand=True 让接收端直接展开成按专家分组的 token 块。
2. 本地 grouped GEMM：gate/up → SwiGLU → down，三段都在本地专家上完成。
3. combine：self.ep_buffer.combine(...) 把各专家的输出按原路送回，聚合 top-k 结果；bias=shared_hidden_states 意味着共享专家的结果可以在 combine 时顺带加进去，少一次独立 kernel。

MegaMoE 则把 gate、dispatch、grouped GEMM、combine 融进一个 deep_gemm.fp8_fp4_mega_moe kernel，用对称内存（deep_gemm.SymmBuffer）做 rank 间数据交换。官方 Q&A 的口径是：在 scale-up 域内，无论 EP 大小与 batch 大小，Mega MoE 都明显快于未融合版本。代价是它要求 EP 组不跨域，所以 Wide-EP 跨节点时仍然得回到 DeepEP 的两段式。

Wide-EP 为什么能提高 decode 的 TPS

decode 是权重带宽受限的：每步只处理很少的 token，但要把激活到的专家权重从 HBM 读一遍。每个 rank 每层读的专家权重大约是：

其中 $b_w$ 是每个权重元素的字节数（FP4 为 0.5），$n_{\text{local active}}$ 是本 rank 上真正被路由到的专家数。EP 越大，$n_{\text{local}}$ 越小；同时每个本地专家分到的 token 越多，grouped GEMM 的算术强度越高。用 V4.1-Flash 的数字粗算：

• EP64：每 rank 7 个专家，单专家约 17.7 MB，一层最多读约 124 MB；
• EP8：若沿用同样的最小冗余口径，每 rank 49 个专家，一层最多读约 867 MB；生产 prefill 会额外加冗余专家，实际数字更高。

两者相差约 7 倍。这就是 Wide-EP 在 decode 阶段的核心收益：把“每卡读全部激活专家”变成“每卡只读一小撮专家”，同时把每个专家的 batch 做大。代价是 dispatch/combine 的跨节点流量，以及所有 rank 必须同步参与每一层 all-to-all——这两点分别由 DeepEP 的高吞吐 kernel 和下一节的 DP lockstep 机制来处理。

（图源：DeepInfer 官方仓库 doc/images/wide_ep_decode_pareto.png。横轴是每 rank 的并发序列数，纵轴是吞吐；EP64 的曲线整体上移，说明同样的显存与延迟预算下，把专家摊到更多 rank 上能换到更高的 token 吞吐。）

每个 DP rank 是一个完整引擎

llm_engine.py 的 _init_workers 只在一个引擎内部拉起 cp_size 个 worker：

1
for cp_rank in range(1, cp_size):
2
    worker = SpawnProcessWithCrashHeader(... name=f"worker-cp{cp_rank}", ...)
3
    worker.start()
4
self.driver_worker = Worker(..., local_rank=0, cp_rank=0, ..., True)

cp_size=1 时没有子进程，driver worker 就是这张卡上唯一的执行体。每个引擎有自己的 Scheduler、BlockManager、CacheEngine 与 KV 池；请求由外部的负载均衡器分派进来，引擎之间不共享调度队列。ParallelProcessGroup 里的 DP 组因此只承担两件事：控制面的存活对齐和调度器的 prefill 投票。

存活对齐：一条 all_reduce(MAX)

LLMEngine.has_unfinished_requests 是入口循环判断“还要不要继续 step”的地方：

1
unfinished = self.scheduler.has_unfinished_seqs()
2
if dp_group.size() > 1:
3
    unfinished = torch.full((1,), unfinished, dtype=torch.int64, device=device)
4
    dist.all_reduce(unfinished, op=dist.ReduceOp.MAX, group=dp_group)
5
    unfinished = unfinished.item() > 0

只要任何一个 DP rank 还有未完成请求，所有 rank 都继续 step。ZOS 开启时这条 all_reduce 走 CPU 的 gloo 组（cpu_data_parallel_group），避免在 GPU 流上插一个同步点；非 ZOS 时走 NCCL 组。一个 int64 的 MAX all_reduce 数据量可以忽略，它的作用是把“谁先退出”变成一个全局一致的决定。

空步不是空转：placeholder step

如果某个 rank 这一步没有请求，调度器会返回空的 SchedulerOutputs。这时 worker 仍然要跑一次前向，只是用一个占位序列代替真实批次：

1
if is_placeholder:
2
    seq_metadata_list = [self.model_runner._placeholder_seq_metadata(is_prompt)]

为什么必须跑？因为 EP 组的 all-to-all 是集合操作，任何一个 rank 不调用，其他 rank 就会卡死。占位序列的 token 会被路由到某些专家、产生一次真实的 dispatch/combine，保证通信图完整；它的输出随后被丢弃。这个设计在数据并行 + 专家并行的系统里是必需的，代价是空步也要付一次前向与通信的钱。也正因如此，请求负载均衡（尽量让每个 rank 都有活）不是锦上添花，而是直接影响吞吐。

调度器里的 DP 投票

LLMEngine._create_scheduler 把 DP 组传给了 C++ 调度器：

1
return Scheduler(
2
    ...,
3
    PG.cpu_data_parallel_group() if envs.DEEPINFER_ZERO_OVERHEAD_SCHEDULING else PG.data_parallel_group(),
4
    self.scheduler_config,
5
    ...
6
)

SchedulerConfig 里有两个与 DP 相关的间隔：

• prefill_attempt_interval：NORMAL 引擎每隔多少个 decode step 尝试一次 prefill，采用 ALL 投票——所有 rank 都有活才一起做 prefill；
• prefill_any_attempt_interval：ANY 保底投票——任一 rank 有活就集体 prefill，防止某个 rank 的 prefill 请求被长期饿死。

为什么 prefill 要投票？因为一次 prefill 步的 token 数远大于 decode，如果各 rank 随意插入 prefill，EP 组的 batch 形状会频繁抖动，通信与 GEMM 的负载也会失衡。把“要不要在这一步做 prefill”提升为组级决策，是用一点调度灵活性换整组步调的稳定。

负载均衡在引擎之外

引擎内部不做跨 DP 的路由。官方 Q&A 描述了外层的两个均衡器：Prefill Load Balancer 按上下文长度把请求分成 <16K / 16–64K / 64–256K / ≥256K 四档，每档按上一轮的计算配额需求动态分配引擎数量；Decode Load Balancer 则在所有 decode GPU 上按“请求数”和“KV 总长度”两个维度做均衡。这样做的前提是 KV Cache 不绑定在单机上——DeepSeek 把块级 KV 放进了 3FS 存储集群，任何 prefill 机器都能命中任意前缀，因此不需要前缀亲和路由。本站拆过的 DeepSeek 3FS 与 DualPath 分别讲了这条存储路径与解码侧 KV 读取优化，可以和本节对照看。

为什么需要 CP，为什么生产没用

长 prompt 的 prefill 是计算密集型，一张卡算得太慢。CP 把一条序列的 token 沿序列维切给多个 rank，每个 rank 只算自己那段 query，但 attention 仍然需要看到完整的 K/V。标准的做法是在 attention 内部做一次 all-gather，把各 rank 的 K/V 拼成完整序列，再算局部 query 对全局 key 的注意力。

DeepInfer 当前的官方选择是先不用 CP，原因是部署层面的：CP 会把一个引擎的 KV、调度与元数据布局都变成“分段”的，而 Wide-EP 已经把 decode 侧的问题用专家切分解决了；prefill 侧的长上下文压力则交给 Prefill Load Balancer 按长度分档来处理。代码保留 CP，意味着将来模型更大、单卡 prefill 真正成为瓶颈时，可以打开它。

建组与缓冲区

CP 组是引擎内部的 cp_size 个相邻 rank。缓冲区由 userbuffer.allocate_cp 分配：

1
max_ag_bytes_per_session = max_num_tokens * max_ag_bytes_per_token * cp_group.size()
2
max_ag_bytes_per_session += max_num_ags_per_session * deep_ep.get_num_rdma_alignment()

max_num_tokens 取的是 max_num_prefilling_tokens，而后者在 finalize_model_config 里被除以了 CP 大小：

1
model_cfg.gpt.max_num_prefilling_tokens = model_cfg.gpt.max_num_batched_tokens // PG.context_parallel_group().size()

也就是说，开 CP 后每个 rank 的 prefill token 预算是总预算的 1/CP，缓冲按“本 rank token 数 × 每 token 每 rank 字节数 × CP”估出一次 gather 的大小。max_ag_bytes_per_token 由模型侧逐层累加得出：V4AttentionBase.get_max_ag_bytes_per_token 加上 SWA 的 qk 维、投影 KV 维、索引器 K 维等，最后取所有层的最大值。max_num_ags_per_session = 8 则允许一次 session 里同时发起多条 gather（模型首尾各一条、注意力若干条）。

zigzag 切分：每段从哪开始

CP 的核心是一个索引预处理 kernel prepare_cp_mirror。它接收每条的 query 长度与 key 长度，算出三样东西：

• mirror_cp_index：本 rank 要处理的 token 在原 varlen 批里的位置，长度 cp_mirror_len，-1 表示 padding；
• mirror_cp_reverse_index：逆映射，把 gather 回来的完整序列还原成原始顺序；
• 每个压缩率下的 ks / ke：Attention 的 K 范围，考虑 KV 压缩后 key 的数量变化。

纯 Python 参考实现把“zigzag”讲得很直白：

1
ps = (sq + 2 * cp_size - 1) // (2 * cp_size)     # 每条序列沿 2*cp_size 个块均分
2
for rank in range(cp_size):
3
    for half, block in enumerate((rank, 2 * cp_size - 1 - rank)):
4
        for j in range(ps):
5
            local_idx = ps * block + j

一条长度为 $L$ 的序列被切成 $2 \cdot p$ 块（$p$ 是 CP 大小），rank $r$ 拿走第 $r$ 块和第 $2p-1-r$ 块。也就是 rank 0 拿“最前一段 + 最后一段”，rank 1 拿“第二段 + 倒数第二段”，依此类推。之所以不用“连续切段”，是因为因果注意力下 rank 0 只算最早那段 query，却要等所有 rank 的 K；zigzag 让每个 rank 同时持有序列的头尾，各 rank 的 key 覆盖范围更接近、负载更均衡。这和 Ring-Attention 里按块轮转的做法是同一个思路的变体。

ks / ke 的计算则处理压缩 KV：对压缩率 $c$，本 rank 处理第 $i$ 段 query 时，需要看的 key 数量是

也就是说，压缩 KV 的窗口随 query 在序列中的位置增长，再按压缩率折算成压缩条目数。这样 attention kernel 不需要知道 CP 的存在，只拿到一个“本段 query 对应的 key 区间”。

前向里的三处 gather

打开 CP 后，HFModel.forward 在两个位置各做一次 all-gather：

1
if input_metadata.is_prompt and PG.context_parallel_group().size() > 1:
2
    input_metadata.prepare_for_mirror_cp()
3
    hidden_states = gather(hidden_states, input_metadata.mirror_cp_index)
4

5
...
6

7
if input_metadata.is_prompt and PG.context_parallel_group().size() > 1:
8
    with userbuffer.cp_session():
9
        gathered_hidden_states = userbuffer.cp.all_gather(hidden_states)()
10
        hidden_states = gather(gathered_hidden_states, input_metadata.mirror_cp_reverse_index)

入口处把本 rank 的 token 重排进 mirror 布局（每段的 token 拼在一起），跑完 40 层后再 gather 一次、按逆映射切回本 rank 的 token。之所以“进出各 gather、中间不切”，是为了让每层都只算本 rank 的 query——如果每层都重新切分，通信次数会乘以层数。

中间还有一处：注意力里的 KV all-gather。V4AttentionBase 的 prefill 分支：

1
with userbuffer.cp_session(enabled=use_cp):
2
    wait_projected_kv = _make_cp_gather_getter(projected_kv, use_cp) if not yoco_full_kv_stored else None
3
    q_a, kv_swa = self._project_q_and_swa(hidden_states, shared_hidden_bf16)
4
    ...

注意 projected_kv 的 gather 在 Q 投影之前发起，等待放在后面真正用到 KV 的时候。这是 CP 路径上最典型的重叠手法：all-gather 在通信流上异步进行，GPU 同时在计算本 rank 的 Q 投影、SWA KV 与索引器，等到要组装完整 KV 时再 wait()。prepare_cp_mirror 的测试用例覆盖了 cp_size ∈ {2,4,8}、随机长度、含 padding 的序列，参考实现逐元素对照，这部分逻辑的正确性是有回归保护的。

CPManager.all_gather 的返回值是一个闭包而不是张量：

1
handle = self._buffer.all_gather(x)
2
return lambda: handle.wait().view(gathered_shape).flatten(0, 1)

调用方拿到它之后可以先去干别的，等需要数据了再调用。这种“发起即返回、等待即取值”的接口，是 DeepEP 异步通信 API 的惯用形态，本站在 DeepEP 完全拆解 里讲过 EventOverlap 的那一套。

解包后的重新切分

gather 回来的 KV 是“按 rank 拼接”的顺序，而 attention 需要的是按序列顺序的完整序列。所以 attn.py 会用 mirror_cp_reverse_index 再 gather 一次——这里的 gather 是 TileLang 实现的按索引重排（不是集合通信），把 [rank][block] 布局还原成 [token] 布局。mirror_cp_reverse_index 的第 $i$ 项记录了“原始位置 $i$ 的 token 在 gather 结果里的位置”，包括 padding 的位置，所以输出张量按它的形状分配，填充行会在后续被 mask 掉。

与 vLLM

vLLM 的并行以 TP 为核心：ColumnParallelLinear / RowParallelLinear 是默认线性层，tensor_parallel_size 是主要参数，DP 与 EP 是在 TP 之上叠加的。DeepInfer 的 ReplicatedLinear 正好相反——所有线性层都复制，注意力不切分；专家切分从第一天就是 MoE 实现的主体。这不是能力差距，而是模型形态决定的：DeepSeek 的模型参数绝大部分在专家里，TP 切注意力几乎不省显存。

读者可以对照本站的 vLLM 源码完全拆解（十一）：张量并行与 Worker 看 TP 的一整套实现：权重切分、all-reduce、Executor 广播。DeepInfer 恰好是把那篇里的大部分机制省掉之后的形态。

与 SGLang

SGLang 的 DP Attention 与 DeepInfer 的思路一致：注意力按 DP 复制、MoE 按 EP 切分，用 deep_ep 做 dispatch/combine。差异在于 SGLang 仍然支持 TP，并在 DP Attention 模式下要把各 rank 的 hidden state 做 gather/scatter 来保证注意力的一致性；DeepInfer 不做 TP，DP rank 之间的注意力完全独立，唯一的同步是存活对齐与 prefill 投票。本站的 SGLang 源码完全拆解（十七）：DP Attention 与专家并行 可以拿来逐项对照。

与 TensorRT-LLM

TensorRT-LLM 的 Mapping 是一个显式的多维 rank 坐标系（tp、pp、cp、dp、ep 各自一组），DeviceMesh 在此基础上建组，Communicator 提供自定义集合通信原语。DeepInfer 没有这种通用坐标系，它直接按“DP/CP/EP/ENP”四次 rearrange 建组，并用一个 ParallelProcessGroup 对象持有全部组。灵活度不如 TensorRT-LLM，但因为只服务一个模型，拓扑是固定的，省掉了坐标系带来的抽象层。相关实现见本站 TensorRT-LLM 源码完全拆解（十一）：并行拓扑与通信。

三者的共同点

三个框架都收敛到同一个结论：大 MoE 模型推理的瓶颈在专家权重带宽，因此 EP 越大越好；注意力的跨卡同步则是纯开销，能不做就不做。 vLLM 通过 DP Attention、SGLang 通过 DP Attention、DeepInfer 通过“不做 TP”，走的是同一条路线，只是起点的默认值不同。

按 8 个输出组切，而不是按头切

前面的账只说明了“不做 TP 更好”，但没有说清楚 V4.1-Flash 的注意力参数是否本身就预留了并行空间——如果某个参数天然只能被整体复制，那么 TP 缺失就是结构决定的，而非选择。V4.1-Flash 的公开配置给出了一组值得琢磨的数字：num_attention_heads=64、head_dim=512、o_groups=8、o_lora_rank=1024、q_lora_rank=1280、kv_lora_rank 在公开 config 里没有直接出现。

o_groups=8 是其中最值得注意的一项：它把 64 个 query 头分成 8 组、每组 8 个头，mla_attn.py 的容器构造先断言“头数能被组数整除”，再把每个组的 Value 投影输入拼在一起：

1
self.n_wv_group = cfg.o_groups
2
assert self.n_head % self.n_wv_group == 0
3
self.o_head_dim = cfg.o_lora_rank or self.v_head_dim       # V4.1-Flash 中为 1024
4
mid_dim = self.n_wv_group * self.o_head_dim                # 8 * 1024 = 8192
5
wv_in_features = (self.kv_lora_rank + self.rope_head_dim) * (self.n_head // self.n_wv_group)
6
self.Wv = ReplicatedLinear(wv_in_features, mid_dim, bias=False, use_fp8_gemm=True)

两处细节值得展开。第一，Wv 的输入宽度是“组内头数 ×（KV latent 维 + rope 维）”，说明 8 个组是沿输出维度拼接的，而不是沿输入维度切分——所有组看到的是同一份压缩 KV。第二，每组经 Wv 得到 o_head_dim = 1024 宽的低秩表示，8 组拼起来是 8192 宽，再由 out_proj 投回 hidden_size = 5120；运行时侧 wv_group_dim = (num_heads // n_wv_group) * qk_head_dim = 8 × 512 = 4096 则是每组 Value 在低秩投影之前的宽度。Wv 与 out_proj 在容器里都是 ReplicatedLinear，没有按组切到不同 rank 上。

从张量并行的角度看，8 个输出组确实是一个天然的切分维度：把组切到不同 rank 上，每组只做本组 Value 的低秩投影，最后对 out_proj 的输入做一次聚合，就能把输出侧的计算摊开而不必按 query 头切分。

DeepInfer 当前没有这么做，原因不难推：每个 rank 的注意力仍然要看到全部 query 头去算 q·k，输出组切分只能省掉输出投影那一小段计算，收益有限，却会引入一层跨 rank 聚合。这组参数说明的是“如果要在这里做注意力 TP，入口是输出组而不是头”，而不是“现在已经在做”。out_proj 的输入已经按组展平成 n_wv_group * o_head_dim，它同样是一个 ReplicatedLinear——在 DeepInfer 里，连这层“天然可切”的投影也选择了复制，和前面的账保持一致。读这类配置时，区分“结构上开出的口子”和“部署上实际使用的切法”，比单看参数名更有价值。