NVIDIA Exemplar Cloud：在AI基础设施上释放全部性能的经验教训（12分钟阅读）

# NVIDIA Exemplar Cloud：释放 AI 基础设施全部性能的经验教训 来源：https://developer.nvidia.com/blog/nvidia-exemplar-cloud-lessons-for-unlocking-full-performance-on-ai-infrastructure 两套由相同的 NVIDIA H100、GB200 NVL72 或 GB300 NVL72 系统构建的 AI 计算集群，其训练吞吐量可能截然不同。我们经常发现，合作伙伴部署与相应的 NVIDIA 参考架构（RA）在相同工作负载、相同模型、相同全局批大小下存在 8% 到 12% 的差距。其原因往往是一系列配置选择——内核、虚拟机监控程序、BIOS 和 NVIDIA 集体通信库（NCCL）设置——每项只造成几个百分点的损失，但叠加起来就形成了一个足以导致无法达到 **NVIDIA Exemplar Cloud**（https://www.nvidia.com/en-us/data-center/ai-cloud-performance/）验证所需 95% 阈值的差距。本文将介绍来自真实合作伙伴集群的四个调试调查案例。每个诊断都隔离了技术栈中不同的层面：NVIDIA Grace CPU（https://www.nvidia.com/en-us/data-center/grace-cpu/）上的系统内存管理单元（SMMU）和页表行为；基于 x86 的 CPU 上的功耗管理和非一致内存访问（NUMA）放置；1.6 Tbps 网络上的 NVIDIA NCCL（https://developer.nvidia.com/nccl）队列对并发；以及静默的硬件安装缺陷。本文还展示了 `perf`、NVIDIA Nsight Systems（https://developer.nvidia.com/nsight-systems）或 NVIDIA NCCL 测试（https://github.com/nvidia/nccl-tests）中指向根本原因的特定信号，以及消除差距的调优变更。已经运行这些基准测试的基础设施工程师和性能架构师，可以在正式 RA 验证之前，借鉴我们在内部使用的这些诊断模式来检查他们自己的集群。 ### **前提条件** https://developer.nvidia.com/blog/nvidia-exemplar-cloud-lessons-for-unlocking-full-performance-on-ai-infrastructure#prerequisites 要复现本文中的诊断，你需要： - 一个 NVIDIA HGX H100、HGX H200、HGX B200、GB200 NVL72 或 GB300 NVL72 系统集群，并配备 NVIDIA Quantum InfiniBand（https://www.nvidia.com/en-us/networking/products/infiniband/）或 RoCE 互连。 - 一个迭代计时稳定的分布式训练工作负载——在 Llama 3 模型上使用 NVIDIA NeMo（https://github.com/nvidia-nemo）、NVIDIA Nemotron（https://developer.nvidia.com/topics/ai/nemotron）或 DeepSeek 配置，可作为合理的参考。 - 至少一个节点上的 root 访问权限，用于 `perf`、BIOS/UEFI 更改和内核参数更改。 - 与你的训练技术栈所用 NCCL 版本相同的 `nccl-tests` 构建、NVIDIA Nsight Systems，以及带有内核符号的 Linux perf。 ## 训练性能差距背后的常见模式 https://developer.nvidia.com/blog/nvidia-exemplar-cloud-lessons-for-unlocking-full-performance-on-ai-infrastructure#common_patterns_behind_training_performance_gaps 最近的 Exemplar 训练合作表明，性能差距很少来自某个单一的明显故障。更多情况下，它们来自只有在工作负载压力下才可见的配置细节。一些反复出现的模式包括： 1. **Grace 与虚拟化就绪性：**缺少平台能力、SMMU 开销、IOMMU 行为，或页大小设置与预期配置不匹配。 2. **CPU 功耗与进程放置：**核心运行低于预期的睿频频率，rank 或辅助线程被放置到错误的核心上，或 NUMA/PCT 绑定与平台拓扑不匹配。 3. **运行时拓扑：**主机拓扑文件或 NCCL 设置在节点上正确，但在工作负载容器或启动器环境中缺失。 4. **网络与集体行为：**NCCL 设置与目标网络、消息大小或训练工作负载规模不匹配。 5. **应用与平台绑定：**训练进程按核心 ID 或 rank 顺序绑定，而非按拓扑感知的亲和性绑定。 这些并不是训练性能差距的全部原因，检查它们也不能替代用真实应用进行验证。下面四个案例研究展示了这些模式如何在近期的训练工作中出现：什么信号暴露了问题、做了什么更改，以及如何验证修复效果。这个顺序并不是通用的分诊流程；正确的起点取决于工作负载、平台和第一个性能剖析器信号。 **层面：虚拟化与 SMMU** 一个运行 DeepSeek-V3 混合专家（MoE）FP8 预训练（在 VM 内）的 GB200 NVL72 合作伙伴部署，其迭代时间比裸机 RA 长 12% 到 14%。Llama 3 70B 等稠密模型的预训练方案运行在 RA 性能的 3% 以内，而 DeepSeek-V3 MoE（每次迭代发出许多小内核）则成为异常值。在合作伙伴集群上捕获的 Nsight Systems 追踪显示，工作负载中小型内核区域的 CPU 开销明显更高。仅针对 CPU 单线程性能的微基准测试表明，合作伙伴集群节点和 RA 集群节点上的性能几乎相同。这表明，在主机上使用 `perf record -a -g` 捕获 30 秒，并通过 `perf report` 查看，暴露出一个意外的顶层帧：24% 的 CPU 周期花费在 `arm_smmu_cmdq_issue_cmdlist` 上。 *图 1. Linux perf icicle 图，突出显示在虚拟化 NVIDIA GB200 NVL72 系统上运行 DeepSeek-V3 FP8 预训练期间，Arm SMMU 命令队列无效化开销显著，表明 Arm SMMU 命令队列开销巨大。* `arm_smmu_cmdq_issue_cmdlist` 是将无效化命令提交到 Arm SMMU 命令队列的函数。在虚拟化环境下，每次 map/unmap 导致的来宾无效化都会使主机陷入（trap），并通过单个命令队列串行化，从而产生剖析中可见的自旋锁争用。虚拟命令队列（VCMDQ）是标准 Arm SMMUv3 的命令队列虚拟化扩展提供的一项功能，允许来宾直接向硬件发出 SMMU 无效化命令，而无需 VM 退出。 **修复方法：**在合作伙伴集群的主机内核中启用 CMDQV/VCMDQ，并将其暴露给来宾。这需要使用内置 `tegra241-cmdqv` 驱动的内核，以及相应的虚拟机监控程序支持；较新的 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% https://developer.nvidia.com/blog/nvidia-exemplar-cloud-lessons-for-unlocking-full-performance-on-ai-infrastructure#case_study_2_h100_cluster_losing_12%_to_cpu_contention_and_numa_misbinding **层面：CPU 功耗与进程放置。** 一个合作伙伴的 H100 SXM5 集群，运行与 NVIDIA HGX RA 相同的 NCCL 版本和 NeMo 容器，其 Llama 3 70B 预训练速度比参考慢 12%。与 GB200 NVL72 案例不同，这不是内核级问题；一切都发生在用户空间和 BIOS 中。 **突出两点：** 1. **CPU 频率：**训练期间 `turbostat -i 1` 显示繁忙核心固定在 3.0 GHz，尽管该 SKU 额定睿频为 3.8 GHz。空闲核心也处于 3.0 GHz，C 状态停留在 C1 而未降至 C6。 2. **NUMA 远程流量：**`numastat -p <pid>` 显示训练进程约 18% 的内存访问指向远程 NUMA 节点。 **根本原因：** - 合作伙伴集群上的 CPU 在 BIOS 中配置为将 C 状态限制为 C1。这是一种常见的“低延迟”默认设置，但对 AI 训练工作负载来说实际上是错误的。空闲核心保持在 C1，它们会继续消耗封装功耗；向 GPU 提供内核的繁忙核心无法获得足够的封装功耗预算以达到睿频。允许空闲核心降至 C6 释放了功耗余量，使繁忙核心攀升至 3.8 GHz，在该工作负载上恢复了约 4% 的性能。 - 虚拟机监控程序的后台线程被固定在与训练进程数据加载器工作线程相同的物理核心上。在 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 网络 https://developer.nvidia.com/blog/nvidia-exemplar-cloud-lessons-for-unlocking-full-performance-on-ai-infrastructure#case_study_3_gb300_nvl72_with_nvidia_connectx-8_supernic_under-utilizing_16_tbps_fabric **重点：ConnectX-8 SuperNIC 集体调优** 一个配备 NVIDIA ConnectX-8 SuperNIC（https://www.nvidia.com/en-us/networking/infiniband-adapters/）（每节点 1.6 Tbps）的 GB300 NVL72 部署，在 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。 *图 2. Nemotron-4 15B 在 512 GPU 规模下使用 NCCL QPS 优化的性能；红色框突出显示上方轨迹中较长的 AllGather/ReduceScatter 区域，绿色框显示在 QPS=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 改善了大消息 AllGear 和 ReduceScatter 行为。在其他网络或消息大小分布上，相同设置可能会增加 CPU 开销而无益于训练吞吐量。正确的方法是在工作负载真实消息大小下测试集体操作，在目标网络上扫描该设置，并在训练工作负载中验证结果。 ## 案例研究 4：从未进入容器内部的环境变量 https://developer.nvidia.com/blog/nvidia-exemplar-cloud-lessons-for-unlocking-full-performance-on-ai-infrastructure#case_study_4_the_environment_variable_that_never_made_it_inside 在一个虚拟化 B200 部署中，训练吞吐量比 NVIDIA 参考低 13%-53%，尽管在主机上运行的 `nccl-tests` 显示性能符合预期。在 `enroot` 工作负载容器内部，AllGather 和 ReduceScatter 慢了 2-4 倍，这使调查从网络健康状况转向直接比较 VM 上可见的 NCCL 拓扑配置与训练作业内部可见的配置。 ``` 主机（VM） 容器（enroot） ───────── ───────── NCCL_TOPO_FILE=/etc/nccl/topo.xml → NCCL_TOPO_FILE（未传播） /etc/nccl/topo.xml 存在 → /etc/nccl/topo.xml（未挂载） ↓ NCCL 回退到自动检测 → 比参考低 13-53% ``` **平台**：B200，虚拟化技术栈 **症状**：比参考低 13-53%；AllGather/ReduceScatter 慢 2-4 倍；主机上的 NCCL 测试通过 **根本原因**：`NCCL_TOPO_FILE` 在 VM 上设置，但变量和拓扑文件均未挂载到 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 | perf 中 arm_smmu_cmdq_issue_cmdlist 占主导；dTLB 未命中率增加数倍 | 启用 VMDQV | ~12% | | 2 | H100（VM） | CPU + NUMA | 核心卡在 3.0 GHz；步长时间双峰分布；18% NUMA 远程 | C 状态调优、cpuset 隔离、numactl 绑定、关闭 SMT/缓解措施 | 9%（12-3） | | 3 | GB300 NVL72 | NCCL 并发 | AllGather busbw 约 28 GB/s，而 QPS=4 时约 61 GB/s | 将 NCCL_IB_QPS_PER_CONNECTION 从 1 更新为 4（针对 CX8） | 迭代时间缩短 31% | | 4 | B200（VM） | 运行时可见拓扑 | 主机 NCCL 拓扑看起来正确，但在 enroot 容器内 NCCL_TOPO_FILE 未传播且 /etc/nccl/topo.xml 未挂载；AllGather/ReduceScatter 慢 2-4 倍 | 将拓扑文件绑定挂载到容器中，并从作业容器内部验证 NCCL_TOPO_FILE | 弥合 13-53% 参考差距 | *表 2. 四个 Exemplar Cloud 案例研究中的诊断信号、纠正措施和恢复性能* ## 全规模训练调试前的预检检查 https://developer.nvidia.com/blog/nvidia-exemplar-cloud-lessons-for-unlocking-full-performance-on-ai-infrastructure#preflight_checks_before_full-scale_training_debug 当集群性能低于其 NVIDIA 参考架构规格时，以下检查有助于在全规模工作负载调优前排除常见的平台问题。 | **领域** | **要检查的内容** | **有用的工具** | |---|---|---| | **GPU 和硬件健康** | 持续负载下的时钟、功耗、热状态和 NVLink 带宽一致性 | nvidia-smi、DCGM、dcgm-exporter | | **Grace 和 VM 就绪性** | CMDQV 支持、来宾页大小、IOMMU 直通行为和大页可用性 | perf、dmesg、内核配置、启动参数 | | **CPU 功耗和放置** | 繁忙核心睿频、cpuset 隔离，以及靠近 GPU 的 NUMA / PCT 绑定 | turbostat、lscpu、numactl、nvidia-smi topo -m | | **运行时拓扑** | 拓扑文件、NCCL 环境变量，以及 HCA v | 运行与基准测试相同的容器/启动器，检查 $NCCL_TOPO_FILE 和文件挂载 |