华为昇腾960超节点：破解十万亿参数大模型的万卡协同难题

1. 十万亿参数的算力账，先算到"绝望"

1.1 训练百万亿参数模型到底需要多少计算量

大模型这条赛道，这两年已经从"能不能训"卷到"能训多大"，再卷到"怎么高效训完"。十万亿参数，纸面上看是一个刺激的数字，但在工程上，它就是一座实打实的算力大山。很多人第一次听到"十万亿参数"时，第一反应是"存储得多少TB"，但真正让工程团队头疼的远不止存储——训练用的卡从几百张拉到几千张、上万张，集群互联、通信调度、故障恢复，每一项都会被放大到难以容忍的程度。

先算笔最基础的账。Transformer架构的训练计算量有一个业界公认的近似公式：FLOPs ≈ 6 × N × D，其中N是模型参数量，D是训练数据量（token数）。假设我们要训一个100万亿（即10^14）参数的模型，训练数据用常见的10万亿（10^13）token，那么总计算量就是：

6 × 10^14 × 10^13 = 6 × 10^27 FLOPs

这是什么概念？哪怕单张加速卡能做到1 PFLOPs（10^15 FLOPs，已经是当前顶级AI芯片的FP16密集算力水平），全速跑一秒也才10^15 FLOPs。要凑够6×10^27 FLOPs，需要6000张卡跑满整整一年，而且是零空闲、零故障、零通信开销的理想状态。现实世界里，集群利用率能从50%跑到70%就已经算优秀，算下来轻松突破一万张卡，训练周期还要按数月计。

1.2 显存和带宽：比算力更先卡脖子的瓶颈

比算力更早浮出水面的，其实是显存。100万亿参数模型，光是把参数用BF16格式装进显存，就需要200TB。这还只是参数，训练过程中还要保存梯度（又是200TB），还有Adam优化器的动量项和方差项（BF16下各200TB，FP32下更加倍），粗略一算，基础状态就要600TB以上。再加上激活值、中间结果、通信缓冲区，整个训练态轻松突破PB级。

单卡显存撑死一两百GB，所以必须把模型切到成千上万张卡上。模型并行、流水并行、数据并行、序列并行，这些并行策略本质上都是在"拆"，把一张卡装不下的东西拆到多张卡上。但拆完以后，卡和卡之间就要频繁交换数据，梯度同步要通信，张量并行的All-to-All要通信，序列并行的跨卡注意力也要通信。模型越大、切的维度越多，通信量就越恐怖。

所以十万亿参数真正让人绝望的地方不是"需要多少算力"，而是"怎么让这么多卡协同不出错、不卡死、不浪费"。算力可以堆卡，但协同不行。协同上的问题，每多一张卡就多一分爆炸的风险。这篇文章我就用华为昇腾960超节点这个案例，把"万卡协同"背后的架构逻辑、算力账和实操经验拆开聊一聊。核心就三个关键词：华为昇腾960、超节点、万卡协同。适合正在规划大模型训练集群的Infra工程师、算法工程师，也适合所有想搞清楚"为什么堆卡越多越慢"的朋友。

2. 万卡协同为什么是"噩梦"

2.1 传统集群组网在万卡规模下会怎样崩盘

传统AI训练集群普遍采用多层CLOS架构：GPU/加速卡挂载在计算节点上，节点通过网卡上行到接入交换机，接入层再汇聚到脊层交换机，流量层层转发。这种架构在几百卡规模时问题不大，但拉到万卡级别，组网结构就会急剧复杂化。

先看端口数量。万卡集群至少需要几千台服务器，每台服务器两到八张卡不等。接入交换机要提供足够的高密度端口去连服务器，脊层交换机又要提供足够的上行带宽把所有接入层串起来。实际组网时，很多集群面临的问题是上联端口不够、互联带宽不足、时延抖动不可控。

不过端口还只是表面问题，真正致命的是通信模式的变化。大模型训练里最常用的集合通信操作是AllReduce（梯度同步）和All-to-All（张量并行里的数据交换）。AllReduce是"多对多、全体要和全体说话"，All-to-All更是每个节点都要给其他所有节点发数据。这种通信模式在分布式系统里叫全对全通信，它的特点是流量呈现东西向爆炸式增长。

在500卡规模下，千兆级别的节点间互联还能勉强支撑。但到了万卡规模，一次AllReduce就需要把全集群的梯度汇总再分发回去，总流量高达几十GB甚至上百GB。传统三层组网里，这些流量要经过接入层、汇聚层、脊层多级转发，每一跳都会引入延迟和丢包风险。网络拥塞一旦发生，整个集合通信的完成时间就会从毫秒级恶化到秒级，训练效率直接崩塌。

我不止一次见过这样的场景：明明GPU的算力利用率在监控面板上显示只有20%，但网络端口已经打满了，交换机丢包率居高不下。算法团队以为是模型代码的问题，网络团队指着监控说是流量模型的问题，最后扯皮半天才发现谁都改变不了物理拓扑的瓶颈。传统组网在万卡规模下不是"优化就能解决"的问题，而是架构层面的天花板。

2.2 可靠性、调度与训练效率的连锁反应

万卡集群的第二个噩梦是故障率。单卡的年故障率哪怕只有千分之一，万卡集群里每天都会有几张卡出问题。再加上网卡、光模块、交换机、电源、散热，整个集群的平均无故障时间（MTBF）可能在几小时到十几小时之间。

大模型训练又是一个长时程、强同步的任务。任何一个节点掉线、任何一张卡报错、任何一条链路抖动，都可能导致集合通信卡住、训练进程崩溃。恢复训练需要加载检查点（checkpoint），而万亿参数模型的检查点动辄几百GB甚至上TB，保存和加载一次都是巨大的时间开销。训练中断一次，可能浪费几小时甚至一整天。

调度层面同样麻烦。万卡集群里，训练任务往往需要独占一批拓扑上连续的节点来保证通信性能。但集群里同时跑着多个任务，资源碎片化严重。有时候好不容易凑齐了足够的卡，却发现它们在网络拓扑上分散在不同交换机下面，通信要绕远路，性能直接掉一截。所以业界的资源调度越来越强调拓扑感知（topology-aware），分配计算资源时要像选机房位置一样考虑网络距离。

还有一个更隐蔽的问题：负载不均衡。同样的并行策略，在通信拓扑不均匀的集群上，某些节点承担了更多的转发流量，成了"热点"，整个集群的训练速度被最慢的那一个节点拖住。万卡规模下，这种"木桶效应"被无限放大。最终结果就是集群规模上去了，MFU（Model FLOPs Utilization，模型算力利用率）却从60%跌到30%以下。算力是买了，但实际用上的只是其中一小部分。

这其实也是最近大家总在聊"算力约束下提升大语言模型能力的资源配置建模"的原因——现在的问题已经不是"算力够不够"，而是"怎么在给定算力约束下做最优的资源配置"。集群不是卡一插就能跑的，卡的排布方式、网络拓扑结构、并行策略选择、容错机制，每个环节都直接影响最终能榨出多少有效算力。

3. 华为昇腾960超节点：把互联做到"像一张卡"

3.1 超节点到底是什么

要破解万卡协同的噩梦，核心思路不是继续优化传统组网，而是重构物理层级。华为昇腾960超节点给出的答案，是把尽可能多的卡用超高带宽、超低延迟的互联方式"焊死"在一起，对外呈现为一个巨大的、统一的"超级加速设备"。

打个比方。传统集群组网就像把几千人放在不同的楼里，平时沟通要坐公交车、过红绿灯，数据包在交换机之间排队等待。而超节点相当于把人集中到一栋超级大楼里，每层之间有高速电梯，同一层内直接走廊串门，通讯距离和延迟被压到极致。这栋"大楼"对外就是一个整体，调度系统不需要关心楼里面每一间房是怎么连的。

行业内对超节点的定义，一般聚焦在三个"统一"上：

• 统一计算域：节点内的所有AI芯片作为一个整体参与计算，任务分解和调度在芯片间直接完成，不走外部网络协议栈。
• 统一内存域：多张卡的显存通过硬件互联实现统一编址，任意一张卡可以访问整个超节点内的显存空间，打破"显存墙"。
• 统一通信域：卡间的集合通信不再依赖外部交换网络，而是走芯片间的高速直连通道，通信延迟从微秒级进一步压到亚微秒级。

昇腾960超节点正是沿着这个思路落地的。相比上一代昇腾910系列，昇腾960在单卡算力提升的基础上，把重点放在了节点内互联带宽和显存池化能力上。用通俗的话说，昇腾960超节点就是"把一堆卡变成一张大卡"，让训练框架在逻辑上就像在操作一张拥有海量显存和超高带宽的巨型加速卡。当然，具体芯片参数和互联规格要以官方最终发布为准，但这一代超节点架构的设计方向，业内已经形成共识。

传统组网与超节点的核心差异，可以用一张表格说清楚：

3.2 昇腾960到底改了哪几件事

单看"超节点"这个概念，很多厂商都在讲，但昇腾960超节点真正值得关注的是它把这几件事做扎实了：

第一是节点内互联架构。超节点里的卡不再是"插在服务器上、通过网络交换机互相访问"的关系，而是通过专门的芯片间互联总线组成一个紧密耦合的计算矩阵。昇腾960超节点在互联带宽上做了大幅提升，单卡和相邻卡之间的通信带宽达到数百GB/s级别，是传统PCIe链路的好几倍。这意味着，Tensor并行（需要频繁交换中间结果）可以放心地在超节点内部进行，通信开销不再是瓶颈。

第二是显存池化与统一编址。这是超节点最有价值的部分。传统多卡训练里，显存是每个设备私有的，数据从一个卡搬到另一个卡要经过"显存→内存→网卡→网络→对端网卡→对端显存"的漫长路径。而昇腾960超节点通过硬件层面的统一内存编址，让所有卡的显存组合成一个巨大的资源池，任意卡可以直接读写池内任意地址的数据。这一方面缓解了大模型对单卡显存的依赖，另一方面也让ZeRO（一种显存优化策略）、激活值重计算等显存优化手段变得更简单高效。

第三是集合通信库与训练框架的协同优化。超节点硬件再强，软件栈跟不上也是白搭。昇腾配套的集合通信库（对标业界常用的HCCL）和MindSpore等训练框架，针对超节点的拓扑结构做了深度融合：并行策略自动感知节点边界，通信原语自动选择最优路径，梯度同步可以在超节点内部完成绝大部分，只有跨超节点的部分才走外部网络。这种"软硬协同"的设计，才是昇腾960超节点能让万卡协同从"噩梦"变"标配"的关键。

从整个集群的视角看，超节点带来的最大变化是扩展粒度变了。以前扩展集群的最小单位是一张卡，组网复杂度随卡数线性甚至超线性增长；现在最小单位是超节点，几个超节点之间用高速网络互联就能组成万卡规模集群。外部网络拓扑从"几千个节点互联"简化为"几十个超节点互联"，交换机端口、路由条目、故障域都大幅缩减，集群设计的复杂度下降了一个数量级。

4. 从理论到落地：超节点集群规划与实操要点

4.1 先算清楚需要的算力与精度

做超节点方案规划，第一步永远是算账，而且要把精度和算力的关系算明白。AI芯片在不同精度下的算力差异巨大，市面上常见的AI加速卡，FP16算力通常是FP32的2倍以上，INT8算力又通常是FP16的2倍左右。所以"这块卡有多少算力"这个问题，答案是分精度的，不能混为一谈。

对训练而言，业界主流做法是混合精度训练：用BF16/FP16做正向和反向计算，用FP32做优化器和权重更新。BF16相比FP16有个关键优势——它和FP32有同样的指数位范围，做梯度累积时不容易溢出，对大规模训练更稳。所以昇腾960超节点方案的训练主力精度一定是BF16。FP64一般是科学计算用的，大模型训练基本用不上；FP32只在优化器状态和部分累积计算中保留；INT8则主要在推理加速场景使用，训练阶段极少直接上INT8。

算账的时候，我习惯用"有效算力"这个口径，不要直接拿标称算力乘卡数。所谓有效算力，等于标称算力乘以实际利用率MFU。根据我的经验，一个优化良好的超节点集群，MFU能稳定在50%~60%就算不错，能达到70%以上就是顶尖水平了。带着这个折扣去规划集群规模，才不会被漂亮的纸面参数骗到。

举个例子：假设目标是在30天内训完一个十万亿参数模型，数据量10万亿token，总计算量约6×10^27 FLOPs。如果单张卡的BF16有效算力按300 TFLOPS计算（这里只是示意），那么需要的卡时数为：

6 × 10^27 ÷ (300 × 10^12) ≈ 2 × 10^13 秒卡

也就是大约23万卡日（一张卡跑24小时）。30天训练窗口意味着需要大约7700张卡满负荷跑。考虑到故障重训、检查点保存、集群利用率损耗，实际规划建议做到10000~12000张卡的规模，也就是用几十个昇腾960超节点堆起来。

4.2 并行策略如何配合超节点

有了超节点，并行策略的划分逻辑会更清晰。业界公认的分工方式是：超节点内部做重通信的并行，超节点之间做轻通信的并行。

张量并行（Tensor Parallelism）会把一个Transformer层切到多张卡上，每张卡只计算矩阵乘法的一部分，前向和反向都要做All-to-All通信。这种并行对通信延迟极其敏感，最适合放在超节点内部。昇腾960超节点的高带宽低延迟互联，就是为张量并行量身定制的。序列并行（Sequence Parallelism）同理，它把序列长度维度切开，跨卡做Attention时通信量也很大，同样应该放在超节点内。

流水线并行（Pipeline Parallelism）则是把不同层分配给不同设备，通信只发生在相邻层之间，通信量相对可控，而且可以通过微批处理把通信和计算重叠起来。这种并行可以放在超节点之间。数据并行（Data Parallelism）每个节点持有完整模型副本，只同步梯度，也是跨超节点通信的主力。跨超节点的梯度同步虽然还有流量，但频率和总量比张量并行的All-to-All低得多，对网络的要求自然降下来了。

显存池化在并行策略上带来一个额外好处：激活值的存放不再局限于某一张卡。传统训练里，每一层计算产生的激活值必须存在执行该层的卡上，显存不够就只能重计算或者切更小的batch。超节点统一内存域出现后，激活值可以分布存储在超节点内多张卡的显存里，让显存的"水位"更平滑。这直接放宽了batch size的限制，对提升硬件利用率和训练稳定性都有帮助。

4.3 部署阶段容易忽略的几件事

超节点集群的部署，硬件安装只是第一步，真正磨人的是一些"看起来不起眼"的环节。

第一，网络拓扑映射必须提前规划。超节点之间采用高速网络互联，但到底是环形、二维Mesh还是Fat-Tree，直接决定了跨超节点通信的最坏时延。我的建议是：在集群规划阶段就把并行策略和网络拓扑画在一张图里，给调度系统打上拓扑标签。分配计算资源时，尽量把同一个训练任务分配到拓扑上相邻的超节点组，不要跨越过多的网络层级。

第二，检查点策略要重设计。传统集群的checkpoint以单卡粒度保存，恢复时逐卡加载。超节点方案下，检查点最好以超节点为单位做分布式保存，同时利用超节点内部的高速互联实现异步保存，把保存操作对训练的阻塞降到最低。说白了，大模型训练的checkpoint要的是"轻量、快速、可断点续训"，不能每次存完检查点都要停半天。

第三，监控和告警体系要做到超节点粒度。传统监控只看到单卡利用率、温度、功耗，超节点集群还需要看节点内互联带宽使用率、显存池化水位、集合通信延迟分布。尤其是显存池化水位，接近上限时要提前预警，因为池化显存耗尽往往意味着训练任务的失败，而不是简单的OOM报错。

5. 常见问题与排查技巧实录

5.1 集合通信相关的那些坑

超节点架构并不能消灭所有网络问题，它只是把问题从"大规模网络拥塞"转移到"边界处的流量调度"上。超节点内部通信快如闪电，但跨超节点的通信仍然要走外部网络，如果外部链路带宽不足，依然会出现集体通信卡顿。

一个典型的故障现场：训练日志里出现集合通信超时，任务卡住不动，看超节点内部互联一切正常，但网络端口的出入流量已经打满，丢包率肉眼可见地往上涨。排查思路一般分三步：先查外部网络的链路质量，是否存在光模块异常或交换机端口协商降速；再查通信任务在超节点间的流量分布，是不是某些超节点承担了过多转发任务；最后查调度系统有没有把同一任务的不同超节点分配到了拓扑距离过远的位置。

实操里还有一个容易被忽视的点：网卡的流控和优先级队列配置。集合通信的流量通常应该走最高优先级队列，而检查点保存、日志同步这些后台流量要降级处理。如果所有流量都挤在同一个队列里，一次大检查点保存就可能把集合通信的延迟拉高几倍，训练速度肉眼可见地掉一截。

5.2 显存池化的碎片问题

超节点的显存池化带来便利的同时，也引入了碎片化问题。显存池里的空间虽然统一编址，但分配和释放仍然是动态的，训练过程中激活值、梯度、临时缓冲区频繁申请释放，容易形成大量碎片。表现为"池化显存总量看起来还有很多，但申请一块连续大显存时失败"。

这类问题很难像普通OOM那样直接定位到具体代码，更有效的做法是从源头控制。我一般建议团队在训练框架里开启显存预分配和显存复用池，把频繁使用的小块显存缓存起来，减少碎片产生。同时要监控显存池的碎片率指标，发现碎片率持续上升，就主动触发一次显存整理或调整并行策略中的batch size。

还有一个经验是：激活值重计算不要一刀切全开。超节点显存池化后，很多人倾向于把重计算比例降低，多存激活值以换取速度。但实际训练中，如果显存池碎片率较高，反而容易因为分配不到连续空间而触发fallback到重计算路径，导致性能波动。建议在充分观察显存水位和碎片率后，再逐步调低重计算比例。

5.3 训练中断与性能不稳定

超节点集群的训练中断，绝大多数和硬件故障无关，而是软件配置问题。最常见的是"看起来训练在跑，但速度越来越慢"。这种情况通常是某个超节点的通信路径出现热点，或者某张卡的散热/功耗触发降频，导致该节点速度变慢，整个训练被拖到最慢节点的速度上。

排查性能不稳定，强烈建议开启集合通信和计算流水线的详细打点（profiling）。不要只看每步的平均耗时，要看每个通信算子的耗时分布。如果某些集合通信算子的耗时方差很大，说明通信路径不稳定，优先检查网络链路质量和路由策略。如果计算和通信没有重叠（比如GPU在等数据，或者网卡在等计算），要调整并行策略中的流水线划分，让计算和通信尽量重叠起来，把"等待"时间压缩到最低。

最后说一个我踩过多次坑的经验：训练任务的步长（step time）监控曲线一定要保留至少30天的历史。很多问题不是突变，而是渐变。比如某条链路的光模块老化，丢包率从0.001%慢慢升到0.01%，训练速度每天掉一点，不拉长周期看根本发现不了。有了历史曲线，才能在最早期抓住这种"温水煮青蛙"式的性能劣化。

6. 一点个人的实在体会

我做了几年大规模分布式训练，最大的感受是：超节点这个东西，不是一个"锦上添花"的硬件概念，而是从架构层面解决万卡协同问题的正确方向。昇腾960超节点把通信域、内存域、计算域统一起来，让"万卡协同"从需要手工调优的噩梦，变成了默认就work的基础设施——训练框架天然知道怎么用超节点，调度系统天然知道怎么编排超节点。

如果你现在正在规划十万亿参数级别的训练集群，我的建议是先做小规模验证，再铺开建设。先用两三个超节点跑通一个千亿参数模型的端到端训练，把网络拓扑、并行策略、检查点恢复、监控告警这些环节都验证到位，确认这轮超节点集群方案适配你的框架和模型；然后再扩展到一个超节点组、几十个超节点组。千万不要一上来就追求"万卡亮机"的仪式感，集群没有真正跑稳之前，规模越大，踩坑的代价越高。按这个节奏走，才能真正把纸面上的十万亿参数算力账，变成落到实处的训练产能。