先澄清一下背景这篇是“算法同学学Infra”系列的第二篇上一篇聊的是显存和算力的基本账这一篇直接干硬货——把LLM分布式计算里最常见的五个缩写TP、DP、PP、CP、EP一次性讲透。我个人见过太多算法同事模型结构倒背如流一到训练推理就跑不过Infra同学核心问题不是不会调参而是对这五个并行度的切分逻辑没有体系化理解。这篇文章不涉及具体框架API只把“为什么这么切、通信代价是什么、什么场景用哪个”讲明白适合刚接触大模型训练/推理、想看懂集群资源利用率报告的算法工程师也适合想从单卡过渡到多卡开发的工程同学。1. 并行到底在并行什么先把底层问题摆出来为什么大模型训练必须要分布式两个硬约束一是单卡显存放不下比如一个7B模型用FP16存权重就要14GB但训练时还要存优化器状态、梯度、激活值实际占用经常是权重的3到4倍一张A100的80GB根本扛不住70B模型二是单卡算力不够训练速度会慢到不可接受。但分布式并行不是“把任务随便拆成几份就行”而是要想清楚一个问题你究竟沿着什么维度去切计算数据、模型参数、计算图流水线、序列长度、专家模块这五个维度分别对应DP、TP、PP、CP、EP。这五种并行是“正交”的可以互相组合而且理论上每一维都是独立的切法。我用一个类比帮你建立直觉。想象有一本很厚的书要翻译成另一种语言多人协作有几种方式DP是每个人拿一本完整的书各自翻译不同的章节最后校对合并TP是每个人负责一个句子里的不同部分有人查名词、有人查动词最后拼句子PP是按流程分工第一个人把英文转成中文草稿第二个人润色第三个人排版CP呢是这本书太长每个人只读其中几页但需要和自己不负责的页配合时就通过传纸条方式协调EP更像是“按专业知识分工”遇到法律术语找法律专家遇到医学术语找医学专家每个人只管自己最擅长的词条然后把答案汇总。这五种并行不只是名字不同它们的通信模式、显存占用、扩展限制都完全不一样。下面逐个拆。2. DP数据并行最没有门槛的并行2.1 数据并行的基本玩法数据并行是最直觉、最容易理解的一种每个GPU都放一份完整的模型然后把训练数据切成多份每个GPU处理不同的一份最后同步梯度。用公式表示就是global_batch num_gpus × micro_batch_size × grad_accum_steps。这里grad_accum_steps是梯度累积步数一般用来在batch很大、显存吃紧时保持一致的总batch大小。我见过不少新手上来就把micro_batch_size调得很大结果OOM但没意识到“数据并行”的显存开销其实并不低——模型参数、优化器状态、梯度在每个GPU上都有一份完整的副本。7B模型FP16权重14GBAdamW优化器状态fp32主权重一阶二阶动量约56GB加上梯度就是84GB左右单卡如果只有40GB显存数据并行根本跑不起来哪怕batch再小也没用。所以DP有个很关键的限制它解决不了“单卡放不下模型”的问题解决的仅仅是“单卡跑太慢”的问题。2.2 梯度同步里藏着的通信成本数据并行每次迭代结束后都要做梯度同步把各卡算出的梯度做平均。实现上传统做法是AllReduce操作。不需要把每个GPU算出来的梯度发给所有GPU那样通信量太大现代框架用Ring AllReduce把GPU排成一个环每个GPU只跟相邻的GPU通信分两步走第一步reduce-scatter每个GPU汇总部分梯度分片第二步all-gather把完整梯度广播出去。这样总通信量是2倍的参数大小而不是GPU数倍。举个实际数字7B模型梯度如果用FP16存储一次AllReduce就需要传输14GB左右的数据。NVLink带宽约600GB/s的话光梯度同步都要花几十毫秒。你要是用千兆以太网带宽慢到一个step的时间都耗在通信上训练速度直接崩盘。这些通信发生在每次backward之后所以训练时经常可以观察到GPU计算和通信在时间轴上交错——框架会尽量让梯度通信和下一层的计算重叠起来这也是为什么看训练日志时利用率曲线总会有周期性小凹槽那些往往是通信造成的空档。2.3 从DP到ZeRO再到FSDP因为DP每个卡都存完整副本显存浪费很大微软提出了ZeROZero Redundancy Optimizer优化器状态分片方案。它的思路很优雅既然DP同步梯度时反正要AllReduce那不如把冗余的状态也分片存储用的时候再取回来。ZeRO有三个阶段阶段一优化器状态分片阶段二优化器状态梯度分片阶段三再额外把模型参数也分片。这就是FSDPFully Sharded Data Parallel的核心。FSDP在PyTorch里基本是开箱即用算法同学遇到单卡放不下的Transformer模型时我的经验是优先考虑FSDP而不是PP因为FSDP不需要手工改模型结构对算法同学最友好。FSDP意味着每个GPU上只有模型的一部分参数。前向计算时需要用哪一层就把哪一层的参数AllGather取回来计算完再释放反向传播时梯度会ReduceScatter回各自分的分片上。这个取参数的操作会引入通信但通信量跟DP是同一量级不会更差显存却省了一大截。所以现在大模型训练里“纯数据并行”基本已经被FSDP取代了大家嘴里的DP往往指的是FSDP。3. TP张量并行把一层切开到多张卡3.1 矩阵乘法到底怎么拆如果说DP是“复制模型”TP则是“切分模型”。具体来说TP指的是把神经网络中某一层的计算——尤其是矩阵乘法——按矩阵的维度拆到多张卡上并行算。以Transformer里的Linear层为例。假设输入X的维度是[batch, seq_len, hidden]权重W的维度是[hidden, hidden]。可以按输出维度把W竖着切成两块W1和W2每个GPU只做X×W1和X×W2最后拼起来。这就是列并行。也可以按输入维度横着切权重的行每个GPU输入是X的一部分输出是完整的Y这要求先对输入做切分输出端需要AllReduce。矩阵乘法巧妙之处在于不管是行切还是列切都可以精确等价地对原矩阵乘法做分解不引入任何近似。这一点在工程上极其重要——TP不是近似计算而是严格等同的计算数值上只存在浮点累计顺序的微小差异。3.2 Transformer里的TP怎么设计在Megatron-LM的标准做法里Transformer层里有一组Linear要配合使用第一个Linear是做QKV投影第二个Linear是做Attention输出投影FFN部分也是类似Gate/Up投影是一组Down投影是一组。如果QKV投影做列并行那Attention输出投影就必须做行并行。为什么因为行并行会把各卡的部分输出求和正好能把列并行两块结果拼起来的通信给省掉一部分。这里有一个很经典的结论列并行 行并行的组合可以做到每个子层只要一次AllReduce通信而不是两次。具体实现时QKV列并行每张卡算出各自的QKV然后在attention内部进行局部计算到输出投影时做一次AllReduce把两块结果合起来之后FeedForward也是类似的模式Gate/Up列并行Down行并行再做一次AllReduce。所以一个Transformer block在TP下的通信量是固定的两次AllReduce通信数据量为batch × seq_len × hidden。这个通信量和TP的卡数无关但TP卡数越多每一块的计算时间越短而AllReduce的耗时又随卡数变长所以TP的扩展性是有限制的——不是卡数翻倍速度就翻倍。3.3 TP为什么一般不超过8卡TP的核心优势是显存省每个卡只存模型权重的一个分片加上中间激活也被切开显存占用大幅下降。代价是通信非常频繁而且通信发生在计算的关键路径上无法像DP那样跟计算重叠得很好。实际中最常见的是TP8因为NVLink一个域通常8张卡互联卡间通信有高带宽。如果跨节点做TP就得走IB或者以太网带宽一下掉一个数量级AllReduce延迟会非常高。我见过有人TP16跨两台机器结果训练效率惨不忍睹基本每层都在等通信。给算法同学一句很实在的话TP是把双刃剑能不用就不用能用小就不用大。它主要用在超大规模模型、单卡完全放不下场景。若模型能塞进单卡优先DP/FSDP因为DP通信次数远少于TP训练效率往往更高。4. PP流水线并行把层切成段4.1 朴素切法与气泡问题PP的思路和TP完全不同。TP是把一层内的计算切开PP则是把整个模型的层按顺序切成若干段每个GPU负责其中一段。比如70层的模型切到4个GPU上GPU0负责1到17层GPU1负责18到35层以此类推。这听起来很简单但直接按“GPU0算完所有层才传给GPU1”的方式顺序执行你会发现GPU0后面的设备大部分时间都在空等利用率惨不忍睹。因为GPU1必须等GPU0跑完前向才开工整个前向是串行的而且反向传播还会反向串行一遍GPU之间的空闲时间形成一个大大的气泡。4.2 Micro-batch与1F1B调度解决气泡的标准方案是引入micro-batch。把一个大batch切成多个小micro-batch一个micro-batch算完就立即传给下一个stage这样多个micro-batch能够在不同流水线stage上像流水线一样交错执行。Gpipe在2018年提出用micro-batch流水气泡比例约等于(P-1)/(MP-1)P是stage数M是micro-batch数。如果P8M16气泡占比还不到三分之一如果M太小气泡占比就会很高GPU利用率惨淡。Megatron-LM的1F1B调度进一步优化了内存占用。它的做法是让每个GPU交替执行一个前向一个反向保证同一时间每个GPU上最多只保存一份前向激活内存占用相对Gpipe低不少。这个细节对算法同学来说不需要手写但理解它能帮助你明白为什么框架里调PP时会同时要求你设置梯度累积步数或者micro-batch数量——两者直接影响流水线填充程度是PP性能的关键。4.3 PP的隐性成本PP有个坑容易被忽略模型分段的负载均衡问题。不同层的计算量并不是均等的比如embedding层和最后的head差异很大切分不好就会出现某个stage变成瓶颈。实际中框架会做层数配比但算法同学手动切分时要留意这个差异。另外PP带来的显存收益其实是“隐性”的因为你切的是模型层每个GPU上只保存部分参数但前向反向过程需要把前一stage的中间激活全部保存下来这本身是显存大户。所以PP的显存收益不如TP直接但对单卡完全放不下完整模型、又不想引入TP通信开销的场景很有效。5. CP上下文并行主攻超长序列的利器5.1 序列维度也能切开吗CPContext Parallelism听起来比较陌生但在长上下文大模型场景越来越重要。CP是沿着序列长度维度切分每个GPU只处理一个序列片段。回到attention的计算输入序列长度是S每个token都要和所有token计算attention复杂度是O(S²)。如果S是128K全局注意力矩阵就是128K×128K这个量级在单卡上根本无法计算和存储。CP的思路是把序列切成C块第i个GPU只负责第i块token对应的Q但KV块需要所有GPU共同持有参与计算。和TP类似CP也不是近似——如果把KV切成多块逐个处理对每个Q块而言它要和所有KV块做attention这就是完整的全局注意力。难点在于KV块的流通GPU之间需要交换KV块数据让每个GPU都能拿到所有KV块。5.2 Ring Attention的基本想法实现CP最经典方案是Ring Attention。把所有GPU排成一个环每个GPU初始持有自己对应序列片段的一块KV。计算的时候每个GPU先用本地KV做一轮attention接着把KV传给下一个GPU同时从上一个GPU接收新的KV块再做下一轮attention。这样循环直到所有KV块都访问过一遍。这涉及到不平衡的局部attention计算但可以利用在线softmax技巧把多个注意力结果融合最终得到和全局attention数值上近似的结果。Ring Attention最妙的地方在于它让attention的通信量不再随序列长度线性增长而是取决于设备数和分块大小所以能把超长序列吃到128K甚至更长而显存不会炸。5.3 CP和TP/DP怎么区分对算法同学来说CP最大的迷惑点是它和TP都涉及切分计算到底什么情况用哪个我的理解是TP切的是hidden维度当前transformer层的前向计算就被拆到多张卡上CP切的是序列维度每个卡计算的是序列中不同片段对应的完整层。TP的通信频率更高更密集CP的通信通常是KV块的轮转总量可控。在实际场景中CP一般只在序列特别长比如超过32K token时启用。常规训练里用DPTPPP就够了但一旦你要训练超长上下文模型CP就不可或缺。像一些32K以上窗口的模型训练CPTP的组合是标配。5.4 CP带来的额外变化引入CP之后训练时还要处理一个隐性变化attention_mask的语义。因为每个卡只看到序列的一部分原始的因果mask要改造成块级别的mask组合否则不同片段之间的attention关系会错乱。这个bug非常隐蔽我曾经排查过一个训练曲线异常问题最后发现是CP的mask切分实现有误。算法同学如果自己写分布式训练代码这点一定要检查。另外CP切分对normalization层也有影响一般来说strict是LayerNorm/RMSNorm需要跨设备allreduce均值否则每个块看到的统计量不一致结果就会偏差。现在多数框架已经处理好了但自己实现时容易漏。6. EP专家并行MoE模型专属的切法6.1 MoE先补个课EPExpert Parallelism是专门为MoEMixture of Experts模型设计的。不是说它是万能的而是它只在含专家模块的模型里才有意义。MoE的核心是一个FFN层不再是一个大FFN而是有若干个独立的小FFN称为专家外加一个路由器。输入token经过路由器计算与其最匹配的top-k个专家然后这些token分别进入对应专家计算最后把结果合并。这样在不增加每次前向计算量的前提下大幅增加模型总参数量所以MoE能在参数量很大的情况下保持较低的推理成本。6.2 专家并行怎么切EP的做法非常“物理”既然模型有很多专家那就把这些专家平均分配到各个GPU上每个GPU只负责其中一部分专家。token会经过路由器被发往对应专家所在的GPU执行。这个通信模式是all-to-all即每个GPU都可能要向其他所有GPU发送token和接收token的中间表示。这也是EP和TP/DP最大的区别DP是梯度同步通信量跟参数大小有关TP是激活同步通信量跟hidden size有关EP则是激活数据的稀疏分发通信量取决于token路由的分布具有不确定性。EP的工程难点主要在负载均衡如果某个专家特别热门大部分token都被路由过去那个GPU就会过载其余GPU闲着。缓解手段是辅助负载均衡loss抑制token过度集中的情况或者直接限制专家容量超出的token做drop或overflow处理。算法同学如果训练MoE模型调辅助loss系数时会影响最终指标需要谨慎平衡。6.3 EP和DP怎么组合实际训练MoE大模型通常不单独用EP而是EPDP的组合。attention层和router层用DP每卡都有完整副本FFN专家层用EP专家分片。这样已路由的token只在需要的时候才跨越设备进行通信其余注意力计算完全在本地。这也是为什么像DeepSeek这种大规模MoE能高效训练的原因。EP技术让每个token找专家的开销变得可控因为通信发生在token级别而不是把整个模型广播出去。7. 组合拳训练3D并行和推理的并行选择7.1 训练里的PTD-P组合前面五种并行不是互斥的真实大模型训练很少只用一种最经典的是DPTPPP组合即所谓3D并行也叫PTD-P。典型配置是先沿层方向做PP切分每个PP stage内部再用TP切分一层最后沿数据维度复制多组。比如一个模型需要4路PP每路内TP8那么一个模型副本占32张卡如果机器有128张卡就可以数据并行复制4份global batch被切成4份分别给4个模型副本。这种组合的显存账是这样算的PP让每个stage只保存部分层参数TP让单层参数被切开DP/FSDP又让跨副本的优化器状态分片。三层叠加以后70B模型的权重从140GBFP16可以被压到单卡个位数GB。但通信也是叠加的所以调参时要根据集群拓扑调整PP、TP维度尽量让高频通信TP/EP走卡间高带宽低频通信DP梯度同步走节点间的网络。7.2 推理场景的并行取舍训练场景和数据并行绑定很深但推理场景有不同的考量。推理时batch通常很小甚至1这时DP没有意义——每个GPU跑着相同模型处理同一份数据纯浪费。传统推理主要用TP和PP来切分模型让单卡负担下降。有一个很实用经验推理的prefill阶段处理输入prompt计算所有token注意力batch和sequence都较大TP和CP很有效decode阶段逐token生成batch1TP反而低效因为token的hidden向量要先切到各卡上每张卡都做很少的计算却要等两次AllReduce通信占比极高。这也是为什么很多推理框架会做prefill/decode分离部署prefill用TP并行decode阶段用PP甚至单卡本质上是让并行策略跟计算形态匹配。如果推理时要支持超长上下文CP又是一个重要选项。CP可以把KV cache按序列块分散到多卡避免单卡KV cache超标同时attention计算也在各卡上并行不会因为序列长而OOM。和TP组合使用时通常CP程度选4或8。7.3 为什么一些模型训练完全不用PP有一派观点认为PP在超大规模训练里越来越不受欢迎。原因是PP有气泡、调度复杂、显存管理困难而且micro-batch的切分还会影响batch norm之类的语义虽然Transformer一般都用LayerNorm不受影响。现在很多训练框架对超大模型直接用FSDPTP组合用FSDP处理参数分片TP处理层内并行反而比PP更灵活更好调。PP最适用的场景反而是单机多卡、模型刚好超出一张卡但不多例如用PP把层分段让两卡各存一半。算法同学遇到“模型超过了单卡但不算太多”的场景可以优先考虑PP而不是一上来就TP。8. 避坑手册调并行必踩的坑8.1 通信开销不等于带宽瓶颈我发现很多算法同学看到训练日志里GPU利用率只有40%就会骂框架效率低但这往往是通信拉胯导致的。在单机多卡上TP的AllReduce走NVLink还算快带宽瓶颈其实常常在CPU侧——比如dataloader太慢、数据预处理在CPU上耗时GPU空转等数据。排查时不要只看GPU util要看nvidia-smi的SM busy和内存占用同时看通信库的事件统计。基于我的经验慢训练的第一嫌疑是数据加载不是并行策略不对。8.2 序列长度对并行的隐性影响有些同学把训练配置从seq_len2048调到8192时以为只影响显存中的激活但实际上TP的通信量每次AllReduce是batch×seq_len×hidden序列变长直接拉高TP通信负担CP也不可能免通信只是它把通信改为按块轮转总量不变。所以当序列长度变大性能下降不该只归咎于显存。要重新评估并行维度seq太长优先加CP而不是硬撑TP。8.3 显存够不够不能只看权重单卡显存占用的大头是激活值和优化器状态。训练一个模型激活值的显存经常比权重本身还大尤其在长序列高batch下。要判断是否需要TP/PP得算清楚前向激活的峰值不是简单拿参数量乘精度。实用技巧是先用小batch把模型载入跑一次观察实测峰值显存而不是靠理论估算。8.4 调并行维度时的启动顺序建议如果已经决定要分布式训练我一般建议的启动顺序是先用DP或者FSDP跑通基准再根据显存需求决定是否加PP再根据性能瓶颈决定是否加TP最后处理超长序列时才考虑CP。每种并行都让代码复杂度和调参难度上一个台阶不是越高级越好够用才是最好。9. 最后再分享一点实际体会做了这么多年模型训练和推理优化我的一个体感是算法同学学分布式最难的其实不是理解某一种并行而是脑子里要有一个“数据在哪、计算在哪、谁需要什么”的空间想象。每次看到mem的需求都要在脑子里过一遍当前这一步计算需要的权重或者激活在哪个设备上如果在远端通信代价有多大能不能通过调整并行策略让通信落在时间轴的空档里。这五种并行DP/FSDP解决的是“数据放不下训练太慢”TP解决的是“单层超过单卡能力”PP解决的是“整个模型超过单机能力”CP解决的是“序列太长单卡装不下”EP解决的是“MoE专家多但复用率低”。把它们的适用条件、通信模式、踩坑点记清楚你就能看懂绝大多数训练框架的并行配置说明也能跟Infra同学精准地聊资源需求而不是互相鸡同鸭讲。以后遇到别人问你TP和PP选哪个你可以反问他你的模型单卡能放下吗序列有多长是训练还是推理这三个问题一问基本就有答案了。