这两年做大模型训练集群的人肯定绕不开一个词超节点。而我最近几个月的大半精力都耗在把超节点的Scale-Up域从72卡扩到144卡这件事上。听起来只是多了72块卡对吧真动手才知道这基本等同于把一栋楼的电梯系统重装一遍还要保证里头正在搬家的住户不断电。这篇文章我想把这段时间踩过的坑、重新算过的账、验证过的方案都盘一盘给准备做同样扩容的团队一份参考。尤其适合正在搞GPU计算、GPU服务器选型、k8s调用GPU、深度学习环境GPU版配置甚至涉及GPU驱动开发的朋友。老实说规模翻倍后真正难的不是卡而是让144张卡像一个整体一样稳定工作。我会按实际部署顺序来讲从Scale-Up域到底是什么到72到144的拓扑怎么变、显存和并行策略怎么重新规划、可靠性怎么保持最后给一份可以直接对照排查的问题清单。这里面很多结论不是白纸黑字写出来的而是真金白银的时间和数据堆出来的。1. Scale-Up域的价值为什么大家都盯上这个数字1.1 一张卡跑不动大模型时Scale-Up域到底解决了什么先说最基础的问题为什么大模型训练不能靠一台机器搞定。现在随便一个开源模型都是70B起步100B都不稀奇。一张80GB的GPU连把模型权重全部放进去都费劲更不用说训练过程中还需要保存梯度、优化器状态和激活值。你就算把单卡显存堆到200GB算力也会成为新的瓶颈单个GPU处理一个batch的前向和反向耗时太长训练周期会拉长到无法接受。所以多卡并行是必然选择。而多卡并行要面对的核心问题只有一个通信。同一台服务器里的8张卡可以通过NVLink这样的高速互联获得接近1TB/s级别的带宽通信延迟也很低。但一旦跨了机器走普通数据中心网络带宽立刻掉到几十GB/s量级延迟增加几十倍都不止。对数据并行这种每个step都要同步梯度的模式通信速度基本决定了训练效率的上限。Scale-Up域就是干这个的。它把参与同一计算任务的GPU用高带宽、低延迟的互联方式“粘”在一起让它们对外表现为一个超大号的GPU。我一般这么给新同学打比方Scale-Out网络是城市之间的物流系统讲究大吞吐、远距离、多跳转发Scale-Up域是同一栋楼里的电梯和传送带追求的是极短路径和极快响应。你要做张量并行这种细粒度拆分靠电梯和传送带才对得上节奏。1.2 72到144到底意味着什么先理解72卡在旧方案里是什么地位。很多团队上一代训练集群就是9个8卡节点通过高速互联组成一个计算域。为什么是72因为8卡天然是一台GPU服务器的标准形态机内全互联已经做得很成熟拿9台绑一起互联成本和技术风险都可控。对于70B左右的稠密模型TP8 PP9这种组合在72卡域里已经能跑得不错。144卡的逻辑就不一样了。要么把两个72卡域合并成一个更大的Scale-Up域要么从零设计一个144卡的互联拓扑。目标也很明确让单个训练任务可以享受更大的并行度尤其是MoE模型的专家并行能在一个域里完成全部通信不碰慢速的跨域链路。好处立竿见影但代价是组网复杂度、调度复杂度、故障恢复复杂度全都上来了。最关键的一点是从72到144不是简单翻倍。Scale-Up域的互联端口数、拓扑结构、信号完整性、功耗散热、故障域范围全部要重新定义。如果还是沿用72卡时代的拓扑和调度策略大概率会出现“明明加了卡训练速度却没怎么涨”的尴尬局面。我自己的经验是如果扩容后系统效率掉超过15%问题基本都出在互联和调度而不是GPU本身。2. 网络拓扑与互联架构144卡背后的组网逻辑2.1 从8卡到72卡再到144卡拓扑演进不是简单翻倍8卡单机是最容易的因为厂商已经把机内全互联做到了极致任意两张卡之间的通信都能吃到很高的带宽。到了72卡这个规模常用的做法是在8卡节点之上再加一层高速交换典型形态可以是8卡9机或者4卡18机。这一层要保证的关键项叫做等分带宽也就是任意两个节点之间的通信能不能跑满物理带宽。144卡就麻烦在这里。如果依然追求全域全互联你要准备多少交换端口、多少光模块、多少线缆成本会非常难看。更大的问题是信号完整性线缆一旦拉长误码率、重传率都会上升Scale-Up最看重的低延迟优势会被冲淡。所以实际设计中基本都得走分层比如先凑4个36卡子域或者6个24卡子域每个子域内部高速互联打满子域和子域之间再用高层互联打通。选哪套方案核心看负载类型。我一般会给两种建议如果主跑超大稠密模型全带宽all-reduce是刚需等分带宽不足会直接拖慢每个step的梯度同步这时候宁可多花钱把跨子域互联做高基数如果主跑MoE模型通信热点是all-to-all就需要重点优化跨子域带宽和路由调度。不同拓扑没有绝对好坏只有适配不适配。拓扑类型典型规模等分带宽适用场景单机全互联8卡100%TP域、中小模型节点一层交换32~72卡60%~90%看基数稠密模型训练、通用集群子域高层互联144卡及以上50%~80%看设计MoE大规模训练、超节点场景全互联大域1024卡以上理论高但成本爆炸极少数特殊场景2.2 计算域、通信域和集合通信的匹配问题超节点设计里最容易被忽视的是“域”的概念。同一个Scale-Up域内所有GPU共享一套高速通信平面但训练时不同并行策略对通信的需求差别很大。张量并行TP要求每步都all-reduce通信频率极高最适合放在8卡小域内流水线并行PP只在stage边界传输激活值通信量小可以容忍较慢链路专家并行EP在MoE模型里需要做all-to-all通信模式对拓扑最敏感。举一个直观的例子。一个70B稠密模型每step产生的梯度大约是140GBfp16精度下要在144张卡之间做all-reduce。按900GB/s的域内带宽来算光裸数据传输就要0.15秒以上实际跑起来还有ring算法的数据翻倍、协议开销、栅栏同步延迟翻个两三倍很正常。这就是为什么TP的并行度不能无脑拉大——TP越大单次通信的数据量和参与节点越多通信耗时增长是非线性的。实操层面的建议是调整通信库的拓扑感知能力。NVIDIA的NCCL、学术界常用的RCCL这类库都能通过检测GPU所在位置自动选择最快的通信路径。但默认参数未必适合144卡的超大域需要手工调一些环境变量比如限制P2P通信范围、调整网络直接读写的开关等。# 常见NCCL调优变量具体值取决于节点拓扑 export NCCL_P2P_LEVELLOCAL export NCCL_NET_GDR_LEVELPHB export NCCL_BUFFSIZE16777216调这些变量之前建议先用NCCL的benchmark工具跑一遍全量all-reduce看看实际带宽和理论带宽差多少。差得多再动手调调一次测一次别拍脑袋。2.3 为什么不能只用Scale-Out网络总有人问为什么不直接用普通数据中心网络把所有GPU连起来非得搞这么贵的Scale-Up域答案就是带宽和延迟差了一个数量级以上。普通RoCE网卡的单口带宽能做到400Gbps也就是50GB/s而NVLink这类Scale-Up域内互联单卡能拿到的带宽通常到400GB/s甚至900GB/s中间还少了很多层交换转发。对张量并行这种细粒度通信来说延迟比带宽更致命。走Scale-Out网络每次通信多跨几跳交换延迟增加几十微秒看起来不长但一个step里有大量小包通信累计起来训练效率掉得非常明显。只用Scale-Out跑数据并行还好跑TP基本等于把GPU算力闲置在等待通信上。当然Scale-Up互联贵是贵但整体算账还是划算的。如果因为域内带宽不够导致训练效率掉10%训练一个前沿模型多跑的时间、电费、人力和GPU折旧早就超过那点互联差价了。这也是为什么各家厂商都在把超节点、Scale-Up域这事儿往前推说白了大模型训练的收益模型决定了通信这块省不得。3. 显存规划与并行策略144卡怎么分活3.1 先说显存账训练一个大模型究竟要吃掉多少GB做144卡规划之前先得把显存账算清楚。混合精度训练下模型权重用fp16存每参数占2字节梯度在大多数框架里也用fp16再占2字节优化器state最狠Adam要保存fp32的master weight、momentum和variance每参数12字节。加起来一个参数在训练时要吃16字节。按这个公式算70B模型的理论显存就是70B乘以16字节约1120GB。如果部署在144张80GB卡上每卡要分摊约7.8GB给参数、梯度和优化器状态剩下的空间给激活值和通信buffer。看起来还有不少余量但你随便开个大batch size或者赶上序列特别长激活值瞬间能把剩余显存吃光。实际情况比理论紧张得多。我整理了一张速查表方便做容量规划时快速估算模型规模混合精度训练理论显存占用按80GB卡计算的静态卡数7B112GB2卡70B1120GB14卡100B1600GB20卡700B11200GB140卡这张表一拉出来你会发现700B模型的理论静态占用正好逼近144卡。这其实不是巧合144卡刚好是当前能“塞下”700B级模型训练的一个临界规模再往上就得靠ZeRO、offload、Flash Attention这类技术去抠显存。所以很多团队把超节点定在144卡本质上是冲着这个量级模型去的。3.2 TP、PP、EP怎么配比从72到144不是照搬翻倍72卡时代大家最常用的并行组合是TP8、PP99个stage每个stage放8卡配合上数据并行维度整体调度直观而且通信开销可控。到了144卡你要面对的第一个选择就是TP到底提不提。把TP从8提到16好处是单个权重矩阵被切得更碎每卡算力利用率更高坏处是每次all-reduce通信量翻倍、参与卡数翻倍通信耗时可能涨到无法接受。所以我见过不少团队在144卡时代反而坚持TP8不动把多出来的卡放到PP维度或者数据并行维度。PP从9提到18好处是流水线可以做得更深坏处是stage多了以后微批次数量和stage数如果不匹配流水线气泡比例会显著上升训练吞吐照样掉。MoE模型则是另一种玩法。专家并行EP把不同的专家分配到不同卡上每次token路由会产生大量的all-to-all通信。144卡的Scale-Up域对于EP来说是个好东西144个专家放一个域里通信不用出域延迟比跨域低一个量级。但EP的通信模式跟TP不同它在反向传播时也有额外的梯度聚合所以通信buffer要单独留模型并行度也要单独测别把TP或DP的经验直接套上去。我建议所有团队在扩容后都做一组消融实验固定模型和batch size跑TP8/PP18、TP16/PP9、TP8/PP9/DP2等几种组合用真实吞吐说话。MP配置这件事永远不要相信别人博客里的最优值因为你的模型结构、通信拓扑、甚至驱动版本都不一样。3.3 显存碎片和实测校准别让OOM成为扩容的常态理论算完了落到实际还会碰一堆麻烦。PyTorch的缓存分配器默认会把显存留在手里重复利用多进程训练时每个进程都会预占显存再加上NCCL要预留通信buffer实际可用显存比“总显存减模型显存”少得多。常见的情况是明明模型不大却OOM或者换一个batch size就崩多半是显存碎片或者buffer预留的问题。碰到这种问题先用框架自带工具定位别急着改代码。PyTorch下可以开显存统计看到底是哪一块占了大头。# PyTorch显存分布统计 import torch print(torch.cuda.memory_summary(devicecuda, abbreviatedTrue))经验做法是预留至少10%的显存给通信库和框架缓存。如果训练任务本身已经把显存打到95%以上说明并行度或者batch size需要回调不要硬扛。还有一个容易被忽略的点如果你用GPU微调大模型很多问题其实出在并行策略和显存配置上而不是模型代码逻辑。先把环境变量、优化器状态、激活值重计算这些基础项处理好再谈调优。日常做推理或者给外部用户提供GPU资源池时MIG或者GPU虚拟化可以提升利用率但在追求极致性能的超节点训练域里我不推荐做虚拟化。物理隔离越彻底性能越可预期故障定位也越简单。生产环境还是裸金属加容器的组合最稳。4. 可靠性、运维与故障恢复规模翻倍后的头号敌人4.1 规模翻倍后故障概率是怎么悄悄变大的很多团队在72卡阶段活得很舒服因为偶然坏一张卡、掉一条链路重启一下还能忍。但规模翻倍之后概率站在你对面。我做一个很粗略的估算假设单个节点一周内故障概率是0.5%72卡对应9个节点每周至少一个节点故障的概率约为4.4%听着还能接受144卡对应18个节点这个数就涨到了约8.6%。再加上算力变强后大家倾向于把任务排得更长故障对训练进度的杀伤力被进一步放大。故障类型也要重新认识。除了明星硬件GPU本身网卡、光模块、电源、内存、甚至一根线缆松了只要影响到Scale-Up域内任意两点通信训练就会被拖住。在单机Windows上GPU出问题可能报“d3d设备已移除”在服务器上对应的就是Xid错误、设备lost、NVLink降速或者NCCL超时这些都是训练集群的日常。所以从72到144我不再追求“永远不故障”而追求“故障后能快速恢复”。超节点这种强耦合的Scale-Up域换一块卡可能就要重新初始化整个域恢复动作不设计好一次故障磨掉半天都很正常。4.2 监控与快速恢复体系光看GPU利用率远远不够传统的GPU监控只看利用率、显存、温度这在超节点场景下远远不够。我建议至少还要采集NVLink链路速率、PCIe错误计数、光模块收发功率、显存ECC错误、电源功耗这几类指标。举个典型例子NVLink链路如果因为温度过高降速到一半NVIDIA驱动会记为链路降速甚至错误但你从GPU利用率上完全看不出异常只有训练吞吐莫名掉了发现不对。工具链可以分两层。第一层是硬件层诊断第二层是训练框架层的NCCL日志和超时控制。# 查看ECC错误计数 nvidia-smi -q -d ECC # 执行GPU健康诊断 dcgmi diag -r 1 # 训练时开启NCCL调试信息 NCCL_DEBUGINFO python train.pyNCCL的超时参数也是个重点。设太短正常的网络抖动会直接掐断训练设太长故障影响面会扩散到整个域。我一般建议先跑基准测试看正常通信时间然后在这个基础上加50%到100%的余量作为超时阈值。别把超时随便设成3600秒故障卡住一个小时才被发现那就是纯烧钱。Checkpoint策略同样要升级。旧的“每10分钟存一次”在144卡阶段不够建议做异步保存同时把模型权重、优化器状态、随机数种子分文件保存。这样即使某一类文件损坏还有机会从半损坏状态里抢救。更进一步可以在训练框架里做“心跳故障自动隔离”检测到某卡失去响应就自动熔断当前step而不是让整个任务死等。4.3 驱动、容器与调度侧的经验真正拉开差距的地方扩容到144卡最容易被忽略的坑往往出在软件层。第一个是驱动和CUDA版本对齐。驱动不需要所有机器都一样但同一批参与超节点的机器最好锁定同一驱动分支、同一CUDA runtime、同一NCCL版本。某个节点驱动版本偏旧看起来没问题但一旦NCCL用到了新特性整个域的性能和稳定性都会被这个短板拖垮。第二个是k8s调度侧。如果超节点交给k8s管理默认的调度器并不会考虑GPU之间的物理拓扑。一个训练任务申请144卡理论上可以但如果调度器把Pod拆到了两个不相邻的Scale-Up域通信就会退化到慢速网络性能直接崩。真要上k8s必须配合拓扑感知调度给每个超节点打标签让训练Pod尽可能落在同一个域内。国内环境还可能碰到麒麟系统、海光GPU这类软硬件组合。装PyTorch GPU版之前先确认驱动、CUDA版本和PyTorch的CUDA版本三者是否匹配不然报一堆看不懂的错最后发现是兼容性问题。我的经验是做一套“环境矩阵”文档把驱动、固件、CUDA、NCCL、框架版本全部锁死任何变更都要走灰度不要在144卡的集群上玩“顺手升个级”。5. 常见问题与排查技巧实录5.1 我整理的超节点扩容踩坑清单从72到144的扩容过程中我们团队记录过大量问题。我把最有代表性的几个整理成表格方便大家对照着查。现象可能原因排查手段解决方案训练启动卡在NCCL初始化超时容器网络端口未放通、多机通信失败开NCCL_DEBUGINFO查看卡在哪一步放通需要通信的端口检查路由和防火墙显存OOM但模型显存估算不高显存碎片、通信buffer预留过大torch.cuda.memory_summary看分配明细调高PYTORCH_CUDA_ALLOC_CONF的GC阈值减少缓存预留GPU利用率周期性掉到0集合通信瓶颈、某个节点掉队跑NCCL all-reduce基准对比各节点耗时找出掉队节点检查驱动和链路速率NVLink速率降为一半链路误码、温度过高nvidia-smi -q -d NVLink查dmesg清理尘灰、调整散热、检查线缆连接GPU设备丢失或Xid报错驱动Bug、电源不稳、显存ECC累计查Xid错误码、查dmesg日志按错误码定位硬件优先更换/隔离问题卡多进程训练时单卡程序反而崩溃环境变量没隔离、CUDA_VISIBLE_DEVICES没设置检查进程环境变量每个进程显式设置CUDA_VISIBLE_DEVICES和torch.cuda.set_device机器上出现莫名的GPU占用有GUI进程或第三方工具在占用显存nvidia-smi查进程列表清理无用进程训练服务器别装动态壁纸这类软件这个清单看着简单但每一条背后都是真金白银的教训。尤其是NCCL超时和NVLink降速这两个在144卡规模里出现频率比单机高得多而且初期很难发现。5.2 实操心得先小规模验证再全量放开如果你也准备做这类扩容我最想劝你的一句话是别一步到位。从72到144中间可以先搭一个32卡的小域把驱动、拓扑、调度、监控全部验证一遍再扩到72、144。这样做虽然慢但每个阶段的问题都能控制在可接受范围内不会出现“144卡全插满才发现拓扑设计错了”的灾难。基准测试一定要做扎实。NCCL test里的all_reduce_perf是标配分别在32、72、144规模下跑出基线和理论带宽对比。如果扩到144后实际吞吐只是72的1.2倍而不是接近2倍优先排查拓扑和调度不要怪GPU。# 144卡规模跑一次all-reduce基准 mpirun -np 144 -hostfile hostfile ./build/all_reduce_perf -b 64M -e 8G -f 2 -g 1最后变更管理要有“一键回滚”机制。驱动、固件、NCCL版本、调度策略任何变更前都保存好当前能用的组合。扩容后一旦性能异常先回滚再看日志。这能帮你快速判断是新硬件的问题还是新配置的问题。结束前再说几句最后分享一个我自己的体会。以前做72卡集群我总觉得“再大的问题重启就能解决”。到了144卡之后这个思路彻底不灵了——一次不优雅的重启可能让整个Scale-Up域进入半降级状态训练效率掉得一塌糊涂。所以现在我把超节点当作一套完整的“单机系统”来对待硬件、固件、驱动、通信库、调度、故障恢复每一个层面都要可观测、可回滚、可快速切换。我自己的习惯是把所有变更记录做成清单每次训练任务启动前都会核对一遍驱动版本、NCCL版本、拓扑标签和checkpoint状态。听起来繁琐但144卡规模的集群任何一次小失误都会被放大成小时级的恢复成本。如果你也在从72往144甚至更高规模走希望这篇能帮你少踩几个坑尤其是Scale-Up域的拓扑、显存规划和可靠性设计上别等到卡全插满了才想起来回头改。