Konfiguracja referencyjna: laboratorium robotyki i AI w jednym racku

Wcześniejsze artykuły opisują architekturę, stos oprogramowania, budżet mocy i projekt sieci. Ten dokłada do tego cennik i listę komponentów — opartą na sprzęcie, który Kentino realnie dostarczyło i przetestowało, a nie na teoretycznym BOM-ie zestawionym z materiałów marketingowych.

Celem wdrożenia jest laboratorium badawcze lub integracyjne obsługujące od jednego do czterech robotów wraz z inferencją on-premise i zapleczem do trenowania modeli. Skala średnia: ani hobbystyczny komputer, który ledwo udźwignie model 7B, ani klaster hiperskalowy wymagający własnego zespołu technicznego. Poważne środowisko robocze, które zespół dwóch do sześciu osób jest w stanie uruchomić, utrzymywać i rozwijać bez dedykowanego DevOps.

Artykuł obejmuje dwa poziomy tego samego wzorca architektonicznego. Poziom deweloperski z 4 GPU (development tier) to miejsce, od którego zaczyna większość laboratoriów. Poziom produkcyjny z 8 GPU (production tier) to miejsce, w którym lądują po pierwszym realnym obciążeniu. Dobór sprzętu jest inny; architektura pozostaje identyczna.

Co pokazują dane z floty

Kentino wdrożyło flotę jednolicie skonfigurowanych węzłów obliczeniowych z 4 GPU. Każda jednostka ma tę samą specyfikację: AMD EPYC 7542 (32 rdzenie / 64 wątki, 2.9 GHz boost), 512 GB DDR4 ECC LRDIMM 2666 MT/s na ośmiu modułach DIMM, cztery karty RTX 4090 (po 24 GB VRAM, łącznie 96 GB), dysk roboczy NVMe 2 TB oraz SSD SATA 512 GB na system operacyjny. Płyta główna to ASRockRack ROMED8-2T/BCM. Ubuntu 24.04 LTS, jądro 6.8.0-generic, sterownik NVIDIA 590.48.01, CUDA 13.1/13.2.

Wszystkie dziesięć węzłów osiąga identyczne wyniki testów. To nie przypadek — to właśnie sens budowy referencyjnej. Kiedy każda jednostka wychodzi w tej samej konfiguracji, benchmark staje się specyfikacją, a nie szczęśliwym pomiarem.

Wydajność obliczeniowa GPU

Mnożenie macierzy FP16 na rdzeniach tensorowych wszystkich czterech kart (obciążenie 8192 × 8192):

GPU 1 osiąga około 6% mniej niż GPU 0, 2 i 3 — mieści się to w normalnym rozrzucie loterii krzemowej dla kart konsumenckich. Wszystkie cztery przeszły 60-sekundowy test GPU-burn oraz łączny test GPU+CPU bez jednego błędu obliczeniowego. Zapas termiczny jest komfortowy: próg throttlingu dla RTX 4090 wynosi 83 °C, a najgorętsza karta we flocie osiągnęła maksymalnie 73 °C przy jednoczesnym obciążeniu GPU i CPU. Na żadnym węźle nie zaobserwowano throttlingu.

Uwaga praktyczna dotycząca limitów mocy: flota dostarczana jest z nieco różnymi limitami na kartę (450 W, 480 W, 500 W w zależności od slotu). Przy ciągłej pracy produkcyjnej ujednolicenie wszystkich czterech do 450 W wygładza sumaryczny pobór i zmniejsza nierównowagę zasilaczy. Strata w TFLOPS przy 450 W względem 500 W jest mniejsza niż 2% — asymetryczne obciążenie szyn nie jest tego warte.

Inferencja vLLM — Llama 3.3 70B AWQ

Testowane na vLLM 0.19.0, tensor_parallel_size=4, gpu_memory_utilization=0.80, max_model_len=2048:

Jedno istotne zastrzeżenie: w teście użyto jądra kwantyzacji awq, a nie awq_marlin. Ścieżka awq_marlin na architekturze Ada Lovelace (RTX 4090) jest 2–3× szybsza pod względem opóźnienia pojedynczego zapytania. We wdrożeniach produkcyjnych należy stosować awq_marlin lub ścieżkę FP8 w vLLM 0.20+, która dodatkowo zmniejsza różnicę. Przy awq_marlin powyższy wynik dla pojedynczego zapytania rośnie z ~8 tok/s do około 16–20 tok/s na tych kartach — bliżej tego, co użytkownicy obserwują w praktyce. Zysk w łącznej przepustowości wsadowej jest proporcjonalnie mniejszy, ponieważ przy wysokiej współbieżności wąskim gardłem staje się przepustowość pamięci, a nie moc obliczeniowa.

Powyższe liczby dotyczą Llama 3.3 70B w INT4 (AWQ). Model 7B lub 8B w Q4 działa na tym samym sprzęcie 4–6× szybciej w przeliczeniu na token; model 13B mniej więcej 2.5× szybciej. To wynik dla 70B jest właściwym ograniczeniem przy doborze konfiguracji dla modeli VLM i dużych modeli planowania w zastosowaniach robotycznych.

llama.cpp — jeden użytkownik, bez współbieżności

Testowane na llama-cpp-python 0.3.20 (CUDA/cuBLAS), Llama 3.3 70B Instruct Q4_K_M GGUF, wszystkie cztery GPU:

llama.cpp ładuje się szybciej (10.8 s wobec 95 s dla vLLM) i osiąga na tych kartach wyższą prędkość dekodowania dla jednego użytkownika, bo nie ponosi narzutu harmonogramu ciągłego batchowania. Kosztem jest zerowa współbieżność — jeden użytkownik naraz. Właściwa interpretacja tych liczb: llama.cpp na węźle z 4 GPU daje programiście responsywny model 70B do pracy interaktywnej; vLLM jest właściwym wyborem w momencie, gdy klientów jest więcej niż jeden.

Zob. I02, gdzie znajduje się pełna macierz decyzyjna dla stosu serwującego. W skrócie: zacząć od vLLM w Dockerze, używać kwantyzacji awq_marlin, a na llama.cpp przechodzić wyłącznie w przypadku jednostanowiskowych maszyn deweloperskich lub wdrożeń na Jetsonie.

Przepustowość pamięci GPU

Przepustowość device-to-device (w obrębie karty) jest stabilna na poziomie 920.2–920.6 GB/s na wszystkich czterech kartach — rozrzut poniżej 0.04%, co potwierdza, że GDDR6X nie jest tu zmienną. Przepustowość PCIe Host→Device wynosi 26.2–26.3 GB/s, co potwierdza pełne wynegocjowanie Gen4 x16 pod obciążeniem (stan łącza w spoczynku pokazuje Gen1 z powodu oszczędzania energii ASPM — to normalne, nie usterka). Transfery peer-to-peer między GPU po PCIe (bez NVLink) osiągają 19–22 GB/s, co jest oczekiwanym pułapem dla komunikacji peer-to-peer przez wspólny root complex PCIe bez NVLink (zob. N03).

Pamięć masowa NVMe

Przepustowość sekwencyjna jest bliska pułapowi Gen4 x4. Losowe IOPS przy głębokości kolejki 32 wysycają się dobrze: 568 tys. IOPS odczytu to znacznie więcej, niż wymaga ładowanie wag LLM czy wzorce dostępu do zbiorów danych w skali pojedynczego węzła. Ładowanie modelu z NVMe do VRAM trwa 10–30 sekund w zależności od jego rozmiaru; ten dysk nie jest wąskim gardłem.

Budowa referencyjna

BOM — poziom deweloperski z 4 GPU

Poziom deweloperski to właściwy punkt wyjścia dla laboratorium obsługującego jednego lub dwa roboty, jeden lub dwa aktywne modele oraz okazjonalne dostrajanie LoRA.

Poziom deweloperski: węzeł obliczeniowy z 4 GPU + zarządzalny przełącznik ToR + AP 6 GHz + UPS online 5 kVA.

BOM — poziom produkcyjny z 8 GPU

Poziom produkcyjny podwaja liczbę GPU. Wzorzec architektoniczny jest ten sam; CPU, RAM i obudowa skalują się odpowiednio, aby obsłużyć osiem slotów PCIe o pełnej przepustowości. Platforma AMD EPYC Genoa lub Turin zapewnia budżet linii PCIe dla 8 slotów x16 bez kompromisu w postaci bifurkacji (zob. W02).

Uwaga: dodatkowa karta sieciowa 25 GbE wchodzi w grę wyłącznie w obudowach 8-GPU. W obudowie 4-GPU nie ma miejsca na kolejną kartę sieciową — porty 10 GbE na płycie ROMED8-2T/BCM są praktycznym limitem na poziomie 4 GPU (zob. N01 oraz zasady opisane na stronie produktu).

Pamięć masowa poza węzłem obliczeniowym

Na poziomie deweloperskim NAS na cztery dyski z 4 dyskami HDD po 16 TB daje 48 TB użytecznych w RAID-5 — to wystarcza na rok danych epizodycznych dla laboratorium z dwoma robotami. Należy podłączyć go przez 10 GbE do przełącznika ToR i nie umieszczać na tym samym interfejsie, co ruch robotów.

Zasilanie i chłodzenie szafy rack

Na podstawie I04:

Dane z testów obciążeniowych floty potwierdzają, że węzeł z 4 GPU pobiera ~1,914 W przy pełnym obciążeniu GPU, gdy wszystkie cztery karty osiągają swoje limity mocy. Po doliczeniu CPU (~120 W w trybie ciągłym), NVMe i wentylatorów węzeł ląduje na poziomie około 2.1–2.2 kW w pracy ciągłej.

Instalacja elektryczna dla poziomu deweloperskiego: zasilanie trójfazowe 400 V 16 A to minimum; trójfazowe 32 A daje zapas na rozbudowę. Przewody zasilaczy na dwóch odrębnych fazach. Zob. I04 oraz P02, gdzie opisano schemat okablowania. Dla poziomu produkcyjnego (10 kW na pełną szafę) potrzebne jest zasilanie trójfazowe 400 V 32 A oraz co najmniej 15 kW mocy chłodniczej.

Dobór UPS: dobiera się go wyłącznie pod serwer, nie pod roboty. Dla poziomu deweloperskiego UPS online 5 kVA z podwójną konwersją to rozsądne minimum. Dla poziomu produkcyjnego — 10 kVA. Zawsze należy wybierać topologię online z podwójną konwersją. Zob. P05.

Stos oprogramowania na bare metal

Stos oprogramowania: przypięte Ubuntu + sterownik NVIDIA → container toolkit → vLLM + llama.cpp + nginx + monitoring.

Przypięcie sterownika nie podlega dyskusji. Flota pracuje na sterowniku 590.48.01; apt-mark hold nvidia-driver-590 to pierwsza czynność po instalacji systemu na bare metal. Nienadzorowane apt-get upgrade, które pobiera nowszy sterownik, zepsuło produkcyjną inferencję dokładnie tyle razy, ile można się spodziewać. Zob. L01, gdzie opisano pełną procedurę.

Monitoring nie jest opcjonalny. Dane z floty pokazują, że GPU 3 w jednym z węzłów miało podczas testów korygowalne błędy PCIe AER (RxErr + BadTLP) — naprawione sprzętowo, ale widoczne w licznikach DCGM. Bez monitoringu objawia się to tygodnie później jako „sporadyczne dziwne błędy inferencji”. Należy wdrożyć DCGM i ustawić alert na korygowalne błędy ECC powyżej przyjętego poziomu bazowego. Zob. L05, gdzie opisano stos Prometheus + Grafana.

Warianty doboru konfiguracji

Poziom deweloperski 4 GPU — co faktycznie uruchomi

Łącznie 96 GB VRAM (4× 24 GB) przy TP=4:

Model VLM 72B nie mieści się komfortowo na 4× 24 GB w INT4 — rachunek jest bliski granicy, ale okna kontekstu powyżej 4K przeważają szalę. Należy albo użyć wariantu VLM 32B, albo przejść na poziom 8 GPU lub węzeł z 4 kartami RTX Pro 6000 Blackwell (po 96 GB VRAM) dla klasy 72B. Zob. W07, gdzie omówiono zależność VRAM a klasa modelu.

Poziom deweloperski obsłuży: jeden model inferencyjny 70B serwujący 1–3 równoległych klientów robotycznych, jeden VLM (klasa 32B) do zapytań wizualnych oraz okazjonalne dostrajanie LoRA na mniejszym modelu bazowym. To pokrywa 80% zastosowań laboratoriów robotycznych w 2026 roku.

Poziom produkcyjny 8 GPU — dodatkowy zapas

Łącznie 192 GB VRAM (8× 24 GB):

Poziom 8 GPU otwiera także drogę do jednoczesnego serwowania wielu modeli: LLM 70B na czterech kartach i VLM 32B na pozostałych czterech, obsługujące w tym samym czasie mieszaną flotę robotów o różnych wymaganiach — z jednej maszyny. Na poziomie 4 GPU wymaga to podmiany modelu z przestojem 30–120 s przy każdej zmianie.

Uwaga na temat TP=8 dla modelu 70B: TP=8 po PCIe peer-to-peer (bez NVLink) skaluje się gorzej niż TP=4 × PP=2 przy współbieżności powyżej 8, ponieważ koszt komunikacji all-reduce rośnie wraz ze stopniem równoległości tensorowej. Dane z benchmarku pokazują przepustowość PCIe między GPU na poziomie 19–22 GB/s — to wystarcza dla TP=4, ale all-reduce przy TP=8 i dużych batchach wysyca te łącza. Zalecana konfiguracja dla modelu 70B na 8 kartach 4090 to TP=4 × PP=2, jak pokazano w I02.

Układ szafy rack

Węzeł obliczeniowy zawsze znajduje się poniżej przełącznika i UPS — przepływ front-tył wymaga, aby zimne powietrze wchodziło od frontu szafy (zimna strefa lub nawiew klimatyzacji), przechodziło przez serwer i wychodziło do gorącej strefy z tyłu. Zob. W05 oraz I04, gdzie opisano zasady przepływu powietrza.

Host pomostowy to maszyna 1U lub w małej obudowie z wyprowadzonym wyjściem graficznym, używana do pierwszego uruchomienia, instalacji sterowników i obsługi serwisowej, gdy serwer główny jest nieosiągalny przez sieć. Nie potrzebuje GPU. Używana stacja robocza lub niewielki serwer 1U z 16 GB RAM i dyskiem SSD Gen3 w zupełności wystarczy.

Czym ta konfiguracja nie jest

To nie jest desktopowy serwer GPU w obudowie rack. Otwarta konstrukcja typu desktop tower — karty GPU na riserach, bez obudowy, wentylatory skierowane w sufit — nie jest tym, co tu opisano. Składy desktopowe sprawdzają się w pracy deweloperskiej; nie są przewidziane do ciągłej pracy 24/7 i nie zapewniają ukierunkowanego przepływu front-tył, który utrzymuje stabilną temperaturę pracy GPU przez tygodnie.

To nie jest klaster NVLink. RTX 4090 (klasa konsumencka / stacji roboczej) nie ma NVLink. Transfery między GPU odbywają się po PCIe z prędkością 19–22 GB/s, a nie 900 GB/s. Dla serwowania inferencji przy TP=4 to wystarcza, a przy trenowaniu z TP=8 stanowi realne ograniczenie. Jeśli obciążeniem jest intensywne trenowanie rozproszone modelu 70B lub większego, RTX Pro 6000 Blackwell (z obsługą NVLink w wersji wielokartowej) albo platforma z NVSwitch zmienia ten rachunek — ale zmienia też cenę. Zob. N03.

To nie są redundantne zasilacze. Konfiguracja z dwoma zasilaczami to rozdzielone zasilanie: zasilacz A zasila GPU 0 i 1 (oraz płytę główną), zasilacz B zasila GPU 2 i 3. Awaria zasilacza A oznacza utratę dwóch GPU i płyty głównej. Nic nie przełącza się automatycznie. To uczciwa konfiguracja dwuzasilaczowa — równoważy obciążenie szyn i zmniejsza ryzyko pojedynczego punktu awarii względem jednego dużego zasilacza, ale nie jest redundancją N+1. Zob. W04.

To nie jest alternatywa dla chmury we wszystkich zastosowaniach. Jeśli głównym obciążeniem laboratorium jest jedno wywołanie modelu dziesięć razy dziennie, rachunek TCO nie uzasadnia wdrożenia on-premise. Ta konfiguracja zwraca się wobec wydatków na API w chmurze wtedy, gdy prowadzi się ciągłą inferencję dla wielu klientów, regularnie dostraja modele lub działa pod rygorem wymogów dotyczących miejsca przechowywania danych. Zob. T02, gdzie znajduje się szczegółowy rachunek.

Dlaczego akurat takie wybory

AMD EPYC 7542 jako procesor hosta. 32-rdzeniowy EPYC udostępnia 128 linii PCIe 4.0 z samego procesora, co wystarcza na 4 karty GPU w trybie x16 bez bifurkacji, a do tego na kartę sieciową, pamięć masową i przełącznik PCIe pod rozbudowę. EPYC nie bez powodu jest standardową platformą dla wielokartowych serwerów AI w tej skali: Intel Xeon przy tej samej liczbie rdzeni oferuje mniej linii PCIe, co przy konfiguracjach z 4 i więcej GPU wymusza kompromisy z bifurkacją. Zob. W02, gdzie rozpisano arytmetykę linii PCIe.

512 GB pamięci systemowej. Flota dostarczana jest z 512 GB (8× 64 GB), co przekracza nominalną specyfikację 256 GB. Jest to celowe: ładowanie dużych modeli przy starcie kontenera, wstępne pobieranie zbiorów danych do trenowania oraz systemowa pamięć podręczna stron zużywają RAM, którego VRAM nie zastąpi. W vLLM z włączoną przestrzenią wymiany dla KV-cache pamięć systemowa jest bezpośrednio wykorzystywana jako nadmiarowa — 4 GB przestrzeni wymiany na GPU wymaga 16 GB zapasu pamięci systemowej. 512 GB zapewnia ten zapas, a przy tym miejsce dla Isaac Sim, które podczas trenowania polityk potrafi utrzymywać 10–30 GB stanu symulacji w pamięci systemowej.

Dysk roboczy NVMe 2 TB. Benchmark pokazuje 4,589 MB/s odczytu sekwencyjnego — dość, by załadować model 70B w FP8 (~75 GB) w czasie poniżej 20 sekund. W laboratorium, które często podmienia modele (praca deweloperska, testy A/B stosów inferencyjnych), czas ładowania ma znaczenie. Wolniejszy dysk SSD SATA wydłuża go dwu- lub trzykrotnie przy każdej zmianie.

Przepływ powietrza front-tył w szafie rack. Najczęstszy błąd przy pierwszych instalacjach: orientacja desktopowa (wlot z boku, wylot górą i tyłem) nie sprawdza się w zamkniętej szafie. Węzeł obliczeniowy musi mieć ukierunkowany przepływ powietrza zgodny z konwencją zimnej i gorącej strefy w szafie. Zob. I01 oraz W05.

Uczciwe spojrzenie na sprzęt roku 2026

To budowa referencyjna na maj 2026. RTX 4090 nie jest najnowszą opcją GPU w ofercie Kentino — dostępne są RTX 5090 (32 GB VRAM, architektura Blackwell, sm_120) oraz RTX Pro 6000 Blackwell (96 GB VRAM), które istotnie zmieniają rachunek VRAM na kartę. Węzeł z czterema kartami RTX Pro 6000 Blackwell daje 384 GB VRAM — dość, by komfortowo utrzymać Qwen 2.5 VL 72B w FP8 na czterech kartach — przy proporcjonalnie wyższym koszcie jednostkowym.

Co nie zmienia się między generacjami: wzorzec architektoniczny. Host na AMD EPYC, wiele GPU po PCIe, obudowa z przepływem front-tył, dwa zasilacze, Ubuntu 24.04, vLLM w Dockerze, Prometheus + eksporter DCGM. Ten wzorzec pozostał spójny przez dwie generacje GPU i przetrwa następną. Lista komponentów tanieje i przyspiesza; wzorzec pozostaje.

---

To część Kentino Wiki — serii referencyjnej o obliczeniach AI, robotyce i systemach, które je łączą. Uwagi i sprostowania prosimy kierować na info@kentino.com.