返回 文章 学习 CMS 文章

H100 vs GB200 NVL72 训练基准测试:功耗、TCO 与可靠性深度分析

H100 与 GB200 NVL72 的全面对比,揭示 Blackwell 在能效和 TCO 上的潜力与可靠性短板。

H100GB200 NVL72训练基准测试TCO
成长分 / 100 70 综合收获、行动、留存与影响

H100 vs GB200 NVL72 训练基准测试:功耗、TCO 与可靠性深度分析
为什么值得读了解 H100 和 GB200 NVL72 在训练基准测试中的真实性能差异,包括 MFU、TCO 和每 Token 能耗。

掌握 GB200 NVL72 当前面临的可靠性问题及其对大规模训练的影响。

关键洞察
  1. GB200 NVL72 的每 GPU 总拥有成本(TCO)约为 H100 的 1.6 倍,需要至少 1.6 倍性能优势才能胜出。
  2. H100 集群通过软件优化,GPT-3 175B 训练的 BF16 MFU 在 12 个月内从 34% 提升至 54%,吞吐量提升 57%。
  3. GB200 NVL72 的 NVLink 铜背板可靠性差,缺乏有效诊断工具,目前无法用于大规模前沿模型训练。
转成行动

深入阅读

正文与原文对照

原文保真覆盖:全文原文字符:20104

H100 vs GB200 NVL72 训练基准测试 - 功耗、TCO 和可靠性分析,软件随时间改进

每 Token 焦耳数、每百万 Token 的 TCO、MFU、每户美国家庭年能耗对应的 Token 数、DeepSeek 670B、GB200 不可靠性、背板停机时间

前沿模型训练已将 GPU 和 AI 系统推向极限,使得成本、效率、功耗、每 TCO 性能以及可靠性成为有效训练讨论的核心。Hopper 与 Blackwell 的比较并不像英伟达让你相信的那么简单。

在本报告中,我们将首先展示超过 2000 块 H100 GPU 的基准测试运行结果,分析模型算力利用率 (MFU)、总拥有成本 (TCO) 以及每训练 100 万 Token 的成本数据。我们还将讨论能源使用情况,检查每个训练 Token 消耗的公用事业焦耳数,并将其与美国家庭年均能耗进行比较,从社会角度重新审视能效。我们还将展示将 GPU 集群从 128 块 H100 扩展到 2048 块 H100 以及在不同版本的英伟达软件下的分析结果。

在本报告后面,我们还将分析 Llama4 400B MoE 和 DeepSeek 670B MoE 的 GB200 NVL72 基准测试结果,并将这些数据与我们之前从 H100 获得的结果进行比较。我们将讨论一旦考虑可靠性问题,GB200 NVL72 的每美元性能优势是否仍然存在。

由可靠性差导致的停机时间和工程时间损失是我们将在每 TCO 性能计算中捕获的主要因素之一。目前,由于软件仍在成熟且可靠性挑战尚未解决,GB200 NVL72 上尚未进行大规模训练运行。这意味着英伟达的 H100 和 H200 以及谷歌 TPU 仍然是目前成功用于完成前沿规模训练的唯一 GPU。就目前而言,即使是前沿实验室和 CSP 中最先进的运营商也还无法在 GB200 NVL72 上进行大规模训练运行。

话虽如此,每个新架构自然都需要时间让生态系统提升软件以有效利用该架构。GB200 NVL72 的软件成熟速度略慢于前几代,但相差不大,我们相信在今年年底之前,GB200 NVL72 的软件将有显著改进。结合前沿模型架构与更大规模扩展域世界大小的协同设计,我们预计到今年年底,使用 GB200 NVL72 将带来显著的效率提升。

在可靠性方面,英伟达必须与合作伙伴更紧密合作以快速解决重大挑战,但我们认为生态系统将迅速集中资源应对这些可靠性挑战。

SemiAnalysis 正在招聘

我们正在寻找一名新毕业的工程师加入我们的工程团队。这是一个独特的机会,可以在许多行业领袖和 CEO 的支持下从事高知名度的特殊项目。如果你对性能工程、系统可靠性充满热情,并希望在硬件和软件的交汇处工作,这是一个难得的产生行业影响的机会。

你将从事的工作:

跨多个供应商(AMD、NVIDIA、TPU、Trainium 等)构建和运行大规模基准测试

设计可复现的 CI/CD 管道以自动化基准测试工作流程

确保行业合作伙伴使用的系统的可靠性和可扩展性

什么

我们正在寻找:

扎实的 Python 技能

站点可靠性工程(SRE)或系统级问题解决背景

CI/CD 流水线和现代 DevOps 实践的经验

对 GPU、TPU、Trainium、多云和性能基准测试的好奇心

申请链接:https://app.dover.com/apply/SemiAnalysis/2a9c8da5-6d59-4ac8-8302-3877345dbce1

基准测试与分析方法论

在我们的基准测试和分析中,我们依赖 NVIDIA 的 DGXC 基准测试团队在 NVIDIA 内部 H100 EOS 集群上执行的新 DGX Cloud 基准测试脚本,该集群配置了 8×400 Gbit/s InfiniBand 网络。这些结果作为官方参考数字,用于在 Neocloud 与其客户定义服务级别协议(SLA)时与 Neocloud 环境进行比较。

云服务商也可以向 NVIDIA 提交基准测试结果,如果能够达到这些 EOS 参考数字,则可以获得 NVIDIA Exemplar Cloud 称号。我们即将推出的 ClusterMAXv2 在评估服务质量时将重点考虑提供商的 Exemplar Cloud 状态,因为该状态是对提供商能够在大规模 GPU 部署中跨多种工作负载提供参考性能表现的认可。

上述基准测试使用 NeMo Megatron-LM 进行,但考虑到许多 GPU 最终用户并不完全依赖 NeMo Megatron-LM,DGXC 基准测试团队计划将覆盖范围扩展到原生 Torch DTensor 框架,如 TorchTitan。

我们要感谢 NVIDIA DGCX 基准测试团队创建了这些基准测试集并提供参考数字,以帮助提升 GPU 云行业!

H100 和 GB200 NVL72 的资本支出、运营支出与总拥有成本分析

过去 18 个月中,H100 服务器的价格有所下降,每台服务器约为 19 万美元。包括存储、网络和其他项目,典型超大规模云服务商的每台服务器前期总资本支出为 25 万美元。

对于 GB200 NVL72,典型超大规模云服务商的机架级服务器本身成本为 310 万美元。包括网络、存储和其他项目,每个机架的总成本约为 390 万美元。

在比较所有三种买家类型(从超大规模云服务商到 Neocloud 巨头再到新兴 Neocloud)时,GB200 NVL72 的每 GPU 总资本支出约为 H100 的 1.6 到 1.7 倍。

比较两个系统的运营拥有成本,我们发现 GB200 NVL72 的每 GPU 运营支出并不比 H100 高太多。成本差异源于 GB200 NVL72 的每 GPU 总功耗高于 H100。这主要是由于 GB200 芯片每芯片功耗为 1200W,而 H100 为 700W。

在综合考虑资本支出和运营支出以得出总拥有成本(TCO)时,我们看到 GB200 NVL72 的 TCO 约为 H100 的 1.6 倍。这意味着 GB200 NVL72 需要比 H100 快至少 1.6 倍,才能在每 TCO 性能方面相对于 H100 具有优势。

NVIDIA 可以为机器学习社区做得更好的三件事

在深入探讨基准测试和结果之前,我们向 NVIDIA 提出三个关键建议。

首先,我们建议 NVIDIA 扩大基准测试工作并进一步提高透明度。为了让 NVIDIA 持续提升整个 GPU 云行业的水平,它需要在其超大规模云服务商合作伙伴和 NVIDIA 云合作伙伴中进行基准测试。

rs(NCPs)并将数据公开。这样,机器学习社区的任何人都可以在签署价值数千万或数亿美元的合同之前,将基准测试数据纳入他们的决策过程。

例如,在我们首次发布的ClusterMAX评级系统中,我们指出,GCP较旧的a3-mega H100在O(Llama 70B)规模训练中的MFU比平均水平低10%,在O(8x7B)混合专家稀疏模型的MFU中比平均水平低15-20%。因此,最终用户应向GCP支付比平均租赁成本低10-20%的费用,才能获得与市场平均水平相同的每美元性能。拥有跨超大规模云和NCP提供商的公开基准测试结果集,将极大地提高谈判公平合同价格的便利性,并加快决策速度。这可以通过避免进行广泛、昂贵且耗时的概念验证运行,为双方节省大量时间和金钱。

我们对Nvidia的第二条建议是,将基准测试重点扩展到NeMo-MegatronLM之外,因为许多用户更喜欢使用带有FSDP2和DTensor的原生PyTorch,而不是NeMo-MegatronLM。使用NeMo-MegatronLM的一个优势是,在任何给定时间,NeMo-MegatronLM中有许多性能特性在原生PyTorch中尚不可用。最新的特性首先在NeMo-Megatron中推出是合理的,但所有这些特性最多应在一个月后上游到原生PyTorch。为此,应分配更多Nvidia工程师从事PyTorch核心开发,而不是负责向NeMo添加更多特性。Nvidia扩大基准测试重点应包括使用PyTorch的运行,这将与此计划完美契合。

与其让工程师优化NeMo,他们应该优化TorchTitan。新的NeMo AutoModel库是朝着正确方向迈出的一步,因为它除了支持Megatron-LM外,还支持原生PyTorch FSDP2后端,但明显缺少原生PyTorch的3D+并行与DTensor,并且许多预训练特性缺失,大多数特性用于微调。

我们的第三条建议是,Nvidia继续加速开发GB200 NVL72背板的诊断和调试工具。不幸的是,即使经过广泛的烧机过程,NVLink铜背板仍然不太可靠。GB200 NVL72的操作者也感叹,用于诊断和调试背板相关错误的工具落后且不理想,使问题更加复杂。Nvidia还可以通过坚持对其ODM/OEM合作伙伴进行更严格的验收测试,然后再将GB200 NVL72机架交付给客户,来改善这种情况。

GPT-3 175B Token/s/GPU,训练性能和功耗。2024年1月至2024年12月的成本改进

在下表中,我们展示了在不同时间点使用128个H100集群训练GPT-3 175B的基准测试结果。我们选择展示从2024年1月开始到2024年12月结束的不同NeMo-Megatron LM版本的结果,分别代表H100大规模部署开始后的一年和两年。

基准测试设置使用128个H100,4个数据副本。每个数据副本由32个GPU组成,每层使用NVLink域跨4个GPU进行张量并行(即TP=4),然后进行流水线并行。有人可能认为最好使用d

o 对于H100,TP=8以匹配整个NVLink域的世界大小(8个GPU),但对于GPT-3 175B模型,使用TP=4更好,因为这样算术强度更高。

详细说明,GPT-3 175B的隐藏维度是12,288,这意味着如果使用TP=8,结果将是较小的K归约维度1,536。相比之下,使用TP=4时,隐藏归约维度将为3,072。

基准测试的序列长度遵循原始GPT-3论文的设置,使用2,048的序列长度以及256个样本的全局批次大小。这意味着模型在每个优化器步骤之前将看到500k(全局批次大小 * 序列长度)个token。

在BF16模型浮点运算利用率(MFU)方面,我们看到在12个月内从34% MFU显著提升到54% MFU,这意味着仅通过CUDA软件栈的改进,训练吞吐量就提高了57%。这一改进得益于NVIDIA CuDNN/CuBLAS工程师编写了更优化的融合wgmma内核,NCCL工程师编写了更优化的集合通信(使用更少的SM进行通信)以及其他改进。归根结底,完整的软件栈优化才是关键。

FP8 MFU也呈现出同样的趋势,在同一时间段内从29.5% MFU提升到39.5% MFU,仅通过软件改进就实现了34%的吞吐量提升。

谈到成本,假设每GPU每小时1.42美元(不包括任何租赁利润),我们看到使用FP8训练GPT-3 175B的成本从2024年1月的每百万token 72美分下降到2024年12月的每百万token仅54.2美分。这意味着,使用原始训练token数300B训练GPT-3 175B的成本从2024年1月的21.8万美元改善到2024年12月的仅16.2万美元。

最后,我们考察训练GPT-3的功耗。我们估算了128个H100集群的总功耗,包括GPU、CPU、网络、存储和其他组件。然后,我们根据典型托管数据中心的电能使用效率(PUE)对其进行调整,得出每个token的总能耗(焦耳)。

作为对高中物理的不愉快回忆,焦耳是能量单位,相当于1牛顿的力使物体沿力的方向移动1米所做的功。点亮一个60W的白炽灯一秒钟消耗60焦耳(瓦特(W)是每秒能耗单位),每小时消耗216千焦。另一种表示能量单位的方式是使用瓦时或千瓦时,即设备的功率乘以使用的小时数。2022年美国平均每户家庭年能耗为10,791千瓦时,约合38,847,600,000焦耳。将10,791千瓦时除以每年8,760小时,得到平均功率1,232瓦——略高于单个GB200 GPU使用的1,200瓦!

我们看到,使用2024年12月版本的NVIDIA软件,每个token训练消耗2.46焦耳(FP8)和3.63焦耳(BF16)。如果我们拥有相当于美国平均家庭年能耗的能源预算,我们可以训练158亿个FP8 token。进一步推算,在GPT-3 175B上训练300B个token需要19个美国家庭年能耗(FP8)和28个家庭年能耗(BF16)。

GPT-3的总训练成本16.2万美元和19个家庭的年能耗听起来并不算高,但这是许多实验和

许多失败的训练运行累积起来,导致了我们现在在美国看到的AI训练能源消耗的急剧增长。

弱扩展与强扩展

强扩展和弱扩展描述了在不同问题设置(例如不同批次大小)下扩展计算资源所带来的性能提升。

强扩展是指在保持模型大小和全局批次大小不变的情况下扩展计算资源。在这种情况下,可以使用阿姆达尔定律(描述通过并行化计算步骤所能获得的加速比)来量化强扩展的加速效果。

另一方面,弱扩展是指在恒定时间内扩展计算资源以解决更大的问题。AI训练本质上利用了弱扩展,因为你可以通过增加训练作业中使用的GPU数量来扩大模型大小和全局批次大小(取决于收敛性)。

Llama3 405B 的 Token/s/GPU、每百万Token成本、每Token焦耳数与GPU数量(弱扩展)

在此基准测试中,我们考察了随着集群中H100 GPU数量的增加,Llama3 405B的训练性能如何变化——这是弱扩展的一个例子。

在下表中,我们看到当GPU集群规模从576个H100增加到2,304个H100时,FP8 MFU和BF16 MFU在所有规模下分别保持在约43%和54%左右。在《Llama 3模型群论文》中发表的训练运行中,研究人员使用了16,000个H100来训练Llama 3 405B,使用类似的并行策略实现了41%的BF16 MFU用于预训练。请注意,上述预训练运行使用的序列长度为8192,而对于中训练上下文扩展,每个样本的序列长度为131,072而不是8,192。这种更长的序列长度需要跨16个节点进行上下文并行,导致MFU下降到38%,因为环形注意力需要额外的通信。

转向总训练成本,我们看到仅进行预训练运行,在15T个Token上训练Llama 3 405B,使用BF16在2,304个H100集群上训练时,每百万Token成本为1.95美元。这仅预训练阶段就累计达到2910万美元,远高于混合专家模型(如DeepSeek)——每次训练运行仅需500万美元。

当然,我们再次强调,这个成本反映的是单次最终成功训练运行的成本,以及达到最终阶段所需的多次实验成本,以及雇佣研究人员等成本。

由于Llama3 405B的总参数量大约是GPT3 175B的2.3倍,因此每个Token的总能耗(焦耳)Llama3 405B大约是GPT3 175B的2.3倍,分别为每个Token 8.8焦耳和3.6焦耳。

这意味着,用美国普通家庭一年的能耗,Meta可以在Llama3 405B上使用BF16训练44亿个Token。要使用15T个Token训练到收敛,Meta所需的能量相当于整个由3,400个美国家庭组成的社区的年消耗量。

Llama3 70B 训练性能:Token/s/GPU、每百万Token成本、每Token焦耳数与GPU数量(弱扩展)

接下来,我们考察不同集群规模下Llama3 70B的训练性能。当集群规模从64个H100增加到2,048个H100时,我们看到FP8的性能下降了10%,从64个GPU时的38.1%下降到2,048个GPU时的35.5%。非常有趣的是,MFU下降如此之多(按百分比计算——

考虑到较低的MFU基数,这才是真正重要的,因为随着规模扩大,每个数据副本的批次大小不变,并行策略也不变。所有运行仍然使用TP=4、PP=2和上下文并行=2——唯一的变化是增加了更多数据副本。有趣的是,对于BF16,MFU的下降幅度要小得多,仅为1-2%,从64块H100上的54.5% MFU下降到2408块GPU上的53.7%。

Llama3 405B比Llama3 70B大5.7倍,与任何密集模型一样,所需的FLOPs数量与参数数量成线性关系。因此,训练Llama 3 405B的成本应该是Llama 3 70B的5.7倍。实际上,在约2000块H100规模下,使用BF16时,Llama3 405B每百万token的成本是Llama3 70B的5.4倍。

在功耗方面,我们看到对于FP8,在2408块H100上训练每个token的能耗比在64块H100上高出10%。使用FP8在64块H100上训练Llama 3 70B达到收敛(15T token)所需的能量仅相当于440个美国家庭的年能耗,而在2048块H100规模下,所需能量相当于472个美国家庭的年能耗。

Llama3 8B训练性能随时间变化

像Llama3 405B和Llama3 70B这样的大型模型都使用张量并行、流水线并行和数据并行,但训练Llama3 8B只需要在NVLink域内的每对GPU之间对8192序列长度进行上下文并行,并使用数据并行将工作分散到其他GPU对。在本分析中,我们还考察了随时间变化的训练性能,以评估整个软件栈的改进对训练性能的影响。我们发现,从2024年11月到2025年4月,性能仅略有提升,后者距离Hopper开始大规模部署已整整23个月。

在下一节中,我们将深入探讨GB200 NVL72当前训练性能与H100训练性能的比较。我们将讨论训练DeepSeek 670B MoE和Llama4 400B MoE的基准测试,分析GB200相对于H100的总拥有成本(TCO)性能。

我们还将聚焦于前述GB200 NVL72缺乏有效诊断和调试工具的问题,并讨论导致GB200 NVL72不可靠的诸多问题。这些是NVIDIA、CSP、Neocloud以及前沿实验室的最终用户必须在年底前成功且经济高效地在GB200 NVL72上训练前沿模型所必须解决的挑战。