Az NVIDIA szerint a beállításokon múlik az AI-klaszterek teljesítménye
Azonos NVIDIA H100, GB200 NVL72 vagy GB300 NVL72 hardveren is 8 és 12 százalék közötti teljesítménykülönbség alakulhat ki a klaszterek között. Az NVIDIA szerint a kernel, a virtualizáció, a BIOS, a NUMA-beállítások és az NCCL konfigurációja együtt okozhatja, hogy egy rendszer nem éri el a referencia-architektúra teljesítményének 95 százalékát.
- Azonos NVIDIA AI-hardveren 8 és 12 százalék közötti teljesítménykülönbség is kialakulhat.
- Az Exemplar Cloud validációjához a referencia-architektúra teljesítményének 95 százaléka szükséges.
- A GB200 virtuális gépének lassulását az SMMU parancssorának sorosítása okozta.
- A H100 klaszter 12 százalékos lemaradásában a C1-re korlátozott C-állapotok és a NUMA-elhelyezés is szerepet játszott.
- A diagnosztikához az NVIDIA perf, Nsight Systems és NCCL-méréseket javasol.
A konfigurációs részletek összeadódó hatása
Az NVIDIA Developer július 30-án közzétett bejegyzése az Exemplar Cloud validációjához kapcsolódó tapasztalatokat foglalja össze. A vállalat szerint a partneri telepítések gyakran elmaradnak a megfelelő NVIDIA referencia-architektúra teljesítményétől, még akkor is, ha ugyanazt a hardvert, modellt, munkaterhelést és globális kötegméretet használják.
A teljesítményvesztés sok esetben nem egyetlen látványos hibából ered. A kernel, a hipervizor, a BIOS és az NVIDIA Collective Communications Library, vagyis az NCCL beállításai külön-külön néhány százalékot vehetnek el, hatásuk azonban összeadódik. Ez különösen fontos az Exemplar Cloud esetében, ahol a validációhoz a telepítésnek el kell érnie a referencia-architektúra áteresztőképességének 95 százalékát.
Az NVIDIA négy valós partneri hibakeresési vizsgálatot ismertet. Ezek a Grace CPU-k virtualizációját és SMMU-kezelését, az x86-alapú H100-rendszerek processzorteljesítményét és NUMA-elhelyezését, az NCCL párhuzamosságát 1,6 Tbps sebességű hálózatokon, valamint a konténerekben hiányzó topológiai információkat érintik.
A GB200 virtuális gépe 12 százalékkal maradt el
Az első esetben egy GB200 NVL72-rendszeren DeepSeek-V3 Mixture-of-Experts, vagyis MoE, FP8 előtanítást futtattak virtuális gépen. Az iterációs idők 12 és 14 százalékkal voltak hosszabbak a bare metal referencia-architektúránál. A sűrű modellekhez, például a Llama 3 70B-hez használt előtanítási receptek három százalékon belül maradtak, a sok kis kernelt indító DeepSeek-V3 MoE azonban kiugróan lassú volt.
Az NVIDIA Nsight Systems nyomkövetése magasabb CPU-terhelést mutatott a kis kernelrégióknál. A hoston készített, 30 másodperces Linux perf mérés szerint a CPU-ciklusok 24 százalékát az arm_smmu_cmdq_issue_cmdlist függvény használta fel. Ez az Arm SMMU parancssorába küldött érvénytelenítési műveletekhez kapcsolódik.
Virtualizált környezetben minden vendégrendszerből érkező memória-leképezési művelet hostoldali csapdát és sorosítást okozott. A javítást a CMDQV, illetve VCMDQ engedélyezése jelentette a host kernelben, majd a képesség átadása a vendégnek. Ehhez az NVIDIA szerint a tegra241-cmdqv illesztőprogrammal fordított kernel, valamint megfelelő hipervizor-támogatás szükséges. A módosítás után a függvény kikerült a perf legfontosabb keretei közül, a dTLB-hibaarány pedig elérte a bare metal rendszer szintjét. Az MoE-iterációs idők különbsége így a referencia toleranciáján belülre került.
A H100 klaszternél a CPU és a NUMA-beállítás okozott gondot
A második vizsgálatban egy H100 SXM5 klaszter Llama 3 70B előtanítása 12 százalékkal lassabb volt az NVIDIA HGX referencia-architektúrájánál. A klaszter ugyanazt az NCCL-verziót és NeMo-konténert használta, ezért a hibát nem a kernelben, hanem a felhasználói tér és a BIOS beállításaiban találták meg.
A turbostat mérése szerint a terhelt processzormagok 3,0 GHz-en működtek, miközben a processzor névleges turbófrekvenciája 3,8 GHz volt. Az üresjárati magok szintén 3,0 GHz-en maradtak, a C-állapotuk pedig C1 volt a C6 helyett. A numastat mérés közben azt mutatta, hogy a tanítási folyamat memóriaeléréseinek hozzávetőleg 18 százaléka távoli NUMA-csomópontra irányult.
Az NVIDIA szerint a BIOS-ban a C-állapotokat C1-re korlátozták. Ez a késleltetés csökkentésére használt beállítás AI-tanításnál kedvezőtlen lehet, mert az inaktív magok így több csomagszintű energiát fogyasztanak. A vállalat által ismertetett diagnosztika szerint a C6 engedélyezése energiakeretet szabadíthatott fel a terhelt magok számára, amelyek így elérhették a 3,8 GHz-es turbófrekvenciát.
A hibakereséshez a saját klaszter mérései adhatnak támpontot
Az NVIDIA a bemutatott mintákat olyan infrastruktúra-mérnököknek és teljesítménytervezőknek ajánlja, akik már futtatják ezeket a referenciaértékeléseket. A cég szerint a Linux perf, az NVIDIA Nsight Systems és az NCCL-tesztek jelei segíthetnek azonosítani, hogy a teljesítményvesztés a virtualizációból, a processzor energiagazdálkodásából, a memória-elhelyezésből vagy a kommunikációs rétegből ered-e.
A reprodukcióhoz az NVIDIA HGX H100, HGX H200, HGX B200, GB200 NVL72 vagy GB300 NVL72 rendszerekből álló klasztert, NVIDIA Quantum InfiniBand vagy RoCE összeköttetést, stabil iterációs idejű elosztott tanítási munkaterhelést, valamint root hozzáférést ír elő. A vizsgálatokhoz az adott tanítási veremmel azonos NCCL-verzióra fordított nccl-tests, NVIDIA Nsight Systems és kernel-szimbólumokkal használható Linux perf is szükséges.
A bemutatott esetek a felhasználóknak azt jelzik, hogy az AI-infrastruktúra teljesítményét nem lehet kizárólag a gyorsítók típusa alapján megítélni. Az NVIDIA szerint a referencia-architektúrához közeli eredményhez a teljes szoftveres és hardveres környezetet a konkrét munkaterheléshez kell igazítani, majd valós alkalmazásokkal ellenőrizni.
NVIDIA Developer: NVIDIA Exemplar Cloud: Lessons for Unlocking Full Performance on AI Infrastructure
