{"slug": "nvidia-exemplar-cloud-lessons-for-unlocking-full-performance-on-ai", "title": "NVIDIA Exemplar Cloud: Lessons for Unlocking Full Performance on AI Infrastructure", "summary": "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.", "body_md": "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.\n\nThe 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.\n\nThis 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`\n\n, [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.\n\nInfrastructure 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.\n\n**Prerequisites**\n\nTo reproduce the diagnostics in this post, you will need:\n\n- An NVIDIA HGX H100, HGX H200, HGX B200, GB200 NVL72, or GB300 NVL72 systems cluster with\n[NVIDIA Quantum InfiniBand](https://www.nvidia.com/en-us/networking/products/infiniband/)or RoCE interconnect. - A distributed training workload with stable iteration timing—\n[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\n`perf`\n\n, BIOS/UEFI changes, and kernel parameter changes. `nccl-tests`\n\nbuilt against the same NCCL version your training stack uses, NVIDIA Nsight Systems, and Linux perf with kernel symbols available.\n\n## Common patterns behind training performance gaps\n\nRecent 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:\n\n**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.\n\nThese aren’t the only causes of training performance gaps, and checking them doesn’t replace validation with real applications.\n\nFour 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.\n\n## Case study 1: NVIDIA GB200 NVL72 FP8 pre-training, 12% slower in a virtual machine (VM) than on bare metal\n\n**Layer: Virtualization and SMMU**\n\nA 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.\n\nNsight 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 `\n\ncapture on the host, viewed with `perf report`\n\n, surfaced an unexpected top frame: 24% of CPU cycles spent on `arm_smmu_cmdq_issue_cmdlist`\n\n.\n\n`arm_smmu_cmdq_issue_cmdlist`\n\nis 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.\n\n**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`\n\ndriver and the corresponding hypervisor support; recent QEMU/libvirt versions have added a `cmdqv`\n\nIOMMU attribute to expose it to guests.\n\nAfter this change, `linux perf`\n\nshowed `arm_smmu_cmdq_issue_cmdlist`\n\nfalling 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%.\n\nThe 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.\n\nThe next layer down is the CPU itself, where the failure mode looks completely different.\n\n## Case study 2: H100 cluster losing 12% to CPU contention and NUMA misbinding\n\n**Layer: CPU power and process placement.**\n\nA 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.\n\n**Two things stood out:**\n\n**CPU frequency:**`turbostat -i 1`\n\nduring 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>`\n\nshowed roughly 18% of the training process’s memory accesses going to the remote NUMA node\n\n**Root cause:**\n\n- 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.\n- 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\n`cpuset`\n\nseparation: hypervisor and host services on cores 0–7 and 56–63, training processes on the remainder.\n\n**Result:** The 12% gap shrank to 3%, with the residual traced to a different NCCL tuning issue covered in the next case study.\n\nThe 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.\n\n## Case study 3: GB300 NVL72 with NVIDIA ConnectX-8 SuperNIC under-utilizing 1.6 Tbps fabric\n\n**Focus: ConnectX-8 SuperNIC collective tuning**\n\nA GB300 NVL72 deployment with [NVIDIA ConnectX-8 SuperNICs](https://www.nvidia.com/en-us/networking/infiniband-adapters/) (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.\n\nThe investigation tested several variables with NCCL Tests (`nccl-tests`\n\n), 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`\n\nto 4 from the default value of 1.\n\nNsight Systems trace showing communication overhead exposed at lower QPS values, contributing to longer training iteration time\n\nSignal was visible in both the workload and the `nccl-tests`\n\ncollective measurements. On the NVIDIA reference cluster, the default configuration ran at about 1.09s per iteration. With `QPS=4`\n\n, 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.\n\n**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.\n\n## Case study 4: The environment variable that never made it inside\n\nIn a virtualized B200 deployment, training throughput was 13%–53% below the NVIDIA reference even though `nccl-tests`\n\nrun on the host showed expected performance. Inside the `enroot`\n\nworkload 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.\n\n```\nHost (VM)                              Container (enroot)\n─────────                         ─────────      \nNCCL_TOPO_FILE=/etc/nccl/topo.xml  →NCCL_TOPO_FILE (not propagated)\n/etc/nccl/topo.xml present       →/etc/nccl/topo.xml(not mounted)\n                                                ↓\n                                  NCCL falls back to auto-detection\n                                    → 13–53% below reference\n```\n\nPlatform | B200, virtualized stack |\nSymptom | 13–53% below reference; AllGather/ReduceScatter 2–4x slower; NCCL tests on host pass fine |\nRoot cause | `NCCL_TOPO_FILE` set on the VM but neither the variable nor the topology file was mounted into the enroot container |\nFix | `--mount type=bind,source=/etc/nccl/topo.xml,target=/etc/nccl/topo.xml` |\n\n*Table 1. Diagnosis and remediation of missing NCCL topology configuration inside a virtualized B200 workload container*\n\n**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`\n\ninside 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.\n\n**Summary of fixes**\n\nCase | Platform | Layer | Diagnostic signal | Fix | Recovered |\n|---|---|---|---|---|---|\n| 1 | GB200 NVL72 (VM) | SMMU | arm_smmu_cmdq_issue_cmdlist dominant in perf; multi-fold dTLB miss increase | Enable VMDQV | ~12% |\n| 2 | H100 (VM) | CPU + NUMA | Cores stuck at 3.0 GHz; bimodal step time; 18% NUMA-remote | C-state tuning, cpuset isolation, numactl binding, SMT/mitigations off | 9% (12-3) |\n| 3 | GB300 NVL72 | NCCL concurrency | AllGather busbw at ~28 GB/s vs ~61 GB/s with QPS=4 | NCCL_IB_QPS_PER_CONNECTION update from 1 to 4 for CX8 | 31% iter time |\n| 4 | B200 (VM) | Runtime-visible topology | Host NCCL topology looked correct, but inside the enroot container NCCL_TOPO_FILE was not propagated and /etc/nccl/topo.xml was not mounted; AllGather/ReduceScatter were 2-4x slower | Bind-mount the topology file into the container and verify NCCL_TOPO_FILE from inside the job container | Closed 13-53% reference gaps |\n\n*Table 2. Diagnostic signals, corrective actions, and recovered performance across the four Exemplar Cloud case studies*\n\n## Preflight checks before full-scale training debug\n\nWhen a cluster underperforms relative to its NVIDIA reference architecture specifications, these checks help rule out common platform issues before full-scale workload tuning.\n\nArea | What to check | Useful tools |\nGPU and hardware health | Clock, power, thermal, and NVLink bandwidth consistency under sustained load | nvidia-smi, DCGM, dcgm-exporter |\nGrace and VM readiness | CMDQV support, guest page size, IOMMU passthrough behavior, and large-page availability | perf, dmesg, kernel config, boot parameters |\nCPU power and placement | Busy-core turbo, cpuset isolation, and NUMA / PCT binding near GPUs | turbostat, lscpu, numactl, nvidia-smi topo -m |\nRuntime topology | Topology files, NCCL environment variables, and HCA visibility inside the job container | env, cat $NCCL_TOPO_FILE, NCCL_DEBUG=INFO |\nFabric collectives | AllGather and ReduceScatter behavior at workload message sizes | nccl-tests, workload traces |\nWorkload tuning | Pipeline parallelism, microbatch sizing, and communication overlap — only after platform issues are ruled out | Nsight Systems, workload logs |\n\n*Table 3. Recommended preflight checks and diagnostic tools for evaluating GPU health, VM readiness, CPU placement, runtime topology, fabric collectives, and workload configuration before full-scale training debugging*\n\n## Debug early, debug less\n\nPerformance 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.\n\nAt 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.\n\n- Go deeper\n**GTC session on demand:**[S81845 —](https://www.nvidia.com/gtc/session-catalog/sessions/gtc26-s81845/).*Drive Optimal Tokens per Watt on any AI Infrastructure Using Benchmarking Recipes* [NVIDIA Grace CPU Performance Tuning Guide](https://docs.nvidia.com/dccpu/grace-perf-tuning-guide/index.html)[NCCL Environment Variables](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/env.html)— particularly NCCL_IB_QPS_PER_CONNECTION, NCCL_IB_SPLIT_DATA_ON_QPS, NCCL_IB_HCA, and NCCL_DEBUG[NVIDIA NeMo Framework](https://www.nvidia.com/en-us/ai-data-science/products/nemo/)— pull updated containers from[NGC](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/nemo)for the latest optimizations on Llama 3, DeepSeek, and Nemotron[NVIDIA Performance Explorer](https://docs.nvidia.com/dgx-cloud/benchmarking/performance-explorer-user-guide/latest/index.html)— TCO Calculator for evaluating infrastructure on perf-per-TCO[NVIDIA Performance Benchmarking Recipes](https://github.com/NVIDIA/dgxc-benchmarking)— ready-to-use templates for evaluating performance of AI use cases across hardware and software combinations", "url": "https://wpnews.pro/news/nvidia-exemplar-cloud-lessons-for-unlocking-full-performance-on-ai", "canonical_source": "https://developer.nvidia.com/blog/nvidia-exemplar-cloud-lessons-for-unlocking-full-performance-on-ai-infrastructure/", "published_at": "2026-07-30 16:00:00+00:00", "updated_at": "2026-07-30 16:04:25.981317+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-infrastructure", "ai-chips", "ai-tools", "ai-research"], "entities": ["NVIDIA", "NVIDIA H100", "NVIDIA GB200 NVL72", "NVIDIA GB300 NVL72", "NVIDIA Grace CPU", "NVIDIA NCCL", "NVIDIA NeMo", "NVIDIA Nemotron"], "alternates": {"html": "https://wpnews.pro/news/nvidia-exemplar-cloud-lessons-for-unlocking-full-performance-on-ai", "markdown": "https://wpnews.pro/news/nvidia-exemplar-cloud-lessons-for-unlocking-full-performance-on-ai.md", "text": "https://wpnews.pro/news/nvidia-exemplar-cloud-lessons-for-unlocking-full-performance-on-ai.txt", "jsonld": "https://wpnews.pro/news/nvidia-exemplar-cloud-lessons-for-unlocking-full-performance-on-ai.jsonld"}}