• Szerző: Peter Vnuk
Két, azonos típusú gyorsítóval szerelt AI összeállítás a gyakorlatban nagyon eltérően teljesíthet. Az előzetesen tesztelt konfiguráció még a vásárlás előtt segít ellenőrizni a kompatibilitást, a tényleges teljesítményt és az adott munkaterhelés korlátait, így csökkenti a hardver leszállítása utáni költséges finomhangolás kockázatát.
AI-infrastruktúra vásárlásakor csábító a GPU-k számát, a memóriakapacitást vagy a PFLOPS-ban mért teljesítményt gyorsan összehasonlítani. Ezekből a paraméterekből azonban nehéz megbecsülni, hogyan viselkedik majd egy konkrét alkalmazás. A céget végső soron az érdekli, mennyi idő alatt kezd el válaszolni a rendszer, hányan használhatják egyszerre, és hogy a kiválasztott modell képes-e kezelni a szükséges kontextushosszt. Ugyanilyen fontos az is, mennyi időt tölt a technikai csapat magának a környezetnek az üzembe helyezésével.
Az adatlapon szereplő paraméterek és a valós üzem közötti különbségből született meg a Validated AI koncepció. A konfigurációt itt összehangolt egészként értékelik, így a hardver mellett az operációs rendszer és a modellekkel való munkához szükséges szoftverkörnyezet is számít. Az ellenőrzés fejlettebb formája konkrét felhasználási forgatókönyvet is tartalmaz – például helyi inferenciát, vállalati dokumentumokon futó RAG-ot, ágensek fejlesztését vagy fine-tuningot.
Minél jobban tükrözi a teszt a jövőbeli valós használatot, annál kevesebb tere marad a kellemetlen meglepetéseknek a vásárlás után. Maga az „AI munkaállomás" megjelölés elsősorban azt árulja el, melyik termékkategóriába tartozik az összeállítás. A részletes dokumentáció viszont már leírhatja a támogatott szoftvereket, a modellek méretosztályát, valamint a memóriából és a tervezett felhasználási módból adódó korlátokat.
Amit ebben a cikkben megtudhatsz:
Egyetlen fogalom mögött az AI infrastruktúrában több, egymástól eltérő ellenőrzési szint húzódik meg, így maga a „validált" szó önmagában még nem ad elegendő információt a vásárlási döntéshez.
Az ilyen ellenőrzés konkrét formáját jól szemlélteti az NVIDIA-Certified Systems program, amelyben a rendszerek meghatározott teszteken és értékelésen esnek át. A Grace Blackwell GB10 platform esetében a validált konfigurációk között szerepel például az ASUS Ascent GX10 és a Dell Pro Max GB10-zel, amelyeket az NVIDIA kifejezetten feltüntet a tanúsított rendszerek listáján.
Egy cég szempontjából ezért elsősorban azok a feltételek számítanak, amelyek mellett az ellenőrzés zajlott. Más az eredmény értéke, ha csupán magát a modellt tesztelték, és más, ha a teljes alkalmazást mérték. A kontextushossz vagy a párhuzamos kérések száma ráadásul annyira megváltoztathatja az összeállítás viselkedését, hogy egy egyébként helytálló benchmark az adott projekthez kevéssé lesz informatív.
Az AI konfiguráció ellenőrzési szintjei
| Ellenőrzési szint | Mit igazol jellemzően | Gyakorlati hatás |
|---|---|---|
| Kompatibilitás | A hardver, illesztőprogramok és szoftver támogatott kombinációját | Kisebb kockázat a telepítés során felmerülő problémákra |
| Előre konfigurált platform | Összehangolt hardver, OS és AI stack | Gyorsabb út az első pilotprojektig |
| Referencia-architektúra | Ajánlott konfiguráció és telepítési mód | Pontosabb kiindulási alap az infrastruktúra tervezéséhez |
| Workload-validáció | Az összeállítás viselkedése konkrét feladattal vagy modellel | Jobb becslés a teljesítményről és az üzemeltetési korlátokról |
| Tanúsított rendszer | A gyártó által meghatározott program szabályainak teljesítése | Egyértelműbben körülhatárolt konfiguráció és támogatás |
A validáció minőségét leggyorsabban abból lehet megítélni, hogy visszakereshetők-e a mérés konkrét feltételei. Ha a dokumentáció csupán egy általános „AI-ready" jelölést vagy a maximális teljesítményt adja meg PFLOPS-ban, a gyakorlati kérdések többsége megválaszolatlan marad. A vásárló továbbra sem tudja, milyen szoftver támogatott, milyen típusú feladatra készítették elő a konfigurációt, és hol húzódik annak valódi korlátja.
Ugyanilyen fontos, hogy a teszt mennyire hasonlít a tervezett terhelésre. Egy rövid, izolált futtatás eredménye csapatszintű üzemben gyorsan elveszítheti az értékét, mert a növekvő párhuzamossággal és kontextushosszal együtt változnak a memóriaigények és a válaszidők is. A teszt értéke tehát annál nagyobb, minél pontosabban szimulálja a várható üzemi körülményeket.
Gyengén alátámasztott validáció figyelmeztető jelei
| Figyelmeztető jel | Mi hiányzik? | Mit ellenőrizz? |
|---|---|---|
| Csak a maximális PFLOPS vagy TOPS van feltüntetve | Kapcsolat a konkrét alkalmazással | Modell, pontosság és a mérés feltételei |
| Az összeállítás AI-ready jelölést kapott | A tényleges ellenőrzés mélysége | Támogatott stack és célzott workloadok |
| A benchmark rövid prompttal dolgozik | Valósághű kontextushossz | A produkciós bemenetekhez hasonló teszt |
| Az eredmény egyetlen felhasználóra vonatkozik | Viselkedés párhuzamos terhelés alatt | Terhelésteszt a várható csúcsterheléssel |
| A szoftvert csak a vásárlás után választják ki | Ellenőrzött kompatibilitás | OS, illesztőprogramok, könyvtárak és runtime verziója |
| Senki sem tudja leírni az összeállítás korlátait | Kapacitási keret | Memória, késleltetés és terhelésnövekedés |
Amint a tesztelés túllép az elméleti specifikációkon, és egy konkrét AI-szolgáltatás működését vizsgálja, a rendszer többi komponensének szerepe is sokkal hangsúlyosabbá válik. A nyelvi modellnek memóriára van szüksége a súlyok tárolásához, az inferencia során pedig további memóriaigény jelentkezik a kontextus és az egyidejű kérések kezelése miatt. A hosszabb dokumentumok vagy a nagyobb számú felhasználó ezért hamarabb kimeríthetik a rendelkezésre álló tartalékot, mint ahogy az AI-gyorsító elméleti számítási teljesítménye teljes mértékben kihasználható lenne.
A szoftver ugyanilyen markánsan képes befolyásolni az eredményt – egy másik illesztőprogram- vagy inferencia-motor-verzió a sebességet és a stabilitást egyaránt megváltoztathatja. További eltérések adódhatnak a választott kvantálásból vagy a gyorsítótár kezelésének módjából. Két hasonló hardverrel rendelkező összeállítás ezért ugyanabban az alkalmazásban meglepően eltérően viselkedhet, ráadásul az éles üzem a hosszú távú terhelést is próbára teszi, amit egy rövid benchmark gyakran nem fed le.
Egy előzetesen tesztelt konfiguráció a bizonytalanság egy részét már az üzembe helyezés előtt csökkentheti. A műszaki csapat egy ismert kiindulópontot kap, és saját tesztelését a céges adatokra, az adott alkalmazás viselkedésére és a valós üzemi csúcsok alatti terhelésre összpontosíthatja.
Az AI-infrastruktúránál a gyorsító csupán a rendszer egyik rétegét jelenti, felette pedig a függőségek egész láncolata húzódik. A meghajtóknak és rendszerkönyvtáraknak helyesen kell együttműködniük a keretrendszerrel, az inference runtime-mal és a modellkezelő eszközökkel. Bármelyik elemben fellépő hiba már az első használható teszt előtt hátráltathatja a projektet, vagy csökkentheti a teljesítményt, amelyet a cég a drága hardverből ténylegesen ki tud hozni.
Kisebb csapatok számára az előkészített AI stack különösen értékes, amikor gyorsan szeretnék validálni az első use case-t. Az alapkörnyezet összerakásával töltött hetek önmagukban is költséget jelentenek, hiszen ugyanezt az időt a fejlesztőcsapat az integrációra vagy magára az alkalmazásra is fordíthatta volna.
Az ilyen összehangolás konkrét formáját jól szemléltetik az NVIDIA GB10 Grace Blackwell alapú kompakt rendszerek. Az NVIDIA DGX Spark 4TB, a már említett Dell Pro Max GB10 FCM1253 vagy az ASUS Ascent GX10 ezt a platformot előkészített szoftverkörnyezettel párosítja a fejlesztéshez és a helyi AI-munkához. Magánál a DGX Spark platformnál az NVIDIA 128 GB egyesített memóriát, FP4-nél akár 1 PFLOP teljesítményt és legfeljebb 200 milliárd paraméteres modellek támogatását ígéri.
Ezeknek a paramétereknek a jelentősége csak a konkrét felhasználás során mutatkozik meg, hiszen ugyanaz a platform a fejlesztés során másként szolgálhat, mint rendszeres helyi inferencia esetén. A felhasználás módja dönti el, hogy az összeállítás megmarad-e pilot környezetnek, vagy a csapat hosszú távú munkájának egy részét is átveszi.
i
Mit kell tudnod egy előre tesztelt platformról vásárlás előtt?
A vásárlás előtt ismerd meg a pontos hardverkonfigurációt, a támogatott operációs rendszert és a kulcsfontosságú szoftverrétegek verzióit. A teljesítmény-eredményekhez hasonló kontextus szükséges: a használt modell, a pontosság és a terhelés jellegének ismerete nélkül a kapacitástervezésbe csak nehezen ültethetők át.
Amikor egy cégnek saját környezetre van szüksége a fejlesztéshez és a rendszeres helyi inferenciához, a GB10 osztályú rendszerek egyetlen eszközön képesek lefedni a projekt több fázisát is. A csapat nyílt modelleket validálhat rajtuk, belső adatokon prototipizálhat, később pedig stabil terhelést futtathat, amelyet már nem akar minden alkalommal külső szolgáltatásba küldeni.
Ez a platformosztály elsősorban olyan forgatókönyvekre céloz, amelyek a nagyobb modellek memóriaigénye miatt egy hagyományos munkaállomásba már nem férnek be kényelmesen. A deklarált 200 milliárd paraméter azonban csak tájékoztató jellegű határ, mivel a tényleges igények a kvantálástól, a kontextushossztól és az inferencia kiszolgálásának módjától függően változnak.
Amikor nőnek a modellek és a kontextushossz, vagy a projekt komolyabb fine-tuning felé mozdul el, a teljesítményigényekkel együtt az egész összeállítás szerepe is megváltozik. A személyes vagy csapatszintű eszközből fokozatosan megosztott számítási csomópont lesz, amelynek bele kell illeszkednie a cég szélesebb üzemeltetésébe. Ilyenkor felértékelődik a hálózati kapcsolódás és az elérhető erőforrások több felhasználó közötti elosztásának módja.
Ebbe a teljesítménykategóriába tartoznak az NVIDIA GB300 Grace Blackwell Ultra rendszerek, például a GIGABYTE W775 vagy az ASUS ExpertCenter Pro ET900N G3. A DGX Station platform GB300-zal akár 748 GB koherens memóriát és legfeljebb 20 PFLOPS FP4 teljesítményt kínál, az NVIDIA pedig akár egybillió paraméteres modellekkel való munkához ajánlja.
Az egyes kategóriák közötti döntésnek ezért a valós felhasználáson és a várható növekedésen kell alapulnia. Egy kisebb csapat jobban ki tud használni egy kompakt platformot, mint egy drágább, nagy tartalékkal rendelkező rendszert. Ha a pilotprojekt már memóriakorlátokba ütközik, vagy a projektnek egyértelmű bővítési terve van, a szükséges tartalékot már a tervezés elejétől be kell kalkulálni.
3. táblázat: A fő AI infrastruktúra-kategóriák összehasonlítása
| Konfiguráció kategóriája | Memóriakategória | AI teljesítmény | Tájékoztató modellméret | Jellemző felhasználás |
|---|---|---|---|---|
| GB10 / DGX Spark kategória | 128 GB egyesített memória | Akár 1 PFLOP FP4 | Akár 200 milliárd paraméter | Helyi fejlesztés, inferencia, ágensek, pilotprojektek és kisebb csapatos forgatókönyvek |
| GB300 / DGX Station kategória | 748 GB koherens memória | Akár 20 PFLOPS FP4 | Akár 1 billió paraméter | Nagyobb modellek, igényesebb inferencia, fine-tuning és megosztott teljesítmény |
| Klasszikus munkaállomás RTX GPU-val | Az adott konfiguráció szerint | A használt GPU szerint | A VRAM, kvantálás és workload szerint | Professzionális alkalmazások helyi MI-vel kombinálva |
| Szerver-infrastruktúra | A tervezés szerint | A gyorsítók számától és típusától függően | A megoldás architektúrája szerint | Éles szolgáltatások több csapat számára, magasabb rendelkezésre állási követelményekkel |
A maximális modellméretre vonatkozó adatok az adott platform tájékoztató jellegű felső határát jelentik. A valós üzemeltetést befolyásolja a modell pontossága, a kvantálás, a kontextushossz, a párhuzamosság és a workload jellege.
Hogy miért nem elég önmagában a modell benchmarkja, azt jól szemlélteti egy belső dokumentumokra épülő vállalati asszisztens. A RAG, vagyis a retrieval-augmented generation a válasz generálása előtt először releváns információkat keres a vállalati forrásokban, és csak ezután adja át azokat a modellnek. Az eredményül kapott szolgáltatás teljesítménye így a teljes adatútvonaltól függ.
Egyetlen felhasználói kérdés is végigmehet az embedding-be való átalakításon és a megfelelő szövegrészletek adatbázisból való kikeresésén, amit a relevancia szerinti rendezés és a modell kontextusának összeállítása követ. Az eredménybe egyidejűleg beleszólnak a jogosultságok is, amelyek meghatározzák, hogy az adott felhasználó milyen háttéranyagokhoz férhet hozzá. Hosszú dokumentumok esetén ráadásul nő a memóriaterhelés, és hosszabbá válik a végső válaszhoz vezető út.
Az ilyen forgatókönyv validálásához ezért olyan bemeneti adatokkal kell dolgozni, amelyek a valós használat során is várhatók. Ha az éles rendszer hosszú dokumentumokat dolgoz fel, és egyszerre több felhasználót szolgál ki, egy rövid prompttal végzett benchmark csak a rendszer tényleges működésének kis részét mutatja meg.
!
Ha a produkciós szolgáltatás hosszú dokumentumokat kezel, és egyszerre több felhasználót szolgál ki, a rövid prompttal végzett benchmark a rendszer valós viselkedésének csak egy kis szeletét mutatja meg.
A benchmarkok összehasonlításakor is tudnod kell, milyen körülmények között született az adott eredmény. A token/másodperc érték a használt modelltől és a számítási pontosságtól függően változik. Hosszabb bemenettel vagy nagyobb párhuzamossággal a rendszer viselkedése ismét eltolódik, így két szabályosan elvégzett mérés eltérő eredményt hozhat anélkül, hogy ellentmondanának egymásnak.
Interaktív szolgáltatásnál ráadásul nem elég csupán a válasz megkezdése utáni generálási sebességet figyelni. A felhasználó számára a TTFT, vagyis az első tokenig eltelt idő is érzékelhetően számít, mert a válasz megkezdésére való hosszú várakozás lassítja a mindennapi munkát. A P95 és p99 latencia pedig a kérések lassabb hányadát tárja fel, amelyet az átlag könnyen elrejt, és amely jellemzően csúcsidőben jelentkezik.
4. táblázat: Metrikák az AI szolgáltatás teljesítményének értékeléséhez
| Metrika | Mit mutat? | Hogyan értelmezd a gyakorlatban? |
|---|---|---|
| TTFT | A válasz első látható részéig eltelt idő | Befolyásolja a szolgáltatás érzékelt gyorsaságát |
| Token/s | A kimenet generálásának sebessége | Segít felmérni a felhasználói élményt és a kapacitást |
| P95/p99 latencia | A kérések lassabb hányadának válaszideje | Csúcsidőben jobban feltárja a viselkedést, mint az átlag |
| Memóriahasználat | A modell, a kontextus és a további kérések számára rendelkezésre álló tartalék | Gyakran ez mutatja meg a konfiguráció gyakorlati korlátját |
| Kontextushossz | A válasz során megtartott információ mennyisége | Hatással van a memóriára és a sebességre egyaránt |
| Párhuzamosság | Az egyidejűleg kiszolgált kérések száma | Meghatározza a használhatóságot csapatszintű üzemeltetésnél |
Csak e metrikák és a tervezett üzemeltetés együttes vizsgálata mutatja meg, hogy a mért teljesítmény valóban értékes-e a cég számára. A technikai eredményekből így természetes módon válnak gyakorlati kérdések, amelyeket érdemes még a konkrét konfiguráció kiválasztása előtt tisztázni.
A választás előtt érdemes ismerni a fő workloadot, amelyet a konfigurációnak ki kell szolgálnia, a szóba jövő modellt vagy modellméret-kategóriát, a bemenetek és válaszok jellemző hosszát, a csúcsidőben érkező kérések számát, a felhasználó számára elfogadható válaszidőt, a promptokba és logokba kerülő adatok érzékenységét, a frissítésekért és monitoringért való felelősséget, valamint a használat várható növekedését a következő 12–24 hónapban.
A nyelvi modellnek a memóriában helyet kell biztosítani a súlyainak, az inferencia során pedig további igények merülnek fel a kontextussal vagy az egyidejű kérések kiszolgálásával kapcsolatban. Ugyanilyen jelentős mértékben képes az eredményt megváltoztatni a szoftver – a driver vagy az inferencia motor más verziója befolyásolhatja a sebességet és a stabilitást, további eltérések pedig a választott kvantálástól vagy a cache kezelésének módjától függően adódhatnak.
A TTFT az első tokenig eltelt idő – vagyis a válasz első látható részéig tartó várakozás. A felhasználókat ez érzékenyen érinti, mert a reakció kezdetére való hosszú várakozás lassítja a mindennapi munkát. Interaktív szolgáltatásnál ezért nem elég csupán a válasz elindulása utáni generálási sebességet figyelni.
Egy belső dokumentumokon dolgozó, RAG-elvű vállalati asszisztens a válasz előtt végigmegy a teljes adatútvonalon – az embedding-konverzión, a releváns szövegrészek keresésén, azok rangsorolásán és a modell számára összeállított kontextus felépítésén. A végső szolgáltatás teljesítménye tehát az egész lánctól függ, nem csupán magának a modellnek a sebességétől.
A GB10 osztályú rendszerek lefedik a helyi fejlesztést, az inferenciát, az ágenseket és a kisebb csapatok pilot projektjeit. Amint nőnek a modellek, a kontextushossz, vagy a projekt komolyabb fine-tuningot és több felhasználó által megosztott üzemeltetést igényel, magasabb kategória jön szóba – például a GB300 Grace Blackwell Ultra chipekkel szerelt rendszerek.
Az előzetesen tesztelt konfiguráció legnagyobb hozzáadott értéke akkor mutatkozik meg, amikor a cég már viszonylag pontosan le tudja írni a feladatát. A tervezett modell és az adattípus ismerete lehetővé teszi, hogy olyan teljesítményt mérj, amely az adott projekt szempontjából valóban releváns, és egyúttal jobban becsüld meg a növekedéshez szükséges tartalékot.
A projekt korai fázisában érdemes lehet az első kísérleteket felhőben elindítani, ahol könnyen változtathatók a modellek és a rendelkezésre álló kapacitás. Az ismétlődő terhelés aztán alapot ad a saját infrastruktúráról való gondolkodáshoz. Amint a csapat ismeri a valós üzemeltetési csúcsokat és a munka hozzávetőleges volumenét, az előzetesen tesztelt platform kiválasztása konkrétabb adatokra támaszkodhat.
Érzékeny adatokat kezelő projekteknél a teljesítmény mellé felmerül a dokumentumok, promptok és üzemeltetési naplók feletti kontroll kérdése is. Maga a konfiguráció validálása nem oldja meg a biztonságot, hiszen az továbbra is az alkalmazás tervezésétől és a vállalat hozzáférési szabályaitól függ. A kiszámítható hardveres és szoftveres környezet azonban stabilabb alapot ad a csapatnak, amelyre ezeket az intézkedéseket építheti.
i
Hol takarítható meg a legtöbb munka?
A legnagyobb megtakarítás jellemzően még az éles üzembe helyezés előtt keletkezik. A hardver és a szoftverkörnyezet ismert és támogatott kombinációja lehetővé teszi, hogy a csapat hamarabb kezdje el a tényleges megoldás mérését a vállalati környezetben. Az idő így a dokumentumok minőségére, a jellemző kérdésekre, a felhasználói viselkedésre és a biztonsági szabályokra fordítható – ahelyett, hogy alapvető kompatibilitási problémákat kellene keresgélni.
AI-konfiguráció megrendelése előtt ismerni kell a konkrét workloadot, a validálás terjedelmét és azokat a feltételeket, amelyek mellett a közölt teljesítményadatok születtek. Ezek együttes vizsgálata mutatja meg, hogy a dokumentáció használható alapot nyújt-e a tervezett szolgáltatáshoz, vagy a lényegi kérdéseket a vásárlás utáni saját tesztelésre hagyja. Egy jól dokumentált validáció elsősorban a műszaki csapat idejét takarítja meg, amely a leszállítás után hamarabb kezdhet mérni, integrálni, és vizsgálni a megoldás viselkedését a vállalati környezetben. Ha a teszt leírása, a támogatott stack és a teljesítményfeltételek hiányoznak, a technikai kérdések csupán a megrendelés utáni időszakra tolódnak, ahol megválaszolásuk általában lassabb és drágább.
Peter Vnuk
A technológia egyszerre munka és szórakozás számomra - leginkább az okostelefonok, laptopok, audio, mesterséges intelligencia és minden más hi-tech dolog érdekel. Szeretem áttekinteni a híreket, követni a futurisztikus trendeket és megjósolni a technológia következő fejleményeit. Lenyűgöznek a sci-fik és a jövő világáról szóló víziók, amelyek gyakran valódi technológiai fejlesztéseket inspirálnak. Szakmailag is foglalkozom videojátékokkal és a játékiparral. Amikor nem dolgozom, szeretek kikapcsolódni egy jó játékkal, egy jó sörrel, vagy tech-mémek készítésével a Facebookon.
