★ FEATURED ARTICLE 1. 从一张算力拓扑图说起现代AI集群到底长什么样这两年我做过不少AI算力相关的规划和评估项目发现一个很有意思的现象很多团队买GPU的时候非常舍得花钱一上来就是几千张卡的大单但等集群真正跑起来利用率却低得吓人有的甚至不到30%。问题出在哪十有八九不是卡不行而是整个算力集群的构成和架构从一开始就没想清楚。所谓AI算力研究框架说白了就是回答三件事第一算力集群由哪些部分组成第二这些部分之间怎么协同第三不同场景下应该如何取舍。如果你手上正好有一份79页的AI算力研究报告你会发现它再怎么展开也绕不开这三条主线。本篇文章就把这套框架掰开揉碎讲一讲我自己的理解和实战经验。先给没有接触过大规模集群的同学一个直观印象。一个典型的AI算力集群从物理形态上看就是三个机房级别的东西叠在一起计算资源、网络资源和存储资源。计算资源很好理解就是那一排排插满GPU卡的服务器机柜网络资源是让这些服务器能够高速互通的交换设备存储资源用来放数据集、模型checkpoint和日志。听起来很简单实际组网的时候这三块的边界会纠缠得让你怀疑人生。举个例子。单机8卡GPU服务器内部卡与卡之间走的是NVLink或者PCIe带宽轻轻松松到几百GB/s而服务器与服务器之间走的是网卡和交换机主流是400Gbps甚至800Gbps。这两者的带宽差距接近一个数量级。所以当你把训练任务从单机8卡扩展到跨机32卡、64卡的时候通信就成了最大的瓶颈。这不是某一个环节的锅而是架构设计时必须前置考虑的问题。我看过一份2024年的全球AI基础设施调研里面提到一个数据在大规模训练集群中通信等待时间平均占到整个训练迭代时间的40%到60%。也就是说假如一个step跑100秒可能有50秒在等数据同步。这种情况下你再堆多少张卡都没有意义因为瓶颈已经不在卡上而在你如何把卡组织起来。所以研究AI算力第一步不是去追最新的GPU型号而是要建立一张从单卡到万卡的完整视图。这张视图从上到下大致包括四个层级芯片层GPU/TPU/NPU提供最基础的算力密度节点层服务器内部的CPU、内存、本地NVMe盘以及卡间的高速互连集群层跨节点的网络拓扑包括Spine-Leaf架构、RDMA协议等调度层任务如何被切分、分发到不同节点上例如借助容器编排系统、资源调度框架来实现这四个层级缺一个就可能让你的整个集群变成一个昂贵的摆设。后文我会沿着这几个层级把每个环节的关键选型和常见坑都过一遍。2. 计算资源选型不是只有GPU这一条路2.1 GPU、NPU与异构计算的适用边界大部分人对AI算力的第一反应就是GPU。没错NVIDIA的A100、H100、H200乃至最新的Blackwell系列确实是当前大模型训练的主力。但如果你把所有希望都押在GPU上很容易踩两个坑一是供应周期太长二是成本结构不合理。先看训练侧。衡量一张卡能不能用于大模型训练主要看几个硬指标显存容量决定单卡能塞下多大模型。以当前主流的70B参数模型为例光模型权重就要占用近140GB以BF16精度估算所以80GB显存的A100/H100只能做切片而H200的141GB显存可以整卡放下一个小一点的模型省掉不少张量并行的通信开销。算力密度FP16/BF16下的TFLOPS这个决定了纯计算速度。卡间互联带宽NVLink带宽低的话多卡并行效率会断崖式下跌。再看推理侧。如果你的业务是高频、低延迟的在线推理比如智能客服、内容生成APIGPU固然能扛但单位成本会压得你喘不过气。这个场景下很多团队都在转向NPU或者专用推理芯片。NPU的优势在于功耗低、单路并发高劣势在于生态不成熟主流框架的算子覆盖不如GPU那么全。我个人的选型思路是这样的训练和重度推理场景优先考虑GPU大规模、高并发、对延迟不敏感的推理场景考虑NPU或CPU推理方案如果是自研专用模型还可以看看FPGA做定点加速。多条腿走路比吊死在一棵树上稳得多。2.2 服务器节点配置的隐藏细节确定了卡型之后下一步是选服务器。这里面的坑要比很多人想象的多得多。第一个是CPU和内存的配比。一张H100的PCIe版本标称功耗350W但实际跑满大模型训练时CPU要负责数据加载、指令分发、结果回收PCIe带宽也会被占满。我见过一个配置8卡H100的服务器只配了64核CPU和512GB内存跑千亿参数模型时数据加载持续跟不上GPU利用率一直在40%上下浮动。后来升级到96核、768GB内存利用率直接拉到了85%以上。问题不大但影响巨大。第二个是本地盘。训练数据的预读取和checkpoint的临时落盘如果全部依赖远端存储网络会成为瓶颈。现在的标准做法是每台服务器配置4到8块NVMe SSD做本地缓存训练框架比如PyTorch DataLoader先把数据预取到本地再喂给GPU。这个细节看起来不起眼但对训练稳定性的影响非常直接。第三个是散热和供电。这个在机房部署阶段最容易翻车。8卡GPU服务器的满载功耗动辄4kW到6kW一个48U机柜如果放6台这样的服务器热密度就接近30kW。标准的风冷机房可能完全压不住。所以规划算力集群不是在Excel表格里填设备清单就行必须同步规划液冷或高密度风冷方案否则设备一到就傻眼。2.3 卡间互联方式NVLink、PCIe与UBB的取舍同样是8卡服务器卡与卡之间的互联方式也分三六九等。NVIDIA的DGX系列用的是NVLink全互联卡间带宽高达900GB/s而普通PCIe方案的8卡服务器卡间带宽只有约64GB/sPCIe 5.0 x16双向理论值。差距接近15倍。这对训练任务的影响是决定性的。以GPT类模型的张量并行为例每个Transformer层的计算需要在不同卡之间频繁交换激活值和梯度。如果卡间带宽不够张量并行几乎没法用只能退回到数据并行而数据并行又会受到梯度同步的限制。所以你会发现同样8张H100在NVLink互联的机器上训练速度可能比PCIe互联快一倍以上。不是所有场景都需要NVLink。如果是做推理部署模型切分不深卡间通信量小PCIe方案完全够用还能省不少钱。核心原则是先看你的模型并行策略再倒推卡间带宽需求。别一上来就喊NVLink更别盲目给每台服务器配UBB底座那玩意儿价格不菲。3. 网络架构集群能不能扩展全看这一层3.1 从Spine-Leaf到无阻塞网络单机8卡只是起点集群规模一旦超过几十张卡网络就成了决定成败的环节。很多团队在单机阶段几乎没有网络设计的概念——几台服务器接个万兆交换机就完事了。等要扩展到几百张卡的时候网络瞬间变成瓶颈训练迭代时间肉眼可见地变慢。现代大规模AI集群绝大多数采用Spine-Leaf两级交换架构。所谓Spine-Leaf其实就是把网络分成两层下面一层Leaf交换机连接服务器上面一层Spine交换机连接所有Leaf。任意两台服务器之间的通信最多经过一台Leaf和一台Spine延迟可控、带宽可扩展。相比传统的三层树形网络Spine-Leaf不会因为某条链路故障导致一大片区域失联扩展性也好很多。但光有Spine-Leaf还不够关键在于收敛比。以一张H100服务器为例8块卡如果配8张400G网卡那么一台服务器对外就有3.2Tbps的通信能力。假设Leaf交换机是64口400G它对接服务器的同时还要上行到Spine。如果Leaf的上行带宽和下行带宽相等即收敛比1:1那这就是无阻塞网络任何时刻任意服务器的通信需求都能被满足。但如果为了省钱Leaf只配了一半的上行口收敛比变成2:1那当多台服务器同时大规模通信时流量就会堵在Leaf上。我的建议是用在训练集群上的网络收敛比不要超过1.5:1追求稳定的话直接上1:1。推理集群对带宽的瞬时压力小一些可以放宽到2:1或者3:1把省下来的钱花在推理节点的数量上收益更明显。3.2 RDMA与拥塞控制看起来都通其实天差地别网络架构确定后真正决定性能的是通信协议的实现。AI训练里节点之间的数据同步用的是RDMA而不是传统TCP/IP。原因很简单TCP在内核协议栈里走一圈延迟增加几十微秒带宽利用率也会因为拥塞控制机制掉下来RDMA允许数据直接从应用内存搬到网卡再搬到对端内存CPU不参与数据拷贝延迟能压到一微秒级。目前主流的RDMA实现有InfiniBand和RoCE。InfiniBand是NVIDIA提出的整套方案性能和稳定性都很好但从交换到网卡到线缆全套锁死贵。RoCE则是把RDMA跑在传统以太网之上成本低很多但需要有额外的流控机制来避免丢包因为以太网本质上是尽力而为的一旦丢包RDMA性能会雪崩。我自己的实战体会是如果集群规模在512卡以内RoCE加上好的交换机支持全速PFC/ECN完全能打成本要比IB方案低30%以上。如果超过1024卡且任务是大模型预训练我建议你还是认真考虑IB或NVLink组网省下的排障时间远超硬件差价。3.3 网络排障经验你以为是卡的锅其实是网的问题这里分享一个真实案例。去年我给一个客户优化训练集群他们用的是256张A800训练一个70B模型理论算力应该能跑到多少我们不算但实际有效算力只有60%不到。一开始客户怀疑是GPU故障做了全套诊断发现卡没问题。后来我们用机房流量监控一看训练时Leaf交换机的出向队列一直在增长ECN标记比例超过5%。这就说明网络拥塞了。再深入排查问题出在两处一是当时RoCE配置里PFC的优先级队列没有单独隔离管理流量和数据流量混在一起一旦有日志备份就能把数据面冲掉二是部分交换机固件版本不一致导致ECN的阈值行为不同有的端口早早标记有的端口完全不标记。结果就是全网流的步调完全错乱。修复方案不复杂把管理面、存储面、数据面用物理或逻辑方式隔离开统一固件版本再把ECN阈值调到推荐参数。之后训练有效算力回升到了80%以上。整个过程没什么高技术含量但如果你没有养成先看网再说卡的习惯这类问题能查一个星期。4. 存储设计喂不饱GPU的代价比你想的更贵4.1 数据流水线的三个层级很多刚接触大规模训练的人会低估存储的重要性。他们的逻辑是GPU算得快存储只要够大就行。但实际运行起来GPU消费数据的速度是惊人的。以一份几百GB的图像数据集为例在做数据增强时每个epoch都要对全部样本做随机裁剪、翻转、颜色扰动。如果这些计算全部交给GPU去等训练一步要等好几秒才能取到下一个batch的数据。这显然不能接受所以工业级方案一般把数据流水线拆成三层热层每台服务器本地NVMe盘存放当前epoch的预处理数据温层机柜或集群内的并行文件系统承载全部数据集和频繁读取的权重冷层对象存储如业内常用的S3兼容方案存原始数据、归档日志、历史模型训练框架首先从热层拉数据miss了再去温层再miss就去冷层。这个层级设计做得好GPU利用率可以长期稳定在高位做得不好GPU就经常饿肚子。4.2 分布式存储选型的性能指标选型时不要只看总容量要看三个指标聚合带宽、IOPS、元数据处理能力。大模型训练的checkpoint写入是非常典型的大文件小并发写一次写入就是几百GB需要的是持续的大带宽而小样本训练集则经常触发数百万个小文件的访问需要的是高IOPS和强悍的元数据性能。目前业界主流的并行文件系统是Lustre和GPFS都有成熟的NVMe缓存层。新一些的项目也会考虑WEKA、JuiceFS这类专业AI存储方案。我的经验是存储系统不要自己用HDFS糊一个HDFS对文件锁和随机读的支持太弱在大模型场景下根本跑不动。4.3 Checkpoint写下不进去的惨痛教训最后说一个我踩过的大坑。有次训练的排查记录显示每次save checkpoint时集群会卡死几十秒GPU利用率掉到接近0。一开始我以为是磁盘满了一查磁盘空间很充裕但写延迟高达数百毫秒。根因是并行文件系统的条带化配置默认配置是把一个文件均匀打散到少数OST上而我那个checkpoint文件是单文件120GB几个OST的写入带宽加起来完全不够用。解决办法是调整条带宽度让这个大文件打散到几十个OST上写带宽立刻翻了好多倍。从那之后我的经验是checkpoint存储路径在正式训练前必须单独做一次压测别等训练跑起来了才发现写不动。5. 调度与集群管理算力能不能用起来看它5.1 调度器的选型和对比集群算力有了不代表任务能自动跑得好。你需要一个调度器把训练任务、推理任务、开发调试任务合理地分配到不同的节点上。目前主流方案无外乎三类Kubernetes生态丰富适合推理服务和在线业务但直接跑大模型训练时调度性能需要仔细调优Slurm传统HPC调度器对GPU任务支持成熟适合一排任务排队跑的高吞吐场景厂商自研调度器比如专门为训练平台设计的全托管调度方案但耦合度高、灵活性差不同业务的调度诉求差别很大。如果你既有在线推理服务又有离线训练建议以Kubernetes为底座再叠加在Kubernetes中扩展训练负载的实现。这种做法的好处是统一资源池坏处是需要投入平台开发人员。调度策略也比较重要。贪心填满和预留批处理都可能造成浪费。大模型训练任务通常是长时间占用一批节点如果调度器在任务间频繁做分片重排反而会引入额外的数据传输。给长训练任务预留节点、给短调试任务用碎片资源是性价比比较高的策略。5.2 监控观测和资源计费集群建好之后运维的核心就是观测。我推荐的指标至少包括以下几项GPU利用率SM占用和显存占用率GPU温度、功耗、NVLink带宽网络出入方向流量和丢包率存储读写延迟和队列长度任务排队时间和任务失败率监控数据建好了还要配上资源计费。如果没有一个有效的budget机制几十个人的算法团队很快就能把集群跑成一团乱账谁的实验在跑、占了多少卡没人说得清。业界常见做法是按卡时计费即一张卡使用一小时为一个单位把实验成本量化。这一步做完大家用卡会收敛很多很多无效的瞎跑实验自然就少了。6. 大模型时代的算力新变量从千卡到万卡不只是乘法题6.1 Scale-up与Scale-out的边界这几年AI算力的一个明显趋势是集群规模越来越大。OpenAI的训练集群据说已经到了数万张卡的量级。国内很多大厂也在朝这个方向走。但万卡集群并不是简单地把千卡乘以十它带来的是指数级增长的工程复杂度。这里要澄清两个概念Scale-up指单节点内的扩展比如8卡变16卡用NVLink把更多卡打成一个大GPUScale-out指跨节点扩展依赖高速网络把多个节点组织成一个逻辑训练任务。当模型大到单机装不下必须走Scale-out时通信开销的增长会远超你的直觉。每增加一倍节点数量通信拓扑的路径长度和拥塞概率都会上升所以需要从算法层面做并行策略的优化比如把Attention层的计算做序列并行而不是所有卡都去通信全量梯度。6.2 可用性设计和故障恢复大规模集群不能假设每一个组件都能一直运行。真实环境中GPU、交换机、存储、电源任何一个环节都可能出问题。所以运营商或平台团队在架构设计时一定要预留故障恢复的机制和手段。一个常见的做法是弹性训练。即训练框架能够感知某个节点的异常自动把任务切到其他可用节点上从最近的checkpoint继续训练。但这里有个严肃的问题如果checkpoint保存得过于频繁存储写入会成为新的瓶颈如果保存得不频繁故障恢复会丢掉大量训练进度。开发级实践是每保存一个checkpoint后先把权重验证一遍再继续训练能规避存了半天存了个坏文件的尴尬。还有一个小技巧训练中段的心跳日志一定要开。有次整个集群因为交换机固件升级导致节点互信超时大批任务被调度器判定为失败而杀掉虽然GPU硬件和网络链路都没坏。如果有心跳日志就能快速判断这是网络抖动还是真正故障而不是傻乎乎地重启一切。6.3 集群效能的度量方法万卡集群听起来很唬人可效率不一定高。行业中常用两个指标来衡量效能有效算力比和模型FLOPs利用率MFU。MFU的含义是模型在单位时间内实际完成的计算量除以GPU理论峰值算力。业界目前能达到的水平各不相同优化做得好的团队能到50%上下不少粗放的团队连25%都不到。MFU上不去通常先查三件事一是通信是否成为瓶颈二是数据加载是否抖动三是并行策略是否合理。这三件事查完还低再去看代码里的算子优化。7. 算力成本经济学从硬件采购到运营支出7.1 采购环节供需失衡下的策略GPU采购是典型的卖方市场交货周期和溢价都很夸张。所以做预算和规划时不能只按官方建议价算。一个比较稳妥的做法是把卡价折旧机房租金电力费用运维人力网络带宽五部分全部算进单位算力成本里。这里有一个容易忽略的点电力费用。以H100满载约700W计算一台8卡服务器就是5.6kW加上网络设备和制冷一个机柜的耗电随随便便到15kW以上。如果当地电价偏高电力成本会占到集群整体运营支出的30%甚至超过硬件折旧费用。这也是为什么很多算力中心都往水电便宜的地方建。7.2 训练与推理的成本结构差异研究AI算力必须分清训练和推理这两种成本结构。训练成本是一次性的模型训完钱就算花完了产出是一个权重文件。而推理成本是持续性的每次用户请求都在花钱。如果一个to C产品每天有百万级请求推理成本往往远超当初训练模型的钱。因此在设计转售算力或内部共享算力时要把训练集群和推理集群分池管理甚至使用不同的硬件。训练池追求的是高算力密度和卡间互联推理池追求的是高吞吐、低功耗和低延迟。把它们混在一个集群里调度复杂度和资源碎化问题会让你痛不欲生。8. 从研究报告到落地决策构建你自己的AI算力研究框架8.1 框架的五个维度说了这么多最终都要回到一套可以指导决策的方法论。我把自己的经验归纳成五个维度大家在评估任何AI算力方案时都可以按这个框架来问问题业务场景要训练还是推理在线还是离线延迟要求多高算力规模当前需求有多大半年后、一年后会增长多少技术架构并行策略怎么定网络、存储、调度如何匹配成本模型单位算力成本多少是否包含电力和运维摊销演进路径集群能不能平滑扩容新技术出来后会不会被锁死这五条分别对应一页纸的五段话。把每段话写清楚一份AI算力研究框架也就出来了。8.2 不要迷信任何单一指标在AI算力这个圈子里最容易犯的错误就是拿单一指标说事。比如看到某张卡的显存是竞品两倍就下结论说性能翻倍看到某台服务器的总算力很高就忽视它的数据中心能耗和散热难题。一位知名技术专家曾在分享里说过评估算力集群的好坏关键是评估实际跑起业务的有效算力而不是理论值。这句话我深以为然。做算力规划目标是把PPT里的峰值算力变成用户真实感受到的响应速度和模型能力。8.3 最后的建议先做小规模验证再谈万卡如果你正在为一个新业务规划AI算力我的最终建议是不要一上来就画一个万卡蓝图也别急着把预算全押上。先用几十张卡跑通一个小规模的业务闭环把数据预处理、训练效率、推理延迟、运维监控这一条链路完全跑顺。之后再按2到3倍的增速做弹性扩容规划每一层都留有加节点的空间。这套思路既能让业务快速启动又能避免因为错误选型导致的大规模返工。算力这事情扩张容易收缩难。小步快跑验证清楚再放大规模是我这几年看过无数案例后唯一敢打包票的经验。
阅读完成 · 觉得有帮助？
