NVIDIA és az izlandi Nscale közös értékelése a DSX MaxLPS dinamikus, politika-alapú fogyasztáskezelését vizsgálta Nscale Verne kampuszán (Keflavík, Izland), ahol az adatközpont kizárólag megújuló energiával működik. A teszt Kimi K2.5 munkaterheléseket futtatott NVIDIA Blackwell Ultra GPU-kkal NVL72 rendszeren; a cél az volt, hogy ugyanazon, jóváhagyott 264,4 kW-os provisionált teljesítménykeret mellett több GPU-t üzembe lehessen helyezni. Az eredmény: a statikus, csúcsteljesítményre méretezett referencia konfiguráció 140 GPU-t kezelt, míg a DSX MaxLPS használatával 192 GPU-t lehetett kezelni (+37,1%), az aggregált átviteli teljesítmény 1,084,503-ról 1,618,443 token/s-re nőtt (+49,2%).
Mi a probléma a statikus méretezéssel?
Az AI-farmok elektromos korlátok hierarchiájában működnek: szolgáltatókapacitás, transzformátorok, elosztóberendezések, rackek, szerverek és maga a GPU mind saját engedélyezett határértékkel rendelkezik. A hagyományos, statikus tervezés gyakran minden node esetében tartalékol annyi teljesítményt, mintha egyszerre érnék el a csúcsot, pedig a valós AI-munkaterhelések váltakozó fogyasztásúak (például training: számítás, kommunikáció, checkpoint; inference: prefill, decode, memória- és hálózati műveletek, idle). Ez a tartalék és a tényleges fogyasztás közt rést hoz létre: szabad kapacitás egy node-on nem mozgatható át automatikusan más node-okhoz, így a teljes létesítmény alatt használhatóság mellett maradhat.
Mit csinál a DSX MaxLPS?
A DSX MaxLPS valós időben figyeli a fogyasztást és politika-vezérelt módon osztja szét az elérhető teljesítményt a részt vevő erőforrások között úgy, hogy az üzemeltető összesített költségvetését és a megadott határokat betartja. Ez nem a site áramellátásának növelése, hanem koordinált újraelosztás a meglévő, jóváhagyott határokon belül.
A vezérlési ciklus elemei
- Topológia és erőforrás-csoportok: az üzemeltető leképezi a résztvevő infrastruktúrát és egy csoportba szervezi a node-okat aggregált teljesítménykerettel.
- Telemetria: GPU-, node-, rack- és csoportszintű fogyasztási adatok gyűjtése időközönként, hogy észlelhető legyen a kihasználatlan tartalék és a kialakuló események.
- Politika: az üzemeltető által definiált szabályok határozzák meg a node-korlátokat, csoport-korlátokat, prioritásokat, tartalékokat és reagálást karbantartási vagy vészhelyzet esetén.
- Allokáció és vezérlés: ha egyes erőforrások kevesebbet fogyasztanak, a szoftver módosítja a részt vevő GPU-k teljesítménykorlátját, hogy mások használhassák a felszabadult kapacitást.
- Validáció és érvényesítés: a tényleges fogyasztás összevetése a jóváhagyott csoport-költségvetéssel és allokációk módosítása, ha a fogyasztás közelít a határhoz.
Az értékelés körülményei
A tesztet Nscale adatközpontjában végezték: NVIDIA telemetriát és munkaterhelés-futtatást használtak a kontroll és összehasonlítás érdekében. A hardver és szoftver részletei:
- GPU: NVIDIA Blackwell Ultra
- Munkaterhelés: Kimi K2.5 FP4, NVIDIA Dynamo, NVIDIA TensorRT LLM
- Bemeneti hosszak: 8K token input, 1K token output
- Keverék: magas áteresztőképességű és alacsony késleltetésű inference példányok vegyesen
A statikus referencia: 35 darab négy-GPU-s node (összesen 140 GPU): két magas-áteresztőképességű instance 52 GPU-val és egy alacsony-késleltetésű instance 36 GPU-val. A DSX MaxLPS konfiguráció: 48 darab négy-GPU-s node (összesen 192 GPU), amely megtartotta a 36-GPU-s alacsony-késleltetésű példányt és hozzáadott egy harmadik 52-GPU-s magas-áteresztőképességű példányt.
A munkák négy racken futottak, minden elosztott munkaterhelés ugyanazon rackre korlátozva mindkét konfigurációban, hogy a rackek közötti teljesítménykülönbségeket kontrollálják.
Mért eredmények (összehasonlítás)
- Provisionált teljesítménykeret: 264,4 kW (mindkét konfiguráció ugyanazt használta)
- Kezelt GPU-k: 140 → 192 (+37,1%)
- Aggregált throughput: 1,084,503 token/s → 1,618,443 token/s (+49,2%)
- High-throughput kimenet per instance: 59,153 → 59,220 token/s (+0,1%)
- Low-latency kimenet per instance: 2,265 → 2,265 token/s (0%)
- Átlagos GPU-fogyasztás: 97,0 kW → 131,8 kW (+35,9%)
- Teljes mért fogyasztás: 166,2 kW → 198,9 kW (+19,7%)
- Teljesítménykeret kihasználtsága: 62,9% → 75,2% (+12,3 százalékpont)
- Throughput per provisioned watt: 4,10 token/s/W → 6,12 token/s/W (+49,2%)
A mérések szerint az aggregált throughput jelentősen nőtt anélkül, hogy a meglévő high-throughput és low-latency példányok per-instance teljesítménye érdemben romlott volna. Ugyanakkor a P99 tail latency (time to first token) nőtt: a P99 idő 15,7 másodpercről 17%-kal magasabb értékre emelkedett, ezért a ritkán előforduló lassú kérésekre figyelni kell.
Milyen kompromisszumokat fed fel ez a módszer?
- A munkaterhelés-keverék befolyásolja a rendelkezésre álló "headroom" méretét: ha a különböző munkák különböző időben csúcsosodnak, több átcsoportosítható kapacitás nyerhető vissza.
- A medián és P75 késleltetés közel maradhat az alaphoz, de a P99 érték romolhat; ezért a szolgáltatási elfogadási kritériumokat (SLO-kat) előre definiálni kell.
- Megbízható telemetria szükséges: hiányzó vagy késleltetett mérések gyengíthetik a rendszer döntéseit. A vizsgálat során site-szintű telemetriát használtak a rack-szintű mérések ellenőrzésére.
Ajánlott validációs lépések üzemeltetőknek
- Definiálja a kezelt határt: térképezze fel a topológiát (utility, elosztás, rack, node, GPU), állítsa be a csoport-költségvetést és tartalékigényeket.
- Állítson fel reprezentatív bázist: fusson le statikus provisioning mellett reprezentatív munkaterhelés-keverékkel, mérje meg a teljesítményt és a fogyasztást hosszabb időintervallumon.
- Vezessen be politikákat óvatosan: kezdje a validált bázishoz közeli határokkal, ellenőrizze a telemetriát és a szabályok betartását.
- Növelje fokozatosan a kapacitást és teszteljen minden lépésnél: ellenőrizze az aggregált és per-instance viselkedést, valamint a rendszer reakcióját csúcsidőre, telemetria-hibára és csökkentett energiaellátásra.
- Határozza meg a produkciós működési határokat: csak akkor hagyjon jóvá egy konfigurációt, ha teljesíti a throughput és latency célokat, belül marad a költségvetésen és kiszámítható marad hibák esetén.
Operatív és tervezési megfontolások
A dinamikus allokáció operációs képesség, de a helyszínt úgy kell megtervezni, hogy képes legyen befogadni a képességet, amit engedélyez: elektromos elosztás, hűtés, hálózat, padlóterület és rack-elrendezés legyenek a validált céléletciklus szerint méretezve, még ha kezdetben kevesebb rack is van telepítve.
Az értékelés egy GB300 NVL72 rendszeren mért adatokat mutat; a jövőbeli NVIDIA Vera Rubin NVL72 telepítések esetén a MaxLPS kombinálható további teljesítmény-per-watt technikákkal és magasabb (45°C) folyadékhűtési inlet tervezéssel, de ezek teljesítményelőrejelzéseit külön kell kezelni.
Következtetés
A DSX MaxLPS politika-alapú, dinamikus fogyasztáskezeléssel képes visszanyerni a statikus tervezés által elszigetelt kapacitást, növelve a hasznos számítási erőt ugyanazon engedélyezett teljesítménykeret alatt. Az üzemeltetői munka a határok meghatározása, reprezentatív viselkedés mérése, politika hangolása a szolgáltatási céloknak megfelelően és a megfelelőség igazolása normál és rendkívüli körülmények között.
Először tekintse át az NVIDIA DSX MaxLPS és a NVIDIA Dynamic Power Software dokumentációját, majd kövesse a cikkben bemutatott validációs lépéseket saját AI-farmja produkciós működési határainak megállapításához.
