NVIDIA Exemplar Cloud: Lessons for Unlocking Full Performance on AI Infrastructure NVIDIA reports that two AI computing clusters built from identical H100, GB200 NVL72, or GB300 NVL72 systems can deliver 8% to 12% differences in training throughput due to configuration choices in kernel, hypervisor, BIOS, and NCCL settings. The company's Exemplar Cloud validation requires achieving at least 95% of reference architecture performance, and the post details four debugging case studies from partner clusters that closed such gaps. 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 https://www.nvidia.com/en-us/data-center/ai-cloud-performance/ 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 https://www.nvidia.com/en-us/data-center/grace-cpu/ ; power management and non-uniform memory access NUMA placement on x86-based CPU; NVIDIA NCCL https://developer.nvidia.com/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 https://developer.nvidia.com/nsight-systems , or NVIDIA NCCL tests https://github.com/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 https://www.nvidia.com/en-us/networking/products/infiniband/ or RoCE interconnect. - A distributed training workload with stable iteration timing— NVIDIA NeMo https://github.com/nvidia-nemo on Llama 3 model, NVIDIA Nemotron https://developer.nvidia.com/topics/ai/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. Case study 1: NVIDIA GB200 NVL72 FP8 pre-training, 12% slower in a virtual machine VM than on bare metal 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