Մեկ պարբերության տարբերակը. GB10-ի վրա dcgm-exporter-ը չի գործում, իսկ NVML-ը N/A է պատասխանում այն ամենի զգալի մասին, ինչի վրա օպերատորներն ալերտ են դնում։ Հուսալի ուղին nvidia-smi-ն textfile collector-ի միջով node-exporter-ի մեջ պարսելն է՝ հնացածության ալերտով հենց կոլեկտորի վրա։ Մանրամասները, և թե ինչու է խափանումն այդքան լավ թաքնվում, ստորև են։
Կա կոնկրետ պահ, որին հասնում է DGX Spark-ի ամեն օպերատոր։ Մոդելը սպասարկվում է, vLLM-ը պատասխանում է, Grafana-ի դաշբորդը հավաքված է ճիշտ այնպես, ինչպես տարիներ շարունակ հավաքվել է ամեն CUDA տուփի վրա։ Եվ դաշբորդը կանաչ է։ Կանաչ, դատարկ և ստում է. պանելների կեսը ոչ մի տվյալ ցույց չի տալիս, մյուս կեսը՝ գծիկներ, և ոչ մի տեղ ոչինչ չի ասում՝ ինչու։
Ինչն է իրականում կոտրվում GB10-ի վրա
Այս սարքաշարի վրա իրար վրա են դրվում երկու առանձին խափանում, և դրանք թաքցնում են միմյանց։
dcgm-exporter-ը GB10-ի վրա չի գործում։ Ստանդարտ կոնտեյները, որը NVIDIA-ի տվյալների կենտրոնի սարքաշարի վրա GPU մետրիկաները սնում է Prometheus-ին, Spark-ի unified-memory դիզայնի վրա չի աշխատում։ Ընդ որում՝ աղմուկով չի էլ ընկնում։ Ստանում եք exporter, որն աշխատում է, և դաշբորդ, որի հետևում ոչինչ չկա։
NVML-ը հարցումների զգալի մասին պատասխանում է N/A։ Գրադարանը, որ ընկած
է nvidia-smi-ի և մոնիտորինգային Python-սնիպետների մեծ մասի տակ, N/A է
վերադարձնում շատ դաշտերի համար, որոնց վրա օպերատորները ալերտ են դնում, —
առաջին հերթին հիշողության թվերի։ Unified memory-ն կոտրում է այն
ենթադրությունները, որոնց վրա կառուցվել են այդ հաշվիչները. առանձին VRAM
լողավազան, որի մասին հաղորդես, չկա, ուստի գործիքակազմը, որ դրան սպասում է,
ոչինչ չի հաղորդում։
Համադրությունը տհաճ է հենց նրանով, որ ամեն կեսը նման է մյուս կեսի մեղքին։ Exporter-ը լուռ է, ուստի ստուգում ես գրադարանը; գրադարանը N/A է պատասխանում, ուստի ենթադրում ես, որ exporter-ն էլ նույնը կաներ, և դադարում ես փորել։ Մինչ այդ տուփը պրոդակշնում սպասարկում է 284B պարամետրանոց MoE՝ առանց որևէ աշխատող GPU թելեմետրիայի։
Ինչն է աշխատում. nvidia-smi՝ պարսված, textfile collector-ի միջով
Spark-ի վրա nvidia-smi-ի սովորական տեքստային ելքն ավելի ազնիվ է, քան նրա
տակ գտնվող գրադարանները։ Դաշտերը, որոնք պատասխանում են, պատասխանում են
իրական արժեքներով։ Ուստի կոլեկտորը, որ մենք վարում ենք, միտումնավոր
ձանձրալի է.
- systemd timer-ը կարճ ինտերվալով գործարկում է
nvidia-smi։ - Փոքր սկրիպտը պարսում է միայն այն դաշտերը, որոնք GB10-ի վրա իրոք
պատասխանում են, և գրում դրանք որպես Prometheus մետրիկաներ
.promֆայլի մեջ։ - node-exporter-ի textfile collector-ը ֆայլը վերցնում է հոսթի մնացած մետրիկաների հետ միասին։
- Մեկ լրացուցիչ մետրիկա կրում է կոլեկտորի սեփական վերջին գործարկման timestamp-ը, և ալերտը կրակում է հնացածության վրա։ Մոնիտորինգի խողովակը, որը կարող է լուռ մեռնել, հենց այն հիվանդությունն է, որին այս էջը նվիրված է; բուժումը պետք է տարածվի նաև բուժման վրա։
Ոչ մի դեմոն այն ամենից բացի, ինչ հոսթն արդեն վարում է, ոչ մի արտոնյալ sidecar, և ամեն մետրիկա, որ հասնում է դաշբորդ, մեկն է, որի պատասխանելը այս սարքաշարի վրա մարդ է ստուգել։ Ամբողջական վերլուծությունը՝ պարսինգի մանրամասներով, հրապարակված է Habr-ում՝ ռուսերեն; բաղադրատոմսը, որին այն պատկանում է, — այս կայքում։
Ինչու ենք սա բարձրաձայն ասում
Որովհետև խափանման այս ռեժիմն անտեսանելի է ըստ կառուցվածքի։ Բացակայող մետրիկան ոչ մեկին չի արթնացնում։ Թիմերը բացահայտում են, որ իրենց Spark-ի թելեմետրիան հորինվածք է, առաջին անգամ, երբ ինչ-որ բան սխալ է գնում, և դաշբորդն այդ մասին ասելիք չունի, — ինչը հայտնագործության համար հնարավոր ամենաթանկ պահն է։
Մեր դիրքորոշումը, արտահայտված այս սարքաշարի գնորդական պատասխանում, ուժի մեջ է. սերվինգ-տուփը, որը չես կարող դիտարկել, տուփ է, որը չես կարող շահագործել։ Spark-ը շահագործելի է։ Այն պարզապես դիտարկելի չէ ստանդարտ ստեկով, և ստանդարտ ստեկում ոչինչ ձեզ այդ մասին չի ասում։
Շրջանակ
Սա նկարագրում է մեր լաբորատորիայի GB10 միավորները՝ bring-up-ի պահին ընթացիկ firmware-ով և դրայվերային ստեկով, vLLM-ով սերվինգի պայմաններում։ Մոնիտորինգի վարքը կարող է փոխվել դրայվերների թողարկումների հետ; կոլեկտորային մոտեցումն այդ փոփոխությունները տանում է ավելի լավ, քան գրադարանային binding-ները, — մասամբ հենց դրա համար ենք այն ընտրել։ Այստեղ ոչինչ պնդում չէ տվյալների կենտրոնի Blackwell-ի մասին, որտեղ dcgm-exporter-ը ճիշտ պատասխանն է։