GB300 NVL72 性能超 H200 七倍这类标题在 AI 基础设施群和算力选型讨论里传播得很快。做大模型训练的人看到后第一反应通常是“换掉现有 H200 集群训练时间是不是能缩短到七分之一”做推理服务的人会想“token 成本能不能降到这个量级”。现实情况要复杂一些。这里的 GB300 不是消费级显卡而是英伟达面向数据中心场景的 Blackwell Ultra 方案NVL72 表示一个 NVLink 域里最多可以放进 72 个 GPU。七倍这个数字如果成立通常也只会在特定模型、特定输入规模、特定并行策略和特定软件版本下成立不能直接推广到所有业务。这篇文章围绕两个问题展开GB300 NVL72 比 H200 快在哪里以及这个“七倍”应该怎么验证、怎么排查、怎么落地。理解这一点比记住一个倍数更重要。1. 先把“7 倍”放回真实场景它衡量的是机架级系统不是单卡1.1 NVL72 是什么一台可以放进机柜的超级计算机传统 GPU 计算通常按“8 卡服务器”规划。一台 8 卡 H200 服务器内部用 NVLink 把 8 张卡连成一个小域服务器之间再通过 InfiniBand 或 RoCE 网络扩展。这样做的好处是硬件标准、部署灵活但坏处也很明显当模型规模大到需要跨服务器切分时GPU 之间通信要经过网卡、交换机和线缆延迟和带宽都比机内 NVLink 差一个量级。GB300 NVL72 改变了这种组织方式。它把 72 个 Blackwell Ultra GPU 和 36 个 Grace CPU 组合进一个 NVLink 域GPU 与 GPU 之间的通信不再依赖传统网卡和交换机而是直接走 NVLink 和 NVSwitch。从软件视角看它更像一台拥有 72 个加速器的大型计算机而不是一个普通机柜里的 9 台 8 卡服务器。NVL72 中的“72”指的就是 72 个 GPU。GB300 则是“Grace Blackwell Ultra”的缩写强调的是 Grace CPU 与 Blackwell Ultra GPU 组成的超级芯片。这套设计针对的是大模型时代的两个核心瓶颈显存容量不够以及跨节点通信太慢。1.2 7 倍通常来自哪类测试英伟达发布下一代产品时官方对比材料里的“倍率”通常不是 FLOPS 峰值倍率而是端到端应用倍率。也就是说它不会用“理论算力提升 2 倍”这种话去宣传而是直接告诉你在某个大模型训练或推理任务中新系统比旧系统快多少。GB300 NVL72 对比 H200 的 7 倍一般出现在大语言模型训练吞吐、推理吞吐或 token 总拥有成本这类对比中。这类对比非常依赖测试条件模型是稠密模型还是 MoE 模型。输入序列长度是多少。全局 batch size 是否同步放大。GPU 数量是 8 卡对比 72 卡还是 72 卡对比 72 卡。是否使用了 FP4、FP8 精度。是否用 TensorRT-LLM、vLLM、SGLang 等框架做了针对性优化。如果这些条件不确定只凭“7 倍”做采购决策很容易在验收时出现巨大落差。1.3 最容易误读的一句话最容易误读的地方在于这个 7 倍不是“单卡 GB300 比单卡 H200 快 7 倍”而是“整个 NVL72 机架系统比某个 H200 基线快 7 倍”。单卡 Blackwell Ultra 的显存带宽大约是 H200 的 1.7 倍左右算力提升也达不到 7 倍。如果把对比范围缩小到单个 GPU、单个 kernel或者一个很小的模型上7 倍通常并不存在。真正让 7 倍成立的是 72 卡 NVLink 域带来的显存总量、通信带宽和并行策略空间。注意做方案对比时要先确认基线。基线是“一台 8 卡 H200 服务器”还是“9 台 8 卡 H200 服务器组成的 72 卡集群”结果会完全不同。2. 从 H200 到 GB300 NVL72硬件层面发生了什么2.1 GPU 规格变化显存与带宽才是关键H200 本质上是 H100 的显存增强版本显存从 H100 的 80GB HBM3 提升到 141GB HBM3e带宽也提升到约 4.8TB/s。它解决的问题很直接让大模型参数和 KV Cache 更容易装进单卡显存从而减少模型并行和 CPU 卸载。GB300 用的 Blackwell Ultra GPU在公开资料中通常被认为是约 288GB HBM3e、约 8TB/s 带宽。显存容量是 H200 的约 2 倍带宽是约 1.7 倍。这个差距很大但还不足以解释 7 倍。表格中的数值用于理解对比逻辑实际采购前一定要以官方规格书和测试环境为准对比项H200GB300 NVL72公开资料口径架构HopperBlackwell Ultra单卡显存141GB HBM3e约 288GB HBM3e单卡显存带宽约 4.8TB/s约 8TB/sGPU 规模8 卡/节点72 卡/NVLink 域整机显存规模8 卡约 1.1TB72 卡合计约 20TB 以上机内互连8 卡 NVLink72 卡 NVLink NVSwitch数据格式FP16/FP8 为主增加 FP4 等更低精度加速单卡规格决定了“一个模型能不能放进去”整机规格决定了“一个超大模型能不能在一个低延迟域内跑起来”。2.2 互连变化NVLink 域从 8 卡变成 72 卡H200 时代一个节点内 8 张卡可以通过 NVLink 高速通信但节点之间只能走 InfiniBand 或 RoCE。做 70B 参数模型训练时很多人习惯用 8 卡张量并行再往上的模型就不得不引入流水线并行、数据并行或者跨节点的专家并行。跨节点通信一旦出现吞吐就会明显下降。GB300 NVL72 则把 72 个 GPU 放进同一个 NVLink 域GPU 之间通过 NVSwitch 组成非阻塞交换网络。对大模型来说这意味着张量并行可以扩展到更大的 GPU 规模。专家并行中的 all-to-all 通信不再频繁越过网卡。流水线并行可以切得更细pipeline bubble 更小。显存可以按需聚合模型和数据更容易塞进高带宽域内。“8 卡高速互连”和“72 卡高速互连”看起来只是数字变大实际上改变了并行策略的设计空间。很多 7 倍收益来自这里。2.3 机架级显存总量大模型能不能放得下大模型训练和推理对显存的需求不是“参数大小”这么简单。训练时还要保存梯度、优化器状态和中间激活推理时要保存 KV Cache。序列长度一长KV Cache 会暴涨。72 张 H200 的总显存大约是 10TB但通信要跨节点GB300 NVL72 的总显存超过 20TB而且这些显存处于同一个 NVLink 域内。显存总量大约只有 2 倍差距可用的“低延迟可访问显存量”差异远不止 2 倍。以长上下文推理为例假设一个模型需要 4TB 的 KV CacheH200 8 卡节点只有 1.1TB 显存必然要跨节点切分。H200 72 卡集群虽然总量够但 KV Cache 的 all-to-all 通信会让吞吐下降。GB300 NVL72 可以把 KV Cache 放在同一个 NVLink 域内GPU 之间读取更快吞吐自然更高。这才是“显存大”和“显存又大又能快速访问”之间的本质区别。3. 为什么不是所有任务都能得到 7 倍3.1 训练场景7 倍依赖并行策略能否吃到 NVLink大模型训练性能不等于 GPU 算力乘上 GPU 数量。模型越大通信占比越高最终吞吐越依赖互连。NVL72 的优势主要体现在通信密集的训练模式上。在稠密模型训练中张量并行每层计算后都要做 all-reduce。H200 节点内 8 卡 NVLink 很快但跨节点张量并行会非常痛苦所以通常只能把张量并行限制在 8 卡以内。GB300 NVL72 允许把张量并行扩展到几十张卡对于超大稠密模型这会显著减少其他并行维度带来的通信开销。在 MoE 模型训练中token 需要被路由到不同专家GPU 之间要做大量 all-to-all 通信。H200 集群中跨节点 all-to-all 会打满网卡GB300 NVL72 中这部分通信可以直接走 NVLink。MoE 模型越稀疏专家数量越多NVL72 的优势越明显。如果你的业务是小模型、小 batch、短序列通信压力不大7 倍很可能缩水成 1.5 到 2 倍。3.2 推理场景长上下文和 MoE 的优势更明显推理性能受三个因素影响显存容量、显存带宽、batch size。短请求、低并发场景下GPU 主要受加载权重和计算延迟限制单卡带宽和显存提升能带来一部分收益但不会出现 7 倍。长序列、高并发场景下KV Cache 占用大量显存吞吐需要大 batch 才能打满这时候显存总量和带宽就非常关键。MoE 推理同样受益。H200 集群跑 MoE 模型时专家分布在不同节点上请求路由会引发密集跨节点通信GB300 NVL72 能把专家尽量放在同一个 NVLink 域路由开销大幅下降。场景越接近这些特征7 倍越有可能接近。3.3 软件与精度用 FP4 比 FP8 得到的倍率会被放大Blackwell 架构对低精度计算做了强化FP4、FP8 等数据格式的吞吐远高于传统 FP16/BF16。官方宣传中的倍率如果使用了 FP4而你的业务模型为了保证精度只能跑 FP8 或 BF16倍率就会明显下降。另外框架版本也很关键。同样的 NVL72 硬件用原生 PyTorch 和用 TensorRT-LLM 优化过的推理引擎吞吐差距可能超过 50%。7 倍成绩往往是在软件栈已经完成适配的情况下跑出来的不是插上电源就能复现。注意宣传数据里的“7 倍”默认已经使用了匹配新架构的软件栈。直接用旧代码迁到新硬件通常只能吃到硬件升级带来的小头收益。4. 用可复现的步骤验证“七倍”4.1 先确定测试口径和基线验证性能前至少要明确这几个问题对比对象是单台 H200 服务器还是 72 卡 H200 集群。测试模型是什么参数量多少稠密还是 MoE。输入输出序列长度是多少。batch size 是否按 GPU 数量等比放大。精度是 FP16、BF16、FP8 还是 FP4。是否使用相同版本的 CUDA、PyTorch、NCCL、TensorRT-LLM。建议把这些参数写进测试文档。后续排查性能差异时第一步就是回头检查这些条件是否一致。4.2 用 nvidia-smi 检查硬件状态和 NVLink 拓扑先确认 GPU 是否真正以预期拓扑运行避免“排名靠前但通信没绑定到 NVLink”的问题。# 查看 GPU 名称、显存、利用率 nvidia-smi # 每 5 秒输出一次功耗、温度、显存和利用率 nvidia-smi --query-gpuindex,name,power.draw,temperature.gpu,utilization.gpu,memory.used --formatcsv -l 5 # 检查 NVLink 链路状态 nvidia-smi nvlink -s # 查看 GPU 之间的拓扑关系 nvidia-smi topo -mnvidia-smi topo -m会显示 GPU 之间是 NVLink、NVSwitch 还是 PCIe 连接。如果 NVL72 环境中出现了大量 PCIe 连接说明驱动、BIOS、NVLink 链路或者硬件插槽没有正常工作。nvidia-smi nvlink -s的输出会列出每张 GPU 的 NVLink 链路状态。所有链路应该显示 Active。如果出现 Inactive 或 Unknown通信性能会大幅下降。4.3 跑 NCCL 通信基准确认互连是瓶颈还是硬件没绑定好通信基准比业务代码更容易暴露拓扑问题。以 NCCL 自带测试为例# 老版本 NCCL-tests 的常见位置 mpirun --allow-run-as-root -np 8 -H host1:8 \ /opt/nccl-tests/build/all_reduce_perf \ -b 128M -e 8G -f 2 -g 1 -n 100如果你要验证 NVL72 的 72 卡 NVLink 域可以改成mpirun --allow-run-as-root -np 72 -H gb300-host:72 \ /opt/nccl-tests/build/all_reduce_perf \ -b 128M -e 8G -f 2 -g 1 -n 100运行后重点关注busbw也就是总线带宽而不是algbw。busbw 偏低说明 GPU 之间的数据搬运没有充分使用 NVLink这时候要回到拓扑检查。4.4 跑代表性模型训练或推理基准通信基准正常后还要跑你的业务代表模型。下面是一个示例训练命令实际参数以自己的训练脚本为准torchrun --nproc_per_node8 train.py \ --model-name llama-70b \ --global-batch-size 1024 \ --max-seq-len 4096 \ --mixed-precision bf16如果迁移到 NVL72并且使用 72 卡 NVLink 域命令可能变成torchrun --nproc_per_node72 train.py \ --model-name llama-70b \ --global-batch-size 9216 \ --max-seq-len 4096 \ --mixed-precision bf16这里的关键不是把nproc_per_node从 8 改成 72而是要把全局 batch size 同步放大。GPU 数量增加后如果 batch size 不变单卡利用率会不足性能倍率也会偏低。推理侧可以用 vLLM、SGLang 或 TensorRT-LLM 跑同一模型同一输入长度。要分别测试短序列、长序列、低并发、高并发四组场景因为结果可能差异很大。4.5 记录环境、参数和日志每次测试都要记录驱动版本和 CUDA 版本。PyTorch、NCCL、vLLM 或 TensorRT-LLM 版本。模型参数量、精度、并行策略。输入长度、输出长度、batch size。GPU 功耗是否被限制。是否开启 graph capture、continuous batching 等优化。测试结果建议至少跑 3 次取中位数或均值。单次测试容易受 CPU 调度、存储抖动、网络拥塞影响不能作为性能结论。5. 从 H200 集群迁移到 GB300 NVL72 的成本与约束5.1 电力、散热和机房承重高性能 GPU 机柜的功耗和散热要求远高于普通服务器。NVL72 级别的整机柜方案通常需要液冷支持普通风冷机房很难直接承载。迁移前要确认单机柜供电能力是否满足峰值功耗。是否有预留余量避免瞬间功耗导致掉电。液冷管路、流量、温度和压力是否满足设备要求。机房承重是否允许单柜重量。UPS 和备用电源是否覆盖整柜峰值负载。如果机柜无法满足液冷和供电要求即使硬件到位也无法稳定运行。5.2 网络和存储同步升级NVL72 减少的是机柜内部 GPU 之间的通信压力但它并不代表不需要外部网络。如果业务要扩展到多个 NVL72 机柜机柜之间仍然需要 InfiniBand 或高速以太网互连。模型 checkpoint 动辄数 TB训练中断恢复时要快速读取加权写入存储系统必须有足够的聚合带宽。具体规划时建议确认机柜之间需要多少端口和带宽。存储目标是 20GB/s 还是 100GB/s 以上。checkpoint 写入是否会影响训练迭代时间。是否配置了多副本或 RAID 保护。5.3 依赖、容器和框架适配新架构需要新驱动、新 CUDA、新 cuDNN、新 NCCL。旧容器不一定能在新硬件上直接运行。常见迁移路径是先把训练脚本跑在单卡和单机环境确认基础依赖兼容。再跑通信测试确认多卡链路正常。再跑小模型全流程确认精度和收敛符合预期。最后再扩展到目标规模。在框架适配完成前不要直接用生产业务做大规模压测否则容易把“框架不兼容”误判成“硬件性能差”。5.4 人才与运维机制NVL72 是大型单体系统故障爆炸半径比 8 卡服务器更大。单机柜内 72 卡如果出现 NVSwitch 或液冷故障影响范围可能非常大。运维上至少需要准备监控 GPU 温度、功耗、NVLink 链路和液冷状态。异常节点隔离机制。高频 checkpoint 和快速恢复流程。硬件厂商支持服务和备件响应时间。没有运维能力时追求单柜性能意义不大。6. 常见误读与排查路径6.1 “标称 7 倍实际只有 2 倍”该查什么现象可能原因检查方式处理建议官方标称 7 倍实测不到 2 倍对比基线完全不同确认 H200 基线是 8 卡还是 72 卡重新按“同 GPU 数量、同模型、同精度”对比实测远低于预期当前任务通信占比低用通信基准测试和 kernel profile 确认选择更合适的工作负载或降低预期长上下文推理依旧很慢KV Cache 未分配到 NVLink 域内检查模型并行策略和显存分布使用专家并行、长上下文优化和更好的调度器小 batch 性能提升极小GPU 未打满查看利用率、功耗、kernel 耗时增大 batch size 或开启 continuous batching精度一高性能就下降官方倍率使用了 FP4检查测试精度和数据格式确认业务是否能用 FP4/FP8否则按实际精度验收排查顺序建议为输入配置 - 驱动版本 - NVLink 拓扑 - 网络拓扑 - 并行策略 - 框架优化 - 功耗限制。不要一上来就怀疑硬件。6.2 “显存够大为什么还 OOM”显存总量大不代表单任务一定能用到全部显存。常见原因包括没有打开显存复用多 batch 之间出现显存碎片。KV Cache 没有启用分页管理。CPU 优化器状态仍然占大量显存。模型并行方式不正确导致同一份权重在多卡重复加载。排查时先看nvidia-smi中每张卡的显存使用再看torch.cuda.memory_summary()或 PyTorch Profiler。如果显存碎片化严重可以适当减少 batch size、缩小编译缓存或者启用 KV Cache 分页。6.3 “NVL72 是不是不用再买高速网络”不是。NVL72 解决了“72 卡以内”的通信问题但如果你需要 144 卡、288 卡甚至更大的集群机柜之间仍然需要高速网络。而且多机柜环境下NVL72 的高吞吐会让外部网络更容易成为瓶颈。建议在规划时画一条数据流训练数据读取、模型同步、专家路由、checkpoint 写入。每一个环节都可能是瓶颈不能只盯着 GPU 和 NVLink。7. 选型建议与上线前检查清单7.1 更适合 GB300 NVL72 的场景训练或推理 1B 以上参数级别的稠密模型。推理长上下文场景KV Cache 非常大。MoE 模型专家数量多路由通信频繁。单体机房具备液冷能力希望用高密度降低总拥有成本。团队有框架适配能力愿意投入时间优化并行策略。这类场景里NVL72 的显存总容量、NVLink 域规模和低延迟通信能力会共同产生收益。7 倍不是必然但方向是对的。7.2 暂时继续用 H200 的场景业务模型很小单卡或单节点即可满足。业务 latency 要求极高需要分散部署。机房没有液冷和足够的单柜供电能力。现有 H200 集群利用率偏低采购 NVL72 会增加更重的运维负担。团队不打算修改代码也没有能力做框架适配。这时候 H200 仍然是稳定、成熟、可快速交付的方案。7.3 上线前性能验收清单检查项检查内容合格标准硬件状态GPU 名称、显存、驱动、NVLink 链路全部 Active无降速供电散热功耗、温度、液冷流量满载时温度不超规格功耗无异常抖动通信基准NVLink 域内 NCCL all_reduce busbw接近该架构预期带宽软件版本CUDA、PyTorch、NCCL、框架版本与测试环境一致并记录模型吞吐代表模型同精度、同输入长度多次测试后取稳定中位数长尾场景短序列、长序列、低并发、高并发分别记录不混在一起故障演练模拟单卡或 NVSwitch 故障能隔离、能恢复 checkpoint成本测算每 token 或每训练步的功耗和机房成本用真实数据计算而不是只看倍率做选型判断时建议把“7 倍”当成一个起点而不是终点。单卡规格决定显存和带宽能否支撑模型NVLink 域规模决定通信密集型并行策略能否落地软件优化空间决定最终倍率能否接近标称值。对现有 H200 集群先做一次压测记录基线再用同一套口径评估 GB300 NVL72比直接套用 7 倍更可靠。