去年我们组接到一个非常现实的任务评估十万亿参数大模型的训练与推理到底怎么落地。一开始大家的思路特别朴素——卡不够就加卡集群从几百张扩到几千张总行了吧。但真正把显存账、通信账、时间账一起摊到桌面上之后我发现事情远不是堆机器那么简单。十万亿模型训推真正卡的不是某一个环节而是算力、存储、通信三堵墙同时堵在面前而且它们还会互相放大。这篇文章想沿着这条线拆解三堵墙的成因再说说超节点架构为什么被看作十万亿大模型训推的最优解。全文不绑定某个具体厂商产品只谈技术和实践思路适合正在做大模型基础设施选型、或者想搞清楚超节点到底解决了什么的同学参考。1. 十万亿参数不是一个更大号的问题三堵墙在账本里是怎么出现的1.1 先算一笔显存账十万亿参数的物理体积有多大Scaling Law普及之后模型参数从1B、7B、70B一路涨到405B、1T现在全行业开始认真讨论10^13这个量级也就是我们常说的十万亿参数。很多人觉得十万亿不过是几万亿的线性外推多买几台机器、多攒几张卡就行。但先拿最朴素的BF16精度算一笔账你马上会发现事情不太对。十万亿参数的稠密模型光权重一项就需要10^13 × 2字节 20TB的存储空间。训练过程中还要保存梯度跟权重同体积又是20TB加上AdamW优化器通常要保存的一阶动量、二阶动量和主权重副本训练状态往少了说也要60TB到100TB。当前主流AI加速卡的单卡显存大约在192GB这个量级——也就是说哪怕只放权重都要100张卡以上算上训练状态和激活值500张卡以上的显存池只是起步门槛。这个账算完传统的单机8卡加模型并行的套路基本失效。千亿模型可以在一台服务器里靠张量并行硬扛十万亿模型光靠往机柜里堆卡只会把通信墙越顶越高。我之前看到过一个项目组最初方案是直接下单两千张卡后来让运营的同学把显存账摊开算了算才发现光显存容量这块就已经让网络和调度预算吃紧了。没有先算账就直接扩集群是不少团队踩过的第一个坑。1.2 三堵墙互相放大的死循环为什么加机器反而更慢更麻烦的是算力、存储、通信这三堵墙不是各自为政而是互相咬死。存储墙逼你把模型切到更多卡上——显存不够只能多卡分片分片越细卡与卡之间要同步的数据量越大通信墙就越厚。通信墙变厚之后计算单元大量时间在等数据算力墙自然收紧。这就是为什么很多千卡集群跑大模型时实测算力利用率不到50%——不是芯片算力不够是通信在拖后腿。这个死循环决定了十万亿大模型训推不能靠单纯堆机器解。你加一个节点显存是变多了但跨节点通信的开销指数级上升尤其张量并行这种每个Transformer层都要做一两次All-Reduce的高频通信节点越多、距离越远、延迟越离谱最终人多不一定好办事甚至因为协调成本过高变得更慢。所以真正要回答的问题是什么样的架构能把三堵墙一次性推倒而不是一面墙一面墙去凿洞。2. 拆开三堵墙传统集群在大模型训推中的三个真实瓶颈2.1 算力墙的真凶是等待不是计算很多人提算力墙第一反应是单卡性能不够。事实上当前主流AI加速卡的理论算力已经非常高单卡已经不是最主要的天花板。真正的瓶颈在于集群规模变大之后计算单元的空转比例急剧上升。在千卡集群上训练万亿级模型张量并行一旦跨服务器每个Batch要完成大量集合通信网络时延哪怕只有几百微秒乘上每个Batch内的同步次数再乘上每天几百万步的累积等待时间就非常惊人了。我在一个中等规模集群上做过统计当并行策略从单机切换到跨机后一个Transformer层的计算时间从大约200微秒涨到接近500微秒多出来的300微秒基本都在等通信。整个训练周期里这类等待反复叠加直接吃掉三成以上的算力。这也是为什么超节点要把物理距离压缩到板卡之间——集合通信时延从网络级变成芯片互联级计算管线才有可能保持饱满。说白了算力不是被用光的是被等掉的。2.2 存储墙显存容量的增长远远追不上参数规模存储墙的根源非常直白模型参数的增长速度远超单卡显存容量的增长速度。过去几年AI加速卡的显存从40GB、80GB一路涨到192GB已经算是非常快的迭代速度可模型参数从千万级蹿到十万亿级中间差的倍数大得没边。一个像剪刀一样张开的缺口导致模型越来越依赖分布式显存而分布式带来的通信代价又正好喂肥了通信墙。存储墙其实还有第二个维度带宽。显存带宽决定了计算单元能多快把数据吃到嘴里模型越大权重和中间激活的读取量越大。如果单卡算力翻倍而显存带宽没有同比例增长计算单元再强也会被数据供给卡住。我在实际调参时感受特别深小模型看不出来一旦模型到了亿级参数显存带宽不足的症状非常明显——算力曲线始终拉不满每一轮都在等数据搬运。超节点之所以能缓解存储墙不只是因为把显存容量做大了更是因为把带宽和容量的扩展方式从跨网络变成了节点内总线数据供给的延迟和抖动都小了一个量级。2.3 通信墙普通组网撑不起All-to-All的流量大模型训练里常见三类通信张量并行的All-Reduce属于高频小包通信MoE架构中的All-to-All属于中频大流量通信数据并行的梯度同步属于固定周期的全量同步。十万亿模型几乎同时踩中这三类而且每类的流量都大得惊人。传统数据中心组网是为通用互联网流量设计的东西向、南北向都要照顾可大模型训练是极端的集中式场景——几百GB甚至几TB的数据要在几百上千张卡之间同时交换。哪怕使用了高性能RDMA网络跨节点通信的物理距离和交换跳数也摆在那里。网卡再快也改变不了数据要绕路、要排队、要经过多跳转发的事实。所以通信墙最麻烦的地方在于物理限制光在光纤里跑一米就要5纳秒跨机柜、跨机房绕上几圈延迟就上来了。超节点做的事情非常本质——把最需要高带宽低延迟同步的那批卡物理上放进同一个框里从根上砍掉绕路这件事。3. 超节点的破局逻辑把最贵的通信距离压缩到一张卡之间3.1 超节点到底改变了什么从服务器拼网络到一张超级大卡超节点的核心思想是把几十到几百张AI加速卡通过极高带宽、极低时延的私有互联协议整合成一个逻辑上的超级大卡。对上层软件来说它不再是一群需要靠网络拼接的服务器而是一台拥有超大显存、超多计算核心的单一设备。这一步转变直接改变的是整个系统的设计出发点。打个不太严谨但容易理解的比方传统集群像一群独立办公室传文件要靠走廊来来回回跑超节点把所有同事搬进同一个大开间面对面传文件走廊距离被压缩到一臂之内。关键不是多了一个房间而是最贵的通信成本被结构性降下来了。我见过有团队用一套几百卡规模的超节点跑原本需要数千卡集群才敢碰的任务配合合理的并行策略收敛时间和稳定性反而更优。原因是TP、EP这类高频通信被锁在节点内部走的是TB/s级的互联带宽而不是跨机房的常规网络。通信短板一补原来的很多调度妥协和计算浪费也跟着消掉了。3.2 显存池化与统一编址软件视角下的一块大显存存储墙的解法在超节点里具象化为显存池化和统一编址。每张卡原本独立的显存在节点内变成一个整体的、可被软件灵活调度的池子。模型切分时你不再需要斤斤计较哪张卡多放了几GB至少逻辑上编程模型面对的是一块超大容量的显存。对做模型并行的人来说这几乎是梦寐以求的体验——不用再抠抠搜搜地算每张卡的余量。这对推理尤其重要。十万亿模型权重在20TB往上放在超节点的显存池里可以整份常驻推理时不用频繁从外部存储重新加载延迟和抖动都稳很多。服务框架调度KV Cache也像调度普通显存一样顺手相比传统实例固定绑卡的方式宽松得多。不过统一编址不意味着免费跨卡访问的带宽、延迟依然存在软件如果不感知物理拓扑性能照样打折。这也是为什么超节点方案总会绑定深度定制的编译器、集合通信库和调度器——软硬件协同设计才是超节点真正能落地、能兑现性能的秘密。3.3 全互联与集合通信的质变从毫秒级到微秒级通信墙的打破靠的是节点内全互联带来的高带宽和超低延迟。相比普通集群跨节点集合通信动辄几十微秒、上百微秒的耗时超节点内部通常可以做到微秒级的消息延迟带宽高出至少一个数量级而且所有卡都在同一个物理域里不需要经过外部交换芯片中转。这个数字差距直接决定了并行策略可以做多细。我做过一组很简单的对照组测试传统机架上做TP8的All-Reduce每次大概几十微秒同样的操作放到超节点内部耗时降到个位数微秒。单看一次操作好像无所谓但每个Transformer层都要做一两次十万亿模型训练一路积攒下来节省的总时间非常可观。通信墙被推倒之后算力墙的紧张感也会同步缓解——计算单元的空等变少了芯片真实利用率自然上去了。4. 训推一体的工程实践并行策略、调度与扩展4.1 训练场景TP、PP、DP、EP各就各位超节点只是提供了一个更好的物理底座具体能不能跑满还要看并行策略放得对不对。我的核心经验可以浓缩成十六个字高频高带宽留节点内低频低带宽放节点间。千万别把并行策略里的每一种手段都当成可以随意摆放的积木通信成本不同摆放位置必须对症。举个例子假设超节点内有384张卡训练一个万亿级MoE模型一种比较合理的切法是TP8、EP64、PP6、DP128。TP8意味着同一组卡协作完成注意力层的张量切分EP64意味着各专家在64张卡之间做All-to-All这些都是高频通信放在节点内部最合适PP6把网络层切成6段流水线传输放节点间气泡用micro-batch填平DP128只做周期性的梯度全量同步放在节点间也够用。如果把TP或EP错误地扩展到跨超节点通信立刻回到网络级超节点等于白买。这一点在规划集群时就要定死不能等到跑起来了再改。4.2 推理场景预填充、解码与KV Cache的显存博弈推理跟训练的资源需求是完全不同的。十万亿模型推理权重加载是首要矛盾——模型被分散在多台机器上每次请求都要做跨机张量并行节点间通信用一次疼一次。超节点的价值在于让整份权重常驻显存池预填充阶段单个请求可以同时利用几百张卡的并行算力把首Token时延压到很低。对在线推理业务来说首Token时延直接关系到用户体验这一点上超节点的高带宽起了大作用。解码阶段则要应对KV Cache的膨胀。自回归解码每一步计算量不大但延迟敏感并发请求一多KV Cache的显存占用飞速上涨。超节点的显存池在这里立了大功可以大方地给每个并发请求分配足量KV Cache空间同时用节点内低延迟互联加速解码。而且预填充和解码的计算特征不同训练时的并行配置不能直接照搬。我习惯的做法是预填充阶段用大TP解码阶段换小TP、提高数据并行度靠动态资源调整让同一套硬件在不重启服务的情况下平滑切换。这套方式在传统集群上做会束手束脚在超节点上则从容很多。4.3 从单超节点到多超节点节点间通信怎么降级十万亿模型的需求大概率会超过单个超节点能承载的规模实际落地时多个超节点组成更大集群是常态。核心原则还是那句把通信最密集的计算锁在单超节点内部节点间只承担中低频通信。用一张表来对比节点内和节点间的差异会更直观对比维度超节点内部超节点之间通信带宽TB/s级别数百Gb/s级别典型时延微秒级几十微秒级主要承担通信TP、EP等高频同步DP梯度全局同步、PP流水传输集合通信开销极低可近似忽略必须控制频次和消息量两者差着一个数量级因此做分布式切分时模型并行度最好不超过单超节点能够承载的卡数。只要主通信路径不出节点扩展到几倍规模时吞吐效率依然可以维持得很漂亮。万一贪心把TP扩展到跨超节点性能大概率断崖式下跌。这条经验对任何要建大模型集群的团队都很有参考价值别拿生产集群去试错。5. 把超节点搬进机房的真实坎可靠性、软件栈与成本5.1 故障域变大了单卡故障不再是小事件超节点把很多卡绑成一个逻辑大卡好处集中风险也集中。普通集群一块卡坏了影响的是一台8卡服务器里的一部分负载换卡方便超节点里一块卡亚健康可能拖累整组卡的集合通信故障域从单个节点直接扩散到整个超级节点。这一点如果不提前想清楚上线之后会非常被动。应对思路有三条一是实时亚健康检测任何卡在集合通信中出现一次延迟异常立即标记并隔离不要等它反复出问题二是更细粒度的即时检查点让故障后的恢复只回放到最近的安全点避免大范围重算三是在拓扑上预留冗余路径关键位置能快速切换。我们团队在超节点上踩过几次坑之后形成了先检测后调度的固定纪律——宁可临时降一点规模也不让有问题的卡搅乱整个通信域。稳定性的优先级在超节点场景里比普通集群高得多。5.2 软件栈要重新对齐并行库、编译器、调度器都得跟手硬件架构变了最费劲的不是迁移环境而是整套软件栈。传统MPI式集合通信库是为服务器间网络优化的直接搬到超节点不一定发挥得出极限性能。要跑满节点内的高带宽需要重新设计通信拓扑、优化远端内存访问路径甚至重新编译算子让底层代码感知到所有卡都在同一个框里。这不是换个驱动版本就能解决的问题。很多团队低估了这个工作量。我见过某项目组把旧集群的训练脚本原样搬到超节点上性能反而比原来还低因为旧代码大量面向远端网络优化根本走不上新的高带宽低延迟路径。反过来只要把集合通信库优先调度到节点内互联再针对超节点拓扑做算子融合和显存布局优化性能差距很快就会拉开。所以选择超节点方案时千万别忽略软件适配这部分人力和时间预算它不是可选项是必选项。5.3 成本账与选型建议什么时候超节点方案真正划算最后说点现实问题钱。超节点的高带宽互联、大显存池、一体化机柜硬件成本明显高于普通集群。但省下来的东西也很明确训练时间、通信等待、运维成本和调优成本。如果团队天天在跟通信瓶颈斗智斗勇超节点的隐性回报可能早就覆盖了硬件差价。我在评估方案时习惯算单位Token的训推成本而不是看单卡价格。单卡便宜但整体效率低最后总账未必好看。个人建议如果训练的模型超过千亿级别且有训推一体的长期需求超节点方向非常值得认真评估如果只是几十亿参数的常规模型或者业务场景比较单纯传统集群在成本上依然有优势。另外要留意选型不是拍脑袋决定至少拿一两个真实模型在小规模超节点上做基准测试再把结果外推到目标规模比任何厂商白皮书都靠谱。做了这么久超节点相关实践我最大的体会是十万亿大模型训推的最优解不是某一个硬件词汇而是整个系统设计思路的转变——从用网络拼服务器转向用互联造超级大卡。硬件把三堵墙的物理距离压短了剩下的路还得靠我们自己走并行策略、调度策略、容错设计都要重新对齐到新架构上。这条路没有捷径但一旦走通性价比远不是传统堆卡路线能比的。如果各位也在做类似的选型决策欢迎带着具体场景来聊——很多坎儿真的只有踩过才知道深浅。