待翻譯：Nvidia Exemplar Cloud: Lessons for Unlocking Performance on AI Infrastructure

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. 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. Figure 1. Linux perf icicle graph highlighting Arm SMMU command-queue invalidation overhead during DeepSeek-V3 FP8 pre-training on a virtualized NVIDIA GB200 NVL72 system