NVIDIA 示例云：释放 AI 基础设施全部性能的经验教训

由相同的 NVIDIA H100、GB200 NVL72 或 GB300 NVL72 系统构建的两个 AI 计算集群可以提供截然不同的训练吞吐量。在相同的工作负载、相同的模型、相同的全球批量大小上，我们通常会发现合作伙伴部署与相应的 NVIDIA 参考架构 (RA) 之间存在 8% 到 12% 的差距。

其原因通常是内核、hypervisor、BIOS 和 NVIDIA 集合通信库 (NCCL) 设置中的一系列配置选择，每项选择的成本仅为百分之几，而且这一差距足以错过 NVIDIA Exemplar Cloud 验证所需的 95% 值。

本文将介绍来自实际合作伙伴集群的四项调试调查。每次诊断都会隔离堆栈的不同层：NVIDIA Grace CPU 上的系统内存管理单元 (SMMU) 和分页表行为；基于 x86 的 CPU 上的电源管理和非统一内存访问 (NUMA) 放置；1.6 Tbps 网络上的 NVIDIA NCCL 队列对并发；以及无噪声硬件安装缺陷。博文还展示了 perf、NVIDIA Nsight Systems 或 NVIDIA NCCL 测试中指出根本原因的特定信号，以及弥合差距的调整变化。

已经运行这些基准测试的基础设施工程师和性能架构师可以从我们内部使用的这些诊断模式中受益，这些诊断模式用于在正式的 RA 验证之前针对自己的集群运行。

预备知识

要重现本文中的诊断结果，您需要：

采用 NVIDIA Quantum InfiniBand 或 RoCE 互连技术的 NVIDIA HGX H100、HGX H200、HGX B200、GB200 NVL72 或 GB300 NVL72 系统集群。
具有稳定迭代计时的分布式训练工作负载 – 基于 Llama 3 模型的NVIDIA NeMo、NVIDIA Nemotron 或 DeepSeek 配置可作为合理参考。
对至少一个节点进行根访问，以进行 perf、BIOS/ UEFI 更改和内核参数更改。
nccl-tests 基于训练堆栈使用的相同 NCCL 版本、NVIDIA Nsight Systems 和具有可用内核符号的 Linux 性能构建。

训练性能差距背后的常见模式

近期的 Exemplar 培训活动表明，性能差距很少源于一次明显的失败。更常见的情况是，它们来自只有在工作负载压力下才能看到的配置细节。一些反复出现的模式包括：

Grace 和虚拟化就绪：缺少平台功能、SMMU 开销、IOMMU 行为或与预期配置不匹配的页面大小设置。
CPU 功耗和进程布局：运行于低于预期 Turbo 频率的核心、放置在错误核心上的 rank 或辅助线程，或与平台拓扑不匹配的 NUMA/ PCT 绑定。
运行时拓扑：在节点上正确但在工作负载容器或启动器环境中缺失的主机拓扑文件或 NCCL 设置。
网络和集合行为：与目标网络、消息大小或训练工作负载规模不匹配的 NCCL 设置。
应用到平台的绑定：按核心 ID 或秩序 (而非拓扑感知相关性) 绑定训练进程。

这些并不是造成训练性能差距的唯一原因，而且检查它们并不能取代使用真实应用进行验证。

以下四个案例研究展示了这些模式在近期训练工作中的表现：暴露问题的信号是什么、发生了什么变化以及如何验证修复。顺序并非通用分类序列；正确的起点取决于工作负载、平台和第一个分析器信号。

案例研究 1：NVIDIA GB200 NVL72 FP8 预训练，在虚拟机 (VM) 中的运行速度比在 bare metal 上慢 12%

层：虚拟化和 SMMU

在 VM 内运行 DeepSeek-V3 多专家模型 (MoE) FP8 预训练的 GB200 NVL72 合作伙伴部署产生的迭代时间比 bare metal RA 长 12% 到 14%。Llama 3 70B 等密集模型的预训练方法仅在 3% 的 RA 性能范围内运行，而 DeepSeek-V3 MoE (每次迭代都会发布许多小内核) 则是异常情况。

在合作伙伴集群上捕获的 Nsight Systems 跟踪显示，对于工作负载的微小内核区域，CPU 开销显著增加。仅针对 CPU 单线程性能的微基准测试在合作伙伴和 RA 集群节点上的性能几乎相同。这表明主机上的 30 秒 perf record -a -g Capture (使用 perf report 查看) 出现了意外的顶帧：在 arm_smmu_cmdq_issue_cmdlist 上花费了 24% 的 CPU 周期。

arm_smmu_cmdq_issue_cmdlist 是向 Arm SMMU 的命令队列提交无效命令的函数。在虚拟化下，导致客户机无效的每个映射/ 取消映射都会捕获主机并通过单个命令队列进行序列化，从而在配置文件中显示出 spinlock 冲突。虚拟命令队列 (VCMDQ) 是通过标准 Arm SMMUv3 的命令队列虚拟化扩展程序提供的一项功能，允许客户机直接向硬件发出 SMMU 无效命令，而无需退出 VM。

修复：在合作伙伴集群上的主机内核中启用 CMDQV/ VCMDQ，并将其公开给客户机。这需要使用 tegra241-cmdqv 驱动程序和相应的 hypervisor 支持构建内核；最近的 QEMU/libvirt 版本添加了一个 cmdqv IOMMU 属性，以便向客户机公开该属性。

在此更改后，linux perf 显示 arm_smmu_cmdq_issue_cmdlist 从最高帧中消失，dTLB 误码率恢复到裸机奇偶校验。MoE 迭代时间差距从 12% 缩小到 RA 容差范围内。

要点在于，基于 Grace 的虚拟化部署需要 VM 堆栈来为内存映射密集型工作负载提供合适的 SMMU 功能。通过在主机内核中启用 CMDQV/ VCMDQ 并向客户机公开，平台可以避免不必要的 SMMU 序列化，并将 MoE 训练性能恢复到 RA 容限范围内。

下一层是 CPU 本身，故障模式看起来完全不同。

案例研究 2：H100 集群因 CPU 争用和 NUMA 错误绑定而损失 12%

层：CPU 功率和进程布局。

某合作伙伴的 H100 SXM5 集群运行与 NVIDIA HGX RA 相同的 NCCL 版本和 NeMo 容器，运行 Llama 3 70B 预训练的速度比参考慢 12%。与 GB200 NVL72 机箱不同，这不是内核级问题；一切都发生在用户空间和 BIOS 中。

有两点比较突出：

CPU 频率：训练期间的 turbostat -i 1 核心繁忙，频率固定为 3.0 GHz，尽管 SKU 的额定频率为 3.8 GHz。闲置核心的频率也是 3.0 GHz，C 状态位于 C1 而不是下降到 C6。
NUMA 远程流量：numastat -p <python_pid> 显示，训练过程中大约有 18% 的内存访问会访问远程 NUMA 节点

根本原因：

合作伙伴集群上的 CPU 在 BIOS 中配置了仅限 C1 的 C 状态。这是一种常见的“低延迟”默认设置，会在 AI 训练工作负载中造成严重错误。在 C1 中保持空闲核心的情况下，它们继续消耗封装功率；为 GPU 提供内核的繁忙核心无法占用足够的封装功率预算来实现大幅提升。将闲置的核心降低到 C6 释放的功率空间，使繁忙的核心能够攀升至 3.8 GHz，并在此工作负载中恢复约 4% 的性能。
Hypervisor 内部线程与训练过程的数据加载器工作线程固定在相同的物理核心。在 VM 内部，这看起来像是 python 线程中的 50 – 100 毫秒停顿，然后在步长时间内作为长尾传播。修复的问题是 cpuset 分离：服务器虚拟化平台和主机服务在核心 0 – 7 和 56 – 63 上运行，训练过程在其余部分上运行。

结果：12% 的差距缩小到 3%，残差追踪到下一个案例研究中涵盖的另一个 NCCL 调优问题。

这里的模式是，没有一个单一的修复程序能够修复整个缺口。C 状态变化是最大的单一因素，约为 4%，其余部分来自通过 NUMA 绑定实现的进程隔离。解决了 CPU 和虚拟化问题后，下一个上限是网络。

案例研究 3：采用 NVIDIA ConnectX-8 SuperNIC 的 GB300 NVL72 未充分利用 1.6 Tbps 网络

聚焦：ConnectX-8 SuperNIC 集合调优

使用 NVIDIA ConnectX-8 SuperNIC 的 GB300 NVL72 部署 (每节点 1.6 Tbps) 显示，Nemotron-4 15B 预训练的训练性能差距为 31%。单节点吞吐量看起来不错；差距出现在 512 个 GPU 上，分析器显示了 AllGather 和 ReduceScatter 时间。这指向的是 ConnectX-8 网络上的集合路径，而不是计算。

该调查使用 NCCL 测试 (nccl-tests) 测试了多个变量，包括迭代次数、UCX/ UCC 行为、NUMA 映射、NVLS 和 NCCL 版本。对于工作负载的网络性能，相关调优更改范围较窄：将 NCCL_IB_QPS_PER_CONNECTION 从默认值 1 增加到 4。

Nsight Systems 追踪，显示以较低 QPS 值暴露的通信开销，有助于延长训练迭代时间

信号在工作负载和 nccl-tests 集合测量中均可见。在 NVIDIA 参考集群上，默认配置每次迭代运行时间约为 1.09 秒。使用 QPS=4 时，相同的参考工作负载缩短到约 0.83 秒。在配置文件中，AllGather 时间从大约 375 毫秒缩短到 262 毫秒，ReduceScatter 从大约 389 毫秒缩短到 273 毫秒。对比运行时间约为 0.76 秒，并使用了不同的 NCCL 版本。因此，造成差异的部分原因在于比较环境和参考环境之间的 NCCL 版本不匹配；调整版本进一步缩小了残差差距。由于 NCCL 版本更改超出了正常的 Exemplar 调优范围，因此建议的调优会使部署的 NCCL 版本保持不变。

经验：不要在任何地方增加 QPS。QPS 依赖于网络和工作负载。在此 GB300 ConnectX-8 工作负载上，QPS – 4 改进了大消息 AllGather 和 ReduceScatter 行为。在其他网络或消息大小的配置文件中，相同设置可能会增加 CPU 开销，而不会提高训练吞吐量。正确的方法是根据工作负载的实际消息大小测试集合，扫描目标网络上的设置，并验证训练工作负载中的结果。

案例研究 4：从未在内部创建的环境变量

在虚拟化 B200 部署中，即使在主机上运行的 nccl-tests 显示出预期性能，训练吞吐量仍比 NVIDIA 基准测试低 13% – 53%。在 enroot 工作负载容器中，AllGather 和 ReduceScatter 的速度降低了 2 – 4%，这使得调查从网络运行状况转移到直接比较 VM 和训练作业中可见的 NCCL 拓扑配置。

Host (VM)                              Container (enroot)
─────────                         ─────────      
NCCL_TOPO_FILE=/etc/nccl/topo.xml  →NCCL_TOPO_FILE (not propagated)
/etc/nccl/topo.xml present       →/etc/nccl/topo.xml(not mounted)
                                                ↓
                                  NCCL falls back to auto-detection
                                    → 13–53% below reference

平台	B200，虚拟化堆栈
症状	低于参考 13 – 53%；AllGather/ ReduceScatter 速度降低 2 – 4 倍；主机上的 NCCL 测试通过率良好
根本原因	在 VM 上设置 `NCCL_TOPO_FILE`，但变量和拓扑文件均未挂载到 enroot 容器中
修复	`--mount type=bind,source=/etc/nccl/topo.xml,target=/etc/nccl/topo.xml`

表 1. 诊断和修复虚拟化 B200 工作负载容器内缺失的 NCCL 拓扑配置

课程：从相同的容器、启动程序和 Slurm 分配中运行检查，该分配将运行基准测试，而不是从主机运行。在作业容器内运行 echo $NCCL_TOPO_FILE && cat $NCCL_TOPO_FILE 是最快的完整性检查。如果路径未解决，NCCL 会悄无声息地失败且无错误，这使得在不知道往何处看的情况下更难诊断这一缺陷。

修复程序摘要

案例	平台	图层	诊断信号	修复	已恢复
1	GB200 NVL72 ( VM)	SMMU	arm_smmu_cmdq_issue_cmdlist 在性能中占主导地位；dTLB 缺失增加数倍	启用 VMDQV	~12%
2	H100 ( VM)	CPU+ NUMA	核心频率仍在 3.0 GHz；双模态步进时间；18% 的 NUMA 远程	C-state 调优、cpuset 隔离、numactl 绑定、SMT/ 缓解措施关闭	9% ( 12-3)
3	GB300 NVL72	NCCL 并发	AllGather 总线带宽在+ 28 GB/s 下与 ~61 GB/s ( QPS = 4) 下	对于 CX8，NCCL_IB_QPS_PER_CONNECTION 从 1 更新为 4	31% 迭代时间
4	B200 ( VM)	运行时可见拓扑	主机 NCCL 拓扑看起来是正确的，但在 enroot 容器内 NCCL_TOPO_FILE 未被传播，/etc/nccl/topo.xml 未被挂载；AllGather/ ReduceScatter 的速度比原来的慢 2-4 倍	将拓扑文件绑定到容器中，并在作业容器内验证 NCCL_TOPO_FILE	填补了 13-53% 的参考差距

表 2. 四个示例云案例研究中的诊断信号、纠正措施和恢复性能

全面训练调试前的飞行前检查

当集群相对于其 NVIDIA 参考架构规格表现不佳时，这些检查有助于在全面调优工作负载之前排除常见的平台问题。

面积	要检查的内容	实用工具
GPU 和硬件运行状况	持续负载下的时钟、功率、散热和 NVLink 带宽一致性	nvidia-smi、DCGM、dcgm-exporter
Grace 和 VM 就绪	CMDQV 支持、客户机页面大小、IOMMU 直通行为和大页面可用性	perf、dmesg、kernel config、启动参数
CPU 功率和位置	GPU 附近的忙碌核心 Turbo、cpuset 隔离和 NUMA/ PCT 绑定	turbostat、lscpu、numactl、nvidia-smi – topo -m
运行时拓扑	作业容器内的拓扑文件、NCCL 环境变量和 HCA 可见性	env、cat $NCCL_TOPO_FILE、NCCL_DEBUG = INFO
网络集合	AllGather 和 Reduce 工作负载消息大小下的散布行为	nccl-tests、工作负载追踪
工作负载调优	工作流并行、微批量大小和通信重叠 – 仅在排除平台问题后	Nsight Systems、工作负载日志

表 3. 推荐的飞行前检查和诊断工具，用于在全面训练调试之前评估 GPU 运行状况、VM 就绪情况、CPU 放置、运行时拓扑、结构集合和工作负载配置

尽早调试，减少调试

云训练部署与相应的 NVIDIA 参考架构之间的性能差距通常以 CPU 功耗设置、NUMA 或 PCT 绑定、缺失的内核功能、容器 – 可见拓扑或结构配置的百分比累积。在验证之前，这些问题值得检查，因为它们可能会转化为昂贵的完整调试会话。

同时，飞行前诊断无法保证通过 Exemplar Cloud。某些问题仅在验证工作负载本身中出现，具体取决于运行所使用的确切模型、精度、拓扑、容器、启动器和网络条件。实际目标是尽早消除已知的平台风险，然后使用训练工作负载追踪来调试仅大规模出现的差距。

点播观看更深入的 GTC 会议：S81845 – 使用基准测试方法在任何 AI 基础设施上实现每瓦最佳 token。
NVIDIA Grace CPU 性能调优指南
NCCL 环境变量，特别是 NCCL_IB_QPS_PER_CONNECTION、NCCL_IB_SPLIT_DATA_ON_QPS、NCCL_IB_HCA 和 NCCL_DEBUG
NVIDIA NeMo 框架 – 从 NGC 中提取更新的容器，以针对 Llama 3、DeepSeek 和 Nemotron 进行最新优化
NVIDIA Performance Explorer – TCO 计算器，用于评估基础设施的每 TCO 性能
NVIDIA 性能基准测试方法 – 即用型模板，用于评估硬件和软件组合中 AI 用例的性能