Az egész úgy indult, hogy egyre jobban kezdtem érezni a zárt cloud modellek korlátait. GPT 5.6, Claude Fable 5.1 és társai ugyan brutálisak, de a nyílt kódú modellek olyan tempóban törnek előre, hogy már egyszerűen nem lehet figyelmen kívül hagyni őket. Úgy alakult, hogy pár hete lemondtam az cloudos AI előfizetéseimet, így egy rövid időre teljesen modell nélkül maradtam. Ekkor kaptam egy lehetőséget a vshosting.eu-tól: egy hétre egy NVIDIA RTX PRO 6000 Blackwell Server Edition szervert teszthetek.
Örültem a lehetőségnek, mert mindig is foglalkoztatott, hogy egy valódi, dedikált infrastruktúrán milyen érzés dolgozni, nem csak egy API-kulcs mögött.
A "vas" és a paraméterek
A gép paraméterei rögtön egyértelművé tették, hogy nem egy kisebb játékról van szó. Egy 64 vCPU-s, 244 GB RAM-mal felszerelt Ubuntu szerverről beszélünk, aminek a szíve a 96 GB VRAM-mal rendelkező RTX PRO 6000 Blackwell. A tárolást 1.92 TB-os NVMe SSD-re bízták, ami azért fontos, mert a mai modellek súlyai százas gigabájtokba mennek - így nem kellett aggódnom a helyhiány miatt sem.
Üzembe helyezés és a saját API
Az üzembe helyezés gyorsan ment, a vshosting.eu munkatársai profin intéztek mindent. Miután megkaptam a hozzáférést a szerverhez, telepítettem rá a vLLM-t és a szükséges környezetet, majd neki is álltunk nyüstölni a szervert. A Qwen3.8-27B modellt próbáltuk ki kódolásos tesztekhez, ami hibrid Mamba és attention architektúrájával nagyon ígéretesnek tűnt. Az egész folyamat zökkenőmentesen zajlott, nem akadtam olyan illesztőprogram- vagy konténerhibába, ami egy egész délutánt elvette volna. Sőt, egy LiteLLM proxy és Caddy szervert is felállítottam egy központi API-kapuként, hogy teszteljem, mennyire skálázható a rendszer, és mennyire kényelmes több felhasználónak egyben szolgáltatni a modell hozzáférését.
A teljesítmény és a DFlash2 "varázslata"
A mérések során az egyik legnagyobb meglepetés a DFlash2 technológia volt. Ez egy olyan újdonság, amit a Qwen3.8-27B modellel lehet kihasználni, és amit külön szekcióban is érdemes megemlíteni: a nyers számok azt mutatják, hogy a megfelelő tuninggal a szerver teljesítményét gyakorlatilag megsokszorozhatjuk.
Így nézett ki a folyamat egyetlen streamnél:
- BF16 vLLM baseline: 26,3 tok/s
- SGLang alap: 27,0 tok/s
- DFlash2 + compile + thinking: 64,7 tok/s
- NVFP4 baseline (thinking kikapcsolva): 62,8 tok/s
- NVFP4 + DFlash2 + compile + thinking: 128,1 tok/s
Ez azt jelenti, hogy egy egyszerű "out-of-the-box" telepítés után a gép kb. 26 tokennel másodpercenként válaszolt, de a full tuning után ez 128 tok/sec-re ugrott.
De a valódi kérdés az, hogy ez egy programozónak mit jelent a gyakorlatban? Szimuláltunk egy életszerű forgatókönyvet: 64k valódi kód-kontextus, bekapcsolt gondolkodás (thinking ON) és egy nagyobb, 4096 tokenes kimeneti blokk. Itt jött ki a lényegi különbség:
| Konfiguráció | Conc | TTFT | Aggregált tok/s | Per-stream tok/s | vs. baseline |
|---|---|---|---|---|---|
| vLLM BF16 + FP8 KV (baseline) | 4 | 34,5 s | - | 17,2 | 1,00x |
| vLLM BF16 + FP8 KV (baseline) | 6 | 49,7 s | - | 15,0 | 1,00x |
| SGLang BF16 + DFlash2 + compile | 4 | 24,4 s | 150,3 | 37,6 | 2,19x |
| SGLang BF16 + DFlash2 + compile | 6 | 33,4 s | 187,8 | 31,3 | 2,09x |
| SGLang NVFP4 + DFlash2 | 4 | 13,4 s | 275,4 | 68,8 | 4,00x |
| SGLang NVFP4 + DFlash2 | 6 | 18,4 s | 329,1 | 54,9 | 3,66x |
Ez egy brutális ugrás. Míg az alapkonfigurációnál egy ilyen nagy kódblokk generálása egy "örökké tartó" folyamat volt, az NVFP4 + DFlash2 kombinációval a sebesség négyszeresre ugrott (68,8 tok/s). A TTFT (az első token érkezéséig eltelt idő) is drasztikusan csökkent 34 másodpercről 13-ra. Ez a különbség dönt arról, hogy egy programozónak meg kell várnia, amíg lehűl a kávéja, vagy egyetlen pillanat alatt ott van a megoldás.
Sőt, ha párhuzamosítjuk a kéréseket, a számok még érdekesebbek lesznek: 4 egyidejű kérésnél (concurrency 4) az aggregált sebesség már a 275,4 tok/s-t ért el a maximális tuningnál.
Stabilitás és nagy kontextus
Ami azonban a leginkább meglepetett, az a stabilitás és a nagy kontextus kezelése. A 200k-s kontextus-ablak tesztjei egyértelműen nyerték a mérkőzést a 64k-s ablakkal szemben: ahol a kisebb ablakkal a feladat a 30 perces időlimiten belül egyszer sem készült el, a nagyobb ablakkal 15,4 perc alatt tiszta befejezés született. A prefill sebesség is brutális: egy 160k-s prefillnél a TTFT mindössze 46 másodperc volt. Egy programozó számára, aki egy egész könyvtárat vagy egy több száz fájlból álló repóval dolgozik, ez a képesség életmentő.
A stabilitás pedig szikla szilárd volt. Egy teljes hét alatt nem volt egyetlen szakadás, hálózati probléma vagy szerver-leállás. Minden nagyon gyorsan, teljesen flottul működött.
Ami azonban egy profi felhasználót vagy egy vállalati IT-t valóban érdekel, az a hatékonyság. A mérések során figyeltük a kártya fogyasztását is: terhelés alatt a Blackwell stabilan a 340-450 Watt közötti sávban mozogott, a hőmérséklet pedig nem ment 70 fok fölé. Ez azt jelenti, hogy a szerver nem csak gyors, hanem hűtés és áramellátás szempontjából is optimális környezetben fut, így egy éjszakán át futó, több tízmillió tokent generáló batch-munka során sem kell félni a hőmérséklet miatti throttlingtől. (Egy-egy ilyen éjszakai feladatnál mindig aggódom, hogy reggelre vajon lefut-e a feladat, vagy valamikor az éjjel folyamán elakad, de a teszthét során egyetlen egyszer sem történt ilyen probléma, a szerver megbízhatóan dolgozott éjjeleken át.)
Valós használat: agentic workflow
A valós használat során pedig egy olyan workflow-t építettem fel, ami már túlmutat a sima chatelésen. Bekötöttem a saját végpontomat a Claude Code-be és az OpenClaw-ba, és igazi szerkesztőségi feladatokat bíztam a modellre. Kódolási feladatok, komplex mérések és adatfeldolgozások.
A "csapaterős" teszten is jól teljesített: 8 párhuzamos agent futtatása során 6/8 tiszta befejezést kaptunk 26-37 perc alatt, miközben a proxyn 40 perc alatt összesen ~6,27M token ment át. Ez azt mutatja, hogy tipikus, kisebb kontextusú agent-munkára a gép valóban kiszolgál egy csapatot. Nagy repónál viszont más a leosztás: a szűk keresztmetszet nem a memória, hanem a prefill - a kártya másodpercenként nagyjából 5 ezer tokennel tölti be a kontextust, és ez oszlik el a párhuzamos fejlesztők között. 40 ezres kontextussal már csak 1-2 ember dolgozik kényelmesen, 160 ezres monoreponál gyakorlatilag egyedül vagy a szerveren. Több fejlesztő nagy repoval = több kártya.
Ezen kívül még egyfajta meta-kísérletet is végeztem: az egész cikket ennek a szervernek a segítségével írtam meg! A hangjegyzeteket a szerveren futó Whisper-rel transzkripáltam, egy másik modell készítette el a vázlatot a lediktált anyagból, és végül egy harmadik modell segített a szöveg összerakásában. Szóval ez egy félig-meddig AI-generált cikk, amit az a gép írt, amiről szól az egész történet. :)
Mások mire használják?
Én fejlesztő-sapkában nyúztam a gépet, de megkérdeztem a VSHostingot, ügyfeleik mire bérelnek ilyen kártyákat. Szerintük az RTX PRO 6000 "univerzális kártya" HPC és grafikai célokra egyaránt: a 96 GB VRAM a modellek többségéhez elég, a beépített videókódolók és videodekódolók pedig kifejezetten a kép- és videofelismerésnek kedveznek. A tipikus ügyfeleik: nagyrendezvények fotósai, akik több tízezer felvételt kategorizálnak szoros határidőre; orvosi kutatók, akik felvételeken betegségeket, tüneteket kereső AI-modelleket tanítanak; és szerzői jogi védelemmel foglalkozó cégek, amelyek a webet pásztáztatják illegálisan közzétett meccs- és koncertfelvételek után. H100-as kártyák kiváltására is használják számítási feladatokra.
Gazdaságosság és adatszuverenitás
A gazdasági oldal pedig így alakul. A tesztelt konfiguráció bérleti díját a szolgáltatónál is megkérdeztem: a díj a vállalástól függ - elköteleződés nélkül havi 1400 euró, 12 hónapos vagy hosszabb futamidő esetén havi 1250, tíz kártya felett volumen-engedmény is kapható. Ebbe a korlátlan adatforgalom, a korlátlan számú kérést fogadó 24/7 support és a tárolás is beletartozik - ezek olyan tételek, amit sok versenytárs külön számláz. A korlátlan forgalom nem pusztán marketing: a mai modellek súlyai száz gigabájtos nagyságrendűek, a teszt első napjaiban magam is körülbelül 170 GB-ot töltöttem le.
Ha ezt összevetjük a nagy cloud szolgáltatók API-költségeivel, akkor egyértelműen azoknak éri meg, akiknek hatalmas mennyiségű tokent kell generálni naponta, vagy akiknek kritikus az adatszuverenitás (hogy az adatok egy konkrét szerveren maradjanak).
Pro
- Stabilitás (1 hét, 0 downtime)
- Nagy VRAM (96 GB), ami lehetővé teszi a nagyobb modellek BF16-os futtatását
- Gyors NVMe tároló a modellbetöltésekhez
Kontra
- A bérleti díj magasabb belépési küszöböt jelent, mint egy egyszerű API-előfizetés
- A Mamba-alapú modelleknél a párhuzamosítottságnak vannak fizikai plafonjai
- Önkiszolgáló konzol (IPMI) ehhez a típushoz jelenleg nincs: az újratelepítés a supporton át megy, díjmentesen
Összességében olyan érzés volt, mint gyerekkorban az első saját gaming PC: máshol is lehetett volna játszani, de a saját gépet te hoztad össze, te tuningoltad, és éjfélkor is a tiéd volt. Ez a szerver ugyanaz, felnőtt kiadásban. Az API is megtenné ugyanezt - de itt te döntesz a 96 GB-ról megabájtról megabájtra, és az egyszerűen jobb érzés. Akár egy nagyobb modellt is betölthetsz, és lecserélheted, amikor épp másra van szükséged; ha inkább azt szeretnéd, hogy egyszerre több modell álljon rendelkezésre, több kisebb vagy kvantált modellt is futtathatsz egymás mellett.
Ha fejlesztőként vagy adattudósként olyan megbízható, nagy VRAM-es környezetre van szükséged, amelyben a saját modelljeid futnak, a VSHosting dedikált GPU szervere erős választás. Ha viszont csak pár napra van nagyobb erőforrásra szükséged - egy tanítás, egy nagy renderelés, egy egyszeri batch futás -, a VSHosting GPU cloud szolgáltatása pont erre való: napidíjas, kötelezettség nélkül, egy kártya töredékétől a H200-ig.
Az NVIDIA RTX PRO 6000-rel szerelt szervert a vshosting.eu biztosította.