昇腾超节点：破解十万亿大模型算力存储通信三堵墙

做AI Infra这几年我最大的一个感受是真正难倒人的问题从来不是单卡不够强而是卡一多整个系统的效率就开始崩。十万亿参数大模型这个概念出现之后这个问题直接被放到了台面上——它需要的算力规模、显存总量、通信带宽已经超出了“把更多服务器拼起来”这种想法的承受范围。昇腾超节点的出现本质上是把思路从“攒集群”改成了“造机器”不再靠堆卡、堆交换机去凑规模而是重新设计一个以算力、存储、通信一体化为目标的计算域用于正面解决十万亿大模型训推的工程难题。这篇文章我结合自己对AI基础设施的理解和实际调优经验把昇腾超节点为什么在“算力存储通信”三堵墙面前能给出“最优解”这件事拆开来讲清楚。1. 先算一笔账十万亿模型为什么能把现有集群全部“卡死”很多人听到“十万亿参数”这个数字没什么感觉无非是比现在的大模型多一个数量级。但真正做过分布式训练的人都知道参数规模往上涨问题不是线性的而是指数级的。这里我先把训练和推理两边的账算清楚你就明白为什么传统的“堆机器”路线在这里会直接失效。1.1 先看训练账算力数量级与显存总需求先算算力。一次完整的大模型训练总计算量大致可以估算为 6 × 参数量 × 训练token数。一个十万亿10T参数模型假设训练数据量在10T token这个量级总计算量就是6 × 10^14 × 10^13 6 × 10^27 FLOPs这个数字是什么概念假设一个集群的有效算力是100 EFLOPS也就是每秒10^20次浮点运算那需要6×10^7秒大概是700天。即便集群持续有效算力做到700 EFLOPS也需要整整100天。注意我这里说的是“有效算力”不是硬件峰值算力实际集群能跑到峰值的百分之三四十就已经非常了不起了。再算显存。十万亿模型的权重在BF16精度下是20TB。训练过程中不光要放权重还要放梯度、优化器状态Adam优化器通常每个参数要额外占12B左右、激活值等。按训练动态显存需求通常是模型权重字节数的8到16倍来估算一个训练副本就需要80到160TB的显存。假设单颗加速卡显存只有64GB那么光装下一个训练副本就需要1250到2500张卡。如果考虑数据并行冗余、流水并行气泡、激活重计算等实际因素万卡级起步是跑不掉的。1.2 再看推理账权重、KV Cache与并发挤爆显存推理端的账同样不好算。十万亿模型推理时权重本身是200TBBF16单机根本装不下。更要命的是KV Cache——随着序列长度增长KV Cache占用的显存是线性上升的。一个长上下文请求动辄几十GB到几百GB如果有几百个并发请求KV总容量直接到几十TB。这就带来一个残酷的现实传统推理解决方案是靠“把模型切到几十张卡上每张卡放一部分”然后请求进来时跨卡搬运数据。模型越大切分越碎跨卡通信越频繁延迟就越难看。十万亿模型如果用这种路子做推理延迟和吞吐都会崩到完全不可用。我见过不少团队在百亿模型上推理调优时的痛苦权重放不下KV Cache放不下并发一起来显存直接爆掉。这些在十万亿模型面前全部加倍而且不是“多买点卡”能解决的——因为显存总量虽然可以靠加卡解决但加卡带来的通信开销会让系统更快陷入瓶颈。2. 拆开“三堵墙”算力、存储、通信各自卡死在哪个环节标题里说的“三堵墙”我理解不是营销概念而是十万亿模型真实遇到的三个物理瓶颈。下面把每一堵墙的“材质”和“位置”拆开看才能明白超节点到底在拆哪堵墙。2.1 算力墙瓶颈不在单卡而在“算力利用率”单卡算力的增长已经明显放缓了。功耗墙在那里物理尺寸在那里先进封装和制程的红利越来越薄。过去靠单卡性能翻倍来带动整个集群性能翻倍的日子已经过去了。现在的问题是即便你有几万张卡集群的有效算力利用率也上不去。分布式训练里有个核心指标叫MFUModel FLOPs Utilization模型算力利用率它衡量的是硬件峰值算力中真正用于计算的比重。我在调优千卡集群的时候MFU做到35%-45%已经算不错规模扩大到五千卡以上很多时候会掉到百分之二十几。剩下的时间去哪了等通信、等同步、等数据加载、处理并行切分产生的气泡。十万亿模型意味着什么意味着必须用更大的并行度而更大的并行度又会进一步吞噬MFU。你越想用算力算力的损耗就越大。这就是算力墙的真面目不是没有算力而是算力被系统开销吃掉太多。2.2 存储墙显存放不下搬运成本比计算还高存储墙的本质很简单单卡显存容量和超大模型的内存需求之间存在数量级差距。拿十万亿模型来说光训一个副本就需要上百TB显存而单卡只有几十GB到一百多GB。唯一的办法就是把模型分到几百张甚至上千张卡上。问题是模型切分之后每一步训练都需要跨卡搬运数据。张量并行要搬中间激活流水并行要搬层间输出数据并行要搬梯度。搬运本身就是一种存储墙的体现——数据在显存和显存之间移动耗费的时间和带宽往往比计算本身还贵。另一个隐藏问题是检查点Checkpoint。十万亿模型的权重和优化器状态加起来一份Checkpoint就是几十TB。如果每次保存都要从各卡汇集到存储系统再在故障恢复时从存储系统拉回来这个时间足够让运维团队崩溃。存储墙不只是“放不下”更是“搬不动”。2.3 通信墙集群越大通信反而越“吃”算力通信墙是我在实际项目中感受最深的一堵墙。它的本质是集群规模越大通信开销占总时间的比例越高而通信一旦变慢再多的算力也只能闲置。集合通信Collective Communication是大模型训练的命脉。以AllReduce为例它的通信量与模型参数量成正比参数量越大的模型每次梯度同步的数据量越大。十万亿模型做一次全量梯度同步数据量是几百GB的级别而这一步在每一个训练step都要发生一次。传统集群的通信拓扑是多级交换网络从服务器机柜到汇聚交换机再到大二三层交换机每一层都有转发延迟和带宽收敛。规模越大跳数越多拥塞越随机尾延迟越不可控。我调试过几千卡集群的分布式训练通信时间占比超过40%是常有的事。这时候你再往里加卡通信时间比例只会更高加卡带来的算力增量全被通信吃掉了。通信墙还有一个隐蔽的危害它对并行策略的约束。为了让通信少工程师只能选择粗粒度的并行方式但粗粒度并行又会导致显存不够或者计算气泡变大。这是一个死锁存储墙逼着你切细通信墙逼着你切粗最后只能在一个狭窄的窗口里挣扎。下表总结了“三堵墙”的核心表现以及每堵墙对十万亿模型的冲击程度瓶颈传统方案的核心问题十万亿模型下的具体表现超节点的拆墙思路算力墙集群越大MFU越低有效算力被通信和同步吞噬减少通信时间让算力真正用于计算存储墙单卡显存容不下模型/ KV Cache训练需上百TB显存推理需超长KV Cache显存池化多卡显存统一编址通信墙多级网络转发带宽收敛延迟不可控梯度同步几百GB/step通信占比极高全互联高带宽低延迟内存语义通信3. 昇腾超节点的设计逻辑从“攒集群”到“重构计算域”我前面说“造机器”而不是“攒集群”这不仅是措辞问题而是两种完全不同的工程路线。传统做法是单机做不强就加机器用高速网络把机器串起来。昇腾超节点走的是另一条路把计算、存储、通信重新捏合成一个紧耦合的整体对外暴露一个算力资源池。3.1 超节点是什么把“一堆机器”变成“一台超级计算机”超节点不是简单的“机柜里多插几块卡”。它是以昇腾芯片为核心通过自研高速互联技术把多颗芯片组成一个高带宽、低延迟、大显存池的紧耦合计算单元外部呈现为一个完整的资源域。以华为CloudMatrix 384这种形态为例384颗昇腾芯片构成一个超节点对外看起来就像一台拥有巨大显存的超级计算机而不是“384台服务器组成的一个集群”。这个区别很关键。传统集群的调度单元是“服务器”任务要考虑网络拓扑、机柜位置、交换机带宽否则性能不可控。而超节点的调度单元就是“整个节点”任务拿到手里不需要关心内部拓扑——它像一台单机一样分配资源。这其实是在把分布式系统的复杂度从用户侧移到了平台侧。3.2 三大技术支点全互联、内存语义、显存池化超节点能成立靠的是三个核心技术支点缺一个都不行。第一个是全互联拓扑。超节点内部每颗芯片和另一颗芯片之间都有高速直连通道不经过传统的多级交换。这意味着通信路径是确定的不会因为网络拥塞而波动。通信延迟从过去的几十微秒降到纳秒到微秒级别带宽也完全不受外部交换机的收敛限制。第二个是内存语义通信。传统跨节点通信走的是消息传递CPU介入、协议栈封装、网络传输、接收端解包过程重且慢。超节点内部通信更像访问本地内存——发端像写本地地址一样写入远端芯片显存收端直接读不需要消息协议。这个改变的意义巨大通信从“收发消息”变成“读写内存”延迟直接下降一个数量级。第三个是显存池化。多颗芯片的物理显存统一编址组成一个逻辑上的超大显存池。上层应用不需要关心数据在哪颗芯片上框架层负责数据放置和迁移。这也直接解决了存储墙——训练和推理拿到的“显存上限”不再是单卡显存而是整个超节点池化后的巨量显存。3.3 与传统集群的本质差异调度单位、故障域、并行策略全变了传统集群和超节点的差异不只是硬件形态而是上层整个软件栈的假设都变了。传统集群里写大模型训练代码需要考虑模型并行度设多少、流水并行多少段、数据并行多少副本、哪个张量放在哪张卡上、通信算子走哪条链路。每个选择都直接影响性能。这导致大模型的分布式训练严重依赖专家经验试错成本极高。超节点场景下很多并行策略可以交给框架层自动处理。因为超节点内部通信足够快、显存足够大你甚至可以把一个超节点当成一个巨型单卡设备来编程由框架决定如何把计算切分到内部芯片上。并行策略不再是开发者的核心负担。同时故障域也变了。传统集群里一个节点坏了影响的是几百张卡中的一个子集调度器可以把任务打到别的节点上重跑。超节点是整体调度单位一方面管理简单另一方面坏一块卡等于整个超大“单卡”不可用这对底层硬件的可靠性和上层的容错设计都提出了新要求。这个话题我会在第五部分展开讲。4. 训推双侧的落地价值收敛时间、推理延迟与成本账聊完设计逻辑必须回到实际问题超节点给大模型训推带来哪些可量化的收益我不太喜欢看厂商的白皮书参数更喜欢算落地账。下面从训练侧、推理侧、成本侧三个维度看。4.1 训练侧MFU提升是实打实的并行策略大幅简化训练侧最大的收益是有效算力利用率MFU的提升。超节点内部通信低延迟、高带宽同步梯度的开销被压缩到很小通信时间占迭代总时间的比例大幅下降。同样规模的模型传统集群MFU可能只有25%-35%超节点架构下做到45%甚至更高是完全可以预期的。别小看这十几个百分点的提升它直接换算成训练天数缩短、电费减少、项目周期缩短。第二个收益是并行策略的简化。我前面说过传统大模型训练非常依赖精细的人工并行切分。比如TP8、PP16、DP64这种配置需要反复试错才能找到最优组合。在超节点里因为显存池化很多原来必须做张量并行才能放下的模型现在可以更粗粒度地部署跨节点的通信约束大幅缓解。对小一点的团队来说这意味着不再需要一个专职的“分布式训练调优专家”才能训大模型。第三个收益容易被忽视Checkpoint和模型加载。十万亿模型的Checkpoint几十TB传统集群保存和加载要走网络到外部存储时间以小时计。超节点内部数据搬运走高速互联域内Checkpoint可以做到分钟级故障恢复的速度快得多。4.2 推理侧长序列、高并发、低延迟不再互相拆台推理侧的收益更直观。大模型推理最怕两件事KV Cache放不下并发一高延迟就飞。传统方案里这两个问题互相冲突——为了降低延迟你得少并发为了提升吞吐你得加批处理但批次加大的前提又是KV Cache有足够显存。超节点的大显存池一次性解决两件事长上下文请求的KV Cache可以完整留在显存里不用反复写回外部存储大批并发也不再是问题因为池化显存是海量的。十亿、百亿模型推理或许感觉不到超节点的优势但万亿级模型、尤其是十万亿模型进入推理部署场景后没有超大显存池的硬件几乎是无解的。还有一个容易被忽略的点推理阶段的Decoder是访存密集型任务性能瓶颈往往不在算力而在显存带宽和数据移动距离。超节点里数据在近邻芯片的显存之间流动物理距离短、带宽大这对推理延迟的改善是结构性的不是优化算子能追回来的。4.3 算总账成本、能耗与TCO用成本角度算一笔简化账假设训练一个十万亿模型传统万卡集群需要100天超节点集群因为MFU提升同等规模下可能只需要70-80天。省下来的20-30天意味着数千万度的电费、机房租金的减少以及产品上市周期的提前。后者往往是商业项目里最值钱的部分。另外超节点因为内部互联紧凑减少了大量的交换机、光模块和线缆。传统万卡集群中网络设备的成本占比可以到20%-30%而且功耗不低。超节点把这些环节省掉一部分整体TCO总拥有成本反而有优势。当然这不是说超节点就是“全能省钱王”它对机房供电、散热、容错的要求也更为苛刻。后面一节我会专门讲这些工程上的冷思考。5. 部署超节点前的实操提醒五件容易被忽略的事超节点听起来很美好但作为一线搞过AI基础设施的人我必须提醒上超节点不是“买来插上就能跑”。下面这五个问题是我根据大型集群部署和运维的经验总结出来的任何团队在决策前都应该认真过一遍。5.1 故障域变大容错设计必须前置传统集群里单卡故障影响的是一个局部任务调度器可以把它重新调度到其他节点。超节点把大量芯片绑成一个整体故障影响范围也随之变大——块卡出问题整个超节点任务可能都要回滚。这意味着Checkpoint策略要提前设计频率可能要大幅提高调度器要支持“超节点整体重调度”的语义模型代码要做好断点续训的兼容。这些都是软件层面的工作量不能指望硬件白送。5.2 机房配套供电和散热不是小事超节点的功率密度远高于传统机柜。一个超节点机柜的电力和散热需求接近甚至超过传统标准机柜的几倍。液冷基本是标配三相供电、高功率母排、精密温控都要提前规划。如果机房基础设施没跟上超节点就算到了现场也发挥不出性能。这块我特别提醒做预算的时候不要只算硬件采购成本还要算机房改造费用。一些团队上了高密度设备后发现“机房带不动”被迫降频运行性能大打折扣这属于典型的前期规划不足。5.3 软件栈适配不是买来就能直接用昇腾平台有自己的一套软件栈包括底层驱动、算子库、通信库HCCL、框架适配层如PyTorch的昇腾适配、MindSpore等。存量代码要迁移过来需要评估算子的覆盖情况、数据加载的兼容性、并行策略的重构方式。我的建议是不要一上来就跑到十万亿模型先在一个超节点上跑通小规模模型验证算子覆盖率、通信库性能和并行框架的效率确认没有隐藏的性能坑之后再放大规模。这个“先小后大”的过程虽然慢但能省掉后面大量返工。5.4 边界意识不是所有模型都需要超节点超节点不是万能的它解决的问题是“超大模型在大规模集群上的训推效率”。如果你的模型只有十亿、百亿参数推理并发也只有几百路那传统集群加标准优化完全够用强行上超节点只会增加部署和运维复杂度。我见过一些团队在模型还没到万亿级别时就去追“新平台”结果是迁移成本远大于收益。选型要基于自身的真实需求模型多大、训练多久、并发多高、延迟要求多少。超节点的价值在十万亿模型这种量级才会全面释放小模型场景里它不一定优于最优化的传统集群方案。5.5 两层组网超节点之间怎么配合要考虑清楚单个超节点再强也装不下无限的模型规模。未来更可能的架构是多个超节点通过高速网络互联组成更大规模的算力集群。这种“超节点内部一个域超节点之间一个网”的两层拓扑对并行策略设计提出了新要求。我的判断是模型并行策略要面向两层拓扑重新规划尽可能在超节点内部完成更多通信TP、PP、长序列切片让超节点之间只跑数据并行或者专家并行这类粗粒度的通信。这也是未来训练框架需要内置支持的一个重要方向。做架构选型时建议优先了解所选软件栈对两层拓扑的感知调度支持程度。最后说一点个人体会。我在实际项目里最深刻的体验就是分布式训练的复杂度最后总是会以某种形式回落到“通信做得快不快”这件事上。昇腾超节点把通信从“跨网络”变成了“域内访问”这个思路不只对十万亿模型有意义对任何规模的AI集群都有参考价值。真正决定落地成敗的往往是软件栈适配和运维体系能否跟上。如果你也正在规划下一代训练集群我的建议是别只盯参数和峰值数字先把自己的模型规模、容错要求、机房条件盘清楚再去判断超节点适不适合你。这个思考顺序比硬件选型本身重要得多。