Az elosztott AI-munkaterheleteknél egyetlen hiba számos tünet láncolatát indíthatja el: egy GPU- vagy fabric-esemény NCCL-hibaként jelenhet meg más rangokon, ütemező-állapotváltozásokat generálhat, illetve több ezer downstream üzenethez vezethet. A végül riportált kivétel csak azt mutatja meg, hol állt meg a munkamenet, nem pedig azt, hogy hol indult a hiba.
NVIDIA Attribution egy olyan munkaterhelés-központú hibahatározó rendszer, amely munkaterhelésre szűkített naplókat, metrikákat, telemetriát és ütemező állapotot kapcsol össze, majd strukturált diagnózist ad vissza: kimenet (outcome), gyökéroka (root cause / sub_domain), érintett node-ok, támogató tünetek és az evidenciát követő nyomvonal. A munkaterhelés-központúság azt jelenti, hogy a hibák vizsgálatát a munkaterhelet kontextusában végzi, nem pedig elkülönített node-eseményekként. Determinisztikus szabályok garantálják az ismételhetőséget és testreszabhatóságot, a strukturált kimenet pedig lehetővé teszi az integrációt meglévő egészség- és helyreállító rendszerekkel.
NVIDIA Attribution-t évek óta használják éles környezetben az NVIDIA AI-infrastruktúrában: hetente több millió munkaterheletet elemeznek több százezer GPU-n. Egy nagy, RDMA-t támogató klaszterben például a rendszer porthibákat, kapcsolat-visszaállásokat és ütemező eseményeket kapcsolt össze, így mintákat talált speciális host- és switch-portok körül, és ezzel célzottan segítette a fabric javítását és a torlódás hangolását.
Komponensek és működés
NVIDIA Attribution kettő telepíthető részből áll: az NVIDIA Attribution Service és az NVIDIA Attribution Blueprint; mindkettő egy központi attribution engine-t használ. A Service REST API-n keresztül elérhetővé teszi az attribúciót; a Blueprint összeköti a klaszter ütemezőit és telemetria-forrásait a Servicel, és írja a strukturált eredményt.
A szolgáltatás egy munkamenet-kísérletet (workload attempt) elemez egyszerre. A Blueprint gyűjti össze a munkaterhelés kontextusát és bizonyítékait, a Service kinyeri és korrelálja az eseményeket, majd a Blueprint visszaad egy strukturált diagnózist. A folyamat négy fő lépésből áll:
- Munkaterhelés körének meghatározása: a Blueprint azonosítja a workload-attemptet ütemezőazonosítók vagy explicit végrehajtási ablak és node-allokáció alapján.
- Megfigyelések gyűjtése: napló- és metrika-connectorok előállítják a munkaterhelésre szűkített Observation rekordokat alkalmazásnaplókból, syslogból, GPU-driver és Fabric Manager üzenetekből, ütemező történelemből, node- és hálózati metrikákból.
- Események kinyerése és korrelálása: az attribution engine felismeri a jelentős eseményeket (pl. GPU XID-ek, NCCL-hibák, ütemező-átmenetek, metrikafeltételek). Determinisztikus szabályok vizsgálják ezek időbeli egymásra hatását, elkülönítik a downstream tüneteket attól az eseménytől, amely a hibát kiváltotta, és beazonosítják a gyökérokat.
- Strukturált eredmény visszaadása: a Blueprint egyesíti az ítéletet a munkaterhelés kimenetével (terminal_state), az attribúciós doménnel (sub_domain), a tünetekkel, érintett node-okkal és a gyűjtők lefedettségének/hibáinak rekordjával.
Gyakorlati példa: alkalmazásnaplóktól az attribúcióig
A cikk egy bemutató példán keresztül mutatja be az adatok kinyerését, az események értelmezését és a tünetlánc megőrzését. Tegyük fel, hogy egy több rangos (multi-rank) tréning munkafolyamatnál egy GPU kemény hibát kap (például XID 149), és ezt követően NCCL-hibák jelennek meg más rangokon. NVIDIA Attribution összekapcsolja a csomópontok közti eseményeket, a XID-et gyökérokra mutatóként azonosítja, miközben a NCCL-hibákat megőrzi a tünetláncban, és megnevezi a felelős node-ot. A riport hardverhibaként jelenti a munkaterhelést, nem pedig független kommunikációs hibák halmazaként.
Egy sikertelen kollektív művelet több node-on hagyhat hibajelentéseket; ezek megmutatják, hol vette észre a munkaterhelés a problémát. Az Attribution magyarázatához ezeket más források bizonyítékaival kombinálja és a tüneteket együttesen értékeli.
A példában az alkalmazásnaplók három különböző NCCL-hibát tartalmaznak. A node-02 rendszerlogjaiban szerepel az XID 149, amelynek hibaszavai NVLink jelintegritási problémára dekódolhatók. Az alábbiakban ez az evidenciaként végighalad a szabálypipeline-on.
Kinyerés és szűrés
Az Extraction fázis fut először: a nyers naplókból strukturált, típusos eseményeket állít elő forrásprovenienciával, amelyeket a későbbi fázisok dolgoznak fel. A szűrőszabályok (filter rules) olvassák és módosítják az eseménysort; az EARLY szakaszban futó HandleXidBurstEvents szabály dekódolja az XID-burstot, kiad egy attribúciós eseményt NVLink jelintegritási problémára vonatkozóan a node-02-re, miközben a három NCCL-esemény változatlan marad.
Finomítás és végső attribúció
A framework eseményeket per-node tünetekké materializál, node-szintű „scrubbing”-ot futtat, majd az életben maradt tüneteket összegzi a teljes munkára. A bemutatott szintetikus példában mind a négy jelölt eljut a FINAL finomításig. A Xid149AndNvlinkFiltering megőrzi a jelintegritási tünetet és visszasorolja a többi node-tünetet; a Gb200PriorityRootCause csökkenti az aktív, teljes munkára vonatkozó tünetkészletet, majd az outcome mapping hardverhibaként rögzíti az attribúciót. Az attribúció megnevezi a node-02-t és a jelintegritási problémát, miközben a NCCL-raportok „érdekes” bizonyítékként megmaradnak a további vizsgálathoz.
Amikor több ok is megfelel az evidenciának, a sub_domain lehet kétértelmű; az attribúció minősége a telemetria minőségétől és teljességétől függ. A diagnózis rögzíti ezt a bizonytalanságot ahelyett, hogy hiányos adatokból tévesen egyértelmű következtetést vonna le.
Architektúra: Service és Blueprint
Az attribution engine maga tartalmazza a szabálymotorlogikát és az alapvető attribúciós mechanikát. Az Attribution Service HTTP API-n keresztül expozícionálja ezt a logikát; a Blueprint a klaszter-specifikus integrációkat kezeli. Ez a szétválasztás lehetővé teszi, hogy ugyanazt a szabálykészletet különböző klaszterekre alkalmazzák, miközben a scheduler-, telemetria- és output-connectorokat a környezethez igazítják.
Attribution Service: egy self-hosted HTTP wrapper, amely normalizált observation-öket kap és munkánként egy végső ítéletet ad vissza.
Attribution Blueprint: Python referenciális orchestrator, amely felfedezi a munkákat, feloldja az ExecutionContext-et, futtatja a collectorekat, hívja a Service-t, gazdagítja az ítéletet, írja az AttributionBlueprintResult-ot és biztosít egy read-only dashboardot. Ezt referencia-implementációnak szánják, amelyet a gyakorlatban testreszabhatnak.
A Blueprinthez járnak csatlakozók és példák: Execution-context connectorok Slurm, Kueue és statikus inputokhoz; log- és metrika-connectorok Lokihoz, lokális fájlokhoz, Kubernetes pod logokhoz és PromQL-metrikákhoz; output-connectorok stdout és SQLite számára. Blueprintek a klaszter adataihoz közel futtathatók, egy dedikált Attribution Service-szel vagy megosztott Service-szel több Blueprint számára.
Kiterjesztés saját infrastruktúrára
Mivel NVIDIA Attribution nyílt forrású, az infrastruktúra-csapatok egyszer megírt hibamintákat több munkára és klaszterre alkalmazhatják. Fejlesztők új szabályokat adhatnak hozzá új hibamódokhoz, készíthetnek connectorokat ütemezőikhez és telemetria-backendjeikhez, valamint irányíthatják az AttributionBlueprintResult rekordokat incidens-, helyreállítási és fleet-management rendszerekbe. Mivel az integrációk ugyanazokat az ExecutionContext, Observation és eredmény-szerző szerződéseket használják, az új csatlakozások ugyanazon diagnosztikai pipeline-t táplálják.
Gyakorlati bemutató és gyorsstart
A cikk végigvezeti az olvasót egy példán: NVLink-hiba bizonyítékainak elemzése rögzített tréning munkavégzésből. A bemutató két komponensre támaszkodik: az Attribution Service-re (elemzést futtató), és az Attribution Blueprint-re (munka kontextust és naplókat olvasó, a Service-t meghívó és az eredményt lokálisan tároló, dashboardot biztosító). A minta bizonyítékok a repozitóriummal együtt érkeznek, így a vizsgálat élő klaszter csatlakoztatása nélkül követhető.
Gyorsstart parancsok (példa a repozitórióra mutató git clone utasítással):
- git clone https://github.com/dsx-ai-factory/attribution.git nvidia-attribution
- cd nvidia-attribution
- docker build -f blueprint/docker/Dockerfile -t attribution-blueprint-web:quickstart "$PWD"
- mkdir -p .attribution-sample
- docker run -d --rm --name attribution-blueprint-web-local -e ATTRIBUTION_DB=/data/attributions.db -p "127.0.0.1:8000:8000" -p "127.0.0.1:8080:8080" -v "$PWD/.attribution-sample:/data" attribution-blueprint-web:quickstart
- uv run --project blueprint --frozen nvidia-attribution-blueprint --configs blueprint/examples/static/configs --connector attribution service_url http://127.0.0.1:8000 --connector output db sqlite path .attribution-sample/attributions.db
Ezt követően a http://127.0.0.1:8080 oldalon meg lehet nézni az egyes munkák diagnózisát, érintett node-jait, támogató tüneteit és az evidencia-nyomvonalat.
Szabályok, tesztek és szerkeszthetőség
A szabálymotor deklaratív és Python-szabályokat használ. A példában szereplő gyártásra használt szabály felismer egy érvénytelen Pyxis-argumentumot az alkalmazásnaplóban, és mellé egy helyben futtatható tesztesetet tartalmaz. A Service indításakor betölti a beépített szabálykatalógust és értékeli az inline teszteseteket. A szabályváltozások a Service-sel együtt kerülnek commitolásra és szállításra; a szabályok nem kerülnek dinamikusan feltöltésre az HTTP API-n keresztül. A repository rule-authoring guide-ja ismerteti, hogyan kell megfelelő szabályformát választani, új tüneteket regisztrálni, teszteket hozzáadni és a katalógust ellenőrizni.
Kezdés
Klónozza az NVIDIA Attribution repozitóriumát és kövesse a quickstartot a példa futtatásához és a diagnózisok megtekintéséhez. Saját infrastruktúrával való használathoz nézze meg a Blueprint konfigurációs referenciát a scheduler- és telemetria-csatlakozókhoz, és a dokumentációt arról, hogyan adhat hozzá új extractor szabályt új bizonyítékmintákhoz.
Köszönetnyilvánítás
Aaron Blakeman, Ajay Hotchandani, Alex Shaposhnikov, Ashwin Poojary, Ben Gueret, Chunyang Sheng, Dorrin Poorkay, Gargi Prasad, Felix Abecassis, Grace Tan, Jason Sewall, Mayuri Gupta, Pasha Shamis, Pavan Kumar Gondhi, Piero Orderique, Rahul Kandu, Rakesh Konda és Sirshak Das hozzájárultak az NVIDIA Attributionhoz és a cikk tartalmához.
