Teljes körű observabilitás kiválasztása NVIDIA AI-farmokhoz

Az AI‑infrastruktúra több rétegből áll: platform hardver (tápegység, ventilátorok, BMC, stb.), GPU‑k, hálózati és rack‑szintű összeköttetések, klaszter‑ és munkamenedzsment, valamint az alkalmazási/inferencia szint. Amikor a teljesítmény romlik, a tünetek gyakran egy rétegen látszanak, miközben az oka máshol van a veremben. A teljes veremre kiterjedő observabilitás összekapcsolja a telemetriát ezekben a rétegekben, hogy a műveleti csapatok gyorsan felismerjék a hibákat, izolálják azok okát, és megőrizzék a megbízható AI‑munkaterhelést.

Ez a cikk gyakorlati megközelítést mutat be az NVIDIA AI infrastruktúrára: hogyan nevezd meg az észlelendő meghibásodási tartományokat, hogyan térképezd fel a komponenseket a megfelelő telemetria‑eszközökre, és hogyan redukáld a jeleket egy rövid, döntésre alkalmas riasztáskészletre és egyetlen triage‑dashboardra.

Klasszikus példa: szürkészónás hiba és kaszkádhatás

Gondoljunk egy elosztott edzésfeladatra, amely már három napja fut. A GPU‑kihasználtság és a várakozási idők látszólag normálisak, de hat óra csökkent áteresztőképesség után a csapat egyetlen InfiniBand‑link megnövekedett bit‑hibaarányát (BER) azonosítja. Ez tipikus "gray failure": a hardver nem áll le teljesen, de degradáltan működik.

AI edzésekben, ahol a Bulk Synchronous Parallel (BSP) modell a jellemző, a szorosan összekapcsolt rangok (ranks) közül egy lassú egység lefékezi az egész munkát. Link‑szintű újraküldések blokkolhatnak egyetlen rangot szinkron kollektív műveletek (például az NVIDIA Collective Communications Library – NCCL – all‑reduce) közben, és a teljes throughput a leglassabb rang sebességére esik. Ez egy kaszkád‑szerű lelassulást okoz, amely nagy GPU‑időveszteséget eredményezhet.

Figyelési tartományok: mit kell látnod

Mielőtt monitoring szoftvert választasz, sorold fel azokat a meghibásodási tartományokat, amelyek „csendes” hibái GPU‑órákat fogyasztanak:

• Platform health: ventilátorok, tápegységek (PSU), BMC, chassis, CPU, memória, helyi tároló.
• GPU health and performance: kihasználtság, hőmérséklet, fogyasztás, XID/ECC események, NVLink‑throughput.
• Fabric: InfiniBand vagy Ethernet link integritás, torlódás, switch/kábel állapot; rack‑szintű NVLink ha van.
• Cluster and jobs: ütemezés, foglalások, idle allokált GPU‑k, queue várakozás.
• Inference services: késleltetés, sikeresség, cache viselkedés (NVIDIA NIM vagy hasonló mikro szolgáltatásoknál).

Komplex rendszerekben a lefedetlenségek ritkán tűnnek el egyetlen lépésben; gyakran csak terhelés alatt jelennek meg. Ezért elemezni kell a latent failure mode‑okat, és úgy tervezni a telemetria kiválasztását, hogy a későbbi terheléses hibákat megelőzd.

Komponens→eszköz térkép: döntési keret

A működtetési csapatoknak legyen világos térképe arról, hogy melyik komponens melyik telemetria‑forrást adja. Egy NVIDIA DGX telepítéseken alapuló döntési keret a következő eszközöket használja: NVIDIA Data Center GPU Manager (DCGM), NVIDIA System Management (NVSM), NVIDIA Unified Fabric Manager (UFM), NVIDIA NetQ, NVIDIA NMX, NVIDIA Base Command Manager (BCM), NVIDIA Run:ai és Redfish/IPMI.

A gyakorlatban az ajánlott lefedettség (teljes támogatás = zöld, részleges = sárga):

• Redfish/IPMI: alapinfrastruktúra, compute node szintű platform állapot.
• DCGM: GPU‑szintű telemetria (kihasználtság, fogyasztás, hőmérséklet, XID/ECC, NVLink).
• NVSM: DGX‑osztályú rendszerek rendszer‑egészség összegzésére.
• UFM: InfiniBand port egészség, BER, torlódás és routing.
• NetQ: Ethernet/RoCE fabric láthatóság.
• NMX: rack‑szintű NVLink telemetria (ha rack‑NVLink van).
• BCM: klaszter aggregátor, munkák és foglalások, konszolidált hardverriasztások.
• Run:ai és NIM: munkaszervezés/üzemeltetési igényeknél és inference SLO‑knál.

Kulcsfontosságú választási irányok:

• DCGM vs NVSM: DCGM a GPU‑metrikák Prometheus‑exportjára ideális; NVSM hasznos DGX‑csomagok rendszer egészségátfogó jelzésére. Mindkettő kiegészíti, de nem helyettesíti a BMC/Redfish adatait.
• UFM vs NetQ: válassz hálózati típustól függően (InfiniBand → UFM, Ethernet/RoCE → NetQ). Mindkettő csak akkor kell, ha mindkét fabric jelen van.
• NMX csak rack‑NVLinkhez szükséges; klasszikus több‑node NVLink topológiáknál DCGM lefedheti az interconnecteket.
• BCM legyen a klaszter és munkaszintű aggregátor; ne használd alacsony szintű számlálók forrásaként.
• Run:ai és NIM csak akkor kerüljenek be, ha a scheduler fairness vagy inference SLO‑k üzemeltetési követelményként megjelennek.

Általános szabály: takard le minden zöld cellát a lehető legkevesebb eszközzel. Felesleges exporterek csak zajt és riasztási fáradtságot okoznak.

InfiniBand DGX klaszterre alkalmazott döntés — példaprojekt

Példa: DGX klaszter InfiniBanddal, BCM‑mel és Slurm‑lal; jellemzően edzésmunkák, inference még nem termelésben. Cél: egyetlen triage dashboard és riasztások, amelyek megfogják a fabric vagy GPU regressziókat, mielőtt többórás GPU‑veszteség történne.

Döntési lépések:

• Scope: platform, GPU, InfiniBand fabric, cluster/jobs. Kizárva kezdetben: NetQ, NMX, Run:ai, NIM.
• Eszközök: Redfish/IPMI minden nodera, DCGM minden GPU‑csomagra, NVSM DGX‑okra rendszer egészségért, UFM a fabric‑telemetriáért (port health, BER, congestion, routing), BCM klaszter aggregátorként.
• Indoklás: csak DCGM nincs meg a BER‑típusú regresszió detektálásához; UFM‑mel együtt fedjük le a tail‑at‑scale problémákat. BCM önmagában nem adja az alacsony szintű counters‑t; kombinációjuk ad konszolidált, műveleti riasztásképes nézetet.
• Kizárások: NetQ/NMX/inference‑metrikák kihagyása, amíg Ethernet vagy rack‑NVLink, illetve inference production nem jelenik meg.

Ez az alap stack tehát: Redfish/IPMI, DCGM, NVSM, UFM és BCM, mind Prometheus/Grafana‑ba gyűjtve.

Rövid, cselekvésre alkalmas riasztáskészlet (top‑k)

A legtöbb eszköz százszámra ad metrikát; jobb egy rövid, SLI/SLO‑hoz kötött top‑k riasztáskészlet, ahol minden riasztás mögött világos javító lépés áll. Példák kezdeti metrikákra InfiniBand klaszter esetén:

• Platform (Redfish/IPMI): ventilátor fordulatszámok (SPD_FAN_), PSU státusz (PWR_), kulcs hőmérsékletek (TEMP_*).
• GPU (DCGM, NVSM): DCGM_FI_DEV_GPU_UTIL, DCGM_FI_DEV_MEM_COPY_UTIL, DCGM_FI_DEV_POWER_USAGE, DCGM_FI_DEV_XID_ERRORS; plusz NVSM szerinti GPU/system health riasztások.
• InfiniBand (UFM Telemetry): PortXmitDataExtended, SymbolErrorCounterExtended, Effective_BER, Total_Raw_BER, Chip_Temp.
• Jobs (BCM/Slurm): futó jobok száma, GPU foglalások, várakozási idő, hogy a fabric/GPU riasztások munkára gyakorolt hatása mérhető legyen.

Bővítsd a listát csak akkor, ha egy incidens mutatja a hiányt. Riasztson tünetekre, amelyekhez meghatározott művelet tartozik (node leürítése, kábel csere, fabric esett feljegyzés), ne minden egyes számlálóra.

A Prometheus‑exporterek előnyösek, mert DCGM és NVSM natív Prometheus végpontokat ad; UFM és BCM exportálható vagy API‑n keresztül hozható be ugyanabba a scrape modellbe, így egyszerű marad a protokoll‑kezelés.

Egyetlen triage dashboard felépítése

Ha megvannak az eszközök és a top‑k metrikák, építs egy egységes triage dashboardot:

• Telepíts IPMI és DCGM exportereket minden GPU nodera.
• Futtasd az UFM Telemetry‑t ott, ahol a fabric elérhető; scrape‑eld Prometheusba.
• BCM maradjon a klaszter kezelő és aggregáló réteg.
• Grafana‑t mutasd a Prometheusra, hogy egy nézetben lásd GPU, node és fabric jeleket.
• Ha szükséges, adj hozzá közösségi Slurm dashboardot, ha job‑szintű kontextus nincs elérhető a BCM‑ben.

Használj kétrétegű monitoringot: Layer 1 egy magas szintű triage nézet (gyorsan eldönti: GPU, node vagy fabric a hibás domain), Layer 2 pedig a részletes vendor UI‑k (UFM web UI, BCM Base View stb.) a root cause vizsgálathoz. Day‑2 üzemeltetés gyorsabb, ha az első board megválaszolja a triage‑kérdést.

Elfogadási kritériumok és bővítési sorrend

Készen állsz a következő fázisra, amikor:

• Minden in‑scope meghibásodási tartományban legalább egy full‑support eszköz van.
• A riasztások rövid top‑k metrikalistához kötöttek, egyértelmű tulajdonossal és akcióval.
• GPU, node és fabric jelek közös idősoron láthatók egy nézetben.
• További eszközöket (Ethernet, rack‑NVLink, Run:ai, NIM) csak szükség esetén adsz hozzá.

Bővítési sorrend (ajánlott): DCGM GPU telemetria engedélyezése, NVSM DGX rendszer egészségének validálása, fabric láthatóság UFM‑mel vagy NetQ‑vel a hálózattól függően, BCM a klaszter aggregálására, majd NIM Operator az inference observabilitáshoz. Mindig használd a döntési keretet az egyes kiegészítések igazolására.

3‑lépéses bevezetési ellenőrzőlista

1. Lefedettség kialakítása: válassz egy full‑support eszközt minden in‑scope tartományra (Table 1 alapján).
2. Exporterek integrálása: Redfish/IPMI, DCGM, NVSM, UFM és BCM összekötése Prometheus‑szal; Grafana‑nak mutasd a központi scrape‑végpontot.
3. Felelősség kiosztása: minden riasztáshoz rendelj tulajdonost és playbook‑akciót, mielőtt új exportert adsz hozzá.

Ne a dashboardok számával mérd az observabilitás érettségét, hanem azzal, hogy a jelek megnevezik‑e a hibás komponenst és a következő teendőt, mielőtt jelentős számítási kapacitás veszne el.

Összefoglalás

Egy döntési keret és egy rövid, akcióorientált riasztáskészlet jobb eredményt hoz, mint sok, rendszertelenül gyűjtött metrika. NVIDIA DGX és HGX telepítések azonos observabilitási felületet igényelnek ugyanabban a sorrendben: határozd meg a tartományokat, válassz egy teljes támogatást nyújtó eszközt tartományonként, gyűjtsd össze a legfontosabb metrikákat Prometheus/Grafana‑ba, és építs egy Layer‑1 triage dashboardot, amely gyorsan megmondja, hol kezdj keresni a Layer‑2 részletes eszközökkel.

A végcél: kevesebb, de releváns jel és egyetlen triage nézet, amely megóvja a GPU‑időt a csendes, újra és újra ismétlődő hibáktól.