Případová studie: 4x pracovní stanice s umělou inteligencí a RTX 4090
Sdílet
Tento článek dokumentuje kompletní sestavení zadané pro výzkumného zákazníka, který potřeboval inferenční pracovní stanici LLM s možností montáže do racku, nepřetržitým provozem 24 hodin denně, 7 dní v týdnu a dostatečnou pamětí VRAM pro hostování modelů třídy 70B bez závislosti na cloudu. Vše zde je měřeno na skutečném hardwaru. Žádné syntetické odhady, žádná marketingová čísla.
Stavba byla uvedena do provozu a dodána v dubnu 2026. Srovnávací testy pro uvedení do provozu byly provedeny 10. dubna 2026.
Proč 4× RTX 4090
Požadavek na pracovní zátěž byl od začátku jasný: spustit kvantizovaný 70B LLM s použitelnou latencí jednoho požadavku, obsluhovat souběžné požadavky v prostředí malého výzkumného týmu a uchovávat vše on-premise z důvodu kontroly dat. Otázkou bylo, kolik GPU jakého typu.
Model s 70B RAM na INT4 (AWQ nebo GGUF Q4_K_M) v praxi zabírá zhruba 38–40 GB VRAM. To zcela eliminuje řešení s jednou GPU – ani RTX 4090 s 24 GB nemůže tento model hostovat sama. Potřebujete alespoň dvě, a nejlépe čtyři, aby tenzorově paralelní obsluha pod vLLM měla prostor pro KV cache.
Čtyři grafické karty RTX 4090 poskytují celkem 96 GB VRAM. To stačí k nabití modelu Llama 3.3 70B AWQ INT4... gpu_memory_utilization=0.80 a stále mít smysluplný prostor v mezipaměti KV pro dávkové požadavky. Poskytuje také výpočetní kapacitu – 4× 128 čipů SM běžících současně – což je důležité pro rychlost zpracování.
Zvažovanou alternativou byla 4× RTX Pro 6000 Blackwell, která by poskytla 4× 96 GB = 384 GB VRAM. To je zcela jiná úroveň: více VRAM, než potřebuje kterýkoli jednotlivý 70B model, vhodné pro souběžné spouštění více velkých modelů nebo hostování modelů třídy 200B+ s rozumnou kvantizací. Pro tuto pracovní zátěž – jeden primární model, malá souběžná dávka, na pracovní stanici s jedním klientem – by tato dodatečná kapacita zůstala nevyužita a rozdíl v ceně je značný. 4× RTX 4090 byla pro uvedený případ použití správným řešením.
V nabídce je také alternativa 8× L40. L40 nabízí 48 GB VRAM na kartu, podporu ECC a je navržena pro trvalé zatížení datových center. Pro tohoto zákazníka pracovní zatížení nevyžadovalo smlouvy o spolehlivosti na úrovni datových center, absence zvláštností ovladačů spotřebitelské třídy u L40 byla jen malou výhodou a rozpočet se na tuto hodnotu nedostal. Stojí za zmínku jako možnost upgradu.
Hned na úvod je třeba zmínit jeden architektonický strop: karty RTX 4090 nemají NVLink. Veškerá komunikace mezi GPU probíhá přes PCIe peer-to-peer. To je smysluplné pro tenzorově-paralelní inferenci (popsáno v benchmarkové části) a stojí za to to pochopit před objednáním. Viz. N03 pro úplný popis toho, kdy je NVLink důležitý a kdy ne.
Hardwarová specifikace
| Složka | Detail |
|---|---|
| Procesor (CPU) | AMD EPYC 7542 — 32 jader / 64 vláken, základní frekvence 2.9 GHz |
| Základní deska | ASRockRack ROMED8-2T/BCM, rev. 3.01 |
| RAM | 512 GB DDR4 ECC LRDIMM — 8× 64 GB SK Hynix @ 2666 MT/s |
| GPU | 4× NVIDIA GeForce RTX 4090 — 24 GB VRAM každá, celkem 96 GB |
| NVMe (modelové úložiště) | 2 TB PCIe 4.0 NVMe, namontovaný na /mnt/nvme/models/
|
| Disk s operačním systémem | 512 GB SATA SSD — 100 GB alokován LVM oddíl, zbytek rezervován |
| OS | Ubuntu 24.04.4 LTS, jádro 6.8.0-107-generic |
| Řidič | NVIDIA 590.48.01 (otevřený modul jádra) |
| CUDA | 13.1 (sada nástrojů 13.2), cuDNN 9.20.0 |
| Formální faktor | Montáž do racku 4U, směrované proudění vzduchu zepředu dozadu |
| PSU | Duální ATX – rozdělené napájení (není redundantní N+1) |
Pár poznámek k výběru:
CPU. EPYC 7542 je 32jádrový čip generace Rome se 128 MB L3 cache na 8 CCD čipech. Pro inferenční pracovní stanici je to nadměrně velké množství jader – čistou inferencí nenasytíte 64 vláken. Své místo si zaslouží v rozpočtu na linky PCIe: Rome EPYC poskytuje z CPU 128 linek PCIe 4.0, a proto na tuto platformu můžete umístit čtyři plnohodnotné grafické karty x16 bez sdílení linek nebo rozdvojení. RTX 4090 je zařízení PCIe 4.0 x16; chcete čtyři plné sloty x16 a EPYC je nabízí. Viz. W02 pro detail topologie jízdních pruhů.
RAM. Systém byl dodáván s 512 GB paměti DDR4 ECC LRDIMM, což překročilo původně specifikovaných 256 GB. Dodatečná systémová paměť RAM je zde skutečně užitečná: načítání modelů z NVMe probíhá přes systémovou paměť RAM před přenosem do VRAM a u větších modelů nebo při přepínání mezi modely znamená 512 GB, že v paměti RAM můžete současně uchovávat více sad vah modelů a vyhnout se opakovanému čtení z NVMe.
NVMe. Úložiště modelu (2 TB) je umístěno na vysokorychlostním disku PCIe 4.0 NVMe. Rychlost sekvenčního čtení je při načítání důležitá: 38GB soubor modelu s rychlostí sekvenčního čtení 4 589 MB/s se načte zhruba za 8–10 sekund. Naměřené doby načítání to potvrzují: soubor llama.cpp načetl 70B Q4_K_M GGUF za 10.8 sekundy; vLLM (který také vytváří grafy CUDA při načítání) trvalo 95 sekund.
Duální zdroj. Šasi používá dva napájecí zdroje ATX. Jedná se o rozdělené napájení: každý zdroj napájí část systému – obvykle dvě grafické karty a příslušné komponenty základní desky. Pokud jeden zdroj selže, ztratíte grafické karty na jeho lince. Nejedná se o redundanci N+1; jedná se o uspořádání kapacity napájení, nikoli o uspořádání pro případ selhání. U produkčních systémů, kde je provozuschopnost smluvní, je toto rozlišení důležité. Viz W04 pro kompletní diskusi o dimenzování PSU.
Proudění vzduchu podvozkem. Šasi je montováno do racku s průmyslovým směrovaným prouděním vzduchu zepředu dozadu. Grafické karty nejsou umístěny v otevřeném prostoru; jsou umístěny v kanálu s směrovaným prouděním vzduchu s ventilátory skříně, které nasávají vzduch přes chladiče a odsávají ho ven zezadu. Díky tomu je systém vhodný pro nepřetržitý provoz v rackovém prostředí 24 hodin denně, 7 dní v týdnu. Viz W05 pro detaily tepelného návrhu.
Zásobník softwaru
| Balíček | Verze |
|---|---|
| PyTorch | 2.10.0+cu128 |
| vLLM | 0.19.0 |
| llama-cpp-python | 0.3.20 (CUDA/cuBLAS) |
| transformátory | 4.57.6 |
| HuggingFace Hub, bitsandbytes, akcelerace | aktuální k datu sestavení |
Prostředí Pythonu se nachází na adrese /home/logic/llm-env/, modely na NVMe na /mnt/nvme/models/.
Výsledky uvedení do provozu
Základní úroveň výpočtů GPU
Prvním testem je vždy hrubý výpočet: násobení matic na FP16 (cesta Tensor Core) a FP32. Tím se potvrdí, že karty fungují správně, a poskytne se základní výpočetní hodnota pro porovnání s nominálními specifikacemi.
| GPU | FP16 (8192×8192) | FP32 (4096×4096) | Výpočetní limit |
|---|---|---|---|
| GPU 0 XNUMX | 171.7 TFLOPS | 59.5 TFLOPS | 8.9 |
| GPU 1 XNUMX | 162.1 TFLOPS | 54.9 TFLOPS | 8.9 |
| GPU 2 XNUMX | 171.0 TFLOPS | 58.5 TFLOPS | 8.9 |
| GPU 3 XNUMX | 171.2 TFLOPS | 60.1 TFLOPS | 8.9 |
Pro referenci: Teoretický vrchol Tensor Core FP16 pro RTX 4090 je ~330 TFLOPS, FP32 ~82.6 TFLOPS. Referenční hodnoty na ~52 % vrcholu FP16 jsou očekávané – měření je maturitní měření s trvalou propustností, které nedosahuje teoretického vrcholu ručně laděného jádra GEMM. Potvrzují, že všechna čtyři pole Tensor Core fungují a jsou konzistentní.
GPU 1 je na FP16 o ~6 % slabší než ostatní. Jedná se o normální odchylku v rámci stejného binárního boxu. Nejedná se o hardwarovou chybu.
Šířka pásma paměti GPU
| Cesta | Na GPU |
|---|---|
| Interní VRAM (kopie zařízení) | ~ 920 GB / s |
| Hostitel → Zařízení (PCIe) | 26.2–26.3 GB/s |
| Zařízení → Hostitel (PCIe) | 1.4 GB / s |
| Grafická karta ↔ Grafická karta (PCIe peer-to-peer) | 19–22 GB/s |
Šířka pásma VRAM 920 GB/s je v souladu se specifikací RTX 4090 (špička 1 008 GB/s; rozdíl je režie benchmarku). Tato hodnota šířky pásma je důležitá pro propustnost dekódování: každý vygenerovaný token vyžaduje načtení celé sady KV mezipaměti a váhových tenzorů z VRAM, takže šířka pásma přímo určuje limit rychlosti generování.
Údaj o přenosové rychlosti GPU-GPU (19–22 GB/s přes PCIe peer-to-peer) je architektonickým omezením relevantním pro tenzorově paralelní obsluhu. S NVLinkem běží tato cesta rychlostí 900 GB/s. Pouze s PCIe dosáhnete zhruba 2 % z této rychlosti. To není pro inferenci katastrofální – většina tenzorově paralelní komunikace na modelu 70B AWQ INT4 napříč 4 GPU se vejde do rozsahu, který PCIe zvládne – ale ve srovnání se systémem připojeným přes NVLink to snižuje rychlost dekódování jednoho požadavku. Viz níže uvedená část s benchmarky. N03 pro širší diskusi.
Jedna anomálie: Naměřená šířka pásma mezi zařízením a hostitelem byla 1.4 GB/s, což je hluboko pod očekávanými ~26 GB/s pro PCIe Gen4 x16. Jedná se o známé chování CUDA s nepřipojenou pamětí. Pokud vaše aplikace často přesouvá data z GPU na hostitele (např. vzorkování z výstupních logitů ve vlastním pipeline), použijte torch.pin_memory() nebo předalokovat připnuté vyrovnávací paměti. Standardní obslužné kanály vLLM a llama.cpp tuto cestu v aktivní smyčce neaktivují.
Všechny linky PCIe potvrzeny Gen4 x16 (16 GT/s) při zátěži. V klidovém stavu ovladač používá úsporný režim ASPM a linky klesají na Gen1 (2.5 GT/s) – to je normální a nejedná se o závadu zapojení nebo rozšiřující lišty.
Úložiště NVMe
| test | Propustnost | IOPS |
|---|---|---|
| Sekvenční čtení (bloky o velikosti 1 MB) | 4,589 MB/s | 4,376 |
| Sekvenční zápis (bloky 1 MB) | 4,213 MB/s | 4,017 |
| Náhodné čtení 4K (QD32) | 2,325 MB/s | 568,000 |
| Náhodný zápis 4K (QD32) | 2,273 MB/s | 555,000 |
Toto jsou silná čísla NVMe pro disk PCIe 4.0 pro spotřebitele/průmyslové zákazníky. Pro obsluhu modelů je relevantní číslo sekvenční čtení: 4 589 MB/s znamená, že 38GB model se načte do RAM přibližně za 8–9 sekund před jakýmkoli přenosem VRAM. Hodnota 568 tisíc náhodných IOPS je relevantnější, pokud používáte proces načítání (RAG, vektorové úložiště), kde je pracovní zátěž spočívá v mnoha malých náhodných čteních – tento disk to zvládá, aniž by se stal úzkým hrdlem.
vLLM závěr — Llama 3.3 70B AWQ INT4
Toto je základní benchmark. Model: casperhansen/llama-3.3-70b-instruct-awqPorce: vLLM 0.19.0 s tensor_parallel_size=4, max_model_len=2048, gpu_memory_utilization=0.80.
| test | Výsledek |
|---|---|
| Doba načítání modelu | 95.0 s |
| Jeden požadavek, max. 512 tokenů – propustnost | 8.0 tok/s |
| Jeden požadavek, max. 512 tokenů — čas na zeď | 64.3 s |
| Dávkové (32 souběžných požadavků, max. 256 tokenů) – agregované | 179.3 tok/s |
| Dávka – průměrná latence na požadavek | 1,428 ms |
| Krátký výzva, max. 16 tokenů – průměrná latence | 2,043 ms |
Rychlost dekódování jednoho požadavku 8.0 tok/s vyžaduje kontext. vLLM 0.19.0 spustil model AWQ s awq jádro, ne awq_marlin, awq_marlin Jádro je pro AWQ na grafických procesorech Ada Lovelace (RTX 4090) a Blackwell rychlejší cestou – benchmarkové poznámky ukazují, že během tohoto uvedení do provozu nebylo vybráno a očekává se 2–3× zlepšení rychlosti dekódování jednoho požadavku. awq_marlin, stejný model na stejném hardwaru by měl dosáhnout přibližně 16–24 tok/s v jednom streamu.
Pro produkci je relevantnější souhrnná hodnota 179.3 tok/s na základě 32 souběžných požadavků. Toto číslo uvidí malý tým, který se současně dostane ke koncovému bodu, jako kombinovaný systémový výstup. Nepřetržité dávkování ve vLLM znamená, že souběžné požadavky amortizují mezipaměť KV a výpočet pozornosti v celé dávce, a proto 32násobek počtu uživatelů neprodukuje 32násobek latence.
Latence 2 043 ms u požadavku se 16 tokeny představuje spodní hranici TTFT (time-to-first-token) pod vLLM v této konfiguraci. Pro interaktivní případy užití (chat, asistence s kódem) je to pomalejší varianta. Hlavním faktorem je tenzorově paralelní rozptyl/shromažďování napříč čtyřmi GPU přes PCIe – každý krok předběžného naplnění vyžaduje AllReduce napříč všemi čtyřmi kartami prostřednictvím PCIe fabric. S NVLink by to bylo zhruba 50–100 ms TTFT; s PCIe P2P při 20 GB/s se to prodlužuje ještě více. Toto jsou přímé náklady architektury bez NVLink u jednotlivých požadavků citlivých na latenci (viz N03).
lama.cpp — Lama 3.3 70B Q4_K_M GGUF
Model: Llama-3.3-70B-Instruct-Q4_K_M.ggufBackend: llama-cpp-python 0.3.20 s CUDA/cuBLAS, všechny vrstvy nahrávány na GPU.
| test | Výsledek |
|---|---|
| Doba načítání modelu | 10.8 s |
| Jeden požadavek, max. 256 tokenů – propustnost | 19.9 tok/s |
| Rychlé zpracování (1 302 tokenů) | 1,568 tok/s |
| Generování, maximálně 512 tokenů (vygenerováno 110) | 20.3 tok/s |
llama.cpp dosahuje zhruba 20 takt/s při dekódování jednoho streamu – což je lepší než aktuální číslo vLLM AWQ a lze to připsat cestě jádra llama.cpp založené na cuBLAS, která dobře funguje s kvantizací Q4_K_M. llama.cpp nepodporuje souběžné dávkování více simultánních požadavků tak, jak to dělá vLLM, takže 20 takt/s je strop na relaci, nikoli celková kapacita. Pro interaktivní pracovní postupy s jedním uživatelem je llama.cpp s rychlostí 20 takt/s pohodlná rychlost čtení pro anglický výstup.
Rychlost zpracování výzvy 1 568 tokenů/s je vysoká. To měří, jak rychle dokáže model výzvu zpracovat (fáze předběžného vyplňování). Rychlé předběžné vyplňování je důležité, když model spouštíte na dlouhých systémových výzvách nebo v kontextu dokumentu. Při rychlosti 1 568 tokenů/s je kontext dokumentu se 4 000 tokeny zpracován za méně než 3 sekundy, než začne generování.
Ekonomické aspekty a srovnání s cloudovými alternativami viz T01 (tok/s za euro) a T02 (cena za milion tokenů v on-premise vs. cloud).
K čemu jsou tyto dva motory
| Situace | Správná volba |
|---|---|
| Více uživatelů současně kontaktuje koncový bod API | vLLM (kontinuální dávkovací váhy) |
| Jeden interaktivní uživatel, citlivý na latenci | llama.cpp (nižší TTFT, srovnatelné dekódování při 20 tok/s) |
| Zpracování dlouhých dokumentů, dávková úloha | vLLM (lepší využití GPU pomocí dávkového zpracování) |
| Jednoduché lokální skriptování nebo vývojářské testování | llama.cpp (doba načítání 10 s oproti 95 s, jednodušší nastavení) |
Zátěžový test – trvalé zatížení
Byly provedeny tři 60sekundové zátěžové testy k ověření tepelné a elektrické stability při maximálním zatížení: testování pouze GPU, testování pouze CPU a kombinované testování GPU+CPU.
Vypalování GPU (násobení matice FP16 při 100 %, 60 s)
| GPU | Trvalý počet TFLOPS | Vrcholná teplota | Špičkový výkon |
|---|---|---|---|
| GPU 0 XNUMX | 165.8 | 67 ° C | 482 W |
| GPU 1 XNUMX | 153.2 | 64 ° C | 450 W |
| GPU 2 XNUMX | 166.4 | 72 ° C | 501 W |
| GPU 3 XNUMX | 166.2 | 62 ° C | 481 W |
| Celková cena | 651.6 | ~1 929 W dohromady |
Nulové chyby ve výpočtech na všech čtyřech GPU. Teploty se zvýšily z přibližně 28 °C na stabilní úroveň po 40. sekundě. GPU 2 se zahřívala nejvíce při 72 °C – v této pozici je to nejteplejší karta v proudění vzduchu v šasi. Teplotní prahová hodnota pro RTX 4090 je 83 °C; nejvyšší naměřená teplota (72 °C) ponechává 11 °C rozdíl. Systém se v žádném okamžiku neomezoval.
Stropní limity výkonu byly u všech čtyř karet nastaveny na různé hodnoty (480 W, 450 W, 500 W, 480 W). Jedná se o drobnou nesrovnalost, která by měla být normalizována: nvidia-smi -pl 480 -i 0,1,2,3 (nebo jakýkoli vhodný limit) stanovit konzistentní limity před použitím v produkčním prostředí.
Kombinované vypalování GPU + CPU (všechny 4 GPU + 64 vláken CPU současně, 60 s)
| GPU | Trvalý počet TFLOPS | Vrcholná teplota | Špičkový výkon |
|---|---|---|---|
| GPU 0 XNUMX | 164.9 | 69 ° C | 480 W |
| GPU 1 XNUMX | 152.5 | 67 ° C | 450 W |
| GPU 2 XNUMX | 165.2 | 73 ° C | 519 W |
| GPU 3 XNUMX | 165.1 | 66 ° C | 480 W |
| Celková cena | 647.7 | ~1 929 W dohromady |
Přidání 64 vláken CPU při 100% zatížení snížilo celkový počet TFLOPS GPU pouze o 0.6 %. EPYC 7542 spotřebovává při plném zatížení zhruba 200 W TDP; kombinovaný systém běžel s celkovou spotřebou přibližně 2.1–2.2 kW. Všechny teploty se udržely v rozmezí: GPU 2 dosáhla vrcholu 73 °C při kombinovaném zatížení, stále 10 °C pod prahem plynu.
Průměrné zatížení během fáze vypalování CPU dosáhlo 55+ (očekávalo se pro 64 vláken). Systém byl po celou dobu plně stabilní; žádné tepelné události, žádné výpočetní chyby, žádné paniky jádra.
To potvrzuje, že systém je vhodný pro nepřetržité inferenční úlohy 24 hodin denně, 7 dní v týdnu, kde je CPU také vytížené (předzpracování, tokenizace, režie obslužné infrastruktury).
Co fungovalo dobře
Platforma EPYC. Rozpočet na linky PCIe je skutečně vyřešen. Všechny čtyři karty RTX 4090 běží v plné zátěži na Gen4 x16 (potvrzeno v 04d Kontrola stavu PCIe). Žádné rozdvojení, žádné degradované sloty. Některé sestavy AMD Ryzen se čtyřmi GPU běží dva nebo více slotů na x8; na EPYC Rome tomu tak není.
RAM. 512 GB je pohodlných. Během načítání modelu llama.cpp je soubor GGUF o velikosti 38 GB mapován na paměť; s dostupnými 512 GB můžete spouštět více procesů současně se serverem LLM, aniž byste soupeřili o paměť.
Sekvenční rychlost NVMe. Sekvenční čtení rychlostí 4 589 MB/s zkracuje dobu načítání. V rámci pracovního postupu iterace modelu – načítání, testování, přepínání modelů – se to nasčítá za více než jeden den.
Termoprádlo. Nejhorší případ trvalé teploty 73 °C (GPU 2, kombinované vypalování) s 10 °C rezervy. V typickém inferenčním zatížení nebudou GPU běžet nepřetržitě se 100% využitím – dekódování je vázáno na šířku pásma VRAM, nikoli na výpočetní výkon – takže skutečné provozní teploty budou nižší než vrchol zátěžového testu.
llama.cpp 1 568 tok/s výzva k vyhodnocení. Toto číslo nás pozitivně překvapilo. Předfillovací cesta cuBLAS na čtyřech 4090 je rychlá. Z toho těží aplikace s dlouhým kontextem.
Co nás překvapilo
Jádro vLLM AWQ minulo cíl. Benchmark běžel s awq jádro místo awq_marlinSada pro uvedení do provozu to spustila automaticky na základě aktuální konfigurace modelu. S awq_marlin, očekává se, že propustnost jednoho požadavku vzroste z 8 tok/s na 16–24 tok/s. Jedná se o opravu softwarové konfigurace, nikoli o hardwarové omezení – při nastavování produkčního provozu ověřte řetězec kvantizační metody vLLM.
Šířka pásma D2H. Rychlost přenosu dat mezi zařízeními a hostiteli s rychlostí 1.4 GB/s nás během počáteční analýzy zaskočila. Jedná se o chování paměti CUDA bez nutnosti připnutí, nikoli o chybu PCIe. Pro standardní obslužné zásobníky (vLLM, llama.cpp) to nevadí. Pro vlastní inferenční kód, který přesouvá tenzory do CPU pro následné zpracování, použijte připnutí alokací paměti.
Opraveny chyby v GPU 3 PCIe AER. Během benchmarku vLLM zaznamenala grafická karta GPU 3 (sběrnice c1:00.0) opravené chyby PCIe (RxErr + BadTLP). Tyto chyby byly hardwarově automaticky opraveny a neovlivnily výpočet. Pravděpodobná příčina: Usazení rozšiřující karty PCIe nebo opětovné vyjednávání linky při rychlosti Gen4. Doporučuje se monitorovat při trvalém provozním zatížení; pokud se počet chyb zvýší, znovu usaďte kabel rozšiřující karty GPU 3. Během samotných zátěžových testů nedošlo k žádným chybám.
Krátká klapka propojení síťové karty. Síťové rozhraní krátce přestalo fungovat a znovu se aktivovalo během benchmarkového zatížení GPU (13:38 UTC). Pravděpodobně se jedná o přechodový výpadek napájení způsobený současným zapnutím GPU. V produkčním prostředí s... nvidia-persistenced běží (což udržuje kontexty GPU inicializované), přechodové jevy napájení při spuštění zátěže jsou menší. Povolit nvidia-persistenced jako služba Systemd před produkčním spuštěním.
Co bychom udělali jinak pro v2
umožnit awq_marlin od začátku. Ověřte cestu k jádru kvantizace vLLM během uvádění do provozu, nikoli po něm. Do skriptu pro uvádění do provozu přidejte kontrolu identity jádra.
Před benchmarkingem normalizujte limity výkonu GPU. Čtyři karty byly dodávány s různě nakonfigurovanými limity (480 W, 450 W, 500 W, 480 W). Nastavení konzistentního limitu (nvidia-smi -pl) před prvním benchmarkovým spuštěním poskytuje čistší a srovnatelnější čísla a zabraňuje nekonzistentní spotřebě energie během kombinovaného spalování.
Při dodání přidejte monitorovací zásobník. Nastavení Prometheusu s exportérem DCGM a Grafanou trvá několik hodin a v reálném čase zobrazuje teplotu GPU, využití VRAM a chybovost PCIe. Dodávejte to jako součást standardního uvedení do provozu, nikoli jako úkol po dodání. Viz. L05 pro průvodce nastavením zásobníku.
Pin nvidia-persistenced do souboru systemd jednotky během instalace operačního systému. Je to jednořádkové doporučení, ale neustále se vynechává. Bez něj první načtení grafické karty po období klidu trvá o několik sekund déle a způsobuje přechodové hlášení o napájení, které způsobuje výpadek síťové karty.
Rozšíření LVM. Disk s operačním systémem (512 GB SATA) má pro LVM oddíl alokovaných pouze 100 GB. Zbývajících 374 GB je nepřidělených. Není důvod je ponechávat: lvextend a resize2fs věnujte 30 sekund a ten prostor vám vrátíme na režii operačního systému, logy a vrstvy Dockeru.
Zvažte druhé NVMe pro ukládání modelů. Jeden 2TB NVMe disk v současné době pojme všechny modely a bude se zaplňovat s růstem knihovny modelů. Druhý 4TB NVMe disk v RAID 0 nebo jednoduše jako samostatný disk. /mnt/nvme2 Příkaz mount by zvýšil flexibilitu a udržel vysoký výkon sekvenčního čtení v rámci větší knihovny.
Srovnání: Alternativy k této sestavě
Zákazníkovo pracovní zatížení se dalo zvládnout s jiným hardwarem. Zde je poctivé srovnání:
| Konfigurace | Celkový počet VRAM | Propojení GPU↔GPU | Poznámky |
|---|---|---|---|
| 4× RTX 4090 (tato sestava) | 96 GB | PCIe P2P, 19–22 GB/s | Dobré pro třídu 70B. Žádný NVLink = penalizace PCIe P2P na TP. |
| 4× RTX Pro 6000 Blackwell | 384 GB | PCIe P2P (bez NVLinku na Pro 6000) | Stejná topologie PCIe, 4× více VRAM – nadbytečné pro jednu 70B paměť, správné pro multimodel nebo 200B+ |
| 8× L40 | 384 GB | PCIe P2P | ECC třídy datových center, stejná topologie bez NVLink, vyšší náklady |
| 8× RTX 4090 | 192 GB | PCIe P2P | Dvojnásobná propustnost; šasi s 8 GPU využívá AMD EPYC Genoa/Turin (podle řady K-AI) |
4× RTX 4090 s 96 GB je minimální konfigurace pro spuštění Llama 3.3 70B AWQ INT4 pod vLLM s rozumnou dávkovou propustností. Není to však strop; sestavení s 8 GPU úměrně zvyšuje kapacitu. Pro výzkumného zákazníka, který chce jednu dedikovanou pracovní stanici – nikoli obslužný cluster – je 4× často tím správným místem, kde začít.
Ani konfigurace 4×, ani 8× nemá NVLink mezi GPU, což znamená, že tenzorově paralelní inference funguje přes PCIe. Praktickým důsledkem je latence TTFT pro jednotlivé požadavky, nikoli agregovaná dávková propustnost. Pro pracovní zátěž o velikosti týmu (desítky požadavků za hodinu, ne tisíce) to není omezující faktor. Požadavky na TTFT pod 100 ms viz N03 a důvody, proč se tato řada zaměřuje na systémy s více grafickými procesory připojenými přes PCIe, nikoli na systémy s technologií NVSwitch Fabric.
Celkové plánování napájení a elektroinstalace
Při trvalém zatížení GPU byl celkový výkon systému přibližně 1 900–2 200 W měřeno na lištách GPU (1 914 W spotřeba pouze GPU; odhadováno přibližně 2 100 W v kombinaci s CPU, disky a základní deskou). Zohledněte ztráty účinnosti zdroje (předpokládejte 90 %) a počítajte s minimálním obvodem 16 A/230 V, s preferovaným 20 A pro rezervu.
U dvou zdrojů napájení je toto rozděleno mezi dva výstupy. Oba výstupy musí být na obvodech, které dokáží nezávisle zvládnout zátěž: pokud zdroj A napájí dvě grafické karty s výkonem 500 W každá plus 200 W desky/CPU, je to 1,200 W na obvodu. Dimenzujte podle toho.
Rozpočet na chlazení místnosti: tento systém považujte za trvale výkonný 2.5 kW (konzervativní, zahrnuje ztráty účinnosti a rezervu). U serverovny nebo rackové skříně s více systémy se souhrnné číslo rychle zvyšuje.
See P01 pro porovnání jednofázových a třífázových systémů a P04 pro dimenzování jističe.
Cenové pásmo
Sestavení s touto specifikací – platforma EPYC 7542, 512 GB ECC RAM, 4× RTX 4090, 2 TB NVMe, rackové šasi s duálním zdrojem – spadá do kategorie 18 000–24 000 € bez DPH Rozsah cen komponentů závisí na výběru šasi, načasování dodání paměti RAM a dostupnosti grafického procesoru. Dodací lhůta je 10–28 dní v závislosti na dostupnosti komponent, potvrzené při objednávce.
Tato nabídka nezahrnuje instalaci, rackové PDU, síťové připojení (10GbE přepínač, kabeláž) ani licencování softwaru. Systém je dodáván s předinstalovaným Ubuntu 24.04 LTS a předkonfigurovaným Pythonem venv; přineste si vlastní váhy modelu.
K čemu je tato konstrukce vhodná
- Výzkum a inference LLM v malém týmu. Spuštění modelu 70B pro tým 5–15 uživatelů. Agregát 179 tok/s pod vLLM pohodlně zvládá souběžné relace.
- Vyhodnocení a iterace modelu. Rychlé načítání NVMe znamená rychlé přepínání mezi kandidátskými modely. Rozpočet PCIe linek platformy EPYC znamená, že všechny čtyři GPU jsou vždy na plné šířce pásma.
- Datově suverénní nasazení. Veškerá inference je lokální. Žádné tokeny neopouštějí budovu. Toto je primární neekonomický důvod pro provozování on-premise pro výzkumné kontexty.
- Cenově dostupný vstupní bod 70B. RTX 4090 je GPU s nejvyšší dostupnou kapacitou VRAM pro spotřebitele. S 24 GB na kartu a čtyřmi kartami vás celkem 96 GB zavede do třídy 70B, aniž byste museli překročit cenu profesionálních GPU.
K čemu tato sestava není vhodná
- TTFT s jedním požadavkem pod 100 ms. Tenzorově paralelní topologie PCIe P2P klade u velkých modelů minimální TTFT. Pokud potřebujete rychlou interaktivní latenci na modelech s kapacitou 70B+, je tato architektura špatnou volbou. Chcete grafické karty připojené přes NVLink, což znamená zcela jinou třídu hardwaru (viz N03).
-
Současné spouštění více velkých modelů. S celkovou pamětí VRAM 96 GB
gpu_memory_utilization=0.80, máte k dispozici zhruba 77 GB. Druhý model s 70B INT4 by se nevešel. Pokud potřebujete hostovat dva modely současně, upgradujte na platformu s větším množstvím VRAM na GPU nebo s více GPU. - Obsluha velkovýroby. Pro stovky souběžných uživatelů nebo dostupnost zálohovanou SLA není tato architektura (žádné doplňky síťových karet na šasi se 4 GPU, jeden uzel, spotřebitelské GPU s vypnutou ECC) tím správným základem. 8GPU server K-AI s L40 nebo RTX Pro 6000 Blackwell, řádným monitorováním a dvěma síťovými kartami ano.
- Trénování velkých modelů. S celkovou kapacitou 96 GB VRAM sice můžete u modelů s procesorem 70B jemně doladit parametry (LoRA, QLoRA), ale nelze je trénovat s plnými parametry. Pro trénování je rozpočet VRAM omezenější než pro inferenci. Pokud je trénování součástí plánu pracovní zátěže, zohledněte to.
Poučení a co dělat dál
Čtyři kroky, které je třeba provést před uvedením tohoto systému do produkčního prostředí:
-
Ověřte cestu k jádru vLLM. Běh
vllm serve --helpa potvrďteawq_marlinje vybráno pro modely AWQ na grafických procesorech Ada Lovelace. Očekávaný výsledek: dekódování jednoho požadavku se zvýší z 8 takt/s na 16–24 takt/s. -
Normalizujte limity výkonu. Běh
nvidia-smi -pl 480 -i 0,1,2,3(upravte si zvolený limit) a před spuštěním produkčního benchmarku nebo pracovní zátěže se ujistěte, že všechny čtyři karty hlásí stejný limit. -
umožnit
nvidia-persistencedjako služba Systemd. Zabraňuje přechodovému jevům při prvním zatížení, které způsobují výpadek síťové karty. Jednoduše řečeno, proveďte to při instalaci operačního systému. - Nasaďte monitorovací zásobník. Prometheus + exportér DCGM + Grafana. Teplota GPU, využití VRAM, čítače chyb PCIe, hloubka fronty. Bez něj bude prvním příznakem problému spíše stížnost uživatele než upozornění. Viz L05.
Související čtení: N03 (NVLink vs. PCIe P2P – když na rozdílu záleží), W02 (Topologie PCIe linek na EPYC), W04 (Výběr velikosti zdroje a duální zdroj vs. N+1), W05 (tepelný návrh pro rackové systémy GPU), T01 (srovnání tok/s za euro), T02 (náklady na milion tokenů v on-premise vs. cloudu).
Toto je součást Kentino Wiki, série C (Případové studie). Data sestavení naměřena 10. 04. 2026. Článek publikován 15. 05. 2026. Opravy a následná měření jsou vítány na adrese info@kentino.com.