最近和几个做AI基础架构的朋友碰面,大家口径高度一致:不是买不到算力卡,是电不够用。"算力危机"被念叨了好几年,翻译成机房里的白话就一句——算力危机的本质是能效危机。这几天热搜上飘着的"算力""RTX 3090算力""分布式算力""AI算力集群架构"都指向同一个问题:我们到底怎么把每一度电换成更多的训练迭代?这篇文章基于我自己做GPU集群运维、踩过大模型训练调度坑的经验,把算力与能效的关系、资源配置建模方法、集群架构取舍一次讲透。想搞懂大模型训练要几张卡、怎么省钱省电,或者正打算搭一个小规模AI算力集群的朋友,应该都能从里面找到能直接抄作业的思路。
1. 算力焦虑的另一面:表面缺卡,实际缺瓦
1.1 算力危机的真实语义
我先说个身边的观察。2023年以后,市面上喊"买不到卡"的声音明显变了味:头部云厂商的A100、H100都有货,但新建机房的审批里,最难过的不是采购单,而是供电方案。一个8卡的H100服务器,光GPU的峰值功耗就是8×700W,加上CPU、内存、NVSwitch、电源转换损耗,一台整机的输入功耗普遍在9到10kW。标准数据中心一个机柜一般只给6到10kW的供电容量,所以现在流行的高密度机柜一去到30kW、40kW,配电柜、母线、散热都得推倒重来。换句话说,瓶颈已经从芯片产能转移到了电表容量上。
这个转变不是小事。算力危机如果要翻译成一句人话,那就是:单位面积、单位时间能供给的瓦特数,决定了你能跑多少大模型。GPU可以靠排队等货,但电费是每个月实打实扣走的。我自己管过的集群,电费在总成本里的占比从三年前的百分之十几,涨到现在超过了三分之一。电这个东西,瞬时功率不够会跳闸,累计能耗太高会吃光预算,两头都卡死你。
1.2 把算力换算成"每瓦特产出"
为什么说本质是能效危机?因为我们真正需要的是"有效的模型训练进度",而不是裸算力。同样是FP16 Tensor Core的浮点运算,不同GPU每瓦特能产出的结果差出一大截。打个比方,算力就像汽车的马力,能效就像百公里油耗。大马力赛车确实快,但如果一箱油只能跑两圈赛道,车队还是要掂量掂量。AI Infra领域有个常用的指标:算力能效比,单位是FLOPS/Watt或者TOPS/Watt,指每消耗一瓦电能够完成多少次浮点运算。这个数越大,说明芯片把钱花在刀刃上。
很多做训练的人一开始只盯峰值TFLOPS,等到电费单下来才发现错了。峰值算力再高,如果功耗和散热限制了实际跑不到的频率,那也只是纸面数字。能效比的本质是把"容易算错账"的两个维度统一成一个维度:给一度电,你能跑多少token。谁把这件事算明白,谁就能在大模型军备竞赛里活得更久。
2. 把能效拆开看:单卡、整机、机房三层指标
2.1 单卡能效:从RTX 3090到H100的对照
先看单卡。这里我按厂商公开参数做一个粗口径对比,统一看FP16 Tensor Core稠密算力和TDP,表格里的能效比就是两者相除:
| 型号 | 架构 | FP16 Tensor稠密算力 | TDP | 每瓦算力(FP16 Tensor/W) | 典型定位 |
|---|---|---|---|---|---|
| RTX 3090 | Ampere消费级 | 约71 TFLOPS | 350W | 约0.20 | 个人尝鲜、廉价跑批 |
| A100 80G | Ampere数据中心 | 约312 TFLOPS | 400W | 约0.78 | 上一代训练主力 |
| H100 SXM | Hopper数据中心 | 约495 TFLOPS | 700W | 约0.71 | 大模型训练主力 |
| RTX Pro 5500 | Blackwell工作站 | 新一代架构,INT8/FP4优化 | 约160W | 能效优先设计 | 工作站微调/推理 |
很多人没注意,H100在稠密FP16上的每瓦算力其实没有比A100高多少,真正的代差体现在稀疏模式和FP8/FP4上,那部分能效比能跑到1.4甚至2.8以上。而RTX Pro 5500这类Blackwell工作站卡,定位很有意思:它不追求绝对峰值,而是把TDP压到160W级别,主打"够用、省电、安静",适合个人工作站做微调和小规模推理。选卡的时候别被公司的PPT带偏,先算清楚你要跑的任务吃的是稠密还是稀疏、FP16还是FP8。
这里要提醒一句:表格里的能效比是"标称峰值功耗下的峰值算力",真实负载里,GPU利用率低于一半时,每瓦产出可能只有标称的一半都不到。所以单卡能效只是起点,还得看整机和机房的账。
2.2 整机与机房:PUE 是电费放大器
单卡标称再漂亮,放到机房就绕不开PUE(Power Usage Effectiveness,电能使用效率)。PUE的定义很朴素:机房总耗电除以IT设备耗电。1.0意味着电全部用在服务器上,没有损耗;现实里风冷机房普遍1.3到1.5,液冷机房能压到1.1左右。别小看这0.2、0.3,它会把你的电费放大三成。
举个例子,一套256卡A100集群,IT负载功耗按102kW算,如果机房PUE是1.5,实际总功耗就是153kW,一年下来光"冷却和供电损耗"就吃掉了45万千瓦时以上。换到液冷+PUE 1.1的机房,同样的IT负载,总功耗112kW,一年省下的电费可能够再买一台训练服务器。我在规划集群时会把PUE直接写进机型选型评审表,风冷和液冷方案各出一版能耗预算,用数字说话,比什么都管用。
注意:PUE是动态指标,不是纸面常量。签约机房前一定要看对方实际运行的历史PUE曲线,尤其是低负载时段的表现,否则宣传册上的1.15到你账单上很可能变成1.4。
2.3 动态能效:标称满载只是理想情况
还有一个坑是动态能效。GPU不是一块纯电阻,它在不同负载下的能效差异非常大。经常有人跑推理服务,GPU利用率只有20%,功耗却占满载的50%以上——因为显存、HBM、各类控制器只要上电就在耗电。实测下来,H100空载功耗能有80到120W,A100也有60到90W,占TDP的15%到20%。所以一个集群最费电的状态往往不是满载训练,而是"有空闲GPU挂着没人理"。
针对这个现象,我在生产环境里养成了两个习惯。第一个是给推理任务开功率上限,比如把A100用nvidia-smi -pl 300限制到300W,对延迟不敏感的批量推理能把利用率堆到80%以上,性能损失通常不到10%,功耗却能省25%左右。第二个是调度器里做严格的bin-pack:按GPU整数卡占用来排任务,把碎片化空闲卡合并关停或休眠,能省出一大块电费。能效管理不是买几块省电卡就完事,是持续跟功耗曲线作斗争。
3. 算力约束下给大模型做资源配置建模
3.1 先用6ND公式把算力需求算出来
聊完能效指标,落到具体问题:给一个大语言模型做资源配置,到底需要多少算力?业内最常用的是Chinchilla论文给出的估算公式:一次完整训练的浮点运算量(FLOPs)大约等于6乘以参数量N乘以训练token数D,即FLOPs ≈ 6ND。
这个公式背后的直觉是:前向传播大概要2ND次运算,反向传播是前向的2倍,加起来约6ND。它不算精,但足够用来做资源配置的顶格估算。举个例子,训练一个70亿参数(7B)模型、训练数据2万亿token,总FLOPs就是6×7×10^9×2×10^12,约8.4×10^22。别小看这个数,它就是一切后续规划的起点。
有了总量,再看单卡产能。以A100 80G为例,FP16稠密算力312 TFLOPS,一天的理论吞吐是312×10^12×86400秒,约2.7×10^19 FLOPs。但真实训练还有通信、等待、访存瓶颈,行业里通常用MFU(Model FLOPs Utilization,模型浮点利用率)来衡量实际效率。A100集群MFU能到40%到50%已经不错,按45%算,单卡每天有用算力约1.2×10^19 FLOPs。8.4×10^22除以这个数,约7000个A100·天。这就是"算力约束"落到账本上的样子。
注意:6ND只是一个理想估算,真实训练还会被激活重算、通信、日志检查点等额外开销拖累,建议在算出的GPU·天上乘以1.1到1.3的工程系数。
3.2 一个可以直接照抄的估算模板
我把这个流程整理成五步模板,你直接往上套就行:
- 定参数量和token数,用6ND算出总FLOPs。
- 选卡,查官方算力和TDP,估算一个现实MFU(训练用0.4到0.5,推理用0.2到0.4)。
- 算单卡每日有用算力=算力×86400×MFU。
- 用总FLOPs除以单卡每日产能,得到GPU·天。
- 用GPU·天乘以24小时、乘以单卡功耗、乘以PUE,得到总耗电。
我拿7B/2T这个任务分别套H100、A100、RTX 3090三种方案,假设都在一个组织靠谱的机房里、PUE取1.2,结果是这样的:
| 方案 | 卡数 | 预计训练耗时 | IT负载功耗 | 总耗电量(含PUE 1.2) |
|---|---|---|---|---|
| H100 | 256卡 | 约17天 | 约180kW | 约88MWh |
| A100 | 256卡 | 约27天 | 约102kW | 约79MWh |
| RTX 3090 | 512卡 | 约76天 | 约180kW | 约390MWh |
这里的MFU假设是:H100和A100能到45%,RTX 3090集群因为PCIe交换机通信瓶颈,只能按35%算。看到最后一栏你就明白为什么我一直反对用消费卡堆训练集群——它单卡便宜,但单位token的能耗和时间成本高得吓人,训练一个7B模型要烧掉390MWh,几乎是H100方案的4.5倍。省了卡的钱,全在电费和人工等待里吐回去了。
经验之谈:千万不要用消费级显卡堆大模型训练集群,它省下的采购成本,会在电费、散热和时间成本上连本带利吐回去。
3.3 资源配置还要跟训练策略联动
资源配置建模不是算完GPU·天就算了,它跟训练策略强耦合。同一个任务,你用张量并行、流水线并行还是数据并行,MFU天差地别;你用BF16还是FP8,显存压力和能效也完全不同。我的经验是:先决定并行策略,再定卡数,最后才是选卡型。
比如显存吃紧时,很多人无脑开梯度检查点,但梯度检查点是用额外计算换显存,会让总FLOPs上涨10%到30%,直接拉低能效。更划算的路线是先做序列打包、激活分区、offload优化器状态,把显存利用率拉满,再考虑检查点。此外,通信占比过高的集群,与其加卡,不如换更好的互联设备——一张算力翻倍的卡,如果天天在等AllReduce,能效比就是一纸空文。这些策略层面的选择,最终都会反馈到每度电能产出多少有效FLOPs上。
4. 从单机到集群:AI算力集群构成与能效架构
4.1 一套AI算力集群的典型构成
顺着资源配置再往上走,就得看集群本体。现在一套正经的AI算力集群,基本由五层构成:算力层、网络层、存储层、调度层、配套层。算力层就是GPU服务器,常见8卡一台,靠机内NVLink和NVSwitch组成一个高带宽域;网络层是跨服务器的通信骨架,高性能场景用InfiniBand或RoCE,低性能场景用普通以太网;存储层要给训练数据提供高吞吐,并行文件系统几乎是标配;调度层用Slurm或Kubernetes把任务分给GPU;配套层是电源、散热、机柜、监控,它决定了集群能稳定跑多久。
很多人搭集群只盯着算力层,结果网络层配了张万兆网卡,8卡H100之间数据搬不动,MFU直接腰斩。存储层如果带宽跟不上,dataloader一卡壳,GPU就在那空转烧电。这个坑我见过太多,配置集群时一定要把"算力/网络/存储"三者的带宽做匹配,宁可GPU算力略吃紧,也别让任何一个环节成为电费黑洞。
4.2 架构选型里的能效取舍
架构选型表面看是技术选型,实际是能效取舍。第一层是机内互联:NVLink能让8卡共享显存带宽,但如果你只跑数据并行,NVLink的优势发挥不出来,不如用PCIe卡;反过来,做张量并行的超大模型,没有NVLink就是灾难。第二层是机房散热:风冷方案便宜但PUE高、噪声大,液冷方案前期贵但能把PUE压到1.1以下,还能让GPU在更高功耗下不撞温度墙、不掉频,长期看电费反而省得多。第三层是调度器:用Slurm按整数卡bin-pack,把闲卡合并休眠,比让任务乱跑省电得多。
还有一点容易忽略:供电余量。很多人按GPU峰值功耗加个20%就算完,实际训练用DCGM测一下,8卡H100瞬时总功耗冲到9kW很正常,供电余量不够就会触发电源保护,训练中断重来,白白浪费电。我给每台服务器预留的供电余量都在30%以上,宁可多报一点容量,也不要让整机在临界点跳舞。
4.3 分布式算力:把闲置瓦特变成有效产出
分布式算力这两年很热,我的判断是:它的本质是把"碎片化的瓦特"聚合成"有效的算力"。一家公司晚上空闲的几百张卡,白天可以租给别的团队做推理或微调;个人开发者手里的RTX 3090,也能通过各类算力平台接一些小任务,把闲置电费摊薄。这也是为什么很多厂商开始做面向开发者的算力申请计划——与其各自买卡吃灰,不如把高能效的算力按小时分出去。
但分布式算力不是万能药。跨机房、跨地域的带宽延迟很高,做分布式训练要把任务拆成粗粒度:按数据集切片做数据并行可以,按层拆流水线也行,唯独跨机房做张量并行是找死,一个AllReduce的通信延迟就能让MFU掉到个位数。我建议把分布式算力定位在"推理、微调、后训练对齐"这类通信量可控的场景,训练大模型还是老老实实放在同一个高带宽集群里。算力可以分布,电费的账要集中算。
5. 能效优化的实操总结与常见问题排查
5.1 我亲手踩过的三个能效坑
第一个坑是贪便宜组RTX 3090集群。两年前我接过一个项目,为了省采购费,买了上百张3090搭训练集群,结果训练一个中型模型跑了快三个月,电费预算爆掉,机房空调天天满载不说,PCIe交换机还成了通信瓶颈,GPU利用率平均只有30%出头。后来算总账,那颗"省钱"的糖衣里包的全部是电费和时间的苦药。
第二个坑是只看满载算力,没配监控。有段时间集群GPU利用率看着有80%,但训练吞吐没有同步上升,查下来发现部分卡因为温度墙自动降频,实际运行功耗只有TDP的70%。没有DCGM和nvidia-smi dmon的逐卡监控,你根本发现不了这种"偷偷省力"的卡。第三个坑是PUE被厂商宣传误导。签约时机房说PUE 1.15,实际跑起来因为部分机柜闲置,冷却机组在小负载下效率很差,全年算下来PUE接近1.4,电费凭空多出25%。签约前一定要看对方真实的历史PUE曲线,而不是看宣传册上的数字。
5.2 能效问题快速排查清单
我把日常最常用的排查项整理成一张速查表:
| 现象 | 排查手段 | 常见原因与对策 |
|---|---|---|
| GPU利用率高但MFU低 | 做NCCL带宽测试、看通信占比 | 网络或PCIe瓶颈,升级互联或调整并行策略 |
| 训练速度突然变慢 | nvidia-smi -q查温度、功耗、频率 | 温度墙降频,清理风道或降低PUE |
| 整柜电费异常上涨 | 核对DCGM功耗日志和机柜PDU读数 | 存在空闲GPU未休眠,补调度策略 |
| 推理延迟没降但功耗高 | nvidia-smi -pl设功率上限 | 对批量推理做power cap,能效提升明显 |
| 新任务频繁中断重启 | 检查供电余量、UPS负载 | 瞬时功耗超限,预留30%以上供电余量 |
这套清单不需要昂贵工具,nvidia-smi、DCGM、ipmitool、机柜PDU自带的功率计,基本能把九成问题定位出来。关键是养成习惯:每周看一次功耗趋势,每月做一次能效复盘。
5.3 一些能长期受益的习惯
最后分享几个我坚持了很久的做法。第一,维护一张"能效台账":每天记录训练任务消耗的GPU·天、耗电量和有效token产出,算出一个"每度电token数"的指标,它会逼着你在每一次架构调整后量化对比,而不是靠感觉。第二,给所有GPU设置合理的功率上限:训练卡可以放开,推理卡和低优先级任务一律power cap,收益立竿见影。第三,不要盲目追新卡,每张卡先跑一遍微基准,测出它在你的任务负载下的真实每瓦算力,再决定要不要采购。我在引入RTX Pro 5500这类工作站卡前,就在自己的微调任务上对比过它的能效比,发现比同价位旧旗舰高出一截,才敢推荐团队换。
说起来,我这些年从"堆卡"到"算能耗",最大的转变是意识到一件事:AI基础设施的战争,最后会变成一度电产出多少token的战争。算力危机的本质是能效危机,这句话不是口号,而是每个月电费账单、每次硬件选型、每场集群扩容会议里反复验证过的现实。如果你看完这篇文章只记住一个动作,我希望是:从今天开始,给你的训练任务建一张"算力/能耗台账",把GPU·天、耗电量、有效token三列数据记下来。三个月后再回看,你会感谢自己现在做的这一步。未来真要扩集群,也请先拿这些账本数字说话,再决定要不要下单买卡。