NVIDIA tapasztalatai szerint két, ugyanazokkal az NVIDIA H100, GB200 NVL72 vagy GB300 NVL72 rendszerekkel épített AI klaszter azonos modell és globális batchméret mellett is 8–31% közötti eltérést mutathat a tanítási iterációs sebességben a referencia architektúrához képest. A leggyakoribb okok konfigurációs rétegekből adódnak: kernel-, hypervisor-, BIOS- és NVIDIA Collective Communications Library (NCCL)-beállítások kombinációja, amelyek egyenként csak néhány százalékot jelentenek, de összeadódva meghaladják a 95%-os küszöböt, amely az NVIDIA Exemplar Cloud validációhoz szükséges.
A következőkben négy valós partner klaszteren végzett hibakeresési esetet ismertetünk. Minden eset egy-egy réteget izolál: SMMU és lapoztábla viselkedés NVIDIA Grace CPU esetén; CPU teljesítmény/power és NUMA elhelyezkedés x86 alapú rendszeren; NCCL queue-pair párhuzamosság 1.6 Tbps hálózatoknál; és csendes hardver-/telepítési hibák. A cikk bemutatja azt a jelzést is (perf, NVIDIA Nsight Systems, vagy nccl-tests), amely a gyökérokra mutatott, valamint a beavatkozást, amely csökkentette a teljesítmény-gapet.
Előfeltételek a reprodukáláshoz
- NVIDIA HGX H100, HGX H200, HGX B200, GB200 NVL72 vagy GB300 NVL72 rendszerek klasztere NVIDIA Quantum InfiniBand vagy RoCE hálózattal.
- Stabil iterációs idővel rendelkező elosztott tanítási munkaterhelés (például NVIDIA NeMo Llama 3, NVIDIA Nemotron, vagy DeepSeek konfigurációk).
- Root hozzáférés legalább egy node-on perf, BIOS/UEFI és kernel-paraméterek módosításához.
- nccl-tests a használt NCCL verzióval, NVIDIA Nsight Systems és Linux perf kernel szimbólumokkal.
Gyakori mintázatok a teljesítménykülönbségek mögött
- Grace és virtualizáció: hiányzó platform-képességek, SMMU költség, IOMMU viselkedés vagy lapméret beállítások.
- CPU power és process placement: magok alacsonyabb turbófrekvencián futnak, rossz NUMA/PCT kötés vagy helper thread-ek helytelen pinningje.
- Futási topológia: hoston helyes topológiafájlok vagy NCCL változók hiánya a konténer/launcher környezetben.
- Fabric és kollektív viselkedés: NCCL beállítások nem illeszkednek a célszövethez, üzenetmérethez vagy skálához.
- Alkalmazás–platform kötés: folyamatok magazonosító vagy rangsor szerinti kötése topology-aware affinity helyett.
Ezek nem az egyetlen okok; mindig valós alkalmazásokkal kell érvényesíteni a rendszert.
Esettanulmány 1 — GB200 NVL72: 12% lassabb FP8 MoE pre-training VM-ben, mint bare metal
Layer: virtualizáció és SMMU
A partner GB200 NVL72 rendszere DeepSeek‑V3 Mixture‑of‑Experts (MoE) FP8 előképzést futtatott VM-ben, iterációs idők 12–14%-kal hosszabbak voltak a bare‑metal referenciaarchitektúrához képest. Dense modellek (pl. Llama 3 70B) receptjei közel 3%-on belül futottak, azonban a MoE, amely sok kis kernel-t futtat iterációnként, kiugróan rosszabb volt.
Jel: NVIDIA Nsight Systems trace-ek magas CPU overheadet mutattak a kis kernel régióknál. Hoston végzett 30 másodperces perf mintavétel perf record -a -g, majd perf report elemzés 24% CPU-ciklust mutatott az arm_smmu_cmdq_issue_cmdlist függvényre.
Ok: under virtualizáció, minden map/unmap, ami guest invalidációt eredményez, host trap-et vált ki és serializálódik egyetlen SMMU parancssoron keresztül, ami spinlock contention‑t okoz.
Javítás: engedélyezték a CMDQV/VCMDQ támogatást a host kernelben (tegra241-cmdqv driver) és exponálták a guestnek. Modern QEMU/libvirt kiadások rendelkeznek cmdqv IOMMU attribútummal a vendég számára.
Eredmény: perf-ben eltűnt az arm_smmu_cmdq_issue_cmdlist top frame-státusza, a dTLB miss arány visszatért bare‑metal szintre, és a MoE iterációs idők 12%-os gapje RA tolerancián belülre szűkült.
Tanulság: Grace-alapú virtualizált telepítésekhez a VM‑stacknek ki kell exponálnia a megfelelő SMMU képességeket, különösen memóriamozgatás-igényes munkaterheléseknél; CMDQV/VCMDQ engedélyezése elkerüli az SMMU serializációját.
Esettanulmány 2 — H100: 12% veszteség CPU contention és NUMA misbinding miatt
Layer: CPU power és process placement
Egy H100 SXM5 klaszter Llama 3 70B pre-training alatt ~12%-kal lassabb volt a referencia értéknél. A különbség a kernelben nem jelentkezett, a problémák user-space és BIOS szinten voltak.
Jelzések:
- turbostat -i 1 mutatta, hogy a foglalt magok 3.0 GHz-en álltak, holott a SKU turbo 3.8 GHz. Az idle magok sem estek C6 állapotba, C1‑ben maradtak.
- numastat -p <python_pid> ~18% NUMA-remote memóriamozgást mutatott.
Okok:
- BIOS-ban a C‑state-ek C1‑re voltak korlátozva (alacsony késleltetésű alapértelmezett), ami tartotta az idle magokat magasabb energiafelvételen, így a foglalt magok nem kaptak elég package power‑t a turbo eléréséhez.
- Hypervisor housekeeping threadek ugyanazon fizikai magokon voltak, mint a training data loader worker‑ek, ami 50–100 ms szaggatást eredményezett a python szálakban.
Javítások:
- C‑state beállítások engedélyezése (engedni a C6‑ot), ami felszabadította a package power‑t: ~4% javulás.
- cpuset elkülönítés: hypervisor/host szolgáltatások magokra 0–7 és 56–63; training folyamatok a maradék magokon.
- numactl binding és egyéb izolációs lépések.
Eredmény: a 12%-os rés 3%-ra csökkent; a maradék különbség egy további NCCL hangolási problémából származott (lásd 3. eset).
Tanulság: több, kis hozzájárulású hiba összeadódhat; a legnagyobb javulást a C‑state engedélyezése hozta (~4%), további előny a process isolation és NUMA‑kötés révén.
Esettanulmány 3 — GB300 NVL72: ConnectX‑8 SuperNIC és alacsony QPS miatt alulhasznosított 1.6 Tbps fabric
Fókusz: ConnectX‑8 SuperNIC kollektív hangolás
Egy GB300 NVL72 telepítés NVIDIA ConnectX‑8 SuperNIC kártyákkal (1.6 Tbps/node) 31%‑os teljesítmény‑rést mutatott Nemotron‑4 15B pre-trainingnél. A single‑node áteresztőképesség rendben volt; a gap 512 GPU skálán jelentkezett, ahol AllGather és ReduceScatter idők voltak kitettségben.
Vizsgálat: nccl-tests és profilos futtatások változókkal (iterációk száma, UCX/UCC, NUMA mapping, NVLS, NCCL verziók) voltak tesztelve. A releváns beavatkozás: NCCL_IB_QPS_PER_CONNECTION növelése 1‑ről 4‑re.
Jel: Nsight Systems trace és nccl-tests mutatták, hogy alacsony QPS mellett AllGather és ReduceScatter idő jelentősen magasabb. Referencia cluster defaulttal ~1.09s/iter; QPS=4 esetén javult ~0.83s/iterre (egy összehasonlító futás ~0.76s volt, más NCCL verzióval).
Eredmény: AllGather idő ~375ms → ~262ms; ReduceScatter ~389ms → ~273ms. Verziókülönbség is hozzájárult a maradék eltéréshez; NCCL verziók összehangolása tovább csökkentette a részt.
Tanulság: ne növeld a QPS‑t mindenhol vakon — a QPS érték fabric‑ és munkaterhelésfüggő. A helyes eljárás a mérések futtatása a munkaterhelés valós üzenetméretein, a beállítás sweep‑elése a célszöveten, és a validálás a tényleges tanítási futtatáson.
Esettanulmány 4 — Hiányzó környezeti változó és topológia a konténeren belül
Egy virtualizált B200 telepítésben a training throughput 13–53% alatt volt a referenciához képest, miközben hoston futtatott nccl-tests megfelelt. Az enroot konténeren belül AllGather és ReduceScatter 2–4× lassabb volt.
Ok: a NCCL_TOPO_FILE=/etc/nccl/topo.xml környezeti változó és maga a /etc/nccl/topo.xml fájl a VM‑en be volt állítva, de a változó illetve a fájl nem volt propagálva/mount‑olva az enroot konténerbe. Ennek eredményeként NCCL visszaesett auto‑detektálásra a konténeren belül, ami 13–53% v. referenciagaphez vezetett.
Javítás: bind‑mount a topo.xml fájlba a konténerbe (--mount type=bind,source=/etc/nccl/topo.xml,target=/etc/nccl/topo.xml) és ellenőrizni a NCCL_TOPO_FILE és a fájl elérhetőségét a munkafolyamaton belül (például echo $NCCL_TOPO_FILE && cat $NCCL_TOPO_FILE a konténeren belül).
Tanulság: futtasd a checkeket abból a környezetből, amelyben a benchmark fut (konténer, launcher, Slurm allocation), ne a hostból. NCCL csendben bukik vissza auto‑detektálásra, így a topológia hiánya nehezen diagnosztizálható.
Összegzés: javítások és visszanyert teljesítmény
A négy esetből származó diagnosztikai jelzések és korrekciók jelentős részt hoztak vissza az elveszett teljesítményből (esetek alapján: ~12%, 9% [12→3], 31%, és 13–53% bezárása). A hibák gyakran több rétegen halmozódtak: kernel/virtualizáció, CPU/BIOS, NCCL/fabric, és runtime topológia láthatóan mind hozzájárulhatnak.
Preflight ellenőrzések a teljes méretű debug előtt
- GPU és hardver egészsége: nvidia-smi, DCGM — órajel, fogyasztás, termika, NVLink.
- Grace és VM readiness: perf, dmesg, kernel config — CMDQV támogatás, guest page size, IOMMU passthrough, large pages.
- CPU power és placement: turbostat, lscpu, numactl, nvidia-smi topo -m — busy‑core turbo, cpuset izoláció, NUMA/PCT binding.
- Runtime topológia: env, cat $NCCL_TOPO_FILE, NCCL_DEBUG=INFO — topológia fájlok és NCCL változók láthatósága a konténeren belül.
- Fabric collectives: nccl-tests és munkaterhelés trace‑ek — AllGather és ReduceScatter viselkedés a valós üzenetméreteken.
- Workload tuning: Nsight Systems, alkalmazás logok — pipeline parallelism, microbatch sizing, communication overlap csak miután a platform kérdések rendeződnek.
Végkövetkeztetés
A cloud‑ban futó tanítási munkaterhelmek és az NVIDIA referenciaarchitektúrák közti teljesítménykülönbségek gyakran apró konfigurációs hibák összegei. Előzetes platform‑ellenőrzések érdemben csökkenthetik a formális Exemplar Cloud validáció előtt fellépő kockázatokat, de a végső igazolás mindig a pontos validációs munkaterheléseken történő futtatás és a skálázás közbeni trace‑ek elemzése alapján derül ki.
További források
- 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 (például NCCL_IB_QPS_PER_CONNECTION)
- NVIDIA NeMo Framework (NGC konténerek frissítéseiért)
- NVIDIA Performance Explorer és Benchmarking Recipes
