Studium przypadku: stacja robocza AI z 4x RTX 4090

Artykuł dokumentuje kompletną konfigurację złożoną na zamówienie klienta badawczego, który potrzebował stacji roboczej do inferencji LLM — montowanej w racku, przystosowanej do pracy 24/7 i wyposażonej w ilość VRAM wystarczającą do uruchomienia modeli klasy 70B bez zależności od chmury. Wszystkie wartości zmierzono na rzeczywistym sprzęcie. Żadnych szacunków syntetycznych, żadnych liczb marketingowych.

Konfigurację zamówiono i dostarczono w kwietniu 2026. Testy odbiorcze przeprowadzono 2026-04-10.

Dlaczego 4× RTX 4090

Wymagania dotyczące obciążenia były jasne od początku: uruchomić skwantyzowany model LLM 70B przy użytecznym opóźnieniu pojedynczego zapytania, obsłużyć równoległe zapytania w małym zespole badawczym i utrzymać całość lokalnie, ze względu na kontrolę nad danymi. Pytanie brzmiało: ile kart GPU i jakich.

Model 70B w INT4 (AWQ lub GGUF Q4_K_M) zajmuje w praktyce około 38–40 GB VRAM. To całkowicie eliminuje rozwiązania jednokartowe — nawet RTX 4090 z 24 GB nie pomieści modelu samodzielnie. Potrzebne są co najmniej dwie karty, a najlepiej cztery, aby serwowanie w trybie tensor-parallel pod vLLM miało zapas na pamięć podręczną KV.

Cztery karty RTX 4090 dają łącznie 96 GB VRAM. To wystarczy, aby wczytać model Llama 3.3 70B AWQ INT4 z gpu_memory_utilization=0.80 i nadal dysponować sensowną przestrzenią na pamięć podręczną KV dla zapytań wsadowych. Daje to również moc obliczeniową — 4× układy ze 128 SM pracujące jednocześnie — która ma znaczenie dla szybkości przetwarzania promptów.

Rozważaną alternatywą było 4× RTX Pro 6000 Blackwell, co dałoby 4× 96 GB = 384 GB VRAM. To zupełnie inna klasa: więcej VRAM, niż potrzebuje jakikolwiek pojedynczy model 70B, odpowiednia do równoczesnego uruchamiania wielu dużych modeli lub hostowania modeli klasy 200B+ przy rozsądnej kwantyzacji. Przy tym obciążeniu — jeden model główny, niewielka partia równoległych zapytań, budżet jednostanowiskowej stacji roboczej — ta nadwyżka pozostałaby niewykorzystana, a różnica w cenie jest znacząca. Dla opisanego zastosowania 4× RTX 4090 było właściwą odpowiedzią.

W ofercie istnieje też wariant 8× L40. L40 daje 48 GB VRAM na kartę, obsługę ECC i jest projektowana pod ciągłe obciążenie w centrum danych. W przypadku tego klienta obciążenie nie wymagało umów o niezawodności klasy centrum danych, brak sterownikowych osobliwości klasy konsumenckiej był w L40 korzyścią drugorzędną, a budżet nie sięgał tak wysoko. Warto o tym wiedzieć jako o ścieżce rozbudowy.

Jedno ograniczenie architektoniczne warto wymienić od razu: karty RTX 4090 nie mają NVLink. Cała komunikacja GPU–GPU odbywa się przez PCIe peer-to-peer. Ma to znaczenie dla inferencji tensor-parallel (omówionej w sekcji z benchmarkami) i warto to rozumieć przed złożeniem zamówienia. Zob. N03 — pełne omówienie tego, kiedy NVLink ma znaczenie, a kiedy nie.

Specyfikacja sprzętowa

Kilka uwag na temat tych wyborów:

CPU. EPYC 7542 to 32-rdzeniowy układ generacji Rome ze 128 MB pamięci L3 rozłożonej na 8 CCD. Jak na stację roboczą do inferencji jest przewymiarowany pod względem samej liczby rdzeni — czystą inferencją nie da się wysycić 64 wątków. Swoje miejsce zawdzięcza budżetowi linii PCIe: EPYC Rome udostępnia 128 linii PCIe 4.0 z procesora, dzięki czemu na tej platformie można umieścić cztery pełne karty x16 bez współdzielenia linii czy bifurkacji. RTX 4090 to urządzenie PCIe 4.0 x16; potrzebne są cztery pełne sloty x16, a EPYC je zapewnia. Zob. W02 — szczegóły topologii linii.

RAM. System dostarczono z 512 GB DDR4 ECC LRDIMM, czyli powyżej pierwotnie zakładanych 256 GB. Dodatkowa pamięć systemowa jest tu naprawdę przydatna: wczytywanie modelu z NVMe odbywa się etapowo przez pamięć systemową przed transferem do VRAM, a przy większych modelach lub przy przełączaniu się między modelami 512 GB oznacza możliwość jednoczesnego przechowywania w RAM kilku zestawów wag i uniknięcia wielokrotnych odczytów z NVMe.

NVMe. Magazyn modeli (2 TB) znajduje się na szybkim dysku NVMe PCIe 4.0. Prędkość odczytu sekwencyjnego ma znaczenie przy wczytywaniu: plik modelu o rozmiarze 38 GB przy odczycie sekwencyjnym 4,589 MB/s wczytuje się w około 8–10 sekund. Zmierzone czasy to potwierdzają: llama.cpp wczytał GGUF 70B Q4_K_M w 10.8 sekundy; vLLM (który podczas wczytywania buduje też grafy CUDA) potrzebował 95 sekund.

Podwójny zasilacz. Obudowa korzysta z dwóch zasilaczy ATX. Jest to rozdzielone zasilanie: każdy zasilacz obsługuje część systemu — zazwyczaj po dwie karty GPU i powiązane elementy płyty. Awaria jednego zasilacza oznacza utratę kart GPU na jego szynie. To nie jest redundancja N+1; to układ zapewniający moc, a nie przełączanie awaryjne. W systemach produkcyjnych, w których dostępność jest zapisana w umowie, rozróżnienie to ma znaczenie. Zob. W04 — pełne omówienie doboru mocy zasilaczy.

Przepływ powietrza w obudowie. Obudowa jest przystosowana do montażu w racku, z przemysłowym kierowanym przepływem powietrza od przodu do tyłu. Karty GPU nie pracują w układzie otwartym; znajdują się w kanale kierowanego przepływu, w którym wentylatory obudowy przeciągają powietrze przez radiatory i wyrzucają je z tyłu. Dzięki temu system nadaje się do ciągłej pracy 24/7 w środowisku rackowym. Zob. W05 — szczegóły projektu termicznego.

Stos oprogramowania

Środowisko Pythona znajduje się w /home/logic/llm-env/, modele na dysku NVMe w /mnt/nvme/models/.

Wyniki testów odbiorczych

Punkt odniesienia dla mocy obliczeniowej GPU

Pierwszym testem zawsze jest surowa moc obliczeniowa: mnożenie macierzy w FP16 (ścieżka Tensor Core) oraz w FP32. Potwierdza to poprawne działanie kart i daje punkt odniesienia do porównania ze specyfikacją nominalną.

Dla odniesienia: teoretyczny szczyt FP16 na Tensor Core dla RTX 4090 wynosi ~330 TFLOPS, a FP32 ~82.6 TFLOPS. Wyniki benchmarku na poziomie ~52% szczytu FP16 są zgodne z oczekiwaniami — pomiar dotyczy mnożenia macierzy o trwałej przepustowości, które nie osiąga teoretycznego szczytu ręcznie optymalizowanego jądra GEMM. Potwierdzają one, że wszystkie cztery macierze Tensor Core działają i są spójne.

GPU 1 osiąga w FP16 wynik o ~6% niższy niż pozostałe. To normalna zmienność krzemu w obrębie tego samego binu. Brak usterki sprzętowej.

Przepustowość pamięci GPU

Przepustowość VRAM na poziomie 920 GB/s jest zgodna ze specyfikacją RTX 4090 (szczyt 1,008 GB/s; różnica to narzut benchmarku). To właśnie ta wartość decyduje o przepustowości dekodowania: wygenerowanie każdego tokenu wymaga wczytania z VRAM pełnego zestawu pamięci podręcznej KV i tensorów wag, więc przepustowość bezpośrednio wyznacza górny limit szybkości generowania.

Wynik GPU–GPU (19–22 GB/s przez PCIe peer-to-peer) to ograniczenie architektoniczne istotne dla serwowania w trybie tensor-parallel. Z NVLink ta ścieżka pracuje z prędkością 900 GB/s. Przy samym PCIe dostępne jest około 2% tej wartości. Dla inferencji nie jest to katastrofa — większość komunikacji tensor-parallel dla modelu 70B AWQ INT4 na 4 kartach GPU mieści się w możliwościach PCIe — ale obniża to szybkość dekodowania pojedynczego zapytania w porównaniu z systemem połączonym przez NVLink. Zob. sekcję z benchmarkami poniżej oraz N03 — szersze omówienie zagadnienia.

Jedna anomalia: przepustowość w kierunku urządzenie → host zmierzono na poziomie 1.4 GB/s, znacznie poniżej oczekiwanych ~26 GB/s dla PCIe Gen4 x16. To znane zachowanie CUDA przy pamięci niezablokowanej (non-pinned). Jeżeli aplikacja często przenosi dane z GPU do hosta (np. próbkowanie z logitów wyjściowych we własnym potoku), warto użyć torch.pin_memory() lub wstępnie zaalokować bufory pinned. Standardowe potoki serwujące vLLM i llama.cpp nie korzystają z tej ścieżki w pętli krytycznej.

Wszystkie łącza PCIe potwierdzono jako Gen4 x16 (16 GT/s) pod obciążeniem. W spoczynku sterownik korzysta z oszczędzania energii ASPM i łącza spadają do Gen1 (2.5 GT/s) — jest to normalne i nie oznacza usterki okablowania ani riserów.

Magazyn NVMe

To mocne wyniki jak na dysk NVMe PCIe 4.0 klasy konsumenckiej/prosumenckiej. Przy serwowaniu modeli liczy się odczyt sekwencyjny: 4,589 MB/s oznacza, że model o rozmiarze 38 GB wczytuje się do RAM w około 8–9 sekund, jeszcze przed transferem do VRAM. Wartość 568K losowych IOPS nabiera znaczenia przy potokach wyszukiwania (RAG, baza wektorowa), gdzie obciążenie to wiele drobnych odczytów losowych — ten dysk radzi sobie z tym, nie stając się wąskim gardłem.

Inferencja vLLM — Llama 3.3 70B AWQ INT4

To benchmark kluczowy. Model: casperhansen/llama-3.3-70b-instruct-awq. Serwowanie: vLLM 0.19.0 z tensor_parallel_size=4, max_model_len=2048, gpu_memory_utilization=0.80.

Szybkość dekodowania 8.0 tok/s dla pojedynczego zapytania wymaga kontekstu. vLLM 0.19.0 uruchomił model AWQ z jądrem awq, a nie awq_marlin. Jądro awq_marlin to szybsza ścieżka dla AWQ na kartach Ada Lovelace (RTX 4090) i Blackwell — notatki z benchmarku wskazują, że nie zostało wybrane podczas tego uruchomienia odbiorczego, a oczekiwana poprawa szybkości dekodowania pojedynczego zapytania to 2–3×. Z awq_marlin ten sam model na tym samym sprzęcie powinien osiągać około 16–24 tok/s w pojedynczym strumieniu.

Wynik łączny 179.3 tok/s przy 32 równoległych zapytaniach jest bardziej miarodajny produkcyjnie. To właśnie taką łączną wydajność systemu zobaczy mały zespół korzystający z endpointu jednocześnie. Ciągłe grupowanie wsadowe w vLLM sprawia, że równoległe zapytania amortyzują pamięć podręczną KV i obliczenia mechanizmu uwagi w obrębie wsadu — dlatego 32× więcej użytkowników nie oznacza 32× większego opóźnienia.

Opóźnienie 2,043 ms przy zapytaniu o 16 tokenów to dolna granica TTFT (czasu do pierwszego tokenu) dla vLLM w tej konfiguracji. Dla zastosowań interaktywnych (czat, asysta przy kodzie) jest to wartość raczej wysoka. Główną przyczyną jest narzut operacji scatter/gather w trybie tensor-parallel na czterech kartach GPU przez PCIe — każdy krok prefillu wymaga operacji AllReduce na wszystkich czterech kartach przez magistralę PCIe. Z NVLink TTFT wynosiłby mniej więcej 50–100 ms; przy PCIe P2P na poziomie 20 GB/s rośnie wyraźnie. To bezpośredni koszt architektury bez NVLink dla pojedynczych zapytań wrażliwych na opóźnienie (zob. 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 z CUDA/cuBLAS, wszystkie warstwy przeniesione na GPU.

llama.cpp osiąga około 20 tok/s przy dekodowaniu w pojedynczym strumieniu — lepiej niż obecny wynik vLLM dla AWQ, co wynika z dobrego dopasowania opartej na cuBLAS ścieżki jądra llama.cpp do kwantyzacji Q4_K_M. llama.cpp nie obsługuje równoległego grupowania wielu jednoczesnych zapytań w taki sposób jak vLLM, więc 20 tok/s to limit na sesję, a nie łączna wydajność. Przy interaktywnej pracy jednego użytkownika 20 tok/s w llama.cpp to komfortowe tempo czytania tekstu angielskiego.

Szybkość przetwarzania promptu na poziomie 1,568 tok/s jest wysoka. Mierzy ona, jak szybko model przyswaja prompt (faza prefillu). Szybki prefill ma znaczenie przy długich promptach systemowych lub kontekście dokumentowym. Przy 1,568 tok/s kontekst dokumentu o długości 4,000 tokenów jest przetwarzany w niecałe 3 sekundy, zanim rozpocznie się generowanie.

Analizę ekonomiczną i porównanie z alternatywami chmurowymi zawierają T01 (tok/s na euro) oraz T02 (koszt miliona tokenów lokalnie i w chmurze).

Do czego służy każdy z silników

Test obciążeniowy — praca ciągła

Przeprowadzono trzy 60-sekundowe testy obciążeniowe, aby zweryfikować stabilność termiczną i elektryczną przy maksymalnym obciążeniu: wygrzewanie samego GPU, samego CPU oraz GPU i CPU jednocześnie.

Wygrzewanie GPU (mnożenie macierzy FP16 przy 100%, 60 s)

Zero błędów obliczeniowych na wszystkich czterech kartach GPU. Temperatury wzrosły z poziomu wyjściowego ~28°C do stabilnego plateau do 40. sekundy. Najcieplejszy był GPU 2 z wynikiem 72°C — na tej pozycji jest to najgorętsza karta na ścieżce przepływu powietrza w obudowie. Próg ograniczania termicznego dla RTX 4090 wynosi 83°C; najwyższa zmierzona temperatura (72°C) pozostawia 11°C zapasu. W żadnym momencie system nie ograniczał taktowania.

Limity mocy ustawiono na kartach na różnych poziomach (480 W, 450 W, 500 W, 480 W). To drobna niespójność, którą należy ujednolicić: nvidia-smi -pl 480 -i 0,1,2,3 (lub inny odpowiedni limit), aby ustawić spójne wartości przed wdrożeniem produkcyjnym.

Łączne wygrzewanie GPU + CPU (wszystkie 4 karty GPU + 64 wątki CPU jednocześnie, 60 s)

Dodanie 64 wątków CPU przy 100% obciążenia obniżyło łączne TFLOPS kart GPU zaledwie o 0.6%. EPYC 7542 pobiera przy pełnym obciążeniu około 200 W TDP; cały system pracował z poborem około 2.1–2.2 kW. Wszystkie temperatury pozostały w granicach zapasu: GPU 2 osiągnął pod łącznym obciążeniem maksymalnie 73°C, nadal 10°C poniżej progu ograniczania.

W fazie wygrzewania CPU obciążenie systemu (load average) przekroczyło 55 — wartość oczekiwana przy 64 wątkach. System przez cały czas pozostawał w pełni stabilny; żadnych zdarzeń termicznych, błędów obliczeniowych ani kernel panic.

Potwierdza to, że system nadaje się do ciągłych obciążeń inferencyjnych 24/7, także wtedy, gdy procesor jest równolegle obciążony (preprocessing, tokenizacja, narzut infrastruktury serwującej).

Co sprawdziło się dobrze

Platforma EPYC. Budżet linii PCIe jest tu realnie rozwiązany. Wszystkie cztery karty RTX 4090 pracują pod obciążeniem w pełnym trybie Gen4 x16 (potwierdzone w kontroli stanu PCIe 04d). Bez bifurkacji, bez obniżonych slotów. W części konfiguracji na AMD Ryzen z czterema kartami GPU dwa lub więcej slotów pracuje w trybie x8; na EPYC Rome tak nie jest.

RAM. 512 GB daje komfort. Podczas wczytywania modelu w llama.cpp plik GGUF o rozmiarze 38 GB jest mapowany w pamięci; 512 GB oznacza, że obok serwera LLM można uruchamiać kolejne procesy bez walki o pamięć.

Prędkość sekwencyjna NVMe. Odczyt sekwencyjny 4,589 MB/s utrzymuje krótkie czasy wczytywania. Przy pracy iteracyjnej z modelami — wczytywanie, testowanie, przełączanie modeli — w skali dnia robi to różnicę.

Warunki termiczne. Najgorszy przypadek temperatury ciągłej to 73°C (GPU 2, łączne wygrzewanie) przy 10°C zapasu. W typowym obciążeniu inferencyjnym karty GPU nie pracują nieprzerwanie przy 100% wykorzystania — dekodowanie jest ograniczone przepustowością VRAM, a nie mocą obliczeniową — więc rzeczywiste temperatury pracy będą niższe niż szczyt z testu obciążeniowego.

1,568 tok/s w ocenie promptu w llama.cpp. Ten wynik pozytywnie nas zaskoczył. Ścieżka prefillu oparta na cuBLAS na czterech kartach 4090 jest szybka. Korzystają na tym zastosowania z długim kontekstem.

Co nas zaskoczyło

Nietrafione jądro AWQ w vLLM. Benchmark wykonano z jądrem awq zamiast awq_marlin. Zestaw testów odbiorczych wybrał je automatycznie na podstawie ówczesnej konfiguracji modelu. Z awq_marlin przepustowość pojedynczego zapytania powinna wzrosnąć z 8 tok/s do 16–24 tok/s. To kwestia konfiguracji oprogramowania, a nie ograniczenie sprzętowe — przy uruchamianiu serwowania produkcyjnego należy zweryfikować ciąg określający metodę kwantyzacji w vLLM.

Przepustowość D2H. Wynik 1.4 GB/s w kierunku urządzenie → host zaskoczył nas przy wstępnej analizie. To zachowanie CUDA przy pamięci niezablokowanej, a nie usterka PCIe. Dla standardowych stosów serwujących (vLLM, llama.cpp) nie ma to znaczenia. We własnym kodzie inferencyjnym, który przenosi tensory na CPU do dalszego przetwarzania, należy korzystać z alokacji pamięci pinned.

Skorygowane błędy PCIe AER na GPU 3. W trakcie benchmarku vLLM karta GPU 3 (magistrala c1:00.0) zarejestrowała skorygowane błędy PCIe (RxErr + BadTLP). Zostały one automatycznie poprawione przez sprzęt i nie wpłynęły na obliczenia. Prawdopodobna przyczyna: osadzenie risera PCIe lub renegocjacja łącza przy prędkości Gen4. Zalecamy monitorowanie przy ciągłym obciążeniu produkcyjnym; jeśli liczba błędów rośnie, należy ponownie osadzić kabel risera GPU 3. W samych testach obciążeniowych — zero błędów.

Krótkie zerwanie łącza karty sieciowej. Interfejs sieciowy na moment stracił łączność i wrócił podczas obciążenia w benchmarku GPU (13:38 UTC). Prawdopodobnie efekt stanu przejściowego zasilania przy jednoczesnym starcie kart GPU. W środowisku produkcyjnym z działającym nvidia-persistenced (który utrzymuje zainicjowane konteksty GPU) stany przejściowe przy starcie obciążenia są mniejsze. Przed wdrożeniem produkcyjnym należy włączyć nvidia-persistenced jako usługę systemd.

Co zrobilibyśmy inaczej w wersji v2

Włączyć awq_marlin od początku. Ścieżkę jądra kwantyzacji w vLLM należy weryfikować podczas testów odbiorczych, a nie po nich. Do skryptu odbiorczego warto dodać kontrolę tożsamości jądra.

Ujednolicić limity mocy GPU przed benchmarkami. Cztery karty dostarczono ze skonfigurowanymi różnymi limitami (480 W, 450 W, 500 W, 480 W). Ustawienie spójnego limitu (nvidia-smi -pl) przed pierwszym uruchomieniem benchmarku daje czystsze i lepiej porównywalne wyniki oraz eliminuje niespójny pobór mocy przy łącznym wygrzewaniu.

Dodać stos monitoringu już przy dostawie. Prometheus z eksporterem DCGM oraz Grafana wymagają kilku godzin konfiguracji i pozwalają na bieżąco obserwować temperatury GPU, wykorzystanie VRAM i częstość błędów PCIe. Warto dostarczać to w ramach standardowych testów odbiorczych, zamiast zostawiać jako zadanie po dostawie. Zob. L05 — przewodnik konfiguracji tego stosu.

Wpisać nvidia-persistenced do pliku jednostki systemd już przy konfiguracji systemu. To jedna linijka, a mimo to regularnie się o niej zapomina. Bez niej pierwsze obciążenie GPU po okresie bezczynności trwa kilka sekund dłużej i wywołuje stan przejściowy zasilania, który spowodował zerwanie łącza karty sieciowej.

Rozszerzenie LVM. Na dysku systemowym (512 GB SATA) partycji LVM przydzielono tylko 100 GB. Pozostałe 374 GB jest nieprzydzielone. Nie ma powodu, by to zostawiać: lvextend oraz resize2fs zajmują 30 sekund i odzyskują tę przestrzeń na narzut systemu, logi i warstwy Dockera.

Rozważyć drugi dysk NVMe na modele. Pojedynczy dysk NVMe 2 TB mieści obecnie wszystkie modele i będzie się zapełniał wraz z rozrostem biblioteki modeli. Drugi dysk NVMe 4 TB w RAID 0 lub po prostu jako osobny /mnt/nvme2 punkt montowania zwiększyłby elastyczność i utrzymał wysoką wydajność odczytu sekwencyjnego przy większej bibliotece.

Porównanie: alternatywy dla tej konfiguracji

Obciążenie klienta można było obsłużyć innym sprzętem. Oto uczciwe porównanie:

Konfiguracja 4× RTX 4090 z 96 GB to minimum pozwalające uruchomić Llama 3.3 70B AWQ INT4 pod vLLM z sensowną przepustowością wsadową. Nie jest to pułap; wariant z 8 kartami GPU zwiększa wydajność proporcjonalnie. Dla klienta badawczego, który potrzebuje jednej dedykowanej stacji roboczej, a nie klastra serwującego, konfiguracja 4× jest często właściwym punktem wyjścia.

Ani wariant 4×, ani 8× nie ma NVLink między kartami GPU, co oznacza, że inferencja tensor-parallel odbywa się przez PCIe. Praktyczną konsekwencją jest opóźnienie TTFT przy pojedynczych zapytaniach, a nie łączna przepustowość wsadowa. Przy obciążeniu typowym dla zespołu (dziesiątki zapytań na godzinę, nie tysiące) nie jest to czynnik ograniczający. Przy wymaganiu TTFT poniżej 100 ms warto sięgnąć do N03 oraz do uzasadnienia, dlaczego oferta celuje w systemy wielokartowe łączone przez PCIe, a nie w rozwiązania oparte na NVSwitch.

Łączny pobór mocy i planowanie instalacji elektrycznej

Przy ciągłym obciążeniu GPU łączny pobór mocy systemu wynosił około 1,900–2,200 W, mierzony na szynach zasilania kart GPU (1,914 W przy wygrzewaniu samego GPU; ~2,100 W szacunkowo łącznie z CPU, dyskami i płytą). Należy uwzględnić straty sprawności zasilaczy (przyjmując 90%) i zaplanować obwód co najmniej 16 A/230 V, przy czym preferowany jest 20 A dla zapasu.

Układ z dwoma zasilaczami rozkłada to na dwa gniazda. Oba gniazda muszą znajdować się na obwodach zdolnych niezależnie udźwignąć obciążenie: jeśli zasilacz A obsługuje dwie karty GPU po 500 W oraz 200 W płyty i procesora, na jego obwodzie przypada 1,200 W. Dobór należy wykonać odpowiednio.

Budżet chłodzenia pomieszczenia: ten system należy traktować jako 2.5 kW w pracy ciągłej (ostrożnie, z uwzględnieniem strat sprawności i zapasu). W serwerowni lub szafie rack z wieloma systemami wartość łączna rośnie bardzo szybko.

Zob. P01 — zasilanie jednofazowe a trójfazowe, oraz P04 — dobór zabezpieczeń nadprądowych.

Przedział cenowy

Konfiguracja o tej specyfikacji — platforma EPYC 7542, 512 GB RAM ECC, 4× RTX 4090, 2 TB NVMe, obudowa rack z dwoma zasilaczami — mieści się przy obecnych cenach komponentów w przedziale €18,000–€24,000 bez VAT, w zależności od wyboru obudowy, momentu zakupu pamięci i dostępności kart GPU. Czas realizacji wynosi 10–28 dni w zależności od dostępności komponentów i jest potwierdzany przy zamówieniu.

Przedział ten nie obejmuje instalacji, listwy PDU do racka, sieci (przełącznik 10 GbE, okablowanie) ani licencji na oprogramowanie. System jest dostarczany z preinstalowanym Ubuntu 24.04 LTS i skonfigurowanym środowiskiem venv Pythona; wagi modeli zapewnia klient.

Do czego ta konfiguracja się nadaje

• Inferencja LLM w badaniach i małych zespołach. Uruchamianie modelu 70B dla zespołu 5–15 użytkowników. Łączne 179 tok/s pod vLLM komfortowo obsługuje równoległe sesje.
• Ocena i iteracja modeli. Szybkie wczytywanie z NVMe oznacza błyskawiczne przełączanie między kandydującymi modelami. Budżet linii PCIe platformy EPYC sprawia, że wszystkie cztery karty GPU zawsze pracują z pełną przepustowością.
• Wdrożenia z wymogiem suwerenności danych. Cała inferencja odbywa się lokalnie. Żaden token nie opuszcza budynku. To główny pozaekonomiczny powód, by w kontekstach badawczych pracować lokalnie.
• Punkt wejścia w klasę 70B przy ograniczonym budżecie. RTX 4090 to konsumencka karta GPU o największej dostępnej ilości VRAM. Przy 24 GB na kartę i czterech kartach łączne 96 GB pozwala sięgnąć po klasę 70B bez przechodzenia na ceny kart profesjonalnych.

Do czego ta konfiguracja się nie nadaje

• TTFT poniżej 100 ms przy pojedynczym zapytaniu. Topologia tensor-parallel oparta na PCIe P2P wyznacza dolną granicę TTFT dla dużych modeli. Jeżeli potrzebne są niskie opóźnienia interaktywne przy modelach 70B+, ta architektura jest złym wyborem. Potrzebne są karty GPU połączone przez NVLink, co oznacza zupełnie inną klasę sprzętu (zob. N03).
• Równoczesne uruchamianie wielu dużych modeli. Przy łącznych 96 GB VRAM i gpu_memory_utilization=0.80 dostępne jest mniej więcej 77 GB. Drugi model 70B INT4 już się nie zmieści. Jeżeli konieczne jest hostowanie dwóch modeli jednocześnie, potrzebna jest platforma z większą ilością VRAM na kartę lub z większą liczbą kart GPU.
• Serwowanie produkcyjne na dużą skalę. Przy setkach równoległych użytkowników lub dostępności objętej SLA ta architektura (brak dodatkowych kart sieciowych w obudowie na 4 GPU, pojedynczy węzeł, karty konsumenckie bez ECC) nie jest właściwą podstawą. Jest nią 8-kartowy serwer Kentino AI z L40 lub RTX Pro 6000 Blackwell, właściwym monitoringiem i dwiema kartami sieciowymi.
• Trenowanie dużych modeli. Przy łącznych 96 GB VRAM można dostrajać modele 70B (LoRA, QLoRA), ale nie da się trenować wszystkich ich parametrów. Przy trenowaniu budżet VRAM jest bardziej ograniczający niż przy inferencji. Jeżeli trenowanie wchodzi w zakres planowanego obciążenia, należy to uwzględnić.

---

To część Kentino Wiki, seria C (studia przypadków). Dane z pomiarów konfiguracji: 2026-04-10. Artykuł opublikowano 2026-05-15. Zapraszamy do przesyłania sprostowań i dodatkowych pomiarów na adres info@kentino.com.