1. 昇腾AI集群的定位与要解决的问题昇腾AI集群服务器架构一句话说清楚它是一套把上千张昇腾NPU卡组织起来协同完成超大规模模型训练和推理的算力基础设施方案。核心关键词是“多维混合并行”——不是单一维度的数据并行也不是简单的模型并行而是把数据并行、张量并行、流水线并行、专家并行等策略混合编排在不同层级同时使用从而把集群算力利用率顶上去。为什么需要这东西这几年大语言模型、多模态模型的参数规模一路猛涨单张计算卡显存撑死也就几十上百GB放不下动辄千亿万亿参数的模型。更麻烦的是模型太大之后单卡算力再强也扛不住训练时长。于是行业里形成共识必须把计算任务拆开分给多张卡、多台服务器一起干。但“拆”这件事本身有讲究——拆得不好通信开销能把算力收益吃掉一大半。昇腾AI集群的多维混合并行本质就是一套如何拆、拆几维、怎么让拆开的碎片高效协作的方法论加工程实现。这事适合谁看三种人。第一种是正在搭建AI训练基础设施的架构师和平台工程师需要评估昇腾这条路怎么走第二种是做分布式训练框架适配和性能优化的研发想搞明白并行策略怎么配、集群拓扑怎么影响通信第三种是想入行AI基础设施的开发者把昇腾集群当样本理解大规模分布式训练的通用逻辑。文章里我会把硬件架构、并行策略、组网拓扑、虚拟化集成、性能调优这些环节逐个拆开讲全程围绕“多维混合并行”这个核心展开。2. 硬件底座昇腾集群由哪些部分组成2.1 计算平面昇腾NPU的架构特征昇腾AI集群的计算核心是昇腾NPU它和GPU在架构上不是一个路子。昇腾芯片采用达芬奇架构最突出的特点是设计了统一的AI Core和专精的Cube、Vector计算单元算力调度由AI Core统一管理。Cube单元擅长矩阵运算Transformer里的Attention计算、FFN层中的矩阵乘法这类操作在Cube上跑得非常快Vector单元处理逐元素操作像激活函数、LayerNorm这些。这个设计意图很清楚Transformer架构占主流的时代矩阵运算就是痛点把矩阵算力堆足大模型训练的性价比就上来了。集群级别来看一台昇腾训练服务器通常插8张或16张昇腾NPU卡卡间通过高速总线互联。以Atlas 800训练服务器为例8卡配置是比较典型的形态单机提供足够的算力和显存继续往上扩展就靠跨节点组网了。这里有个容易忽略的点单卡算力再强如果多卡通信跟不上集群规模上来之后性能曲线会很快变平甚至下降所以通信设计是昇腾集群的重中之重。2.2 网络平面从服务器内部到跨节点互联昇腾集群的网络分为inside和outside两层。服务器内部8张卡之间通过华为自研的HCCS互联带宽高、时延低配合NUMA亲和性设计卡间通信效率很高。这个内部互联拓扑直接影响张量并行的放置策略——同一台服务器内的卡之间通信快所以张量并行的切分最好不跨机先填满机内再往上走。跨节点互联走的是RDMA网络即将发布的昇腾950集群已经普遍支持400Gbps以上的RoCE或InfiniBand方案。RoCE v2协议在兼容性和成本上有优势搭配无损网络配置后性能可以逼近InfiniBand。组网架构上大规模集群普遍采用Fat-Tree或Dragonfly拓扑Fat-Tree实现简单、等价多路径负载均衡容易做但需要的交换机层级多Dragonfly在同等规模下光缆成本和跳数更少但路由算法复杂。目前昇腾大规模集群在向Dragonfly自适应路由的方向演进核心目的只有一个让任意两张卡之间的通信路径可控、时延可预期。网络平面里还有个隐藏的架构设计就是计算网络、存储网络、管理网络三网分离。计算网络承载训练时的张量同步和梯度同步存储网络单独走数据读取和检查点保存管理网络只做管控面通信。这样做的原因很现实如果训练数据和梯度同步混在同一个网络上数据读取的突发流量会直接冲击梯度同步的时延导致集群训练效率抖动。三网隔离之后每个平面的负载特性单一调优起来更清晰。2.3 存储平面与训练数据供给AI集群的存储平面往往被低估但实际训练时瓶颈经常卡在这里。大模型训练每个step都要读一批训练样本检查点周期性地落盘如果存储带宽不够GPU/NPU就得空转等待数据。昇腾集群的存储侧一般建议搭配全闪存并行文件系统配合高速RDMA网络挂载到训练节点。实践中的一个关键指标是存储系统的聚合带宽要大于所有训练节点的数据消费速度总和最好留出40%以上的余量否则峰值读取时极大概率拖慢训练。2.4 昇腾系列产品线梳理与选型建议昇腾产品线目前覆盖从边缘到数据中心的完整算力层级。昇腾310系列主打推理场景功耗低适合边缘盒子、智能摄像头这类设备昇腾810系列用于轻量级训练和推理卡密度高昇腾910系列是数据中心主流训练卡广泛用在千卡集群里。业内高度关注的昇腾950系列已经进入测试阶段从测试流出的数据看在BF16下的算力密度、显存容量和HCCS带宽上相比910B都有明显提升FP8支持也被重点强化。选型时不要只盯着单卡算力一定要结合集群规模看通信能力。小规模训练8卡到64卡看单卡性能和机内互联就够了百卡以上必须评估HCCS跨机能力和RoCE网络配置千卡以上阶段拓扑结构、故障率、运维工具链的成熟度比单卡算力更重要。3. 多维混合并行的原理与策略拆解3.1 为什么单一并行策略不够用并行训练的基本思路是“把活分开干”但分开的方向有讲究。数据并行把训练数据切成多份每张卡都保留一份完整模型副本各自算梯度然后求平均模型并行则反过来把模型切开放到多张卡上。数据并行的问题非常直观模型太大放不下每张卡都得存完整模型显存直接爆掉模型并行的问题也很明显切得太碎之后卡与卡之间互相等的次数增多通信开销直线上升。实际大规模训练中从来没有哪种单一策略能同时解决“模型放得下”和“算得快”这两个问题。数据并行解决不了模型太大模型并行解决不了通信效率。所以业界把多种并行策略组合起来在不同维度同时切分扬长避短。这个组合方案就是多维混合并行也是目前千亿参数训练的唯一可行路线。3.2 数据并行最基础的切分维度数据并行是最容易理解的一种策略。假设有64张卡把训练batch切成64份每张卡喂不同的数据子集每张卡上都有一份完整的模型副本。前向传播各自算损失函数各自算然后反向传播算出梯度接下来需要把64份梯度做AllReduce求平均再同步更新每张卡上的模型参数。这一步AllReduce就是数据并行的关键开销。好在这类通信有成熟的优化手段梯度分桶通信、梯度压缩、延迟同步等。昇腾的HCCL集合通信库对AllReduce做了深度优化配合RDMA网络在千卡规模下依然能把通信开销控制在可接受范围。数据并行还有一个明显的优势是扩展性好卡多了直接把global batch加大就行训练吞吐基本线性增长前提是模型单卡放得下、梯度同步通信占比不被拉得太高。3.3 张量并行与流水线并行模型并行的两种切法张量并行解决的是“模型层内部太大”的问题。拿Transformer的一个Attention层来说QKV矩阵乘法的权重动辄上亿参数单卡算力强也架不住乘以batch size之后中间结果爆显存。张量并行的做法是把权重矩阵按行或按列切成多块分别放在多张卡上每张卡只算自己的那块分片必要时做一次AllReduce把部分结果合并。这个策略要求切分后的碎片之间通信非常频繁因为每个Transformer层的前向反向都要做多次集合通信所以张量并行一般只在机内、通过HCCS高速互联完成跨机的张量并行成本太高除非模型实在大得没办法。流水线并行则是纵向切分把模型按层切成多段每一段分配给不同的设备。比如一个40层的模型切成4段卡0负责1到10层卡1负责11到20层以此类推。数据像流水线一样依次流过各段设备。流水线并行的通信量比张量并行小得多它只需要在段的边界传递激活值和梯度但它有个核心问题是设备利用率——前段设备算完一批数据之后后段还没算完中间会出现空等。业界用micro-batch切分加1F1B调度策略来缓解这个气泡问题把空等时间压到很低。昇腾框架在流水线并行调度上已经内置了成熟的并行策略配置rank和层级关系后基本不用手写调度逻辑。3.4 专家并行MoE模型带来的新维度稀疏专家模型是当前超大模型的一个重要方向原理是模型里同时存在多个结构相同的“专家”子网络每个token只激活其中少数几个专家。这样做的好处是用更少的算力激活更多的模型参数模型容量变大而计算量增长有限。但MoE给并行训练提出了新问题哪张卡放哪个专家token被路由到不同专家之后专家之间的负载可能严重不均衡有的专家忙不过来有的闲着。专家并行就是专门为MoE设计的并行策略——把专家分布到不同设备上token按路由结果被送到对应设备计算通信模式从规则的张量通信变成了动态的All-to-All通信。昇腾的集合通信库对All-to-All通信做了专门优化配合拓扑感知的路由策略在千卡MoE训练中表现稳定。值得注意的是专家并行的通信量和token路由模式高度相关训练过程中如果负载失衡严重要先调整路由分配策略而不是盲目增大网络带宽。3.5 多维组合的核心逻辑怎么混合才最高效多维混合并行不是简单地把各种策略叠加到一起而是要在不同维度上取合适的并行度。通用的框架是先用流水线并行解决模型深度问题把模型切成多层段再在每一段内部用张量并行处理单层参数过大的问题最后对每个模型副本使用数据并行用更多卡并行处理更多数据如果模型里有MoE层再叠加专家并行。并行度怎么分配是个数学问题核心约束是看卡间通信拓扑。张量并行要求通信最频繁必须放在机内流水线并行次之可以放在相邻节点数据并行通信模式最简单跨交换机也无所谓。算力规模相同的情况下张量并行度设8用满一间机内卡、流水线并行度设4、数据并行度设32这种组合往往比张量并行度16、数据并行度16的配置更好调、通信更稳。实际调优时用不同的并行度组合各跑一小段benchmark测吞吐量之后再定方案比纸上谈兵靠谱得多。4. 从单机到千卡集群组网拓扑与部署要点4.1 大规模集群的网络拓扑选择昇腾千卡集群的典型物理组网形态是8卡服务器作为基本单元机柜内通过Leaf交换机互联多个机柜汇聚到Spine层往上还有核心层形成Fat-Tree结构。这样的拓扑在昇腾的RoCE方案里已经非常成熟每一层都保证了等价多路径冗余。选择Fat-Tree的一个实际考量是容错和运维。一个千卡集群的故障率其实是比较高的卡故障、光模块故障、网线松动都是家常便饭。Fat-Tree天然提供多条等价路径单条链路断掉之后流量可以自动切换到其他路径对训练任务的影响能控制在很小的范围。同时ECMP等价多路径让负载可以比较均匀地散到多条链路上避免某条链路成为热点。Dragonfly拓扑在更大规模万卡级别时更有优势因为它减少了网络直径降低了光模块和交换机成本。但Dragonfly的全局路由策略复杂故障对性能的影响扩散面更大调试难度也更高。昇腾950测试阶段已经开始验证Dragonfly方案但我个人建议——除非规模真的奔着万卡去否则第一选择仍然优先考虑Fat-Tree成熟方案踩坑成本低很多。4.2 基于libvirt的KVM虚拟化环境适配昇腾集群里有相当一部分场景是在OpenEuler系统上通过libvirt-daemon-KVM做虚拟化把物理NPU资源虚拟化后分发给云上用户。昇腾提供了NPU直通和NPU虚拟化两种路径。直通模式下虚拟机的QEMU配置里通过vendor device方式直接把NPU映射给虚拟机性能损耗低但灵活性差一台虚拟机只能绑定一张物理卡。虚拟化模式下昇腾的Ascend Docker和KVM配合可以把一张物理NPU切分成多个虚拟NPU实例让多个虚拟机共享同一张卡的算力。这块实际踩坑不少OpenEuler上libvirt-daemon-kvm默认没有启用VFIO的中断重映射直通NPU的虚拟机起不来或者中断报错需要在内核参数里打开intel_iommu或者AMD的对应IOMMU选项再确认vfio-pci模块已装载。QEMU的配置里还要给虚拟机开辟足够的HugePages否则NPU DMA映射大页内存时容易失败。虚拟化环境的性能损耗是必须正视的问题。实测下来纯直通模式的性能损耗基本可以控制在3%以内而NPU虚拟化共享模式的损耗会随虚拟实例数量上升切到4个实例以上时损耗可能达到10%以上。生产环境里如果对性能极其敏感的大模型训练任务我建议优先走直通模式开发和测试环境可以用虚拟化切分提升资源利用率。4.3 集群部署的操作检查清单部署昇腾集群不是一个“装个驱动就能跑”的过程我列一份基于实操的检查清单每一条背后都对应真实踩坑经验固件和驱动版本匹配是第一优先级昇腾NPU对固件版本极其敏感驱动和固件版本不一致会出现训练时莫名其妙报错、NPU掉卡的现象每次升级前先查兼容性列表。BIOS固件里的SR-IOV、NUMA、ACS、Resizable BAR都要确认打开特别是Resizable BAR不打开的话NPU显存映射受限大模型加载会失败。机内HCCS互联有效性测试用ascend-dmi工具查看NPU之间的拓扑和带宽如果出现某张卡和邻居卡互联速率异常大概率是物理链路或PCIe lane配置问题。RoCE网络的PFC和ECN配置必须在所有交换机端口和网卡侧保持一致否则流量一拥塞就会出现RoCE丢包训练性能直接掉一大截而且问题极其隐蔽。三网隔离的VLAN和IP规划先写在部署文档里计算网络、存储网络、管理网络各自独立网段禁止复用。5. 性能调优路径与踩坑实录5.1 集合通信分析与通信瓶颈定位集合通信是分布式训练的命门绝大多数性能问题都能追溯到通信上。昇腾提供了hccl_tool和训练框架中的profiling工具可以直观看到通信算子的耗时占比。当训练吞吐上不去时第一个动作不是调并行度而是跑一次profiling看通信时间占总step时间的比例。这个比例在15%以内是健康的超过30%就需要介入优化。通信瓶颈大概率从这几个方向找第一检查网络有没有丢包RoCE网络的丢包会引发重传风暴重传的代价极高性能断层式下跌第二检查通信数据量是不是过大比如张量并行度太小导致每轮AllReduce的数据量巨大这种情况要增加张量并行度来减小单次通信量第三看通信调度是否是串行的有时候前一个通信算子没算完后一个通信算子就只能排队等待需要用通信算子重叠计算来规避。另外一个参考做法是开启AllReduce的流水线化把梯度按层切分成多个小块每算出一块梯度就开始通信不用等全部梯度算完再统一通信。这样通信和反向计算可以重叠实际训练吞吐能提升10%到20%昇腾的HCCL对这类梯度分桶通信做了专门适配开启成本很低。5.2 并行度与模型结构匹配不同模型结构对并行策略的偏好差异很大。稠密Transformer模型比如GPT类的核心矛盾是模型参数太大放不下显存所以优先保证张量并行的显存节省能力其次再考虑流水线并行MoE模型的核心矛盾是路由不均匀带来的负载漂移专家并行的负载均衡策略比并行度设置本身更重要超大batch场景下数据并行的梯度同步频率和通信量的平衡是主要关注点。实操时有个经验值对于稠密Transformer单卡显存占用率建议控制在80%以下。如果并行度配置导致单卡显存占用超过90%训练一跑起来非常容易OOM而且OOM多半发生在峰值时刻很难提前预判。遇到显存压力大的情况优先检查激活重计算是否开启——开启激活重计算后前向传播的中间激活值不保存反向传播时重新算一遍显存占用能压下一半代价是约10%到20%的计算量增加。这个trade-off在大多场景下都划算。5.3 故障排查与稳定性维护要点大规模集群训练任务跑着跑着掉了某个节点是常态关键是要有故障感知和恢复机制。昇腾集群的训练框架一般支持异常节点自动重启和检查点续训但前提是检查点保存频率设置得过密会拖慢训练过疏会丢进度建议根据训练时长来设定——白天有人盯可以2小时存一次夜间自动跑最好缩短到30分钟存一次。NPU的散热和降频也是稳定性的隐性影响因素。机柜散热不好时NPU温度超过阈值会主动降频训练速度悄悄变慢但日志里不一定有明显报错排查难度大。建议部署温度监控和功耗监控当整柜功耗或卡温度出现异常波动时及时干预。另外长时间训练后卡间HCCS链路偶尔出现误码率上升的现象需要定期跑HCCS自检脚本发现误码率超标尽早更换线缆或光模块避免出现训练中途大规模掉链路的恶性故障。6. 从单机到千卡集群的落地步骤参考6.1 平台软件栈的搭建路径昇腾集群的软件栈遵循从底层到上层的严格顺序NPU固件、NPU驱动、CANN工具链、Ascend训练框架、高层分布式训练接口。顺序错乱会导致兼容性问题比如先装了CANN再装驱动CANN依赖的系统环境检测就会报错。安装之后用自带的检测工具验证NPU状态确认所有卡都处于健康状态再走下一步。容器化部署是当前的主流方式Ascend Docker镜像已经集成了驱动依赖和CANN环境调度平台可以通过Kubernetes的device plugin识别容器内可用的NPU资源。这里有个顺序细节镜像里的CANN版本必须和宿主机驱动版本配套否则容器内跑训练时会报版本不匹配的错误。不少团队踩过这个坑升级了宿主机的NPU驱动但忘了更新容器镜像导致大量训练任务突然失败。6.2 小规模验证到千卡扩展的路线强烈建议遵循“先小后大”的路线走。第一阶段拿一两台8卡服务器做单机多卡验证把模型跑通、并行度调优摸清楚第二阶段扩展到32卡验证RoCE组网和多节点集合通信是否有异常第三阶段再上数百卡甚至千卡重点验证调度平台、容错恢复和运维监控。跳步是大忌——直接从小规模跳到千卡出了问题连排查切入点都没有因为影响面太大。扩卡数时要关注集群有效算力利用率MFUMFU是衡量训练系统效率的核心指标等于实际计算吞吐除以理论峰值算力。业界优秀的千卡训练跑LLM时MFU大概在40%到55%之间。如果扩展到千卡之后MFU比小规模时明显下降不要怀疑硬件变差了大概率是多维混合并行的通信开销随规模非线性增长需要重新平衡并行度或者优化集合通信的拓扑编排。6.3 容器调度与资源池化的配置思路昇腾集群资源池化后训练作业按需申请NPU资源Kubernetes版调度器能感知NPU拓扑尽量把同一个训练任务的不同并行角色调度到通信开销最小的物理位置。比如张量并行的8个rank尽量调度到同一台服务器内流水线并行的相邻rank尽量保持在同一机柜内。这样的拓扑感知调度能把集合通信的跨机流量降到最低训练吞吐更稳定。7. 经验体会与后续扩展建议做了这么多年集群训练我最深的感受是硬件堆料解决不了并行策略设计的问题。昇腾集群的单卡算力、带宽配置其实相当扎实但能不能把千卡集群的算力真正用起来取决于对多维混合并行的理解深度和并行度分配调优的实际经验。一台8卡的机器随便跑点小模型看不出差距但模型规模一上来、集群一上千卡不同的并行配置在MFU上能差出20个百分点这就是调优的价值所在。后续这个方向还有几个可以扩展的点。一个是长稳训练能力千卡集群连续跑数周甚至数月不中断的能力——故障预测、自动容错、保活升级这些是生产训练的硬需求另一个是FP8混合精度训练的深度优化昇腾950对FP8的支持更完善能进一步压低通信量和显存占用还有大模型推理的集群化部署训练集群升级成推理集群后怎么用多维并行思维优化推理的显存和响应速度也是值得单独展开的话题。最后分享一个细节新一代昇腾950目前在测试阶段如果实验室条件允许拿到样机后第一件事不是跑benchmark而是先测HCCS带宽和跨节点RoCE拓扑连通性。平台组网的稳定性和性能是后续所有优化能生效的地基这个环节花的时间绝对不会白费。