★ FEATURED ARTICLE 1. 十万亿参数的算力账先算到绝望1.1 训练百万亿参数模型到底需要多少计算量大模型这条赛道这两年已经从能不能训卷到能训多大再卷到怎么高效训完。十万亿参数纸面上看是一个刺激的数字但在工程上它就是一座实打实的算力大山。很多人第一次听到十万亿参数时第一反应是存储得多少TB但真正让工程团队头疼的远不止存储——训练用的卡从几百张拉到几千张、上万张集群互联、通信调度、故障恢复每一项都会被放大到难以容忍的程度。先算笔最基础的账。Transformer架构的训练计算量有一个业界公认的近似公式FLOPs ≈ 6 × N × D其中N是模型参数量D是训练数据量token数。假设我们要训一个100万亿即10^14参数的模型训练数据用常见的10万亿10^13token那么总计算量就是6 × 10^14 × 10^13 6 × 10^27 FLOPs这是什么概念哪怕单张加速卡能做到1 PFLOPs10^15 FLOPs已经是当前顶级AI芯片的FP16密集算力水平全速跑一秒也才10^15 FLOPs。要凑够6×10^27 FLOPs需要6000张卡跑满整整一年而且是零空闲、零故障、零通信开销的理想状态。现实世界里集群利用率能从50%跑到70%就已经算优秀算下来轻松突破一万张卡训练周期还要按数月计。1.2 显存和带宽比算力更先卡脖子的瓶颈比算力更早浮出水面的其实是显存。100万亿参数模型光是把参数用BF16格式装进显存就需要200TB。这还只是参数训练过程中还要保存梯度又是200TB还有Adam优化器的动量项和方差项BF16下各200TBFP32下更加倍粗略一算基础状态就要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分配计算资源时要像选机房位置一样考虑网络距离。还有一个更隐蔽的问题负载不均衡。同样的并行策略在通信拓扑不均匀的集群上某些节点承担了更多的转发流量成了热点整个集群的训练速度被最慢的那一个节点拖住。万卡规模下这种木桶效应被无限放大。最终结果就是集群规模上去了MFUModel FLOPs Utilization模型算力利用率却从60%跌到30%以下。算力是买了但实际用上的只是其中一小部分。这其实也是最近大家总在聊算力约束下提升大语言模型能力的资源配置建模的原因——现在的问题已经不是算力够不够而是怎么在给定算力约束下做最优的资源配置。集群不是卡一插就能跑的卡的排布方式、网络拓扑结构、并行策略选择、容错机制每个环节都直接影响最终能榨出多少有效算力。3. 华为昇腾960超节点把互联做到像一张卡3.1 超节点到底是什么要破解万卡协同的噩梦核心思路不是继续优化传统组网而是重构物理层级。华为昇腾960超节点给出的答案是把尽可能多的卡用超高带宽、超低延迟的互联方式焊死在一起对外呈现为一个巨大的、统一的超级加速设备。打个比方。传统集群组网就像把几千人放在不同的楼里平时沟通要坐公交车、过红绿灯数据包在交换机之间排队等待。而超节点相当于把人集中到一栋超级大楼里每层之间有高速电梯同一层内直接走廊串门通讯距离和延迟被压到极致。这栋大楼对外就是一个整体调度系统不需要关心楼里面每一间房是怎么连的。行业内对超节点的定义一般聚焦在三个统一上统一计算域节点内的所有AI芯片作为一个整体参与计算任务分解和调度在芯片间直接完成不走外部网络协议栈。统一内存域多张卡的显存通过硬件互联实现统一编址任意一张卡可以访问整个超节点内的显存空间打破显存墙。统一通信域卡间的集合通信不再依赖外部交换网络而是走芯片间的高速直连通道通信延迟从微秒级进一步压到亚微秒级。昇腾960超节点正是沿着这个思路落地的。相比上一代昇腾910系列昇腾960在单卡算力提升的基础上把重点放在了节点内互联带宽和显存池化能力上。用通俗的话说昇腾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。精度类型典型场景相对FP32的算力倍数显存占用特点FP64科学计算、数值模拟1/2 ~ 1/48字节/数精度极高算力低不适合大模型FP32权重更新、优化器状态基准4字节/数稳定但显存开销大FP16训练配合混合精度2~4倍2字节/数加速明显需配合梯度缩放BF16大模型训练主力2~4倍2字节/数动态范围与FP32一致推荐INT8推理加速、量化4~8倍1字节/数算力高但训练慎用算账的时候我习惯用有效算力这个口径不要直接拿标称算力乘卡数。所谓有效算力等于标称算力乘以实际利用率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的基础设施——训练框架天然知道怎么用超节点调度系统天然知道怎么编排超节点。如果你现在正在规划十万亿参数级别的训练集群我的建议是先做小规模验证再铺开建设。先用两三个超节点跑通一个千亿参数模型的端到端训练把网络拓扑、并行策略、检查点恢复、监控告警这些环节都验证到位确认这轮超节点集群方案适配你的框架和模型然后再扩展到一个超节点组、几十个超节点组。千万不要一上来就追求万卡亮机的仪式感集群没有真正跑稳之前规模越大踩坑的代价越高。按这个节奏走才能真正把纸面上的十万亿参数算力账变成落到实处的训练产能。
阅读完成 · 觉得有帮助？
