1. 从一张拓扑图说起为什么单卡跑不动大模型第一次接触昇腾AI集群的人十有八九会问同一个问题我手里这张NPU单卡算力已经够猛了为什么还要折腾什么集群、什么并行答案其实特别朴素——显存不够时间不够规模不够。拿现在主流的千亿参数模型来说光是权重本身FP16精度下就要吃掉接近2TB的显存。单张昇腾NPU的HBM容量再大也塞不下这个体量。更要命的是训练过程中还有优化器状态、梯度、激活值这些额外开销实际占用往往是模型权重的3到5倍。所以从第一天起大模型训练就注定是一个分布式问题单卡只能跑推理训练必须上集群。但集群不是把一堆卡插上电、连上网线就完事了。真正难的地方在于怎么让成百上千张NPU协同工作还能保持接近线性的加速比。这就引出了今天要聊的核心——多维混合并行。昇腾AI集群服务器架构里多维混合并行不是一个可选的高级技巧而是支撑大模型训练的基础设施级能力。它把数据并行、张量并行、流水线并行、专家并行等多种策略组合在一起针对不同的模型结构、不同的集群规模、不同的通信带宽动态选择最优的切分方式。说白了就是让每一张NPU都尽量别闲着同时让卡与卡之间的通信别成为瓶颈。这篇文章适合谁看如果你正在做昇腾平台上的大模型训练或者准备从单卡实验迁移到集群环境又或者你只是好奇“多维混合并行”这几个字背后到底藏着什么工程细节那接下来的内容应该能给你一些可以直接抄作业的东西。我会从架构设计思路讲起然后拆解核心并行策略的实现要点再给出一套可复现的实操流程最后把踩过的坑和排查技巧整理成速查表。2. 多维混合并行的整体设计思路2.1 为什么单一并行策略走不通先说说为什么不能只用一种并行方式。数据并行Data Parallelism是最直观的每张卡拿一份完整的模型副本喂不同的数据算完梯度再AllReduce同步。听起来很美但它有个硬伤——每张卡都得存一份完整的模型。模型一大单卡显存直接爆掉。所以数据并行只适合中小模型或者显存足够大的场景。张量并行Tensor Parallelism解决的是单层内部太大的问题。比如一个巨大的矩阵乘法把它按行或按列切开分到多张卡上算算完再拼起来。这样单卡只需要存一部分权重。但张量并行的通信非常频繁每层前向和反向都要做AllReduce或AllGather对卡间带宽要求极高。如果跨机做张量并行通信开销能把计算收益吃干净。流水线并行Pipeline Parallelism换了个思路按层切分前几层放一组卡后几层放另一组卡数据像流水线一样依次流过。这样通信量小很多但会引入“气泡”——流水线填充和排空阶段部分卡是空闲的。流水线级数越多气泡占比越大需要靠微批次micro-batch来填满。专家并行Expert Parallelism是MoE混合专家模型专属的。不同的专家网络放在不同的卡上每个token根据路由结果只激活部分专家。这样参数量可以做得极大但计算量不会等比例增长。不过路由不均衡会导致某些卡忙死、某些卡闲死需要额外的负载均衡策略。你看每种并行都有它的适用场景和明显短板。真实的大模型训练往往是几千亿参数、上百层、MoE结构还要求高吞吐。这时候单一策略根本不够用必须把它们组合起来——这就是多维混合并行的由来。2.2 昇腾集群的硬件底座NPU与HCCL聊并行策略之前得先认清昇腾集群的硬件底子。昇腾NPU的架构和通用GPU不太一样它采用了达芬奇核心包含Cube矩阵计算单元、Vector向量计算单元和Scalar标量计算单元。Cube单元专门负责矩阵乘加这是深度学习里最密集的计算Vector单元处理激活函数、归一化这些逐元素操作Scalar单元做流程控制。这种分工让NPU在矩阵运算上效率很高但也意味着算子开发时需要针对不同单元做适配。集群内部NPU之间通过HCCLHuawei Collective Communication Library通信。HCCL提供了一套集合通信原语包括AllReduce、AllGather、ReduceScatter、Broadcast、All2All等。这些原语是多维混合并行的通信基础。HCCL会根据集群的物理拓扑——比如同一台服务器内通过HCCS互联、跨服务器通过RoCE或IB网络——自动选择最优的通信路径和算法。这里有个关键点HCCL的通信带宽和延迟直接决定了并行策略的上限。同一台服务器内的NPU互联带宽通常远高于跨服务器网络。所以张量并行这种通信密集型策略一般优先放在同一台服务器内流水线并行和专家并行的通信量相对小一些可以跨服务器部署。这个“通信分级”的思路是多维混合并行设计的核心原则之一。2.3 混合并行的组合逻辑按通信密度分层多维混合并行的设计哲学可以用一句话概括按通信密度分层把高通信密度的并行放在高带宽域内低通信密度的并行放在低带宽域间。具体来说一个典型的昇腾集群混合并行配置是这样的张量并行TP放在同一台服务器内的NPU之间利用HCCS高带宽互联。TP的通信量最大每层都要同步所以必须放在最快的链路上。流水线并行PP跨服务器部署通信量相对小主要是层与层之间的激活值传递。PP的通信可以重叠计算对带宽要求没那么苛刻。数据并行DP放在最外层跨更多的服务器。DP的通信是梯度AllReduce频率低每个迭代一次但数据量大。昇腾集群通常用分层AllReduce来优化先在服务器内做ReduceScatter再跨服务器做AllReduce最后服务器内AllGather。专家并行EP根据MoE模型的路由策略把不同专家分布到不同NPU上。EP的通信是All2All通信模式比较随机需要配合负载均衡。这种分层组合的好处是每一层并行都跑在最适合它的通信域里整体通信开销最小化。但挑战也很明显不同并行维度之间的交互非常复杂切分策略、通信组划分、内存布局、计算图优化任何一个环节出问题都会导致性能断崖式下跌。2.4 昇腾软件栈的支撑CANN与MindSpore硬件之上昇腾的软件栈为多维混合并行提供了完整的支撑。CANNCompute Architecture for Neural Networks是底层的异构计算架构负责算子编译、图优化、内存管理、通信调度。HCCL就是CANN的一部分。上层的MindSpore框架则提供了并行策略的编程接口开发者可以通过简单的配置或自动并行算法把模型切分到集群上。MindSpore的自动并行能力值得一提。它会根据模型的计算图和集群的拓扑信息自动搜索最优的切分策略。比如它会分析每个算子的通信量和计算量然后决定哪些算子做张量并行、哪些做数据并行。当然自动并行不是万能的复杂模型还是需要手动调优。但至少它提供了一个不错的起点让新手不用一上来就面对一堆通信组配置。3. 核心并行策略的细节拆解与实操要点3.1 数据并行看似简单坑在梯度同步数据并行是最好理解的每张卡一份完整模型喂不同数据反向传播后同步梯度。昇腾平台上数据并行的实现主要依赖HCCL的AllReduce。但这里有个容易被忽略的细节梯度同步的时机和方式。最朴素的做法是等所有卡的梯度都算完然后一次性AllReduce。但这样通信和计算是串行的通信时间完全暴露。优化做法是梯度分桶gradient bucketing把梯度按大小分成多个桶一个桶算完就立刻开始AllReduce让通信和后续桶的计算重叠起来。昇腾的HCCL支持这种分桶通信MindSpore里可以通过配置bucket_size参数来控制。桶太小通信次数多启动开销大桶太大重叠效果差。经验值是在16MB到64MB之间具体要看模型梯度的分布和网络带宽。我实测下来在昇腾910集群上32MB的桶大小对大多数Transformer类模型都比较均衡。另一个坑是梯度累积与数据并行的交互。如果你用了梯度累积来模拟更大的batch size那要注意AllReduce的频率。梯度累积的每一步都做AllReduce是浪费的应该等累积完再同步。MindSpore里可以通过accumulation_step配合通信调度来实现。注意数据并行的加速比不是线性的。当卡数增加到一定程度AllReduce的通信时间会超过计算时间加速比反而下降。这时候就需要引入其他并行维度来分担压力。3.2 张量并行切分矩阵的学问张量并行的核心是把大的权重矩阵切开。以Transformer里的注意力层为例Q、K、V的投影矩阵可以按列切分输出投影可以按行切分。这样每张卡只存一部分权重计算也只需要算一部分。但切分方式直接影响通信量。按列切分的话每张卡算出一部分输出需要AllGather拼起来按行切分的话每张卡需要完整的输入算完做AllReduce求和。两种方式的通信量差不多但AllReduce通常比AllGather更高效因为可以做ReduceScatterAllGather的融合。昇腾平台上做张量并行有几个实操要点第一通信组要尽量小。张量并行的通信组通常限制在单机8卡以内因为跨机的AllReduce延迟太高。如果模型太大单机8卡放不下那就得配合流水线并行把不同层放到不同机器上。第二算子融合很关键。张量并行会产生很多小算子比如切分后的矩阵乘、拼接、求和。如果不做融合算子启动开销会吃掉大量时间。CANN提供了图优化能力可以自动融合一些常见模式但复杂的切分模式还是需要手动调优。第三注意内存对齐。NPU的HBM访问有对齐要求切分后的矩阵维度如果不是对齐的倍数性能会明显下降。比如昇腾910的Cube单元对矩阵维度有16的倍数要求切分时尽量保证每张卡上的维度是16的倍数。3.3 流水线并行气泡怎么填流水线并行的核心思想是“层切分微批次”。把模型按层分成多个阶段stage每个stage放在不同的NPU组上。数据切成多个微批次依次流过各个stage。这样同一时刻不同stage可以处理不同的微批次提高利用率。但流水线有个天然缺陷填充和排空阶段部分stage是空闲的这就是“气泡”。气泡占比的公式是气泡占比 (PP - 1) / (micro_batch_num PP - 1)其中PP是流水线级数micro_batch_num是微批次数量。要降低气泡占比就得增加微批次数量。但微批次太多又会增加内存占用和调度开销。昇腾平台上流水线并行的实现通常配合1F1BOne Forward One Backward调度。这种调度方式让每个stage在前向一个微批次后立刻反向一个微批次最大化重叠。MindSpore的流水线并行支持1F1B和更复杂的交错调度。实操中微批次数量一般设为流水线级数的4到8倍。比如PP4微批次可以设16到32。这样气泡占比能降到10%以下。但要注意微批次数量受限于全局batch size不能无限增加。另一个坑是stage之间的负载均衡。如果某个stage的层数特别多或计算特别重它就会成为瓶颈其他stage等它。所以切分时要尽量让每个stage的计算量接近。Transformer类模型通常按层数平均分但要注意embedding层和输出层的计算量差异。3.4 专家并行路由与负载均衡专家并行是MoE模型的专属并行方式。MoE层里有很多个专家网络每个token通过门控网络选择top-k个专家进行计算。专家并行就是把不同专家放到不同NPU上token根据路由结果发送到对应的NPU。这里最大的挑战是负载不均衡。如果路由策略不好某些专家被大量token选中对应的NPU就忙不过来其他专家没人选NPU就闲着。昇腾平台上通常用**容量因子capacity factor和辅助损失auxiliary loss**来缓解这个问题。容量因子限制了每个专家最多处理多少token超出的token会被丢弃或走残差连接。辅助损失则鼓励门控网络均匀分配token。专家并行的通信是All2All每个NPU把token发送到目标专家所在的NPU算完再收回来。All2All的通信模式比较随机对网络拓扑敏感。昇腾的HCCL对All2All做了优化支持分组通信和流水线传输。但实操中还是要注意专家并行的通信组不要跨太多机器否则延迟会很高。3.5 多维混合组合的艺术把上面几种并行组合起来就是多维混合并行。比如一个典型的配置是TP8单机内PP4跨4台机器DP2再复制2份总共8×4×264张NPU。MoE模型还可以加上EP4把专家分布到4个NPU组上。组合的关键是通信组的划分。每个并行维度都有自己的通信组组内的NPU需要频繁通信。TP组是单机内的8张卡PP组是跨机的同stage卡DP组是跨机的同位置卡。这些通信组不能冲突否则会出现死锁或性能问题。MindSpore里可以通过strategy配置来定义每个维度的切分方式。比如from mindspore import context import mindspore.nn as nn from mindspore.parallel import set_algo_parameters # 设置并行模式 context.set_auto_parallel_context( parallel_modesemi_auto_parallel, device_num64, global_rank0, gradients_meanTrue, enable_parallel_optimizerTrue ) # 定义切分策略 strategy { input: (8, 1, 1), # TP8 weight: (8, 1), # TP8 output: (1, 4, 2) # PP4, DP2 }这段代码只是示意实际配置要复杂得多。但核心思路是每个算子的输入输出张量都标注切分维度框架根据这些标注自动生成通信算子。4. 实操过程从单卡到集群的完整迁移4.1 环境准备与集群初始化假设你手里有一个昇腾集群比如8台服务器每台8张NPU总共64卡。第一步是环境准备。首先确认CANN和MindSpore的版本匹配。昇腾的软件栈版本兼容性比较严格CANN 7.0对应MindSpore 2.0CANN 8.0对应MindSpore 2.2。版本不匹配会出现各种奇怪的错误比如算子找不到、通信超时。然后配置HCCL的环境变量。关键的有export HCCL_WHITELIST_DISABLE1 export HCCL_INTRA_ROCE_ENABLE1 export HCCL_EXEC_TIMEOUT600 export HCCL_CONNECT_TIMEOUT120HCCL_EXEC_TIMEOUT是通信超时时间默认是300秒。大模型训练时某些集合通信可能耗时较长建议调到600秒以上。HCCL_CONNECT_TIMEOUT是建链超时集群规模大时也要适当增加。集群初始化时每个NPU进程需要知道自己的rank和总卡数。通常用rank_table文件来配置里面记录了每张卡的IP、端口、device_id。这个文件可以用昇腾提供的工具自动生成也可以手动写。手动写的话注意IP和device_id的对应关系不能错否则通信组会建错。4.2 模型切分策略的配置环境准备好后开始配置模型切分。以MindSpore为例有两种方式自动并行和半自动并行。自动并行最简单设置parallel_modeauto_parallel框架会自动搜索策略。但自动并行对复杂模型效果一般而且搜索过程可能很慢。半自动并行需要手动指定每个算子的切分策略灵活但工作量大。我的建议是先用自动并行跑一遍看看框架给出的策略是什么然后在此基础上手动调整。MindSpore提供了strategy的导出功能可以把自动搜索的策略保存下来然后手动修改。对于Transformer类模型切分策略有一些经验规律Embedding层按词表维度切分做张量并行。注意力层Q、K、V投影按列切分输出投影按行切分。FFN层第一个线性层按列切分第二个按行切分。LayerNorm通常不切分或者按特征维度切分。输出层按词表维度切分配合张量并行。这些规律不是绝对的但可以作为起点。实际调优时要根据通信量和计算量的平衡来调整。4.3 通信组划分与HCCL配置通信组划分是多维混合并行的核心。以TP8、PP4、DP2为例64张卡要分成多个通信组。TP组每8张卡一个组共8个组。组内做AllReduce。 PP组每个stage有16张卡8×2共4个stage。stage之间传递激活值。 DP组每个位置有2张卡跨2个DP副本共32个组。组内做梯度AllReduce。通信组的划分要保证同一TP组内的卡在同一台服务器内同一PP组的卡可以跨服务器同一DP组的卡跨服务器。HCCL会根据通信组的配置自动选择通信算法。对于TP组的AllReduceHCCL会用Ring或Tree算法对于DP组的AllReduce会用分层算法。如果发现通信性能不达标可以手动指定算法export HCCL_ALGORing export HCCL_REDUCE_ALGOHDHD是分层归约适合跨机场景。Ring适合单机内。4.4 训练启动与性能监控配置完成后启动训练。昇腾集群通常用mpirun或rank_table方式启动。启动命令类似mpirun -n 64 --hostfile hostfile \ python train.py \ --config config.yaml \ --rank_table rank_table.json训练启动后要密切监控性能。关键指标包括NPU利用率用npu-smi查看理想情况是接近100%。如果某张卡利用率低说明负载不均衡。HCCL通信带宽用hccn_tool查看确认通信没有成为瓶颈。显存占用用npu-smi查看确保没有OOM。迭代时间记录每个迭代的耗时观察是否稳定。如果发现性能不达标先看NPU利用率。如果所有卡利用率都低可能是通信瓶颈如果部分卡利用率低可能是负载不均衡。4.5 调优实战一个千亿模型的切分案例假设我们要训练一个千亿参数的MoE模型128张NPU每台8卡共16台服务器。模型有64层每层有一个MoE层8个专家。切分策略如下TP8单机内做张量并行切分注意力层和FFN层。PP8跨8台服务器做流水线并行每台服务器放8层。DP2再复制2份跨2组服务器。EP4每个MoE层的8个专家分布到4张卡上每张卡2个专家。总卡数8×8×2128EP4是在TP组内进一步切分不增加总卡数。微批次数量设为32气泡占比约为(8-1)/(328-1)17.9%。可以接受。训练启动后发现NPU利用率只有70%。排查发现MoE层的All2All通信耗时较长。优化方案把EP的通信组限制在单机内即每台服务器内的8张卡做EP专家不跨机。这样All2All的延迟大幅降低利用率提升到85%。进一步优化调整容量因子从1.0降到0.8减少token丢弃同时用辅助损失鼓励均衡路由。利用率提升到90%以上。5. 常见问题与排查技巧实录5.1 通信超时与建链失败现象训练启动时卡住日志显示HCCL建链超时。排查思路检查rank_table文件确认IP和device_id对应正确。检查网络连通性用ping和hccn_tool测试。检查防火墙设置确保HCCL使用的端口开放。增加HCCL_CONNECT_TIMEOUT环境变量。避坑技巧集群规模大时建链时间会很长。建议先用小规模比如8卡验证配置再扩展到全集群。5.2 显存溢出OOM现象训练过程中报OOM错误。排查思路检查切分策略确认每张卡的显存占用是否均衡。减小微批次大小或梯度累积步数。开启重计算recompute用计算换显存。检查是否有内存泄漏比如未释放的中间张量。避坑技巧昇腾NPU的显存管理比较严格建议预留10%到20%的显存余量。MindSpore提供了mindspore.nn.AdamWeightDecay等优化器可以开启enable_parallel_optimizer来切分优化器状态进一步降低显存。5.3 负载不均衡现象部分NPU利用率高部分低。排查思路检查流水线并行的stage切分确认每层计算量均衡。检查MoE的路由策略确认专家负载均衡。检查数据并行的数据分发确认每个卡拿到的数据量一致。避坑技巧流水线并行切分时可以用计算量估算工具来辅助。MindSpore提供了mindspore.parallel.auto_parallel的profile功能可以分析每个stage的计算量。5.4 通信性能不达标现象HCCL通信带宽远低于理论值。排查思路检查通信组划分确认高通信密度的并行放在高带宽域内。检查HCCL算法选择尝试不同的算法。检查网络拓扑确认没有跨交换机瓶颈。检查是否有其他进程占用网络带宽。避坑技巧昇腾集群的HCCS带宽通常很高但RoCE网络可能成为瓶颈。如果跨机通信量大考虑用IB网络替代RoCE。5.5 常见问题速查表问题现象可能原因排查方法解决方案训练启动卡住HCCL建链超时检查rank_table和网络增加超时时间检查防火墙OOM显存不足查看npu-smi减小微批次开启重计算利用率低负载不均衡查看各卡利用率调整切分策略均衡负载通信慢通信组划分不合理查看HCCL带宽调整通信组优化算法梯度爆炸学习率过大查看梯度范数调整学习率加梯度裁剪精度下降并行策略影响对比单卡结果检查切分是否正确调整通信6. 一些个人体会与后续扩展方向多维混合并行在昇腾AI集群上的落地说到底是一个“平衡”的活儿。计算和通信要平衡显存和算力要平衡并行度和气泡要平衡。没有一套放之四海而皆准的配置每个模型、每个集群都需要针对性地调优。我个人的经验是先从简单的并行策略开始比如纯数据并行或纯张量并行跑通了再逐步叠加其他维度。每加一个维度都要重新评估通信开销和负载均衡。不要一上来就搞最复杂的配置那样出了问题很难定位。另外昇腾的软件栈更新比较快CANN和MindSpore的版本迭代会带来性能提升和新特性。建议定期关注官方文档和社区看看有没有新的并行策略或优化工具。比如最近MindSpore在自动并行方面有不少改进对MoE模型的支持也更好了。后续如果要进一步扩展可以考虑几个方向一是结合昇腾的图编译能力做更激进的算子融合和内存复用二是探索异构并行把部分计算放到CPU或其他加速器上三是优化MoE的路由算法进一步降低All2All的通信开销。这些方向都有不少工程细节可以挖等有机会再展开聊。