NVIDIA、AI インフラの最大性能発揮に向けたクラウド設計教訓を公開

Two AI computing clusters built from identical NVIDIA H100, GB200 NVL72, or GB300 NVL72 systems can deliver materially different training throughput. We routinely see 8% to 12% gaps between partner deployments and the corresponding NVIDIA reference architecture (RA) on the same workload, same model, same global batch size.

The cause is often a stack of configuration choices in the kernel, hypervisor, BIOS, and NVIDIA Collective Communications Library (NCCL) settings, each costing a few percent, that compound into a gap large enough to miss the 95% threshold required for NVIDIA Exemplar Cloud validation.

This post walks through four debugging investigations from real partner clusters. Each diagnostic isolates a distinct layer of the stack: system memory management unit (SMMU) and page-table behavior on NVIDIA Grace CPU; power management and non-uniform memory access (NUMA) placement on x86-based CPU; NVIDIA NCCL queue-pair concurrency on 1.6 Tbps fabrics; and silent hardware-installation defects. The post also shows the specific signal in perf, NVIDIA Nsight Systems, or NVIDIA NCCL tests that pointed to the root cause, alongside the tuning change that closed the gap.

Infrastructure engineers and performance architects who already run these benchmarks can benefit from these diagnostic patterns we use internally to run against their own clusters before formal RA validation.

Prerequisites

To reproduce the diagnostics in this post, you will need:

• An NVIDIA HGX H100, HGX H200, HGX B200, GB200 NVL72, or GB300 NVL72 systems cluster with NVIDIA Quantum InfiniBand or RoCE interconnect.

• A distributed training workload with stable iteration timing—NVIDIA NeMo on Llama 3 model, NVIDIA Nemotron, or DeepSeek configuration is a reasonable reference.

• Root access on at least one node for perf, BIOS/UEFI changes, and kernel parameter changes.

• nccl-tests built against the same NCCL version your training stack uses, NVIDIA Nsight Systems, and Linux perf with kernel symbols available.

Common patterns behind training performance gaps

Recent Exemplar training engagements show that performance gaps rarely come from a single obvious failure. More often, they come from configuration details that become visible only under workload pressure. Some recurring patterns include:

• Grace and virtualization readiness: Missing platform capabilities, SMMU overhead, IOMMU behavior, or page-size settings that don’t match the expected configuration.

• CPU power and process placement: Cores running below expected turbo frequency, ranks or helper threads placed on the wrong cores, or NUMA/PCT bindings that don’t match the platform topology.

• Runtime topology: Host topology files or NCCL settings that are correct on the node but missing inside the workload container or launcher environment.

• Fabric and collective behavior: NCCL settings that don’t match the target fabric, message size, or scale of the training workload.

• Application-to-platform binding: Training processes binding by core ID or rank order instead of topology-aware affinity.

These aren’t the only causes of training performance gaps, and checking them doesn’t replace validation with real applications.

Four case studies below show how these patterns appeared in recent training work: what signal exposed the issue, what changed, and how the fix was verified. The order isn’t a universal triage sequence; the right starting point depends on the workload, platform, and first profiler signal.

Layer: Virtualization and SMMU

A GB200 NVL72 partner deployment running DeepSeek-V3 Mixture-of-Experts (MoE) FP8 pre-training inside a VM was producing iteration times 12% to 14% longer than the bare-metal RA. Pre-training recipes for dense models like Llama 3 70B ran within 3% of RA performance, while DeepSeek-V3 MoE, which issues many small kernels per iteration, was the outlier.

Nsight Systems traces captured on the partner cluster showed significantly higher CPU overhead for tiny kernel regions of the workload. Microbenchmarks targeting just the CPU single thread performance demonstrated near identical performance on the partner and RA cluster nodes. This indicated that a 30-second perf record -a -g capture on the host, viewed with perf report, surfaced an unexpected top frame: 24% of CPU cycles spent on arm_smmu_cmdq_issue_cmdlist.

arm_smmu_cmdq_issue_cmdlist is the function that submits invalidation commands to the Arm SMMU’s command queue. Under virtualization, every map/unmap resulting in guest invalidation traps the host and serializes through a single command queue, producing the spinlock contention visible in the profile. Virtual Command Queue (VCMDQ) is a feature available through the Command Queue Virtualization extension to the standard Arm SMMUv3 and allows the guest to issue SMMU invalidation commands directly to hardware without VM exits.

The fix: Enable CMDQV/VCMDQ in the host kernel on the partner cluster and expose it to the guest. This requires a kernel built with the tegra241-cmdqv driver and the corresponding hypervisor support; recent QEMU/libvirt versions have added a cmdqv IOMMU attribute to expose it to guests.

After this change, linux perf showed arm_smmu_cmdq_issue_cmdlist falling out of the top frames and dTLB miss rates returning to bare-metal parity. The MoE iteration-time gap narrowed to within RA tolerance from 12%.

The takeaway is that Grace-based virtualized deployments need the VM stack to expose the right SMMU capabilities for memory-mapping-heavy workloads. With CMDQV/VCMDQ enabled in the host kernel and exposed to the guest, the platform can avoid unnecessary SMMU serialization and return MoE training performance to within RA tolerance.

The next layer down is the CPU itself, where the failure mode looks completely different.

Case study 2: H100 cluster losing 12% to CPU contention and NUMA misbinding

Layer: CPU power and process placement.

A partner’s H100 SXM5 cluster, running the same NCCL version and NeMo container as NVIDIA’s HGX RA, was running Llama 3 70B pre-training 12% slower than reference. Unlike the GB200 NVL72 case, this wasn’t a kernel-level issue; everything happened in user space and BIOS.

Two things stood out:

• CPU frequency: turbostat -i 1 during training showed busy cores pegged at 3.0 GHz, despite the SKU being rated for 3.8 GHz turbo. Idle cores were also at 3.0 GHz, with C-states sitting in C1 rather than dropping to C6.

• NUMA-remote traffic: numastat -p <python_pid> showed roughly 18% of the training process’s memory accesses going to the remote NUMA node

Root cause:

• The CPU on the partner cluster was configured with C-states limited to C1 in BIOS. This is a common “low-latency” default that is actively wrong for AI training workloads. With idle cores held in C1, they continued to draw package power; the busy cores feeding the GPU with kernels couldn’t claim enough of the package power budget to hit turbo. Allowing the idle cores to drop to C6 freed power headroom, enabling the busy cores to climb to 3.8 GHz and recover roughly 4% on this workload.

• The hypervisor housekeeping threads were pinned to the same physical cores as the training process’s data loader workers. Inside the VM this looked like sporadic 50–100 ms stalls in the python threads, which then propagated as the long tail in step time. The fix was a cpuset separation: hypervisor and host services on cores 0–7 and 56–63, training processes on the remainder.

Result: The 12% gap shrank to 3%, with the residual traced to a different NCCL tuning issue covered in the next case study.

The pattern here is that no single fix recovered the whole gap. The C-state change was the largest single contributor at ~4%, and the rest came from process isolation through NUMA binding. With CPU and virtualization addressed, the next ceiling is the network.

Case study 3: GB300 NVL72 with NVIDIA ConnectX-8 SuperNIC under-utilizing 1.6 Tbps fabric

Focus: ConnectX-8 SuperNIC collective tuning

A GB300 NVL72 deployment with NVIDIA ConnectX-8 SuperNICs (1.6 Tbps per node) showed a 31% training performance gap on Nemotron-4 15B pre-training. Single-node throughput looked healthy; the gap appeared at 512 GPUs, where the profiler showed exposed AllGather and ReduceScatter time. That pointed to the collective path on the ConnectX-8 fabric rather than compute.

The investigation tested several variables with NCCL Tests (nccl-tests), including iteration count, UCX/UCC behavior, NUMA mapping, NVLS, and NCCL versions. For the workload’s networking performance, the relevant tuning change was narrower: increasing NCCL_IB_QPS_PER_CONNECTION to 4 from the default value of 1.

Nsight Systems trace showing communication overhead exposed at lower QPS values, contributing to longer training iteration time

Signal was visible in both the workload and the nccl-tests collective measurements. On the NVIDIA reference cluster, the default configuration ran at about 1.09s per iteration. With QPS=4, the same reference workload improved to about 0.83s. In the profile, AllGather time dropped from about 375ms to 262ms, and ReduceScatter dropped from about 389ms to 273ms. The comparison run was about 0.76s and used a different NCCL version. The remaining difference was therefore partly attributable to an NCCL version mismatch between the comparison and reference environments; aligning the versions narrowed the residual gap further. Because NCCL version changes are outside the normal Exemplar tuning scope, the recommended tuning keeps the deployed NCCL version unchanged.

Lesson: Don’t increase QPS everywhere. QPS is fabric- and workload-dependent. On this GB300 ConnectX-8 workload, QPS=4 improved large-message AllGather and ReduceScatter behavior. On other fabrics or message-size profiles, the same setting may add CPU overhead without improving training throughput. The right approach is to test the collective at the workload’s real message sizes, sweep the setting on the target fabric, and verify the result in the training workload.

Case study 4: The environment variable that never made it inside

In a virtualized B200 deployment, training throughput was 13%–53% below the NVIDIA reference even though nccl-tests run on the host showed expected performance. Inside the enroot workload container, AllGather and ReduceScatter were 2–4× slower, shifting the investigation from fabric health to a direct comparison of the NCCL topology configuration visible on the VM and inside the training job.

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

Lesson: Run checks from inside the same container, launcher, and Slurm allocation that will run the benchmark not from the host. Running echo $NCCL_TOPO_FILE && cat $NCCL_TOPO_FILE inside the job container is the fastest sanity check. If the path doesn’t resolve, NCCL fails silently with no error making this one of the harder gaps to diagnose without knowing where to look.

Summary of fixes

Preflight checks before full-scale training debug

When a cluster underperforms relative to its NVIDIA reference architecture specifications, these checks help rule out common platform issues before full-scale workload tuning.

Debug early, debug less

Performance gaps between a cloud training deployment and the corresponding NVIDIA reference architecture are often cumulative with a few percent from CPU power settings, another from NUMA or PCT binding, more from a missing kernel capability, container-visible topology, or fabric configuration. These issues are worth checking before validation because they can turn into expensive full-scale debug sessions.

At the same time, preflight diagnostics don’t guarantee an Exemplar Cloud pass. Some issues only appear in the validation workloads themselves, under the exact model, precision, topology, container, launcher, and network conditions used for the run. The practical goal is to remove known platform risks early, then use the training workload traces to debug the gaps that only appear at scale.

• Go deeper GTC session on demand: S81845 — Drive Optimal Tokens per Watt on any AI Infrastructure Using Benchmarking Recipes.

• NVIDIA Grace CPU Performance Tuning Guide

• NCCL Environment Variables — particularly NCCL_IB_QPS_PER_CONNECTION, NCCL_IB_SPLIT_DATA_ON_QPS, NCCL_IB_HCA, and NCCL_DEBUG

• NVIDIA NeMo Framework — pull updated containers from NGC for the latest optimizations on Llama 3, DeepSeek, and Nemotron

• NVIDIA Performance Explorer — TCO Calculator for evaluating infrastructure on perf-per-TCO

• NVIDIA Performance Benchmarking Recipes — ready-to-use templates for evaluating performance of AI use cases across hardware and software combinations