Prípadová štúdia: AI workstation so 4x RTX 4090

Tento článok dokumentuje kompletnú zostavu, ktorú sme postavili na objednávku pre výskumného zákazníka. Potreboval workstation na LLM inferenciu do racku, schopný prevádzky 24/7 a s dostatkom VRAM na hostovanie modelov triedy 70B bez závislosti na cloude. Všetko, čo tu uvádzame, je namerané na reálnom hardvéri. Žiadne syntetické odhady, žiadne marketingové čísla.

Zostava bola objednaná a dodaná v apríli 2026. Uvádzacie benchmarky prebehli 2026-04-10.

Prečo 4× RTX 4090

Požiadavka na workload bola jasná od začiatku: prevádzkovať kvantizovaný 70B LLM s použiteľnou latenciou pri jednotlivej požiadavke, obslúžiť súbežné požiadavky v prostredí malého výskumného tímu a nechať všetko on-prem kvôli kontrole nad dátami. Otázkou bolo, koľko GPU a akého typu.

Model 70B v INT4 (AWQ alebo GGUF Q4_K_M) zaberie v praxi zhruba 38–40 GB VRAM. To úplne vylučuje riešenia s jednou GPU — ani RTX 4090 s 24 GB neudrží model sama. Potrebujete aspoň dve, ideálne štyri, aby tensor-paralelné serverovanie pod vLLM malo rezervu na KV cache.

Štyri karty RTX 4090 dávajú celkovo 96 GB VRAM. To stačí na načítanie modelu Llama 3.3 70B AWQ INT4 s gpu_memory_utilization=0.80 a stále mať zmysluplný priestor pre KV cache pri dávkovaných požiadavkách. Prináša to aj výpočtový výkon — 4× čip so 128 SM bežiace súčasne — ktorý je dôležitý pre rýchlosť spracovania promptu.

Zvažovanou alternatívou boli 4× RTX Pro 6000 Blackwell, ktoré by dali 4× 96 GB = 384 GB VRAM. To je úplne iná trieda: viac VRAM, než potrebuje akýkoľvek jediný 70B model, vhodné na súbežný beh viacerých veľkých modelov alebo hostovanie modelov triedy 200B+ pri rozumnej kvantizácii. Pre tento workload — jeden primárny model, malá súbežná dávka, rozpočet jednoúčelového workstationu — by táto kapacita navyše zostala nevyužitá a cenový rozdiel je významný. Pre zadaný prípad použitia boli 4× RTX 4090 správnou odpoveďou.

V ponuke existuje aj alternatíva 8× L40. L40 ponúka 48 GB VRAM na kartu, podporu ECC a je navrhnutá na trvalú záťaž v dátovom centre. U tohto zákazníka si workload nevyžadoval zmluvy o spoľahlivosti na úrovni dátového centra, absencia ovládačových zvláštností spotrebiteľskej triedy u L40 bola len drobným prínosom a rozpočet tak ďaleko nesiahal. Oplatí sa o nej vedieť ako o ceste k upgradu.

Jeden architektonický strop treba pomenovať hneď na úvod: karty RTX 4090 nemajú NVLink. Všetka komunikácia medzi GPU prebieha cez PCIe peer-to-peer. Pri tensor-paralelnej inferencii to má svoj význam (rozoberáme to v sekcii s benchmarkmi) a pred objednávkou sa to oplatí pochopiť. Pozrite si N03, kde sa podrobne venujeme tomu, kedy na NVLinku záleží a kedy nie.

Špecifikácia hardvéru

Niekoľko poznámok k výberu komponentov:

CPU. EPYC 7542 je 32-jadrový čip generácie Rome so 128 MB cache L3 rozloženej na 8 CCD. Pre workstation na inferenciu je počtom jadier predimenzovaný — čistou inferenciou 64 vlákien nevyťažíte. Svoje miesto si zaslúži rozpočtom liniek PCIe: Rome EPYC poskytuje z procesora 128 liniek PCIe 4.0, a preto na tejto platforme umiestnite štyri plnohodnotné GPU x16 bez zdieľania liniek či bifurkácie. RTX 4090 je zariadenie PCIe 4.0 x16; chcete štyri plné sloty x16 a EPYC ich dá. Pozrite si W02, kde nájdete detaily topológie liniek.

RAM. Systém bol dodaný s 512 GB DDR4 ECC LRDIMM, čo prekročilo pôvodne špecifikovaných 256 GB. Systémová RAM navyše je tu naozaj užitočná: načítanie modelu z NVMe prechádza cez systémovú RAM ešte pred prenosom do VRAM a pri väčších modeloch alebo pri prepínaní medzi modelmi znamená 512 GB, že v RAM udržíte viacero sád váh naraz a vyhnete sa opakovanému čítaniu z NVMe.

NVMe. Úložisko modelov (2 TB) je na rýchlom disku NVMe PCIe 4.0. Rýchlosť sekvenčného čítania je dôležitá pri načítaní: súbor modelu s veľkosťou 38 GB sa pri sekvenčnom čítaní 4,589 MB/s načíta zhruba za 8–10 sekúnd. Namerané časy to potvrdzujú: llama.cpp načítal 70B Q4_K_M GGUF za 10.8 sekundy, vLLM (ktorý pri načítaní navyše zostavuje grafy CUDA) potreboval 95 sekúnd.

Dva zdroje. Skriňa využíva dva zdroje ATX. Ide o rozdelené napájanie: každý zdroj napája časť systému — typicky po dvoch GPU a príslušných komponentoch dosky. Ak jeden zdroj zlyhá, prídete o GPU na jeho vetve. Nie je to redundancia N+1; je to usporiadanie kvôli výkonovej kapacite, nie kvôli prepnutiu pri poruche. Pri produkčných systémoch, kde je dostupnosť zmluvná, na tomto rozdiele záleží. Pozrite si W04, kde sa naplno venujeme dimenzovaniu zdrojov.

Prúdenie vzduchu v skrini. Skriňa je určená do racku s priemyselným riadeným prúdením vzduchu spredu dozadu. GPU nie sú v otvorenom priestore; sedia v usmernenom vzduchovom kanáli, kde ventilátory skrine ťahajú vzduch cez chladiče a vyfukujú ho vzadu. Vďaka tomu je systém vhodný na trvalú prevádzku 24/7 v rackovom prostredí. Pozrite si W05, kde nájdete detaily tepelného návrhu.

Softvérový stack

Prostredie Pythonu sa nachádza v /home/logic/llm-env/, modely na NVMe v /mnt/nvme/models/.

Výsledky uvádzacích testov

Základná výpočtová úroveň GPU

Prvým testom je vždy hrubý výpočtový výkon: násobenie matíc v FP16 (cesta cez Tensor Core) a v FP32. Potvrdí, že karty fungujú správne, a dá východiskovú hodnotu na porovnanie s nominálnymi špecifikáciami.

Pre porovnanie: teoretické maximum RTX 4090 pre FP16 na Tensor Core je ~330 TFLOPS, pre FP32 ~82.6 TFLOPS. Hodnoty benchmarku na úrovni ~52 % maxima FP16 sú očakávané — meranie je matmul s trvalou priepustnosťou, ktorý nedosahuje teoretické maximum ručne ladeného kernelu GEMM. Potvrdzujú, že všetky štyri polia Tensor Core fungujú a sú konzistentné.

GPU 1 je v FP16 o ~6 % nižšia než ostatné. Ide o bežný rozptyl kremíka v rámci rovnakej série. Žiadna hardvérová chyba.

Pamäťová priepustnosť GPU

Priepustnosť VRAM 920 GB/s zodpovedá špecifikácii RTX 4090 (maximum 1,008 GB/s; rozdiel tvorí réžia benchmarku). Práve toto číslo je rozhodujúce pre priepustnosť dekódovania: každý vygenerovaný token si vyžaduje načítanie celej sady KV cache a tenzorov váh z VRAM, takže priepustnosť priamo určuje strop rýchlosti generovania.

Hodnota medzi GPU (19–22 GB/s cez PCIe peer-to-peer) je architektonické obmedzenie podstatné pre tensor-paralelné serverovanie. S NVLinkom beží táto cesta rýchlosťou 900 GB/s. Len cez PCIe z toho dostanete zhruba 2 %. Pre inferenciu to nie je katastrofa — väčšina tensor-paralelnej komunikácie modelu 70B AWQ INT4 naprieč 4 GPU sa do možností PCIe zmestí — potláča to však rýchlosť dekódovania jednotlivej požiadavky oproti systému prepojenému NVLinkom. Pozrite si sekciu s benchmarkmi nižšie a N03, kde nájdete širšiu diskusiu.

Jedna anomália: priepustnosť zo zariadenia na host bola nameraná na 1.4 GB/s, hlboko pod očakávanými ~26 GB/s pre PCIe Gen4 x16. Ide o známe správanie CUDA pri nepripnutej (non-pinned) pamäti. Ak vaša aplikácia presúva dáta z GPU na host často (napr. vzorkovanie z výstupných logitov vo vlastnej pipeline), použite torch.pin_memory() alebo si vopred alokujte pripnuté buffery. Štandardné servovacie pipeline vLLM a llama.cpp túto cestu v hlavnej slučke nevyužívajú.

Všetky linky PCIe potvrdili pod záťažou Gen4 x16 (16 GT/s). V nečinnosti ovládač používa úsporný režim ASPM a linky klesnú na Gen1 (2.5 GT/s) — to je normálne a nejde o chybu kabeláže ani risera.

Úložisko NVMe

Na spotrebiteľský/prosumer disk PCIe 4.0 sú to silné hodnoty NVMe. Pre serverovanie modelov je podstatné sekvenčné čítanie: 4,589 MB/s znamená, že sa model s veľkosťou 38 GB načíta do RAM približne za 8–9 sekúnd ešte pred akýmkoľvek prenosom do VRAM. Hodnota 568K náhodných IOPS je relevantnejšia, ak prevádzkujete vyhľadávaciu pipeline (RAG, vektorová databáza), kde workload tvorí množstvo malých náhodných čítaní — tento disk to zvládne bez toho, aby sa stal úzkym hrdlom.

Inferencia vLLM — Llama 3.3 70B AWQ INT4

Toto je kľúčový benchmark. Model: casperhansen/llama-3.3-70b-instruct-awq. Serverovanie: vLLM 0.19.0 s tensor_parallel_size=4, max_model_len=2048, gpu_memory_utilization=0.80.

Rýchlosť dekódovania 8.0 tok/s pri jednej požiadavke si žiada kontext. vLLM 0.19.0 spustil model AWQ s kernelom awq, nie awq_marlin. Kernel awq_marlin je rýchlejšia cesta pre AWQ na GPU Ada Lovelace (RTX 4090) a Blackwell — poznámky z benchmarku naznačujú, že počas tohto uvádzacieho behu nebol vybraný, a očakávané zlepšenie rýchlosti dekódovania pri jednej požiadavke je 2–3×. S awq_marlin by ten istý model na tom istom hardvéri mal dosiahnuť približne 16–24 tok/s v jednom prúde.

Súhrnných 179.3 tok/s pri 32 súbežných požiadavkách je číslo bližšie produkčnej realite. Presne toto uvidí malý tím, ktorý sa na endpoint pripojí naraz, ako kombinovaný výstup systému. Priebežné dávkovanie vo vLLM znamená, že súbežné požiadavky rozložia KV cache a výpočet pozornosti naprieč dávkou, a preto 32× viac používateľov neznamená 32× vyššiu latenciu.

Latencia 2,043 ms pri požiadavke na 16 tokenov je spodná hranica TTFT (time-to-first-token) pod vLLM v tejto konfigurácii. Pre interaktívne použitie (chat, asistent pri kóde) je to skôr pomalšie. Hlavnou príčinou je réžia tensor-paralelného scatter/gather naprieč štyrmi GPU cez PCIe — každý krok prefillu vyžaduje AllReduce cez všetky štyri karty po zbernici PCIe. S NVLinkom by bol TTFT zhruba 50–100 ms; pri PCIe P2P s 20 GB/s sa natiahne ďalej. Toto je priama daň architektúry bez NVLinku pri jednotlivých požiadavkách citlivých na latenciu (pozrite N03).

llama.cpp — Llama 3.3 70B Q4_K_M GGUF

Model: Llama-3.3-70B-Instruct-Q4_K_M.gguf. Backend: llama-cpp-python 0.3.20 s CUDA/cuBLAS, všetky vrstvy presunuté na GPU.

llama.cpp dodáva pri dekódovaní v jednom prúde zhruba 20 tok/s — lepšie než aktuálna hodnota vLLM s AWQ, čo možno pripísať tomu, že kernelová cesta llama.cpp postavená na cuBLAS si s kvantizáciou Q4_K_M rozumie. llama.cpp nepodporuje súbežné dávkovanie viacerých naraz bežiacich požiadaviek tak ako vLLM, takže 20 tok/s je strop na reláciu, nie súhrnná kapacita. Pri interaktívnej práci jedného používateľa je llama.cpp s 20 tok/s pohodlná rýchlosť čítania anglického výstupu.

Rýchlosť spracovania promptu 1,568 tok/s je vysoká. Meria, ako rýchlo dokáže model prijať prompt (fáza prefillu). Rýchly prefill je dôležitý, keď model prevádzkujete s dlhými systémovými promptmi alebo dokumentovým kontextom. Pri 1,568 tok/s sa dokumentový kontext so 4,000 tokenmi spracuje za menej než 3 sekundy, ešte než sa začne generovať.

Ekonomike a porovnaniu s cloudovými alternatívami sa venujú T01 (tok/s na euro) a T02 (náklady na milión tokenov on-prem vs. cloud).

Na čo slúžia jednotlivé enginy

Záťažový test — trvalá záťaž

Na overenie tepelnej a elektrickej stability pri maximálnej záťaži prebehli tri 60-sekundové záťažové testy: samotné GPU, samotný CPU a kombinovaná záťaž GPU+CPU.

Záťaž GPU (násobenie matíc FP16 na 100 %, 60 s)

Nula výpočtových chýb na všetkých štyroch GPU. Teploty stúpli z východiskových ~28°C a do 40. sekundy sa ustálili na stabilnej hodnote. Najteplejšie bežala GPU 2 na 72°C — na tejto pozícii je v ceste prúdenia vzduchu skrine najteplejšou kartou. Prah tepelného obmedzenia je pri RTX 4090 83°C; najvyššia nameraná teplota (72°C) ponecháva rezervu 11°C. Systém v žiadnom okamihu kvôli teplote nespomaľoval.

Výkonové limity boli na štyroch kartách nastavené na rôzne hodnoty (480 W, 450 W, 500 W, 480 W). Ide o drobnú nekonzistenciu, ktorú treba zjednotiť: nvidia-smi -pl 480 -i 0,1,2,3 (alebo s limitom, ktorý vám vyhovuje), aby boli pred produkčným nasadením limity rovnaké.

Kombinovaná záťaž GPU + CPU (všetky 4 GPU + 64 vlákien CPU naraz, 60 s)

Pridanie 64 vlákien CPU na 100 % záťaži znížilo súhrnné TFLOPS GPU len o 0.6 %. EPYC 7542 odoberá pri plnej záťaži zhruba 200 W TDP; celý systém bežal približne na 2.1–2.2 kW. Všetky teploty zostali v rezerve: GPU 2 pri kombinovanej záťaži vystúpila na 73°C, stále 10°C pod prahom tepelného obmedzenia.

Load average dosiahol počas záťaže CPU hodnotu 55+ (pri 64 vláknach očakávané). Systém bol po celý čas úplne stabilný; žiadne tepelné udalosti, žiadne výpočtové chyby, žiadne kernel panics.

Potvrdzuje to, že systém je vhodný na trvalé inferenčné workloady 24/7, pri ktorých je vyťažený aj CPU (predspracovanie, tokenizácia, réžia servovacej infraštruktúry).

Čo fungovalo dobre

Platforma EPYC. Rozpočet liniek PCIe je naozaj vyriešený. Všetky štyri karty RTX 4090 bežia pod záťažou na plných Gen4 x16 (potvrdené kontrolou stavu PCIe v 04d). Žiadna bifurkácia, žiadne degradované sloty. Niektoré zostavy na AMD Ryzen so štyrmi GPU bežia na dvoch či viacerých slotoch len na x8; na EPYC Rome to tak nie je.

RAM. 512 GB je pohodlných. Pri načítaní modelu v llama.cpp sa 38 GB súbor GGUF mapuje do pamäte; keď máte k dispozícii 512 GB, môžete popri LLM serveri spúšťať ďalšie procesy bez toho, aby si konkurovali o pamäť.

Sekvenčná rýchlosť NVMe. Sekvenčné čítanie 4,589 MB/s drží časy načítania krátke. Pri iteratívnej práci s modelmi — načítanie, testovanie, prepínanie modelov — sa to počas dňa nasčíta.

Teploty. Najhoršia trvalá teplota 73°C (GPU 2, kombinovaná záťaž) s rezervou 10°C. Pri bežnom inferenčnom workloade nebudú GPU bežať nepretržite na 100 % — dekódovanie je limitované priepustnosťou VRAM, nie výpočtom — takže reálne prevádzkové teploty budú nižšie než špička zo záťažového testu.

Vyhodnotenie promptu v llama.cpp na 1,568 tok/s. Toto číslo nás príjemne prekvapilo. Cesta prefillu cez cuBLAS na štyroch 4090 je rýchla. Aplikácie s dlhým kontextom z toho ťažia.

Čo nás prekvapilo

Nevybraný kernel AWQ vo vLLM. Benchmark bežal s kernelom awq namiesto awq_marlin. Uvádzacia sada testov to v tom čase vybrala automaticky podľa konfigurácie modelu. S awq_marlin sa očakáva skok priepustnosti pri jednej požiadavke z 8 tok/s na 16–24 tok/s. Ide o nápravu softvérovej konfigurácie, nie o hardvérové obmedzenie — pri nastavovaní produkčného serverovania si overte reťazec kvantizačnej metódy vo vLLM.

Priepustnosť D2H. Prenos zo zariadenia na host na úrovni 1.4 GB/s nás pri úvodnej analýze zaskočil. Ide o správanie CUDA pri nepripnutej pamäti, nie o chybu PCIe. Pre štandardné servovacie stacky (vLLM, llama.cpp) to nehrá rolu. Pri vlastnom inferenčnom kóde, ktorý presúva tenzory na CPU kvôli následnému spracovaniu, používajte alokácie v pripnutej pamäti.

Opravené chyby PCIe AER na GPU 3. Počas benchmarku vLLM zaznamenala GPU 3 (zbernica c1:00.0) opravené chyby PCIe (RxErr + BadTLP). Hardvér ich opravil automaticky a výpočet neovplyvnili. Pravdepodobná príčina: usadenie risera PCIe alebo opätovné dojednanie linky na rýchlosti Gen4. Odporúčame sledovať ich pri trvalej produkčnej záťaži; ak počet chýb narastie, preusaďte riser kábel GPU 3. Počas samotných záťažových testov nula chýb.

Krátky výpadok linky NIC. Sieťové rozhranie počas záťaže pri benchmarku GPU nakrátko vypadlo a vrátilo sa (13:38 UTC). Pravdepodobne ide o napäťový prechodový jav pri súčasnom nábehu GPU. V produkcii so spusteným nvidia-persistenced (ktorý udržiava kontexty GPU inicializované) sú prechodové javy pri nábehu záťaže menšie. Zapnite nvidia-persistenced ako službu systemd ešte pred produkčným nasadením.

Čo by sme vo verzii v2 urobili inak

Zapnúť awq_marlin od začiatku. Cestu kvantizačného kernelu vo vLLM overiť už počas uvádzania do prevádzky, nie až po ňom. Do uvádzacieho skriptu pridať kontrolu identity kernelu.

Zjednotiť výkonové limity GPU pred benchmarkovaním. Štyri karty boli dodané s rôzne nastavenými limitmi (480 W, 450 W, 500 W, 480 W). Nastavenie jednotného limitu (nvidia-smi -pl) pred prvým behom benchmarku dá čistejšie a lepšie porovnateľné čísla a zabráni nerovnomernému odberu počas kombinovanej záťaže.

Pridať monitorovací stack už pri dodaní. Prometheus s exportérom DCGM a Grafana sa nastavia za pár hodín a sprístupnia teplotu GPU, využitie VRAM a chybovosť PCIe v reálnom čase. Dodávať to ako súčasť štandardného uvedenia do prevádzky, nie to nechávať ako úlohu po dodaní. Pozrite si L05, kde nájdete návod na nastavenie tohto stacku.

Zafixovať nvidia-persistenced do unit súboru systemd už pri inštalácii OS. Je to jediný riadok, ale pravidelne sa naň zabúda. Bez neho trvá prvé zaťaženie GPU po období nečinnosti o pár sekúnd dlhšie a vznikne napäťový prechodový jav, ktorý spôsobil výpadok NIC.

Rozšírenie LVM. Disk OS (512 GB SATA) má pre oddiel LVM alokovaných len 100 GB. Zvyšných 374 GB je nealokovaných. Nie je dôvod to tak nechať: lvextend a resize2fs zaberú 30 sekúnd a vrátia vám toto miesto pre réžiu OS, logy a vrstvy Dockeru.

Zvážiť druhé NVMe pre úložisko modelov. Jediné 2 TB NVMe v súčasnosti drží všetky modely a s rastúcou knižnicou modelov sa zaplní. Druhé 4 TB NVMe v RAID 0 alebo jednoducho ako samostatný prípojný bod /mnt/nvme2 by pridalo flexibilitu a udržalo vysoký výkon sekvenčného čítania aj pri väčšej celkovej knižnici.

Porovnanie: alternatívy k tejto zostave

K workloadu zákazníka sa dalo pristúpiť aj s iným hardvérom. Tu je úprimné porovnanie:

Zostava 4× RTX 4090 s 96 GB je minimálna životaschopná konfigurácia na prevádzku Llama 3.3 70B AWQ INT4 pod vLLM so zmysluplnou dávkovou priepustnosťou. Nie je to strop; zostava s 8 GPU pridá kapacitu úmerne. Pre výskumného zákazníka, ktorý chce jeden vyhradený workstation — nie servovací klaster — býva 4× tým správnym začiatkom.

Ani konfigurácia 4×, ani 8× nemá medzi GPU NVLink, takže tensor-paralelná inferencia prebieha cez PCIe. Praktický dôsledok sa prejaví na latencii TTFT pri jednotlivých požiadavkách, nie na súhrnnej dávkovej priepustnosti. Pri workloade veľkosti tímu (desiatky požiadaviek za hodinu, nie tisíce) to nie je obmedzujúci faktor. Ak potrebujete TTFT pod 100 ms, pozrite si N03 aj zdôvodnenie, prečo ponuka cieli na viac-GPU zostavy prepojené cez PCIe namiesto systémov s NVSwitch.

Celkový príkon a elektrické plánovanie

Pri trvalej záťaži GPU bol celkový príkon systému približne 1,900–2,200 W meraných na vetvách GPU (1,914 W pri záťaži samotných GPU; ~2,100 W odhadom spolu s CPU, diskami a doskou). Počítajte so stratami účinnosti zdrojov (predpokladajte 90 %) a plánujte minimálne okruh 16 A/230 V, ideálne 20 A kvôli rezerve.

Usporiadanie s dvoma zdrojmi to rozdelí medzi dve zásuvky. Obe zásuvky musia byť na okruhoch, ktoré záťaž zvládnu samostatne: ak zdroj A napája dve GPU po 500 W plus 200 W na dosku a CPU, je to 1,200 W na jeho okruhu. Podľa toho okruh dimenzujte.

Rozpočet na chladenie miestnosti: počítajte tento systém ako 2.5 kW trvalo (konzervatívne, vrátane strát účinnosti a rezervy). Pri serverovni alebo rackovom rozvádzači s viacerými systémami sa súhrnné číslo rýchlo nasčíta.

Pozrite si P01, kde rozoberáme jednofázové verzus trojfázové napájanie, a P04, kde sa venujeme dimenzovaniu ističov.

Cenové pásmo

Zostava v tejto špecifikácii — platforma EPYC 7542, 512 GB ECC RAM, 4× RTX 4090, 2 TB NVMe, racková skriňa s dvoma zdrojmi — spadá do pásma €18,000–€24,000 bez DPH pri aktuálnych cenách komponentov, v závislosti od voľby skrine, načasovania nákupu RAM a dostupnosti GPU. Dodacia lehota je 10–28 dní podľa dostupnosti komponentov a potvrdzuje sa pri objednávke.

Toto pásmo nezahŕňa inštaláciu, rackovú PDU, sieťové prvky (10 GbE switch, kabeláž) ani softvérové licencie. Systém sa dodáva s predinštalovaným Ubuntu 24.04 LTS a prednastaveným Python venv; váhy modelov si prineste vlastné.

Na čo je táto zostava vhodná

• Výskum a LLM inferencia pre malý tím. Prevádzka modelu 70B pre tím 5–15 používateľov. Súhrnných 179 tok/s pod vLLM zvládne súbežné relácie s prehľadom.
• Vyhodnocovanie a iterácia modelov. Rýchle načítanie z NVMe znamená, že prepínanie medzi kandidátskymi modelmi je svižné. Vďaka rozpočtu liniek PCIe platformy EPYC majú všetky štyri GPU vždy plnú priepustnosť.
• Nasadenia so suverenitou nad dátami. Celá inferencia je lokálna. Žiadne tokeny neopustia budovu. Toto je hlavný neekonomický dôvod, prečo vo výskumnom prostredí prevádzkovať on-prem.
• Rozpočtovo priaznivý vstup do triedy 70B. RTX 4090 je spotrebiteľská GPU s najväčšou dostupnou VRAM. Pri 24 GB na kartu a štyroch kartách vás celkových 96 GB dostane do triedy 70B bez prechodu na ceny profesionálnych GPU.

Na čo táto zostava vhodná nie je

• TTFT pod 100 ms pri jednotlivej požiadavke. Tensor-paralelná topológia cez PCIe P2P stanovuje pri veľkých modeloch spodnú hranicu TTFT. Ak potrebujete rýchlu interaktívnu latenciu na modeloch 70B a väčších, táto architektúra je zlou voľbou. Chcete GPU prepojené NVLinkom, čo znamená úplne inú triedu hardvéru (pozrite N03).
• Súbežnú prevádzku viacerých veľkých modelov. Pri celkových 96 GB VRAM a gpu_memory_utilization=0.80 máte použiteľných zhruba 77 GB. Druhý model 70B INT4 by sa už nezmestil. Ak potrebujete hostovať dva modely naraz, prejdite na platformu s väčšou VRAM na GPU alebo s viacerými GPU.
• Produkčné serverovanie vo veľkom meradle. Pre stovky súbežných používateľov alebo dostupnosť krytú SLA nie je táto architektúra (bez prídavných NIC v skrini pre 4 GPU, jeden uzol, spotrebiteľské GPU s vypnutým ECC) správnym základom. Tým je server Kentino AI s 8 GPU s kartami L40 alebo RTX Pro 6000 Blackwell, poriadnym monitoringom a dvoma NIC.
• Trénovanie veľkých modelov. Pri celkových 96 GB VRAM dokážete modely 70B dolaďovať (LoRA, QLoRA), ale nedokážete ich trénovať v plnom počte parametrov. Pri trénovaní je rozpočet VRAM obmedzenejší než pri inferencii. Ak je trénovanie súčasťou plánu workloadu, zarátajte to.

---

Toto je súčasť Kentino Wiki, séria C (prípadové štúdie). Dáta zostavy namerané 2026-04-10. Článok publikovaný 2026-05-15. Opravy a nadväzujúce merania uvítame na info@kentino.com.