NVIDIA Exemplar Cloud：释放AI基础设施完整性能的实战经验

两套由相同NVIDIA H100、GB200 NVL72或GB300 NVL72系统构建的AI计算集群，在训练吞吐量上可能存在显著差异。实际测试中，合作伙伴部署与NVIDIA参考架构（RA）在相同工作负载、相同模型、相同全局批次大小下，性能差距通常在8%至12%之间。

这一差距的根源往往是内核、虚拟机管理程序、BIOS以及NVIDIA集合通信库（NCCL）配置层面的多项设置叠加所致，每项各损失几个百分点，累积后可能导致最终性能低于NVIDIA Exemplar Cloud认证所要求的95%门槛。

本文将梳理来自真实合作伙伴集群的四个调试案例，每个案例聚焦于不同的技术层面：NVIDIA Grace CPU上的系统内存管理单元（SMMU）与页表行为、基于x86 CPU的电源管理与非统一内存访问（NUMA）配置、1.6 Tbps网络中NVIDIA NCCL队列对并发，以及硬件安装的隐性缺陷。文章同时给出了通过perf、NVIDIA Nsight Systems或NCCL测试定位根因的具体信号，以及缩小差距的调优方案。

复现上述诊断过程，需要以下条件：

配备NVIDIA Quantum InfiniBand或RoCE互联的NVIDIA HGX H100、HGX H200、HGX B200、GB200 NVL72或GB300 NVL72系统集群；迭代时间稳定的分布式训练工作负载，可参考NVIDIA NeMo在Llama 3模型、NVIDIA Nemotron或DeepSeek配置上的运行结果；至少一个节点的root权限，用于perf、BIOS/UEFI更改和内核参数修改；与训练框架使用相同NCCL版本编译的nccl-tests、NVIDIA Nsight Systems，以及支持内核符号的Linux perf工具。

近期Exemplar训练项目的经验表明，性能差距很少源于单一的明显故障，更多来自工作负载压力下才会暴露的配置细节。常见问题模式包括：

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

以下四个案例展示了上述问题在近期训练工作中的具体呈现方式。

案例一：虚拟化与SMMU层

某合作伙伴的GB200 NVL72集群在虚拟机内运行DeepSeek-V3混合专家（MoE）FP8预训练，迭代时间比裸机参考架构长12%至14%。在此之前，Llama 3 70B等稠密模型的预训练性能与RA差距在3%以内，而每次迭代调用大量小型内核的DeepSeek-V3 MoE成了例外。

在合作伙伴集群上采集的Nsight Systems追踪显示，工作负载中小型内核区域的CPU开销明显偏高。针对单线程CPU性能的微基准测试表明，合作伙伴与RA集群节点的性能几乎相同。进一步在主机上执行30秒的`perf record -a -g`并通过`perf report`查看，发现一个异常的顶层函数：24%的CPU周期花费在`arm_smmu_cmdq_issue_cmdlist`上。

该函数负责向Arm SMMU的命令队列提交无效化命令。在虚拟化环境下，每次导致访客无效化的map/unmap操作都会触发主机陷入，并通过单一命令队列串行化处理，从而产生配置文件中可见的自旋锁竞争。虚拟命令队列（VCMDQ）是标准Arm SMMUv3命令队列虚拟化扩展提供的一项功能，允许访客直接向硬件发送SMMU无效化命令，无需触发虚拟机退出。

解决方案：在合作伙伴集群的主机内核中启用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电源与进程放置层

某合作伙伴的H100 SXM5集群使用与NVIDIA HGX参考架构相同的NCCL版本和NeMo容器，但运行Llama 3 70B预训练时比参考速度慢12%。与GB200 NVL72的案例不同，这不是内核层面的问题，而是用户空间和BIOS配置导致的。

发现了两个异常：其一，在训练期间用`turbostat -i 1`监测，繁忙核心被锁定在3.0 GHz，尽管该型号支持3.8 GHz的Turbo频率；空闲核心同样处于3.0 GHz，C状态停留在C1而非下降至C6。其二，`numastat -p`显示，训练进程约18%的内存访问发生在远端NUMA节点上。

根本原因：合作伙伴集群在BIOS中将C状态限制为C1，这是一种常见的"低延迟"默认设置，但对AI训练工作负载而言适得其反。空闲核心被维持在C1状态，持续消耗封装功耗；向GPU提供内核的繁忙核心无法获得足够的封装功耗预算，因此无法达到Turbo频率。允许空闲核心降至C6可释放功耗余量，使繁忙核心攀升至3.8 GHz，在本工作负载上恢复约4%的性能。

此外，虚拟机管理程序的内务线程与训练进程的数据加载工作线程被固定在相同的物理核心上。在虚拟机内部，这表现为Python线程出现零散的50至100毫秒卡顿，进而形成步骤时间的长尾效应。修复方案是通过cpuset分离：虚拟机管理程序和主机服务使用第0至7核与第56至63核，训练进程使用其余核心。

结果：12%的差距收窄至3%，剩余差距可追溯到下一个案例中涉及的NCCL调优问题。

案例三：ConnectX-8 SuperNIC集合通信调优

某GB300 NVL72部署配备了NVIDIA ConnectX-8 SuperNIC（每节点1.6 Tbps），在Nemotron-4 15B预训练上呈现31%的训练性能差距。单节点吞吐量表现正常，差距在512 GPU规模时出现，此时分析器显示AllGather和ReduceScatter时间明显暴露。这将问题指向ConnectX-8网络上的集合通信路径，而非计算本身。

调查通过NCCL Tests（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毫秒。

经验总结：不应盲目提高QPS。QPS取决于网络和工作负载类型。在此GB300 ConnectX-8工作负载上，QPS=4改善了大消息AllGather和ReduceScatter的行为。在其他网络或消息大小场景下，相同设置可能增加CPU开销而不提升训练吞吐量。正确做法是在工作负载的真实消息大小下测试集合通信，在目标网络上扫描该参数，并在训练工作负载中验证结果。

案例四：拓扑文件缺失导致的容器环境配置问题

在某虚拟化B200部署中，即使主机上的nccl-tests显示性能正常，训练吞吐量仍比NVIDIA参考低13%至53%。在enroot工作负载容器内，AllGather和ReduceScatter慢了2至4倍，调查方向从网络健康状态转向对比虚拟机与训练作业内NCCL拓扑配置的可见性差异。

主机（虚拟机）设置了`NCCL_TOPO_FILE=/etc/nccl/topo.xml`，且对应文件存在；而容器（enroot）中该环境变量未传播，`/etc/nccl/topo.xml`也未挂载，导致NCCL回退至自动检测，最终性能低于参考13%至53%。

经验总结：检查应在与运行基准测试相同的容器、启动器和Slurm分配内执行，而非在主机上操作。在作业容器内运行`echo $NCCL_TOPO_FILE && cat $NCCL_TOPO_FILE`是最快速的健全性检查。如果路径无法解析，NCCL会静默失败且不报错，这使其成为最难诊断的差距之一，除非知道问题所在。

修复摘要

当集群性能低于NVIDIA参考架构规格时，以下检查有助于在全规模工作负载调优前排除常见平台问题：虚拟化环境确认启用CMDQV/VCMDQ；CPU配置确保C状态可降至C6；检查NUMA/PCT绑定与平台拓扑的一致性；确认NCCL_IB_QPS_PER_CONNECTION设置与目标网络匹配；验证容器内NCCL拓扑文件已正确挂载且环境变量已传播。

云训练部署与NVIDIA参考架构之间的性能差距通常是累积性的：CPU电源设置损失几个百分点，NUMA或PCT绑定再损失几个百分点，缺失的内核能力、容器可见拓扑或网络配置也会逐项叠加。提前解决这些问题有助于避免代价高昂的全规模调试。

需要注意的是，预检诊断并不能保证通过Exemplar Cloud认证。某些问题只有在验证工作负载本身运行时才会出现，精确到模型、精度、拓扑、容器、启动器和网络条件。实际目标是尽早消除已知的平台风险，再利用训练工作负载追踪来调试只有在规模化场景下才出现的差距。

Q&A

Q1：NVIDIA Exemplar Cloud认证对性能有什么要求？

A：NVIDIA Exemplar Cloud认证要求合作伙伴部署的性能达到参考架构的95%以上。常见情况是，CPU电源管理、NUMA绑定、内核能力缺失、容器拓扑配置以及网络设置等多项因素累积叠加，导致性能低于这一门槛。通过逐层排查并修复这些配置问题，可以将差距缩小至认证允许范围内。

Q2：NCCL_IB_QPS_PER_CONNECTION参数应该怎么设置？

A：该参数取决于具体的网络类型和工作负载特征，没有放之四海而皆准的最优值。在GB300 NVL72配备ConnectX-8 SuperNIC的场景下，将其从默认值1调整为4，可显著改善大消息AllGather和ReduceScatter的性能，AllGather时间从约375毫秒降至262毫秒。建议在目标网络上使用实际工作负载的消息大小进行扫描测试，找到最适合自身环境的值，而非直接套用其他场景的配置。

Q3：为什么容器内的NCCL性能和主机上的测试结果差异这么大？

A：容器环境可能缺少必要的NCCL拓扑配置。常见原因是`NCCL_TOPO_FILE`环境变量未传播至容器内，或者对应的拓扑文件未被挂载，导致NCCL回退至自动检测模式，性能可能下降13%至53%。由于NCCL在这种情况下不会报错，问题很难被发现。建议在实际运行作业的容器内执行`echo $NCCL_TOPO_FILE && cat $NCCL_TOPO_FILE`进行验证，确保拓扑文件可访问。