英伟达GB200 NVL72与H100,谁才是训练之王?
本文由半导体产业纵横(ID:ICVIEWS)编译自SemiAnalysis
迄今为止,H100 仍是平衡性能、成本和可靠性的最优选择。
尽管GB200 NVL72在理论上具备显著的性能潜力,但其当前可靠性缺陷与工具链不成熟导致实际每美元性能仍落后于H100。
前沿模型的训练已将GPU和AI系统推至绝对极限,这使得成本、效率、功耗、单位总拥有成本(TCO)性能以及可靠性成为高效训练讨论的核心议题。Hopper与Blackwell架构的对比并非如英伟达所宣称的那般简单。
本报告将首先呈现基于超过2000块H100 GPU的基准测试结果,分析模型浮点运算利用率(MFU)、总拥有成本(TCO)以及每训练100万token的成本数据。本文还将探讨能耗问题,测算每个训练token所消耗的实用焦耳能量,并将其与美国家庭年平均用电量进行对比,从而在社会化语境中重新审视能效意义。
可靠性不足导致的停机时间与工程时间损耗,是本文计算单位TCO性能时考量的核心因素。目前GB200 NVL72尚未完成大规模训练任务,因其软件尚待成熟且可靠性挑战仍在攻关中。这意味着英伟达H100、H200以及谷歌TPU仍是当前能成功完成前沿规模训练的唯一起作用方案。即便是最先进的前沿实验室和云服务提供商(CSP),目前仍无法在GB200 NVL72上实施超大规模训练。
值得注意的是,任何新架构自然需要时间让生态圈逐步完善软件以充分发挥其效能。GB200 NVL72的适配进度虽略慢于前代产品,但差距有限。本文确信,在今年年底前,GB200 NVL72的软件将得到显著改善。加之前沿模型架构在设计之初就考虑了更大规模的扩展需求,本文预计到年底时,采用GB200 NVL72将带来显著的效率提升。
在可靠性方面,英伟达仍需与合作伙伴紧密协作以快速攻克重大挑战,但本文相信整个生态圈将迅速整合资源应对这些可靠性难题。
基准测试与分析方法论
本文的基准测试与分析,采用英伟达DGXC基准测试团队最新的DGX云基准测试脚本,这些脚本在英伟达内部配备8×400 Gbit/s InfiniBand网络的H100 EOS集群上运行。测试结果将作为官方参考标准,新型云服务商在与客户定义服务级别协议(SLA)时,可据此比对自身环境性能。
云服务商也可向英伟达提交基准测试数据。若能达到EOS参考标准,即可获得"英伟达典范云"认证。本文即将推出的ClusterMAXv2评级体系将高度重视该认证——它标志着服务商具备在大规模GPU部署中为多种工作负载提供参考级性能的能力。
当前基准测试基于NeMo Megatron-LM框架开展,但考虑到众多GPU终端用户并不完全依赖该框架,DGXC基准测试团队计划扩展对原生Torch DTensor框架(如TorchTitan)的兼容支持。在此特别感谢英伟达DGXC基准测试团队开发这套基准测试体系并提供参考数据,为提升GPU云行业标准作出重要贡献。
H100与GB200 NVL72资本支出、运营成本及总拥有成本分析
过去18个月内,H100服务器单价已有所下降,目前约为19万美元/台。对典型超大规模供应商而言,包含存储、网络及其他组件的单服务器前期资本支出总计达25万美元。
而对于GB200 NVL72系统,仅机架级服务器本身的成本就达310万美元。包含网络、存储及其他组件后,单机架总成本约为390万美元。
从三类采购商(超大规模供应商、新型云巨头、新兴云服务商)的综合数据来看,GB200 NVL72的单GPU总资本支出约为H100的1.6至1.7倍。
在对比两个系统的总体拥有运营成本时,本文发现GB200 NVL72的单GPU运营成本(Opex)并未显著高于H100。成本差异主要源于GB200 NVL72的单GPU整体功耗高于H100,这主要是因为GB200芯片的单芯片功耗为1200W,而H100仅为700W。
若将资本性支出(Capex)与运营成本(Opex)共同计入总拥有成本(TCO)进行计算,可得出GB200 NVL72的TCO约为H100的1.6倍。这意味着,若要使GB200 NVL72在单位TCO性能表现上优于H100,其运行速度至少需达到H100的1.6倍。
英伟达可优化面向机器学习社区的三大方向
在深入分析性能基准与测试结果前,本文谨向英伟达提出三项关键建议:
首先,本文建议英伟达进一步扩大基准测试范围并提升数据透明度。为推动整个GPU云行业持续进步,英伟达需对超大规模合作伙伴(Hyperscaler)及英伟达云合作伙伴(NCP)进行全面基准测试,并将数据公开化。这将使机器学习社区在签署价值数千万乃至数亿美元合同前,能充分参考基准测试数据优化决策。
例如,在本文首期ClusterMAX评级报告中曾指出:谷歌云平台(GCP)旧款a3-mega H100集群在训练Llama 70B规模模型时,平均模型浮点利用率(MFU)低于行业均值10%;在训练8x7B混合专家稀疏模型时MFU差距扩大至15-20%。这意味着终端用户需争取比市场均价低10-20%的租赁费用,才能实现与行业平均水平持久的性价比。公开跨云服务商的基准测试结果将显著简化合同价格谈判流程,加速决策效率,并通过避免昂贵耗时的概念验证(POC)测试为双方节约大量资源。
第二项建议是拓展基准测试框架范围,不应局限于NeMo-MegatronLM。目前许多用户更倾向采用原生PyTorch(配合FSDP2与DTensor)而非NeMo-MegatronLM。虽然NeMo-MegatronLM能率先集成最新性能特性(这些功能往往暂未登陆原生PyTorch),但合理做法应是在最多一个月内将所有这些特性上游同步至原生PyTorch。为此,英伟达应将更多工程师资源配置到PyTorch核心开发而非NeMo功能叠加,同时将基准测试范围扩展至基于PyTorch的训练任务以形成战略协同。
相较于优化NeMo,英伟达更应聚焦TorchTitan的研发。新版NeMo AutoModel库支持原生PyTorch FSDP2后端(除Megatron-LM外)虽是正确方向,但明显缺乏对原生PyTorch DTensor三维并行及完整预训练功能的支持——现有功能仍主要偏向微调场景。
第三,本文建议英伟达加速完善GB200 NVL72背板的诊断与调试工具。目前即使经过严格老化测试,NVLink铜质背板的可靠性仍显不足。GB200 NVL72运维人员同时指出,落后的背板故障诊断工具加剧了这一问题。英伟达还应通过对ODM/OEM合作伙伴实施更严格的验收测试(再向客户交付GB200 NVL72机架)来改善现状。
下表展示了本文在128块H100组成的集群上,于不同时间点训练GPT-3 175B模型的基准测试结果。本文选取了从2024年1月至2024年12月多个不同版本的NeMo-Megatron LM框架运行数据,这段时间距离H100开始大规模部署分别约为一到两年。
基准测试采用128块H100 GPU,配置4个数据副本。每个数据副本由32块GPU通过并行化策略组成:每层的张量并行(TP=4)在4块GPU之间通过NVLink域执行,随后进行流水并行。尽管有人认为TP=8(匹配H100的NVLink全域8GPU规模)更为理想,但对于GPT-3 175B模型,TP=4能够实现更高的算术强度,因此是更优选择。
具体而言,GPT-3 175B的隐藏层维度为12,288。若采用TP=8,会导致Key维度的缩减尺寸过小(仅为1,536);而采用TP=4时,隐藏层的缩减维度可达3,072,显著提高了计算效率。
基准测试的序列长度遵循原版GPT-3论文设置,采用2,048的序列长度和256的全局批量大小。这意味着模型在每次优化器更新前会处理50万token(全局批量大小 × 序列长度)。
从BF16的模型浮点运算利用率(MFU)来看,在12个月内从34%显著提升至54%,训练吞吐量单凭CUDA软件栈的改进就实现了57%的提升。这一进步得益于NVIDIA CuDNN/CuBLAS工程师编写了更优化的融合wgmma内核,以及NCCL工程师开发出使用更少流多处理器(SM)完成通信的集体操作算法等多项优化。归根结底,软件全栈优化才是关键所在。
FP8的MFU也呈现相同趋势,同期从29.5%提升至39.5,仅通过软件优化就实现了34%的吞吐量增长。从成本角度分析,在假设单GPU成本为1.42美元/小时(不含租赁利润)的情况下,GPT-3 175B的FP8训练成本从2024年1月每百万token花费72美分,降至2024年12月的54.2美分。这意味着基于3000亿token的原训练数据量,总训练成本从2024年1月的21.8万美元下降至2024年12月的16.2万美元。
最后本文考察训练GPT-3的能耗情况。通过估算128块H100集群(含GPU、CPU、网络、存储等组件)的总功耗,并乘以典型托管数据中心的电能使用效率(PUE),本文得出每token消耗的总电能焦耳值。需要说明的是,焦耳是能量单位——1焦耳相当于用1牛顿的力使物体在力的方向上移动1米所做的功。点亮一盏60W白炽灯1秒消耗60焦耳(瓦特是每秒能耗单位),每小时耗能216千焦。另一种能量表述方式是千瓦时,即设备功率与运行时间的乘积。2022年美国家庭年均耗电10,791千瓦时(约38,847,600,000焦耳),按全年8,760小时计算,相当于平均持续功率1,232瓦——略高于单块GB200 GPU的1,200W功耗!
采用2024年12月版NVIDIA软件时,每训练一个token消耗2.46焦耳(FP8)和3.63焦耳(BF16)。若以美国家庭年均能耗为基准,可训练158亿FP8 token。进一步计算表明:训练3000亿token的GPT-3 175B模型,FP8精度需消耗19个家庭年用电量,BF16精度则需28个家庭年用电量。
虽然GPT-3的16.2万美元训练成本和19个家庭年能耗看似不多,但现实中大量实验与失败训练任务的累积,正是导致美国当前AI训练能耗急剧膨胀的根本原因。
弱扩展与强扩展
弱扩展(Weak Scaling)和强扩展(Strong Scaling)用于描述在不同问题设置(如不同批量大小)下扩展计算资源所带来的性能提升方式。
强扩展是指在保持模型规模和全局批量大小不变的前提下,通过增加计算资源来提升训练效率。此类扩展的性能提升可用阿姆达尔定律(Amdahl’s Law)进行量化,该定律描述了通过并行化计算步骤所能实现的理论加速比。
而弱扩展则是指在固定时间内通过扩展计算资源以求解更大规模的问题。人工智能训练本质上更依赖弱扩展,因为在实际训练中,可以通过增加GPU数量来扩展模型规模和全局批量大小(在收敛性允许的前提下),从而在相近的时间内处理更复杂的任务或更大规模的数据。
Llama3 405B 训练扩展分析:单GPU Token处理速度、每百万Token成本及单Token能耗与GPU数量的关系(弱扩展模式)
本次基准测试旨在探究Llama3 405B模型在扩展H100 GPU集群规模时的训练性能变化——这是弱扩展(Weak Scaling)的典型应用。
如下表所示,当GPU集群从576块H100扩展至2,304块H100时,FP8和BF16精度下的模型浮点运算利用率(MFU)分别稳定维持在43%和54%左右。在《Llama 3 模型集群论文》发布的训练任务中,研究者使用16,000块H100训练Llama 3 405B模型,采用类似的并行策略,在预训练阶段实现了41%的BF16 MFU。需要说明的是,上述预训练任务使用的序列长度为8,192,而在训练中期的上下文扩展阶段,每个样本的序列长度延长至131,072(而非8,192)。更长的序列需要跨16个节点进行上下文并行,由于环形注意力(ring attention)机制引入的额外通信开销,MFU降至38%。
从训练总成本的角度来看,若使用2,304块H100集群以BF16精度对Llama 3 405B进行预训练(训练量达15万亿token),每百万token的成本为1.95美元。仅预训练阶段的总成本就高达2,910万美元,显著高于混合专家模型(如DeepSeek每次训练仅耗资500万美元)。
需要强调的是,这一成本仅反映最终成功完成一次训练所需的直接计算开销,并未包含前期大量实验尝试、研究人员人力成本及其他间接投入。
就能耗而言,由于Llama 3 405B的参数规模约为GPT-3 175B的2.3倍,其单token训练能耗也同比增加:Llama 3 405B每token消耗8.8焦耳,而GPT-3 175B为3.6焦耳。这意味着,以一个美国家庭年均能耗为基准,Meta仅能用于训练44亿个Llama 3 405B(BF16精度)的token。若要完成15万亿token的收敛训练,所需能源相当于3,400个美国家庭一年的总用电量。
接下来,本文分析不同集群规模下Llama3 70B模型的训练性能表现。当集群规模从64块H100扩展到2,048块H100时,FP8精度下的模型浮点运算利用率(MFU)下降了10%,从64块GPU时的38.1%降至2,048块GPU时的35.5。这一下降幅度(以百分比计——考虑到MFU基数本身较低,百分比变化更具实际意义)颇为值得关注,因为尽管规模扩大,每个数据副本的批量大小并未改变,并行策略也保持一致。所有实验均采用TP=4、PP=2和上下文并行=2的配置,唯一的变动仅是增加了数据副本数量。
值得注意的是,BF16精度下的MFU下降幅度远小于FP8,仅降低了1-2%,从64块H100时的54.5%小幅下降至2,408块GPU时的53.7%。
Llama3 405B的参数量是Llama3 70B的5.7倍。对于这类稠密模型,所需浮点运算量(FLOPs)与参数量呈线性关系,因此理论上训练Llama3 405B的成本应为Llama3 70B的5.7倍。实际在约2000块H100的集群规模下,基于BF16精度训练时,Llama3 405B的每百万token成本约为Llama3 70B的5.4倍。
就能耗而言,FP8精度下,在2,408块H100上训练每个token的能耗比64块H100集群高出10%。若以64块H100训练Llama3 70B至15万亿token(FP8精度),所需能耗相当于440个美国家庭的年用电量;而将规模扩大至2,048块H100时,这一数字将增至472个家庭年用电量。
Llama3 8B训练性能随时间变化分析
与需同时采用块量并行、流水并行和数据并行的Llama3 405B/70B等大模型不同,Llama3 8B的训练仅需在NVLink域内每对GPU间针对8,192序列长度进行上下文并行,并在更多GPU对间采用数据并行扩展计算。本文还分析了其随时间变化的训练性能,以评估全栈软件优化带来的影响。从2024年11月至2025年4月(即Hopper架构大规模部署满23个月后),性能仅略有提升。
*声明:本文系原作者创作。文章内容系其个人观点,我方转载仅为分享与讨论,不代表我方赞成或认同,如有异议,请联系后台。