上个月我接手一个内部训练任务要在昇腾 AI 集群上跑千亿参数规模的 MoE 模型。第一轮显存估算就把我整懵了单张昇腾 910B 的 HBM 是 64GB光拿 BF16 权重往里塞都放不下更别提梯度和优化器状态。后来把模型摊到一台 8 卡服务器上发现通信开销又开始冒头——卡间互相等数据的时间比真正算的时间还多。折腾了两周真正解决问题的思路并不是某个“魔法开关”而是把训练任务拆到数据、张量、流水线、专家四个维度上做多维混合并行。这篇文章不是昇腾文档的复读机是我在集群上反复调参、看 profiler、等训练看板停表之后整理出来的一套实际操作经验。适合两类人看一类是刚把模型迁移到昇腾、被显存墙和通信墙同时卡住的同学另一类是已经在跑小模型、准备把规模往上抬但不太清楚并行度怎么配、网络怎么规划的朋友。我会把多维混合并行怎么落地到昇腾集群这件事从硬件骨架讲到配置参数再到实测踩坑尽量一次说透。1. 当模型超过单卡显存并行策略成了刚需1.1 一张 910B 到底能装下多大模型先说硬件底牌。昇腾 910B 虽然经常被拿来对比各种 GPU 产品但它本质上不是 GPU而是 NPU华为昇腾系列的核心训练芯片。单卡 HBM 容量 64GB算力在 BF16 精度下大概 300 TFLOPS 的级别卡间走 HCCS 高速互联。这些参数意味着什么用一个最简单的例子70B 稠密模型BF16 权重约 140GB单卡直接超模。即便是 32B 模型权重也要 64GB刚好卡在临界点再加上中间激活和 KV cache单卡根本跑不起来。所以昇腾 AI 集群的应用绝非“单卡就能搞定”而是必须靠多卡、多机协同。这时候问题来了光把模型复制到每张卡上喂不同 batch 并行训练也就是朴素的数据并行能不能解决显存问题答案是能解决一部分但治标不治本。数据并行要求每张卡都放一份完整的模型副本70B 模型在 8 卡上仍然要每卡 140GB单卡 64GB 照样炸。要真正把大模型装进集群必须引入模型并行——把模型本身切开。1.2 “显存墙”和“通信墙”两个同时要解决的瓶颈昇腾集群上跑大模型我会同时盯两个墙显存墙和通信墙。显存墙大家都懂权重、梯度、优化器状态和激活值都需要显存。但其实通信墙在大模型训练里往往才是最先翻车的地方。我举个实测里很直观的现象在一个 8 卡服务器上用张量并行跑 70B 模型每算完一层就把切在 8 张卡上的结果同步一次。如果 HCCS 互联带宽不够或者集合通信算法选得不好计算单元会大量时间空转等数据。这时候看昇腾 profiler会看到“通信算子耗时占比”冲到 40% 甚至更高——这基本就是通信墙把整体吞吐拖垮了。所以要同时解决两个墙思路就得从“单一并行策略”改成“多维混合并行”数据并行负责提高吞吐张量并行把单层切薄以降低显存峰值流水线并行按层切分减少跨机通信专家并行把 MoE 的专家参数分散到多卡。四者组合才能既塞下模型又让通信量在可接受范围。2. 多维混合并行的四个切分维度各自拆开看2.1 数据并行最简单也最依赖梯度同步的维度数据并行DP是所有并行策略里最直觉的一种每张卡都有一份完整模型各自吃不同的 batch前向、反向算完之后互相交换梯度保证所有副本的权重保持一致。昇腾集群上数据并行落地靠的是 HCCL 集合通信库梯度同步通常走 AllReduce 算子。但数据并行有个隐藏成本通信量跟模型参数量成正比。70B 模型一次梯度 AllReduce 就要同步 140GB 的梯度数据BF16总线带宽哪怕再高几十张卡同时做全局规约网络压力也非常大。所以纯数据并行一般只能撑到几十卡规模再往上通信开销增长到完全不划算。那为什么还要在混合并行里保留 DP因为它不切模型、不增加通信频率只是在每个副本之间同步梯度是最稳定的“扩卡手段”。我的经验是DP 维度通常用来“吸收”集群中多余算力比如张量并行 4 张、流水线并行 2 段之后还剩一倍卡就开 DP2 把吞吐拉起来。2.2 张量并行把一层拆成两半同时算张量并行TP是真正意义上“切开模型”的第一种方式。它的思路是把一个 Transformer 层的权重矩阵沿着隐藏维度或者输出维度切成多份分别放在不同卡上计算时每张卡只算自己那 1/TP 的矩阵乘法最后通过一次 AllReduce 把结果拼起来。昇腾 910B 服务器内部 8 卡通过 HCCS 全互联卡间通信延迟低、带宽高所以 TP 是单机内部最常用的切分维度。我用生活化的方式解释 TP 为什么能显著降显存原本一个 100 斤的大箱子一个工人搬不动现在切成 4 份4 个工人同时搬每个人只出 25 斤的力。同理70B 模型切成 TP8每卡只保留 17.5GB 权重单机 8 卡就能装下推理版的全部权重这就是很多人能在单台昇腾 A2 服务器上部署 Qwen3.8Next 这类较大模型的底层原因。但 TP 的代价是通信极其密集每个 Transformer 层的前向和反向都要做至少两次 AllReduceTP 越高单次通信的数据量越小但通信次数和卡间同步的等待就越频繁。所以 TP 一般限制在单机范围内8 卡以内跨机做 TP 会导致通信走 RoCE 网络延迟比 HCCS 高一个数量级性能会非常难看。2.3 流水线并行按层分段的车间流水线流水线并行PP解决的是另一类问题当模型层数很深比如几十层乃至上百层 Transformer完全靠 TP 切分会导致单层跨卡太多、通信量大。PP 的思路是把网络按层切成若干段每个计算设备或设备组负责其中一段。这个概念很像工厂车间里的流水线第一段负责前几层算完把中间结果传给第二段第二段算后面的层第三段再往后。如果想提高流水线效率还要把一个大的 batch 拆成多个 micro-batch让整个流水线像车间里多条工件同时流动一样减少设备空等的时间。PP 的经典问题是气泡bubble流水线刚启动和排空的时候后面的设备和前面的设备不可能完全满负荷。气泡占比大致和“(PP - 1) / (PP 微批次数量 - 1)”成正比。举个例子PP2切 4 个 micro-batch气泡大概占 1/5如果 PP8 而 micro-batch 还是 4 个气泡会涨到一半以上效率惨不忍睹。所以我的实际做法是micro-batch 数量至少是 PP 的 4 倍以上否则不要轻易把 PP 调大。2.4 专家并行MoE 模型的专属切分方式专家并行EP是随着混合专家模型MoE火起来的新维度。MoE 模型的特点是大部分层是共享的稠密计算但每隔几层会有一个专家层里面包含几十到几百个专家网络。前向计算时路由网络把每个 token 分给少数几个专家专家数量多、参数量大但每个 token 只触发其中一部分计算。EP 的核心就是把大量专家切分到不同卡上每张卡只保存一部分专家。token 会根据路由结果通过 All-to-All 通信发给对应的专家所在卡算完再收回来。这样做的收益非常明显千亿参数 MoE 模型里专家部分的参数可能占 600 亿以上如果不做 EP即便 TP 切分也只能硬塞到每卡显存根本不够做了 EP 之后专家参数均匀分散显存压力瞬间降下来。EP 最大的坑是负载不均衡。MoE 路由天然会产生热点专家某些热门专家收到的 token 特别多对应卡负载飙升其他卡闲着。常规解法包括附加负载均衡损失、动态专家并行策略、以及把 All-to-All 做大以分摊流量。在昇腾集群上我一般会把 EP 沿着数据并行副本对应的卡组来切让每个数据副本处理不同的 token 组互相之间的 All-to-All 相对可控。3. 昇腾集群的硬件骨架从板卡互联到跨机组网3.1 单机 8 卡的 HCCS 全互联拓扑要谈昇腾集群服务器架构必须先从一台训练服务器内部的互联说起。以 Atlas 800T A2 训练服务器为例8 张昇腾 910B 卡通过 HCCS 组成全互联拓扑。全互联的意思是任意两张卡之间都有直连通道通信不需要绕过中间的交换芯片。这跟常见 GPU 服务器的 PCIe Switch 互联、NVLink 混合拓扑不是一个概念HCCS 直连带来的好处是带宽高、延迟低非常适合 TP 这种通信密集的并行模式。单机 8 卡的显存总量是 512GB意味着纯权重为 140GB 的 70B 模型在 TP8 或 TPPP 的组合下单机就能装下训练副本。这也是为什么昇腾 A2 单机部署 Qwen3.8Next 这类模型会成为网络热词的原因单机内部的 HCCS 环路延迟极低张量并行的通信成本被控制在可接受范围很多模型无需跨机就能跑起来。给刚接触昇腾的同学一个判断标准如果模型权重加上激活和 KV cache 能控制在单机 8 卡总显存内优先用单机方案通信省下来的收益通常比拿更多机去堆更高 TP/PP 划算得多。3.2 跨机组的 RoCE 网络与集合通信库模型规模继续往上走比如千亿 MoE单机 512GB 也装不下完整权重必须跨机组网。昇腾 AI 集群的跨机互联核心是 RoCERDMA over Converged Ethernet网络典型规格是 100G 或 200G 的 RoCE v2。RoCE 用 RDMA 协议绕过操作系统内核直接读写网卡和内存延迟能压到微秒级但相比卡内 HCCS 还是有一个数量级的差距。这就带来一个设计铁律能放在卡间 HCCS 上做的通信TP不要放到跨机 RoCE 上做需要跨机做的通信PP 的中间激活传递、DP 的梯度同步、EP 的 All-to-All必须尽量降低频率和数据量。我在规划机间组网时基本遵循三个原则一是每台服务器尽量作为一个整体分配到同一个并行组二是跨机的网络拓扑尽量选择无阻塞胖树结构避免多组通信流量在汇聚层打架三是集合通信库 HCCL 的通信算法要按实际拓扑调整避免默认算法在跨机场景产生非最优路径。3.3 算力集群的典型拓扑与规划思路昇腾集群服务器架构从大到小通常是三层训练服务器单机 8 卡、机架内多台服务器的 RoCE 交换、核心层的无阻塞网络互联。举个例子一个 32 卡集群通常是 4 台 8 卡服务器连到一台架顶交换机64 卡或 128 卡集群则会引入两层 Clos 组网保证任意卡之间都能获得接近线性的通信带宽。规划集群的时候我建议先画一张卡位拓扑图每台服务器内部 8 个 HCCS 域是天然的 TP 候选边界服务器之间的 RoCE 链路是 DP、PP、EP 的物理通道。再结合并行策略把 TP4 之类的通信密集组尽可能落在同一台机器内部把 PP 跨机时只传激活值而不是全量权重把 DP 的 AllReduce 拆成机内 HCCS 优先、机间 RoCE 兜底的分层归约。这种“拓扑感知的并行度分配”是昇腾 AI 集群调优的核心思想也是搭好硬件之后真正决定训练效率的关键一步。4. 一个千亿参数的配置方案从理论到可跑的并行组合4.1 以 910B 集群为例的并行度拆分计算理论说再多不如直接给一份可参考的配置。假设我们有一个 64 卡昇腾 AI 集群训练一个总参数约 1200 亿的 MoE 模型其中稠密部分约 400 亿专家部分约 800 亿。我的目标是显存不爆、通信可控、吞吐尽量高。并行度拆分的核心公式是总卡数 DP_local × EP × TP × PP其中 DP_local 是每个专家副本内的数据并行度EP 是专家并行度TP 是张量并行度PP 是流水线并行度。64 张卡可以拆成TP4把 Transformer 层的权重切到 4 卡上卡间走 HCCS单机内部完成通信延迟最低。PP1层数不算特别深且 64 卡规模下 4 层流水线的气泡比较大先不开 PP。EP8800 亿专家参数分成 8 份每卡只保存约 100 亿专家参数显存压力骤降。DP_local2剩下 2 个数据副本并行每个副本吃不同的微批次。四个数相乘4 × 8 × 1 × 2 64成立。这样配置下单卡显存大头是 400 亿稠密参数切 TP4 之后每卡约 20GBBF16再加上专家的 12.5GB100 亿参数加上激活和优化器状态仍然保持在 64GB 以内富余留给 KV cache 和通信。如果你跑的是稠密模型EP 设为 1那么一个 64 卡 70B 模型可以拆成 DP4、TP4、PP2 的组合4 × 4 × 2 32也就是 32 卡够用64 卡就再开 DP8、TP4、PP2总数为 8 × 4 × 2 64。要点是让乘积严格等于总卡数否则框架初始化时就会报并行度不一致的错误。4.2 MindFormers/ModelLink 里怎么描述并行策略昇腾生态里跑大模型最常用的工具链是 MindFormers 和 ModelLink并行策略不需要写 HCCL 底层代码而是通过配置文件和 YAML 参数声明。我在 MindFormers 的并行配置里通常会这样写parallel_config: data_parallel: 2 # DP_local expert_parallel: 8 # EP tensor_parallel: 4 # TP pipeline_parallel: 1 # PP micro_batch_num: 16 # 流水线微批次数PP1 时调大 gradient_aggregation_group: 4 recompute: true # 开启重计算用算力换显存这里有几个容易被忽略的点。第一micro_batch_num在 PP1 时作用不明显但一旦你后期把 PP 调到 2 或 4这个值必须同步拉高否则气泡会直接吃掉 30% 以上的吞吐。第二recompute重计算是显存救星它通过反向传播时重新计算前向激活而不是把所有激活存下来省显存非常多。代价是整体算力开销大约增加 20% 到 30%但当显存不够导致换页或失败时这 20% 的成本远比崩掉重新来划算。MindFormers 加载并行配置后会自动完成模型切分和 HCCL 通信组初始化。但我不建议把所有参数都丢给默认值尤其是卡组顺序在 64 卡集群里卡的编号通常按机内顺序排0-7 是一台机器8-15 是第二台以此类推。TP 组如果跨了机器边界通信就会走 RoCE性能直接打折。所以在配置里要显式指定 device 列表把 0-3 和 4-7 组成两个 TP4 的组而不是让框架按 0-7 连续排列。4.3 折中取舍为什么不是并行度越高越好很多新手会有一种错觉显存不够就把 TP 或 PP 继续调大不就行了但并行度越高通信开销越大最终收益会边际递减。拿 TP 举例TP8 时单层一次 AllReduce 要同步 8 份结果通信量不大但次数多如果跨机做 TP16RoCE 延迟叠加到每次 AllReduce 的等待里造成计算单元的利用率可能低于 50%。PP 同样有取舍。PP4 时理论上能装下更大模型但流水线气泡、微批次之间频繁的激活传递都会拉低整体效率。我通常遵循两个经验规则第一单机内优先把 TP 打到 4 或 8不要跨机做 TP第二跨机优先用 PP 切层或用 DP 扩展样本并行PP 尽量不超过 4超过 4 的收益会被气泡抵消。至于 EP 和 DP 之间更是一个跷跷板。EP 越大专家分布越分散显存越省但 All-to-All 通信流量呈爆发式增长。专家参数只占 800 亿但 token 到专家的路由是动态的如果专家切得太碎单个卡上的本地专家太少很多 token 都必须跨机转发网络瞬间被打满。我实测下来千亿 MoE 在 64 卡规模下 EP8 比较均衡高到 16 时吞吐反而下降 10% 左右。5. 实测调优的几条经验通信重叠、负载均衡和踩坑5.1 计算和通信重叠别让数据搬运打断计算在昇腾集群上跑训练最容易出现的性能杀手不是算力不足而是计算和通信串行执行先等 AllReduce 做完再继续下一层计算。解决办法是实现计算通信重叠——在计算当前层的同时后台提前发起下一层需要的通信。昇腾上做重叠有两种路径。一种靠框架自动优化比如开启图模式后MindSpore 会把通信算子调度到独立的执行流跟计算算子并行执行另一种是手动给通信算子切分把一个大的 AllReduce 拆成多个小的 slice前几个 slice 算完就立即开始下一层计算后面几个 slice 在计算过程中慢慢收尾。这有点像吃饭时不要等所有菜齐了再动筷子先上先吃最后一道菜到的时候你都快吃完了。看训练日志和 profiler 时我会重点盯两个指标一是所有通信算子的重叠率二是单位时间内的有效算力 FLOPs。如果通信耗时占比高但计算 FLOPs 很低说明重叠没生效。此时优先启用多流执行再手动调整通信切分的 chunk 大小而不是盲目加卡。5.2 load balance 与 All-to-All 的优化MoE 训练里All-to-All 通信是最大的不可控项。因为它是动态的跟 token 路由结果强相关如果路由不均衡通信流量也会倾斜到某几块卡上。我遇到过的情况是某个专家非常热门收到的 token 数是平均值的 3 倍导致它的卡显存和通信都过载整个集群停下来等它。针对负载均衡昇腾生态下几个可落地的做法一是加路由辅助损失load balancing loss让路由网络尽量均匀分配 token这是模型层面的兜底二是在配置里调整 EP 的切分粒度把更热门的专家复制成多份类似 expert replication分散热门专家的压力三是把 All-to-All 的通信拆分到多个时间片内执行避免瞬时流量峰值打爆 RoCE 网络的缓存。具体调参的时候我习惯看两个数据所有专家收到的 token 数分布、每张卡的通信流量统计。当分布方差过大时优先加负载均衡损失权重当整体流量都很大时考虑缩小 EP 并放大 TP让更多 token 走卡间 HCCS 而非跨机 RoCE。5.3 我从部署过程中遇到的几个典型问题串一下实际踩过的坑给各位提个醒。第一个问题是并行度乘积对不上总卡数。配置里 DP4、TP4、PP3结果 4×4×348但实际可用 64 卡框架直接报“parallel size mismatch”或者卡在初始化阶段。排查方式很粗暴把四个数乘一遍和world_size比对。新手经常犯但定位最快。第二个问题是集合通信超时。跨机训练时某个 AllReduce 的参与卡被前序计算拖慢导致其他卡等它通信报出 HCCL timeout。我在 64 卡集群上遇到过好几次排查链路是从 profiler 看是哪一台机器的哪张卡明显慢于平均步耗时——通常是某台机器被人并行跑了另一个任务CPU 或内存被打满也可能是 RoCE 网卡热插拔导致链路降速。处理方式是先保证所有机器负载一致再调大通信超时窗口并开启 HCCL 的自适应路由。第三个问题是重计算开关导致的不稳定收益。recompute: true确实能救显存但它会把通信和计算的次序打乱有些算子会重复发起通信导致重叠率下降。我后期的做法是优先靠并行切分把单卡需求压到 45GB 左右剩下的空间再用重计算补而不是把重计算当无脑开启的主干方案。第四个是热词“昇腾系列有哪些 GPU”背后隐含的选型困惑。昇腾没有 GPU但常被人用 GPU 的概念去套。你只需要记住昇腾系列目前主流训练卡是 910 系列910A、910B 等推理和边缘侧常见 310P这些是 NPU生态工具链通过 CANN、MindSpore、HCCL 来对接并行训练跟 CUDA 体系不是一回事。选型时不要光看 TFLOPS还要看 HCCS 拓扑、显存容量、RoCE 网卡规格因为集群架构对实际训练吞吐的影响往往比单卡峰值算力更大。5.4 硬件规模决策什么时候加卡什么时候换策略最后聊聊扩容的策略选择。很多人一看到吞吐上不去第一反应就是加机器但其实加机器之前应该先看看并行策略是不是已经合理。我的建议是分三步走第一步看集群中通信耗时占比如果通信超过 20%先调整并行度分配比如把 TP 缩小、EP 增大、PP 微调而不是加卡加卡会让跨机通信更频繁反而放大问题。第二步看单卡显存余量如果显存还剩 30% 以上优先考虑增大 batch size 或打开梯度累积提升单卡吞吐这比加卡便宜得多。第三步只有模型规模确实超过当前集群的内存总和或者单卡算力利用率已经长期跑满才值得扩卡或换更大算力规格的服务器。扩卡的同时还必须重算并行度分配让通信拓扑和新的卡位图重新匹配。我在实际项目中最明显的一次性能提升来自把 TP 从 8 降到 4同时把 PP 从 1 提到 2DP 从 4 提到 8——完全没加一张卡但因为通信从频繁的机间 AllReduce 变成了更多机内 HCCS 和更少的跨机流水线整体吞吐反而上涨了 18%。这就是多维混合并行的魅力每一维都是在不同资源维度上的杠杆关键不是你用了多少维而是每维的杠杆支点放得对不对。以上经验基本都是我在 32 卡、64 卡昇腾集群上反复对比出来的结论。硬件拓扑不同最优解会有差异但排查链路和调参思路是通用的。你如果正准备把模型往昇腾集群上迁移建议先从最小规模的单机 8 卡把 TP/PP/DP 跑通再逐步叠加 EP 和跨机组网每一步看 profiler、盯通信占比而不是直接把所有并行度一口气配到最大。 上个月我接手一个内部训练任务要在昇腾 AI 集群上跑千亿参数规模的 MoE 模型。第一轮显存估算就把我整懵了单张昇腾 910B 的 HBM 是 64GB光拿 BF16 权重往里塞都放不下更别提梯度和优化器状态。后来把模型摊到一台 8 卡服务器上发现通信开销又开始冒头——卡间互相等数据的时间比真正算的时间还多。折腾了两周真正解决问题的思路并不是某个“魔法开关”而是把训练任务拆到数据、张量、流水线、专家四个维度上做多维混合并行。这篇文章不是昇腾文档的复读机是我在集群上反复调参、看 profiler、等训练看板停表之后整理出来的一套实际操作经验。适合两类人看一类是刚把模型迁移到昇腾、被显存墙和通信墙同时卡住的同学另一类是已经在跑小模型、准备把规模往上抬但不太清楚并行度怎么配、网络怎么规划的朋友。我会把多维混合并行怎么落地到昇腾集群这件事从硬件骨架讲到配置参数再到实测踩坑尽量一次说透。1. 当模型超过单卡显存并行策略成了刚需1.1 一张 910B 到底能装下多大模型先说硬件底牌。昇腾 910B 虽然经常被拿来对比各种 GPU 产品但它本质上不是 GPU而是 NPU华为昇腾系列的核心训练芯片。单卡 HBM 容量 64GB算力在 BF16 精度下大概 300 TFLOPS 的级别卡间走 HCCS 高速互联。这些参数意味着什么用一个最简单的例子70B 稠密模型BF16 权重约 140GB单卡直接超模。即便是 32B 模型权重也要 64GB刚好卡在临界点再加上中间激活和 KV cache单卡根本跑不起来。所以昇腾 AI 集群的应用绝非“单卡就能搞定”而是必须靠多卡、多机协同。这时候问题来了光把模型复制到每张卡上喂不同 batch 并行训练也就是朴素的数据并行能不能解决显存问题答案是能解决一部分但治标不治本。数据并行要求每张卡都放一份完整的模型副本70B 模型在 8 卡上仍然要每卡 140GB单卡 64GB 照样炸。要真正把大模型装进集群必须引入模型并行——把模型本身切开。1.2 “显存墙”和“通信墙”两个同时要解决的瓶颈昇腾集群上跑大模型我会同时盯两个墙显存墙和通信墙。显存墙大家都懂权重、梯度、优化器状态和激活值都需要显存。但其实通信墙在大模型训练里往往才是最先翻车的地方。我举个实测里很直观的现象在一个 8 卡服务器上用张量并行跑 70B 模型每算完一层就把切在 8 张卡上的结果同步一次。如果 HCCS 互联带宽不够或者集合通信算法选得不好计算单元会大量时间空转等数据。这时候看昇腾 profiler会看到“通信算子耗时占比”冲到 40% 甚至更高——这基本就是通信墙把整体吞吐拖垮了。所以要同时解决两个墙思路就得从“单一并行策略”改成“多维混合并行”数据并行负责提高吞吐张量并行把单层切薄以降低显存峰值流水线并行按层切分减少跨机通信专家并行把 MoE 的专家参数分散到多卡。四者组合才能既塞下模型又让通信量在可接受范围。2. 多维混合并行的四个切分维度各自拆开看2.1 数据并行最简单也最依赖梯度同步的维度数据并行DP是所有并行策略里最直觉的一种每张卡都有一份完整模型各自吃不同的 batch前向、反向算完之后互相交换梯度保证所有副本的权重保持一致。昇腾集群上数据并行落地靠的是 HCCL 集合通信库梯度同步通常走 AllReduce 算子。但数据并行有个隐藏成本通信量跟模型参数量成正比。70B 模型一次梯度 AllReduce 就要同步 140GB 的梯度数据BF16总线带宽哪怕再高几十张卡同时做全局规约网络压力也非常大。所以纯数据并行一般只能撑到几十卡规模再往上通信开销增长到完全不划算。那为什么还要在混合并行里保留 DP因为它不切模型、不增加通信频率只是在每个副本之间同步梯度是最稳定的“扩卡手段”。我的经验是DP 维度通常用来“吸收”集群中多余算力比如张量并行 4 张、流水线并行 2 段之后还剩一倍卡就开 DP2 把吞吐拉起来。2.2 张量并行把一层拆成两半同时算张量并行TP是真正意义上“切开模型”的第一种方式。它的思路是把一个 Transformer 层的权重矩阵沿着隐藏维度或者输出维度切成多份分别放在不同卡上计算时每张卡只算自己那 1/TP 的矩阵乘法最后通过一次 AllReduce 把结果拼起来。昇腾 910B 服务器内部 8 卡通过 HCCS 全互联卡间通信延迟低、带宽高所以 TP 是单机内部最常用的切分维度。我用生活化的方式解释 TP 为什么能显著降显存原本一个 100 斤的大箱子一个工人搬不动现在切成 4 份4 个工人同时搬每个人只出 25 斤的力。同理70B 模型切成 TP8每卡只保留 17.5GB 权重单机 8 卡就能装下推理版的全部权重这就是很多人能在单台昇腾 A2 服务器上部署 Qwen3.8Next 这类较大模型的底层原因。但 TP 的代价是通信极其密集每个 Transformer 层的前向和反向都要做至少两次 AllReduceTP 越高单次通信的数据量越小但通信次数和卡间同步的等待就越频繁。所以 TP 一般限制在单机范围内8 卡以内跨机做 TP 会导致通信走 RoCE 网络延迟比 HCCS 高一个数量级性能会非常难看。2.3 流水线并行按层分段的车间流水线流水线并行PP解决的是另一类问题当模型层数很深比如几十层乃至上百层 Transformer完全靠 TP 切分会导致单层跨卡太多、通信量大。PP 的思路是把网络按层切成若干段每个计算设备或设备组负责其中一段。这个概念很像工厂车间里的流水线第一段负责前几层算完把中间结果传给第二段第二段算后面的层第三段再往后。如果想提高流水线效率还要把一个大的 batch 拆成多个 micro-batch让整个流水线像车间里多条工件同时流动一样减少设备空等的时间。PP 的经典问题是气泡bubble流水线刚启动和排空的时候后面的设备和前面的设备不可能完全满负荷。气泡占比大致和“(PP - 1) / (PP 微批次数量 - 1)”成正比。举个例子PP2切 4 个 micro-batch气泡大概占 1/5如果 PP8 而 micro-batch 还是 4 个气泡会涨到一半以上效率惨不忍睹。所以我的实际做法是micro-batch 数量至少是 PP 的 4 倍以上否则不要轻易把 PP 调大。2.4 专家并行MoE 模型的专属切分方式专家并行EP是随着混合专家模型MoE火起来的新维度。MoE 模型的特点是大部分层是共享的稠密计算但每隔几层会有一个专家层里面包含几十到几百个专家网络。前向计算时路由网络把每个 token 分给少数几个专家专家数量多、参数量大但每个 token 只触发其中一部分计算。EP 的核心就是把大量专家切分到不同卡上每张卡只保存一部分专家。token 会根据路由结果通过 All-to-All 通信发给对应的专家所在卡算完再收回来。这样做的收益非常明显千亿参数 MoE 模型里专家部分的参数可能占 600 亿以上如果不做 EP即便 TP 切分也只能硬塞到每卡显存根本不够做了 EP 之后专家参数均匀分散显存压力瞬间降下来。EP 最大的坑是负载不均衡。MoE 路由天然会产生热点专家某些热门专家收到的 token 特别多对应卡负载飙升其他卡闲着。常规解法包括附加负载均衡损失、动态专家并行策略、以及把 All-to-All 做大以分摊流量。在昇腾集群上我一般会把 EP 沿着数据并行副本对应的卡组来切让每个数据副本处理不同的 token 组互相之间的 All-to-All 相对可控。3. 昇腾集群的硬件骨架从板卡互联到跨机组网3.1 单机 8 卡的 HCCS 全互联拓扑要谈昇腾集群服务器架构必须先从一台训练服务器内部的互联说起。以 Atlas 800T A2 训练服务器为例8 张昇腾 910B 卡通过 HCCS 组成全互联拓扑。全互联的意思是任意两张卡之间都有直连通道通信不需要绕过中间的交换芯片。这跟常见 GPU 服务器的 PCIe Switch 互联、NVLink 混合拓扑不是一个概念HCCS 直连带来的好处是带宽高、延迟低非常适合 TP 这种通信密集的并行模式。单机 8 卡的显存总量是 512GB意味着纯权重为 140GB 的 70B 模型在 TP8 或 TPPP 的组合下单机就能装下训练副本。这也是为什么昇腾 A2 单机部署 Qwen3.8Next 这类模型会成为网络热词的原因单机内部的 HCCS 环路延迟极低张量并行的通信成本被控制在可接受范围很多模型无需跨机就能跑起来。给刚接触昇腾的同学一个判断标准如果模型权重加上激活和 KV cache 能控制在单机 8 卡总显存内优先用单机方案通信省下来的收益通常比拿更多机去堆更高 TP/PP 划算得多。3.2 跨机组的 RoCE 网络与集合通信库模型规模继续往上走比如千亿 MoE单机 512GB 也装不下完整权重必须跨机组网。昇腾 AI 集群的跨机互联核心是 RoCERDMA over Converged Ethernet网络典型规格是 100G 或 200G 的 RoCE v2。RoCE 用 RDMA 协议绕过操作系统内核直接读写网卡和内存延迟能压到微秒级但相比卡内 HCCS 还是有一个数量级的差距。这就带来一个设计铁律能放在卡间 HCCS 上做的通信TP不要放到跨机 RoCE 上做需要跨机做的通信PP 的中间激活传递、DP 的梯度同步、EP 的 All-to-All必须尽量降低频率和数据量。我在规划机间组网时基本遵循三个原则一是每台服务器尽量作为一个整体分配到同一个并行组二是跨机的网络拓扑尽量选择无阻塞胖树结构避免多组通信流量在汇聚层打架三是集合通信库 HCCL 的通信算法要按实际拓扑调整避免默认算法在跨机场景产生非最优路径。3.3 算力集群的典型拓扑与规划思路昇腾集群服务器架构从大到小通常是三层训练服务器单机 8 卡、机架内多台服务器的 RoCE 交换、核心层的无阻塞网络互联。举个例子一个 32 卡集群通常是 4 台 8 卡服务器连到一台架顶交换机64 卡或 128 卡集群则会引入两层 Clos 组网保证任意卡之间都能获得接近线性的通信带宽。规划集群的时候我建议先画一张卡位拓扑图每台服务器内部 8 个 HCCS 域是天然的 TP 候选边界服务器之间的 RoCE 链路是 DP、PP、EP 的物理通道。再结合并行策略把 TP4 之类的通信密集组尽可能落在同一台机器内部把 PP 跨机时只传激活值而不是全量权重把 DP 的 AllReduce 拆成机内 HCCS 优先、机间 RoCE 兜底的分层归约。这种“拓扑感知的并行度分配”是昇腾 AI 集群调优的核心思想也是搭好硬件之后真正决定训练效率的关键一步。4. 一个千亿参数的配置方案从理论到可跑的并行组合4.1 以 910B 集群为例的并行度拆分计算理论说再多不如直接给一份可参考的配置。假设我们有一个 64 卡昇腾 AI 集群训练一个总参数约 1200 亿的 MoE 模型其中稠密部分约 400 亿专家部分约 800 亿。我的目标是显存不爆、通信可控、吞吐尽量高。并行度拆分的核心公式是总卡数 DP_local × EP × TP × PP其中 DP_local 是每个专家副本内的数据并行度EP 是专家并行度TP 是张量并行度PP 是流水线并行度。64 张卡可以拆成TP4把 Transformer 层的权重切到 4 卡上卡间走 HCCS单机内部完成通信延迟最低。PP1层数不算特别深且 64 卡规模下 4 层流水线的气泡比较大先不开 PP。EP8800 亿专家参数分成 8 份每卡只保存约 100 亿专家参数显存压力骤降。DP_local2剩下 2 个数据副本并行每个副本吃不同的微批次。四个数相乘4 × 8 × 1 × 2 64成立。这样配置下单卡显存大头是 400 亿稠密参数切 TP4 之后每卡约 20GBBF16再加上专家的 12.5GB100 亿参数加上激活和优化器状态仍然保持在 64GB 以内富余留给 KV cache 和通信。如果你跑的是稠密模型EP 设为 1那么一个 64 卡 70B 模型可以拆成 DP4、TP4、PP2 的组合4 × 4 × 2 32也就是 32 卡够用64 卡就再开 DP8、TP4、PP2总数为 8 × 4 × 2 64。要点是让乘积严格等于总卡数否则框架初始化时就会报并行度不一致的错误。4.2 MindFormers/ModelLink 里怎么描述并行策略昇腾生态里跑大模型最常用的工具链是 MindFormers 和 ModelLink并行策略不需要写 HCCL 底层代码而是通过配置文件和 YAML 参数声明。我在 MindFormers 的并行配置里通常会这样写parallel_config: data_parallel: 2 # DP_local expert_parallel: 8 # EP tensor_parallel: 4 # TP pipeline_parallel: 1 # PP micro_batch_num: 16 # 流水线微批次数PP1 时调大 gradient_aggregation_group: 4 recompute: true # 开启重计算用算力换显存这里有几个容易被忽略的点。第一micro_batch_num在 PP1 时作用不明显但一旦你后期把 PP 调到 2 或 4这个值必须同步拉高否则气泡会直接吃掉 30% 以上的吞吐。第二recompute重计算是显存救星它通过反向传播时重新计算前向激活而不是把所有激活存下来省显存非常多。代价是整体算力开销大约增加 20% 到 30%但当显存不够导致换页或失败时这 20% 的成本远比崩掉重新来划算。MindFormers 加载并行配置后会自动完成模型切分和 HCCL 通信组初始化。但我不建议把所有参数都丢给默认值尤其是卡组顺序在 64 卡集群里卡的编号通常按机内顺序排0-7 是一台机器8-15 是第二台以此类推。TP 组如果跨了机器边界通信就会走 RoCE性能直接打折。所以在配置里要显式指定 device 列表把 0-3 和 4-7 组成两个 TP4 的组而不是让框架按 0-7 连续排列。4.3 折中取舍为什么不是并行度越高越好很多新手会有一种错觉显存不够就把 TP 或 PP 继续调大不就行了但并行度越高通信开销越大最终收益会边际递减。拿 TP 举例TP8 时单层一次 AllReduce 要同步 8 份结果通信量不大但次数多如果跨机做 TP16RoCE 延迟叠加到每次 AllReduce 的等待里造成计算单元的利用率可能低于 50%。PP 同样有取舍。PP4 时理论上能装下更大模型但流水线气泡、微批次之间频繁的激活传递都会拉低整体效率。我通常遵循两个经验规则第一单机内优先把 TP 打到 4 或 8不要跨机做 TP第二跨机优先用 PP 切层或用 DP 扩展样本并行PP 尽量不超过 4超过 4 的收益会被气泡抵消。至于 EP 和 DP 之间更是一个跷跷板。EP 越大专家分布越分散显存越省但 All-to-All 通信流量呈爆发式增长。专家参数只占 800 亿但 token 到专家的路由是动态的如果专家切得太碎单个卡上的本地专家太少很多 token 都必须跨机转发网络瞬间被打满。我实测下来千亿 MoE 在 64 卡规模下 EP8 比较均衡高到 16 时吞吐反而下降 10% 左右。5. 实测调优的几条经验通信重叠、负载均衡和踩坑5.1 计算和通信重叠别让数据搬运打断计算在昇腾集群上跑训练最容易出现的性能杀手不是算力不足而是计算和通信串行执行先等 AllReduce 做完再继续下一层计算。解决办法是实现计算通信重叠——在计算当前层的同时后台提前发起下一层需要的通信。昇腾上做重叠有两种路径。一种靠框架自动优化比如开启图模式后MindSpore 会把通信算子调度到独立的执行流跟计算算子并行执行另一种是手动给通信算子切分把一个大的 AllReduce 拆成多个小的 slice前几个 slice 算完就立即开始下一层计算后面几个 slice 在计算过程中慢慢收尾。这有点像吃饭时不要等所有菜齐了再动筷子先上先吃最后一道菜到的时候你都快吃完了。看训练日志和 profiler 时我会重点盯两个指标一是所有通信算子的重叠率二是单位时间内的有效算力 FLOPs。如果通信耗时占比高但计算 FLOPs 很低说明重叠没生效。此时优先启用多流执行再手动调整通信切分的 chunk 大小而不是盲目加卡。5.2 load balance 与 All-to-All 的优化MoE 训练里All-to-All 通信是最大的不可控项。因为它是动态的跟 token 路由结果强相关如果路由不均衡通信流量也会倾斜到某几块卡上。我遇到过的情况是某个专家非常热门收到的 token 数是平均值的 3 倍导致它的卡显存和通信都过载整个集群停下来等它。针对负载均衡昇腾生态下几个可落地的做法一是加路由辅助损失load balancing loss让路由网络尽量均匀分配 token这是模型层面的兜底二是在配置里调整 EP 的切分粒度把更热门的专家复制成多份类似 expert replication分散热门专家的压力三是把 All-to-All 的通信拆分到多个时间片内执行避免瞬时流量峰值打爆 RoCE 网络的缓存。具体调参的时候我习惯看两个数据所有专家收到的 token 数分布、每张卡的通信流量统计。当分布方差过大时优先加负载均衡损失权重当整体流量都很大时考虑缩小 EP 并放大 TP让更多 token 走卡间 HCCS 而非跨机 RoCE。5.3 我从部署过程中遇到的几个典型问题串一下实际踩过的坑给各位提个醒。第一个问题是并行度乘积对不上总卡数。配置里 DP4、TP4、PP3结果 4×4×348但实际可用 64 卡框架直接报“parallel size mismatch”或者卡在初始化阶段。排查方式很粗暴把四个数乘一遍和world_size比对。新手经常犯但定位最快。第二个问题是集合通信超时。跨机训练时某个 AllReduce 的参与卡被前序计算拖慢导致其他卡等它通信报出 HCCL timeout。我在 64 卡集群上遇到过好几次排查链路是从 profiler 看是哪一台机器的哪张卡明显慢于平均步耗时——通常是某台机器被人并行跑了另一个任务CPU 或内存被打满也可能是 RoCE 网卡热插拔导致链路降速。处理方式是先保证所有机器负载一致再调大通信超时窗口并开启 HCCL 的自适应路由。第三个问题是重计算开关导致的不稳定收益。recompute: true确实能救显存但它会把通信和计算的次序打乱有些算子会重复发起通信导致重叠率下降。我后期的做法是优先靠并行切分把单卡需求压到 45GB 左右剩下的空间再用重计算补而不是把重计算当无脑开启的主干方案。第四个是热词“昇腾系列有哪些 GPU”背后隐含的选型困惑。昇腾没有 GPU但常被人用 GPU 的概念去套。你只需要记住昇腾系列目前主流训练卡是 910 系列910A、910B 等推理和边缘侧常见 310P这些是 NPU生态工具链通过 CANN、MindSpore、HCCL 来对接并行训练跟 CUDA 体系不是一回事。选型时不要光看 TFLOPS还要看 HCCS 拓扑、显存容量、RoCE 网卡规格因为集群架构对实际训练吞吐的影响往往比单卡峰值算力更大。5.4 硬件规模决策什么时候加卡什么时候换策略最后聊聊扩容的策略选择。很多人一看到吞吐上不去第一反应就是加机器但其实加机器之前应该先看看并行策略是不是已经合理。我的建议是分三步走第一步看集群中通信耗时占比如果通信超过 20%先调整并行度分配比如把 TP 缩小、EP 增大、PP 微调而不是加卡加卡会让跨机通信更频繁反而放大问题。第二步看单卡显存余量如果显存还剩 30% 以上优先考虑增大 batch size 或打开梯度累积提升单卡吞吐这比加卡便宜得多。第三步只有模型规模确实超过当前集群的内存总和或者单卡算力利用率已经长期跑满才值得扩卡或换更大算力规格的服务器。扩卡的同时还必须重算并行度分配让通信拓扑和新的卡位图重新匹配。我在实际项目中最明显的一次性能提升来自把 TP 从 8 降到 4同时把 PP 从 1 提到 2DP 从 4 提到 8——完全没加一张卡但因为通信从频繁的机间 AllReduce 变成了更多机内 HCCS 和更少的跨机流水线整体吞吐反而上涨了 18%。这就是多维混合并行的魅力每一维都是在不同资源维度上的杠杆关键不是你用了多少维而是每维的杠杆支点放得对不对。以上经验基本都是我在 32 卡、64 卡昇腾集群上反复对比出来的结论。硬件拓扑不同最优解会有差异但排查链路和调参思路是通用的。你如果正准备把模型往昇腾集群上迁移建议先从最小规模的单机 8 卡把 TP/PP/DP 跑通再逐步叠加 EP 和跨机组网每一步看 profiler、盯通信占比而不是直接把所有并行度一口气配到最大。