☰
算力危机的本质是能效危机:GPU选型与集群架构的节能之道
2026/10/3 4:29:12 网站建设 项目流程

最近和几个做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 3090Ampere消费级约71 TFLOPS350W约0.20个人尝鲜、廉价跑批
A100 80GAmpere数据中心约312 TFLOPS400W约0.78上一代训练主力
H100 SXMHopper数据中心约495 TFLOPS700W约0.71大模型训练主力
RTX Pro 5500Blackwell工作站新一代架构,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 一个可以直接照抄的估算模板

我把这个流程整理成五步模板,你直接往上套就行:

  1. 定参数量和token数,用6ND算出总FLOPs。
  2. 选卡,查官方算力和TDP,估算一个现实MFU(训练用0.4到0.5,推理用0.2到0.4)。
  3. 算单卡每日有用算力=算力×86400×MFU。
  4. 用总FLOPs除以单卡每日产能,得到GPU·天。
  5. 用GPU·天乘以24小时、乘以单卡功耗、乘以PUE,得到总耗电。

我拿7B/2T这个任务分别套H100、A100、RTX 3090三种方案,假设都在一个组织靠谱的机房里、PUE取1.2,结果是这样的:

方案卡数预计训练耗时IT负载功耗总耗电量(含PUE 1.2)
H100256卡约17天约180kW约88MWh
A100256卡约27天约102kW约79MWh
RTX 3090512卡约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三列数据记下来。三个月后再回看,你会感谢自己现在做的这一步。未来真要扩集群,也请先拿这些账本数字说话,再决定要不要下单买卡。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询