DeepSeek-V4 训练并行调优：千卡与万卡配置

把训练从 1024 张卡扩到 8192 张卡，如果模型和全局 batch 都不变，每个数据并行副本分到的工作就会减少。原本能够连续送进流水线的 32 个 microbatch，可能只剩下 4 个。卡多了，流水线却更难填满。

这里以 Megatron-LM 训练 DeepSeek-V4-Pro 为例，从显存和并行分组开始，整理千卡、万卡集群的调优方法，再讨论 EP、PP、CP 的选择与优化效果。文中的算例可以复算，性能数字保留论文中的模型、硬件与实验条件。

DeepSeek-V4 官方报告介绍的训练基础设施继承自 V3。本文以 Megatron-LM 为实现环境讨论调优，涉及的实现条件以 2026 年 10 月的版本为准。配置表是计算示例和搜索起点，未做千卡或万卡实测。DeepSeek-V4 报告、Megatron-LM

模型与实现

DeepSeek-V4-Pro 的总参数约为 1.6T，每个 token 激活约 49B 参数，主体包含 61 个 Transformer 块。每个 MoE 层有 384 个 routed experts，每个 token 选择其中 6 个，另外有 1 个 shared expert。后面计算时，用到的 hidden size 为 7168，专家 intermediate size 为 3072。报告 §4.2.1

总参数和激活参数在调优时承担不同作用。前者关系到参数及优化器状态的存储，后者主要影响每个 token 的计算量。以 BF16 保存全部权重，单是权重就约为：

1.6\times10^{12}\times2\ \mathrm{byte}=3.2\ \mathrm{TB}.

这还没有算梯度和优化器状态。只看 49B 激活参数，无法判断模型是否装得下。

V4 还有三个与并行调优直接相关的变化。CSA/HCA 混合注意力使 CP 需要处理压缩块和样本边界；mHC 增加了激活与流水线边界的数据量；Muon 更新涉及逻辑完整的梯度矩阵，需要与参数分片共同设计。V3 的经验可以帮助定位问题，具体配置仍要重新验证。报告 §3.4

当前 Megatron-LM 已有 V4 的 hybrid attention、mHC 和 Muon 相关实现。实际搜索配置前，先看这条模型路径允许什么组合。

当前实现中的限制	对并行配置的影响
V4 hybrid attention 要求 TP=1，使用 Transformer Engine	后面的 V4 算例固定 TP1
CP>1 要求 packed THD 输入	数据和 packed-sequence 元数据要一起准备
packed 路径要求 cuDNN backend，CP>1 要求 contiguous 布局	普通注意力的 CP 配置不能直接套用
当前只支持 static CP，packed 路径尚不支持 deterministic mode	动态 CP 切换和确定性测试要按实现能力安排
不支持 `core_attn` checkpoint 和 `qkv_linear` offload	重算、卸载只能选择这条路径支持的模块

这些限制分别来自 V4 hybrid attention 与 packed CP 校验。硬件架构及 attention backend 还有额外校验，应连同 TransformerConfig 一起检查。

源码中的组件和测试说明实现已经存在。完整预训练的正确性、收敛与集群性能，仍需要实际训练来确认。

并行分组

先把几种并行的作用对应到训练对象。

并行方式	主要切分对象	需要重点观察的代价
TP，张量并行	层内矩阵	层内通信、矩阵切分后的计算效率
PP，流水线并行	模型层或模型块	气泡、stage 不均衡、边界传输
CP，上下文并行	同一条序列	attention 数据交换、边界处理
DP，数据并行	独立训练数据	梯度与参数同步、每副本 batch 缩小
EP，专家并行	不同专家	token dispatch/combine、路由不均衡
ETP，专家张量并行	单个专家内部的矩阵	专家内部通信、GEMM 粒度变化

Megatron Core 的 MoE Parallel Folding 允许 attention 和 MoE 使用不同分组。固定一个 pipeline stage，其中的同一批 GPU，在 attention 路径和专家路径有两种组织方式。MoE Parallel Folding，§3

设 GPU 总数为 $N$ ，attention 的数据并行度为 $D_a$ ，专家参数的数据并行度为 $D_e$ 。在本文采用的普通 folding 配置下，不加入额外的 GTP 重物化维度，有：

\frac{N}{PP}=TP\times CP\times D_a=ETP\times EP\times D_e.

用 1024 卡、PP8、TP1、CP1、ETP1、EP64 代入：

D_a=\frac{1024}{8\times1\times1}=128, \qquad D_e=\frac{1024}{8\times1\times64}=2.

每个 stage 有 128 张 GPU。attention 对应 128 个数据副本；MoE 对应 2 组专家副本，每组用 64 张 GPU 放置专家。

下面的图只表示逻辑分组，不表示额外申请了 GPU。

同一批 GPU 在 Attention 和 MoE 路径中的逻辑分组

这里 EP 已经包含在同一批 GPU 的另一套分组里。如果再写成 $N=TP\times PP\times CP\times DP\times EP$ ，就会重复计算 GPU。dense 参数和 expert 参数的同步组也不相同，通信量与优化器分片都要分别核算。

显存估算

模型状态只是一部分。一个 rank 的峰值显存可以拆成：

M_{peak}=M_{weight}+M_{grad}+M_{optimizer} +M_{activation}+M_{communication}+M_{workspace}+M_{runtime}.

最后几项经常决定配置能否运行。比如 dispatch 的接收缓冲要容纳路由波动，融合算子需要工作区，VPP 会改变同时存活的激活数量。只把模型参数除以 GPU 总数，容易漏掉副本和峰值。

这里先算一个可检查的下界。忽略 bias，一个 SwiGLU routed expert 的三个矩阵共有：

P_{expert}=3hf =3\times7168\times3072 =66,060,288

个参数。假设某个 PP stage 放置 8 个完整的 MoE 层，ETP1，使用 BF16 常驻 routed 权重，且不再对权重做 FSDP 分片，那么：

M_{routed\ weight}=8\times\frac{384}{EP}\times P_{expert}\times2.

在 1024 卡、PP8、TP1、CP1 下，结果如下。GB 采用十进制单位。

EP	每层每 rank 的 routed experts	expert DP	8 层 routed 权重约占
32	12	4	12.68 GB
64	6	2	6.34 GB
128	3	1	3.17 GB

这个表只计算主体中的 routed 权重，shared expert 和 attention 都没包含，MTP 也没包含。61 个块不均匀划分，意味着各 stage 的实际占用还会不同。

可以看到，增大 EP 能降低常驻专家权重，但同时缩小了 expert DP。优化器状态若沿 expert DP 分片，其变化就不能直接照抄权重这一列。Muon 还有矩阵完整性和分桶约束，必须以实际实现分配出的状态为准。

激活占用则要在真实 schedule 下测峰值。选择性重算如果省出了显存，可能允许减少 PP、调整 EP，或者使用效率更高的 microbatch。比较方案时，要把这些后续变化一起考虑，只比较同一配置中开关重算的耗时，可能错过更好的组合。

PP 与 microbatch

设全局 batch 为 $B$ 条 packed 序列，一个 microbatch 有 $b$ 条，attention DP 为 $D_a$ ，每次参数更新累积 $m$ 个 microbatch，则：

B=bD_am,\qquad m=\frac{B}{bD_a}.

这里讨论固定长度、固定样本数的静态 packing。CP 分开计算同一条序列，EP 改变专家放置，两者都不增加独立样本数。动态 packing 应另查实际的 token budget 和 microbatch 计算方式。Megatron microbatch 计算实现

为了看清扩容后的变化，固定 $B=4096$ 、 $b=1$ 、序列长度 $S=8192$ ，TP1、PP8、EP64、ETP1。每次更新处理的 packed token 位置总数都是 $4096\times8192=33,554,432$ ；如果存在 padding 或 loss mask，实际计入损失的 token 数还要单独统计。

配置	GPU	CP	attention DP	expert DP	累积 microbatch 数 $m$
A，千卡起点	1024	1	128	2	32
B，主要扩 DP	8192	1	1024	16	4
C，增加 CP	8192	4	256	16	16

这些配置满足分组与 batch 的算术约束，尚未证明显存、数值或性能可行。其中 C 还依赖前面列出的 V4 packed CP 条件。

对均衡的、非交错的 1F1B 流水线，设 stage 数为 $p$ ，忽略通信和优化器时间，气泡占比可以粗估为：

f_{bubble}\approx\frac{p-1}{m+p-1}.

代入 $p=8$ ，A、B、C 分别约为 17.9%、63.6%、30.4%。这是理想调度的估算，实际 V4 的混合 attention、mHC 和 stage 不均衡都会改变结果。

B 从 A 扩了 8 倍 GPU，每个流水线副本的 microbatch 却从 32 降到 4，流水线填充和排空的代价更难摊薄。C 通过 CP 减少 attention DP，把 microbatch 数提高到 16；后面还需要检查它增加的通信与计算形状变化。

这里有一个容易遗漏的实现条件。当前交错 VPP schedule 要求 PP ≤ microbatch_group_size ≤ m，B 的 $m=4<PP=8$ ，启用这条 VPP 路径会被拒绝。VPP 的搜索应从合法配置开始。schedule 校验

61 层怎么切

61 不能被 8 整除。还要考虑 embedding、prediction head 和 MTP 的额外负载，各 stage 分到相同数量的块也未必等时。

V4 的 HybridModel 用原始 layer pattern 中的 | 表达 pipeline 划分；attention 和 MoE 可分别编码，pattern 的符号数也不等于论文中的 Transformer 块数。这条路径不能同时套用 --pipeline-model-parallel-layout 或旧的 VPP 分层参数。参数互斥检查

实际调整时，先保留正确的 attention/MoE 顺序，测每段的前向、反向和 P2P 等待时间，再移动切分位置。目标是降低最慢 stage 的时间，同时保持每个 stage 的显存可用。

VPP 增加交错机会，也会增加边界传输与调度工作。Zero Bubble 进一步把 backward 拆成输入梯度和参数梯度计算，将后者安排到空闲位置；优化器同步也需要专门处理。这些机制适合结合显存和时间线评估。Zero Bubble，§2–4

DeepSeek 开源的 DualPipe 同样需要模型实现专用的 overlapped_forward_backward 接口，通信计算的重叠要由这部分实现完成。DualPipe 实现说明

CP 与专家批次

上面的 C 看起来比 B 更容易填满流水线。再算一下专家每次拿到多少 token，就能看到另一个变化。

在本文 TP1、ETP1 的算例中，假设 EP64 组收集 64 个 rank 的唯一 token，每个 rank 在一次 microbatch 中持有 $bS/CP$ 个 token，那么一次 dispatch 覆盖：

T_{group}=EP\times\frac{bS}{CP}.

路由完全均匀、没有丢弃或 padding 时，单个 routed expert 接收的 token assignment 期望为：

\mathbb{E}[T_{expert}]=\frac{kT_{group}}{E},

其中 $k=6$ 、 $E=384$ 。每个 token 产生 6 个 routed assignment，不包含 shared expert 的工作。

配置	每次 dispatch 的唯一 token	每个专家的平均 assignment
A，CP1	524,288	8192
B，CP1	524,288	8192
C，CP4	131,072	2048

C 的累积次数增加了，但单次专家 GEMM 的 token 维度缩小到了四分之一。Grouped GEMM 的效率、量化与 permutation 开销都会随之变化。CP 还增加了 attention 数据交换，所以气泡估算更低的配置，仍可能得到更长的 step time。

这里也能看出 A 和 B 的一个区别：扩 DP 主要减少了每次更新的累积次数，在这个固定 MBS、固定 EP 的例子中，并没有减少单次 dispatch 的专家 token 数。分析时要明确说的是单次算子、单次更新，还是整个作业的平均工作量。

真实路由还存在偏斜。平均每个专家 2048 个 assignment，不代表最热专家也是 2048。应同时查看每专家 token 分布，以及每个 rank 的总接收量。一个 rank 放着多个专家，单专家均衡与 rank 均衡是两个相关但不同的问题。

长上下文边界

V4 的 CP 要处理压缩块跨 rank 和 packed 样本边界。测试样本应包含长度不整除压缩率的情况，也要覆盖样本边界恰好落在 CP 切分处，以及短长样本混装的情况。

边界交换还要求每个 rank 的本地 token 行数不少于 D_window。本文 8K 序列、CP4 的算例每 rank 有 2048 行；向更短序列或更大 CP 扩展前，应检查这个条件。CP 边界交换校验

比较 CP1 与 CP4 时，保持 token 顺序、样本 mask 和 loss normalization 一致，核对前向结果与梯度。当前 packed 路径没有 deterministic mode，应预先定义数值误差容限，结合短程 loss 和梯度统计判断，不能只凭运行没有报错验收。

模型支持百万上下文，并不要求所有预训练阶段都采用这个长度。短序列与长序列阶段可以分别搜索配置，切换时还要计入 checkpoint 重分片和恢复成本；本文讨论的 V4 实现使用 static CP。

EP 与拓扑

假设每节点 8 GPU，节点内有 NVLink/NVSwitch，那么 EP64 至少跨 8 个节点。这个配置需要跨节点网络承担专家通信。

先把逻辑 rank 映射到 GPU、NIC 和交换机位置，检查同一 EP 组经过哪些链路。同样的 EP64，如果跨越不同的上联或超售边界，实际表现可能不同。CP、PP 和 DP 通信也可能同时争用这些路径。

普通 dense 模型中，TP 经常受益于高速节点内互联。但本文讨论的 V4 实现固定 TP1，当前优化空间主要在 EP、PP、CP，以及对应的数据并行度。未来实现支持更多 TP 组合后，还需要重新评估层内通信和切分后的矩阵效率。

MoE Parallel Folding 提供了更灵活的映射方式，便于将频繁通信放到紧凑的互联域；当显存要求专家跨节点时，仍然要支付跨节点通信代价。这个取舍可结合前面的专家权重表判断。MoE Parallel Folding，§4.4

测网络时，应使用接近训练的消息尺寸和并发关系。单独运行一次大消息 AllReduce，只能说明这种通信模式的表现；MoE 的 all-to-all 还受到路由偏斜、目标节点数和 token 去重方式影响。

NVIDIA 的 Hybrid-EP 工程文章讨论了 RDMA 与 NVLink 的分层流水，以及用较少 SM 完成通信的实现。这里值得关注的是通信资源占用，因为这些 SM 和带宽同时也可能被计算需要。Hybrid Expert Parallel

通信重叠

先看一个 MoE 前向的数据依赖。

router → permutation → dispatch → expert GEMM → combine → 恢复顺序

反向还有对应的数据交换。整步训练同时存在 PP 的 P2P、dense/expert 参数梯度同步，以及优化器更新。各路径能够重叠，所有 NCCL kernel 的耗时相加通常大于它们对 step time 的实际贡献。

调优要看关键路径上的等待。例如 expert GEMM 在什么时刻拿到输入，最后一个 combine 是否拖住后续计算，最后一桶梯度是否延后了 optimizer。时间线中两种颜色重叠，只说明执行区间有交集。

通信可能占用 SM 和 HBM 带宽，导致旁边的 GEMM 变慢。启用 overlap 后，应该同时比较 step time、GEMM duration 和显存峰值；只有通信等待减少、计算没有付出更大代价，整步才能加速。

下面这些现象可以作为下一轮实验的线索。

观察到的现象	接下来检查什么
dispatch/combine 明显暴露，网络吞吐偏低	消息大小、rank/NIC 映射、路由偏斜与通信 backend
overlap 后 GEMM 变长，step 几乎不变	通信 SM 配额、HBM 争用、并发流数量
最后几个 stage 经常等待	stage 划分、首尾额外工作、P2P 边界与 microbatch 数
FP8 后计算缩短，通信占比反而上升	原先被计算覆盖的通信尾部、量化与 launch 开销
吞吐偶发下降，平均值看不出异常	最慢 rank、热专家、NIC 异常和数据等待

Grouped GEMM、融合和 CUDA Graph 也需要在完整迭代中比较。NVIDIA 2026 年的融合内核文章同时给出了算子与端到端收益：其 V3 完整栈测试中，端到端提升为 8%。算子加速和整步加速之间的差异，正好说明剩余路径仍然占时间。MoE Fusion Kernels

低精度优化改变了计算和通信的比例，原先合适的 EP 或 overlap 配置可能需要重调。本文的 BF16 权重核算仅用于解释存储；使用 FP8 等训练 recipe 后，要按实际保存的主权重、梯度和优化器状态重新计算。

公开性能数据

把论文结果放在一起时，先保留它们的比较条件。

来源	原文中的设置与结果	对本次调优的启发
Llama 3，2024	405B dense 模型；固定约 16M token/batch、8K 序列，8192 H100 的 BF16 MFU 为 43%，16384 H100 为 41%	固定全局 batch 扩 DP，单副本 batch 缩小，会影响扩展效率
MegaScale，2024	175B 模型，12288 张 Ampere GPU，2K 序列，batch 6144，MFU 55.2%	万卡效率还依赖数据流水、通信重叠与故障诊断
MoE Parallel Folding，2025	MoE 评测扩到 1024 张 H100，并测试长上下文；性能基准使用 capacity factor=1 的 token dropping	分组与 dispatcher 可以共同优化；路由实验条件必须写明
Megatron Core MoE 报告，2026	V3、1024 H100、4K 序列、FP8 blockwise，报告 1412 token/s/GPU；性能配置使用 force-balanced routing	可作为系统能力参考，仍需用自然路由验证尾部与真实吞吐

数据分别来自 Llama 3 Table 4、MegaScale §6、Parallel Folding §4、Megatron Core MoE §8.2。

这些结果回答的是各自实验中的系统问题。尤其是 token dropping 和 force-balanced routing，会改变专家工作量分布。用它们分析实现上限之后，正式候选仍应在目标路由语义下比较，并记录 token drop/padding 的实际数量。

MFU 也要保持口径一致。MoE 计算量应按实际激活专家和 attention 结构估算；把全部 1.6T 参数代入 dense 模型的 $6NT$ 近似，会高估有效模型工作。重算和 padding 产生的额外计算，应与模型必需计算分开报告。分母则说明采用何种精度的硬件 peak，是否包含结构化稀疏条件。

调优顺序

首先固定模型与训练语义，再缩小配置范围。一个可用的记录应包含模型设置、tokenizer、packing/mask、路由方式和优化器，同时保留容器、Megatron 与通信库版本。否则，相同的 EP64 也可能运行了不同的计算。

正确性与显存

先在可承受规模上验证 attention、MoE block 和分布式切片，比较前向与梯度，再做短程训练和保存恢复。完整的 1.6T 模型装不进单卡，可以使用可信的模块基线，以及保持关键维度与数据边界的切片实验。

缩小模型只能验证对应机制。完整模型的显存峰值、专家数量与 stage 负载，仍要在后续集群实验中确认。

按最重 rank 的显存先筛掉不可行配置，再搜索 PP、EP 和 CP。当前 V4 路径先固定 TP1、ETP1；EP32/64/128 都能整除 384 个专家，可作为候选。其余组合还要检查 stage、microbatch 和 backend 的限制。

下面只是 A 配置的并行参数片段，需要接在已经验证的 V4 模型、数据和 HybridModel 布局上，不是一条完整启动命令。

--tensor-model-parallel-size 1 \
--pipeline-model-parallel-size 8 \
--context-parallel-size 1 \
--expert-model-parallel-size 64 \
--expert-tensor-parallel-size 1 \
--micro-batch-size 1 \
--global-batch-size 4096

选择通信 backend 时也要固定版本。当前 Megatron 实现使用 --moe-token-dispatcher-type flex 配合 --moe-flex-dispatcher-backend 选择实现，旧的 --moe-enable-deepep 已弃用；DeepEP 仓库本身的接口也在演进，应把依赖版本一起记录。Megatron 配置校验、DeepEP 仓库

调度与算子

对能运行的配置，联合检查 MBS、累积数和 stage 划分，再加入实现支持的 VPP 与选择性重算。它们会相互影响，单独的最优参数未必能组成最优配置。

建立原因判断时，可以先只改一个因素，例如只替换 dispatcher，记录通信等待和整步时间；之后对相关变量做小范围联合搜索。启用低精度、融合或 CUDA Graph 后，再检查计算形状和 overlap，不能沿用优化前的瓶颈判断。

暖机应覆盖编译、内存分配和 graph capture。测量窗口至少覆盖多个代表性数据批次，记录长度和重复次数；真实路由波动较大时，报告 step time 的 p50/p95/p99，并保留异常窗口。

扩容比较

Strong scaling 固定模型、序列和全局 batch，观察 GPU 增多后时间怎样变化。Weak scaling 则相应增大 batch，用来评估另一类扩展能力。后者改变了优化条件，需要同时比较学习率设置、验证 loss 和达到目标质量所需的 token 数。

从千卡逐步扩到数千卡，再到 8192/16384 这类接近或超过万卡的规模。小规模实验适合排除明显不合适的候选，跨机架争用与尾部问题要留到对应规模验证。

有效吞吐

稳态 token/s 反映训练循环的速度。作业完成时间还包含保存、故障检测、重启和重放，应另算：

Q_{effective}=\frac{\text{成功推进且没有被回滚的训练 token}}{\text{总墙钟时间}}.

例如，两组配置的稳态吞吐与有效训练时间占比，假设分别为 100 万 token/s、90%，以及 110 万 token/s、80%，那么有效吞吐约为 90 万和 88 万 token/s。这是说明计算方法的假设数据。更高的瞬时吞吐，可能被更频繁的故障和恢复抵消。

Llama 3 报告在一个 54 天的训练快照中记录了 466 次作业中断，有效训练时间仍超过 90%。大规模训练的验收需要包含诊断与恢复能力。Llama 3 §3.3.4

保存恢复至少检查模型参数、优化器状态和学习率进度，还要验证数据游标与各 rank 随机状态。若计划修改 PP、EP 或 CP 后恢复，应单独验证该版本的重分片能力，测量转换时间与恢复后的数值表现。

最终留下的实验记录，可以按下面的项目整理。

项目	需要留下的证据
版本与语义	框架、容器与依赖版本，模型设置、精度、路由和 packing
资源分布	GPU/NIC 拓扑，attention/expert 分组，实际 HybridModel 布局
每步工作量	GBS、MBS、累积数，有效 token、padding 与 token drop
显存	最重 rank 的 allocated/reserved 峰值，激活及通信 buffer
端到端时间	连续窗口的 token/s、step p50/p95/p99，最慢 rank/stage
瓶颈解释	时间线中的等待、GEMM 形状、热专家与链路计数
训练质量	短程 loss/梯度检查，验证集表现及目标质量条件
长期运行	保存与恢复耗时，回滚 token，包含停机的有效吞吐

一项调优能保留下来，应该能对应到表中的证据：它省下了哪部分时间，付出了多少显存或通信代价，在同样训练语义下是否仍然成立。进入下一轮实验时，先从这项证据还没有解释清楚的地方继续。

_blog