Referenční sestava: robotická a AI laboratoř v jednom racku

Předchozí články popisují architekturu, softwarový stack, energetický rozpočet a návrh sítě. Tento článek k tomu všemu přidává cenovku a kusovník — vycházející ze skutečného hardwaru, který Kentino dodalo a proměřilo, nikoli z teoretického BOM poskládaného z marketingového letáku.

Cílem nasazení je výzkumná nebo integrační laboratoř, která provozuje jeden až čtyři roboty vedle on-prem inference a prostoru pro trénink. Střední měřítko: ne hobby sestava, která stěží utáhne 7B model, ani hyperscale cluster vyžadující vlastní facility tým. Seriózní pracovní prostředí, které tým dvou až šesti lidí dokáže postavit, provozovat a rozvíjet bez vyhrazeného DevOps.

Článek pokrývá dvě úrovně téhož architektonického vzoru. Vývojová úroveň se 4 GPU je místo, kde většina laboratoří začíná. Produkční úroveň s 8 GPU je to, kam se dostanou po prvním reálném workloadu. Volba hardwaru se liší; architektura je identická.

Co ukazují data z flotily

Kentino nasadilo flotilu jednotně konfigurovaných výpočetních uzlů se 4 GPU. Každá jednotka má stejnou specifikaci: AMD EPYC 7542 (32 jader / 64 vláken, boost 2.9 GHz), 512 GB DDR4 ECC LRDIMM na 2666 MT/s v osmi DIMM slotech, čtyři GPU RTX 4090 (24 GB VRAM každá, celkem 96 GB), 2TB NVMe scratch disk a 512GB SATA SSD pro operační systém. Základní deska je ASRockRack ROMED8-2T/BCM. Ubuntu 24.04 LTS, jádro 6.8.0-generic, ovladač NVIDIA 590.48.01, CUDA 13.1/13.2.

Všech deset uzlů dává v benchmarcích identická čísla. To není náhoda — je to smysl referenční sestavy. Když každá jednotka odchází se stejnou konfigurací, je benchmark specifikací, ne šťastným pokusem.

Výkon GPU

Maticové násobení FP16 na tensor core napříč čtyřmi kartami (workload 8192 × 8192):

GPU 1 běží zhruba o 6 % níže než GPU 0, 2 a 3 — v rámci běžného rozptylu křemíkové loterie u spotřebitelských karet. Všechny čtyři prošly 60sekundovým GPU-burn testem i kombinovaným GPU+CPU burn testem bez jediné výpočetní chyby. Teplotní rezerva je pohodlná: práh tepelného throttlingu u RTX 4090 je 83 °C a nejteplejší karta ve flotile dosáhla při současné zátěži GPU a CPU 73 °C. Na žádném uzlu nebyl throttling pozorován.

Praktická poznámka k limitům příkonu: flotila je dodávána s mírně odlišnými limity na kartu (450 W, 480 W, 500 W podle slotu). Pro trvalý produkční provoz vyrovná nastavení všech čtyř na 450 W souhrnný odběr a sníží nevyváženost zdrojů. Ztráta TFLOPS při 450 W oproti 500 W je pod 2 % — nestojí za asymetrické zatížení větví.

Inference ve vLLM — Llama 3.3 70B AWQ

Měřeno s vLLM 0.19.0, tensor_parallel_size=4, gpu_memory_utilization=0.80, max_model_len=2048:

Jedna důležitá výhrada: benchmark použil kvantizační kernel awq, nikoli awq_marlin. Cesta awq_marlin na architektuře Ada Lovelace (RTX 4090) je 2–3× rychlejší pro latenci jednoho požadavku. Produkční nasazení by mělo používat awq_marlin nebo cestu FP8 pod vLLM 0.20+, která rozdíl dále smazává. S awq_marlin se výše uvedené číslo pro jeden požadavek posouvá z ~8 tok/s na přibližně 16–20 tok/s na těchto kartách — což lépe odpovídá tomu, co uživatelé zažívají v praxi. Přínos pro souhrnnou propustnost dávky je poměrově menší, protože při vysoké souběžnosti se úzké hrdlo přesouvá z výpočtu na propustnost paměti.

Tato čísla platí pro Llama 3.3 70B v INT4 (AWQ). Model 7B nebo 8B v Q4 běží na stejném hardwaru 4–6× rychleji na token; model 13B zhruba 2.5× rychleji. Číslo pro 70B je relevantní dimenzační limit pro VLM a velké plánovací modely v robotickém kontextu.

llama.cpp — jeden uživatel, bez souběžnosti

Měřeno s llama-cpp-python 0.3.20 (CUDA/cuBLAS), Llama 3.3 70B Instruct Q4_K_M GGUF, všechny čtyři GPU:

llama.cpp se načítá rychleji (10.8 s oproti 95 s u vLLM) a na těchto kartách dodává vyšší rychlost dekódování pro jednoho uživatele, protože neplatí režii plánovače průběžného dávkování. Daní je nulová souběžnost — jeden uživatel v jednu chvíli. Správné čtení těchto čísel: llama.cpp na uzlu se 4 GPU dá vývojáři responzivní 70B model pro interaktivní práci; vLLM je správná volba ve chvíli, kdy máte více než jednoho klienta.

Viz I02 pro úplnou rozhodovací matici serving stacku. Stručně: začněte s vLLM v Dockeru, použijte kvantizaci awq_marlin a na llama.cpp přejděte jen u vývojových strojů pro jednoho uživatele nebo u nasazení na Jetsonu.

Propustnost paměti GPU

Propustnost device-to-device (na kartě) je konzistentních 920.2–920.6 GB/s u všech čtyř karet — vzájemně do 0.04 %, což potvrzuje, že GDDR6X zde není proměnnou. Propustnost PCIe Host→Device se pohybuje na 26.2–26.3 GB/s, což potvrzuje, že Gen4 x16 je pod zátěží plně vyjednáno (stav linky v klidu ukazuje Gen1 kvůli úspoře energie ASPM — normální, nikoli závada). Peer přenosy mezi GPU přes PCIe (bez NVLink) měří 19–22 GB/s, což je očekávaný strop pro peer-to-peer přes sdílený PCIe root complex bez NVLink (kontext viz N03).

Úložiště NVMe

Sekvenční propustnost je blízko stropu Gen4 x4. Náhodné IOPS při hloubce fronty 32 saturují dobře: 568K IOPS při čtení je výrazně nad tím, co načítání vah LLM nebo přístupové vzory k datasetům vyžadují v měřítku jednoho uzlu. Načtení modelu z NVMe do VRAM trvá 10–30 sekund podle velikosti modelu; tento disk není úzkým hrdlem.

Referenční sestava

Kusovník — vývojová úroveň se 4 GPU

Vývojová úroveň je správným výchozím bodem pro laboratoř s jedním nebo dvěma roboty, jedním nebo dvěma aktivními modely a občasným doladěním pomocí LoRA.

Vývojová úroveň: výpočetní uzel se 4 GPU + řízený ToR switch + AP na 6 GHz + online UPS 5 kVA.

Kusovník — produkční úroveň s 8 GPU

Produkční úroveň zdvojnásobuje počet GPU. Architektonický vzor je stejný; CPU, RAM a šasi škálují odpovídajícím způsobem, aby obsloužily osm PCIe slotů s plnou propustností. Platforma AMD EPYC Genoa nebo Turin poskytuje rozpočet PCIe linek pro 8× x16 slotů bez kompromisu v bifurkaci (viz W02).

Pozn.: doplněk 25 GbE NIC je proveditelný jen na šasi s 8 GPU. Šasi se 4 GPU nemá volný prostor pro další síťovou kartu — porty 10 GbE na desce ROMED8-2T/BCM jsou praktickým limitem úrovně se 4 GPU (viz N01 a pravidla produktové stránky).

Úložiště mimo výpočetní uzel

Pro vývojovou úroveň dá čtyřpozicový NAS se 4× 16TB HDD 48 TB využitelných v RAID-5 — dost na rok dat z epizod pro laboratoř se dvěma roboty. Připojte jej na 10 GbE do ToR switche; nedávejte jej na stejné rozhraní jako provoz robotů.

Napájení a chlazení racku

Z I04:

Data ze zátěžového testu flotily potvrzují, že uzel se 4 GPU odebírá při plné zátěži GPU ~1,914 W, kdy všechny čtyři karty dosahují svých limitů příkonu. Připočtěte CPU (~120 W trvale), NVMe a režii ventilátorů a uzel se dostane přibližně na 2.1–2.2 kW trvale.

Elektroinstalace pro vývojovou úroveň: minimem je třífázový přívod 400 V 16 A; 32 A třífázově dává prostor k růstu. Napájecí kabely zdrojů na dvě oddělené fáze. Zapojení viz I04 a P02. Pro produkční úroveň (10 kW celý rack) potřebujete třífázový přívod 400 V 32 A a nejméně 15 kW chladicího výkonu.

Dimenzování UPS: dimenzujte na server, ne na roboty. Pro vývojovou úroveň je rozumným minimem online UPS 5 kVA s dvojitou konverzí. Pro produkční úroveň 10 kVA. Vždy specifikujte online dvojitou konverzi. Viz P05.

Softwarový stack na bare metal

Softwarový stack: zamčené Ubuntu + ovladač NVIDIA → container toolkit → vLLM + llama.cpp + nginx + monitoring.

Zamčení ovladače je nediskutovatelné. Flotila běží na ovladači 590.48.01; apt-mark hold nvidia-driver-590 je první věc po instalaci OS na bare metal. Bezobslužný apt-get upgrade, který stáhne novější ovladač, rozbil produkční inferenci přesně tolikrát, kolikrát byste čekali. Viz L01 pro celý postup.

Monitoring není volitelný. Data z flotily ukazují, že GPU 3 na jednom uzlu mělo během benchmarkování opravitelné chyby PCIe AER (RxErr + BadTLP) — hardwarem automaticky opravené, ale viditelné v čítačích DCGM. Bez monitoringu se to o týdny později projeví jako „občasné podivné chyby inference“. Zapojte DCGM a nastavte alert na opravitelné ECC chyby nad základní úrovní. Viz L05 pro stack Prometheus + Grafana.

Varianty dimenzování

Vývojová úroveň se 4 GPU — co skutečně utáhne

Celkem 96 GB VRAM (4× 24 GB) při TP=4:

72B VLM se na 4× 24 GB v INT4 pohodlně nevejde — matematicky je to těsné, ale kontextová okna nad 4K jej přetlačí. Buď použijte variantu VLM 32B, nebo přejděte na úroveň s 8 GPU či na uzel se 4× RTX Pro 6000 Blackwell (96 GB VRAM na kartu) pro třídu 72B. Viz W07 k diskusi o VRAM versus třídě modelu.

Vývojová úroveň zvládne: jeden 70B inferenční model obsluhující 1–3 souběžné robotické klienty, jeden VLM (třída 32B) pro vizuální dotazy a občasné doladění LoRA na menším základním modelu. To pokrývá 80 % případů užití robotických laboratoří v roce 2026.

Produkční úroveň s 8 GPU — rezerva navíc

Celkem 192 GB VRAM (8× 24 GB):

Úroveň s 8 GPU navíc otevírá dveře souběžnému provozu více modelů: 70B LLM na 4 GPU a 32B VLM na zbývajících 4, obsluhující smíšenou flotilu robotů s různými požadavky na modely současně, z jedné skříně. Na úrovni se 4 GPU to vyžaduje výměnu modelu s 30–120 s výpadku na každou výměnu.

Poznámka k TP=8 pro 70B: TP=8 přes PCIe peer-to-peer (bez NVLink) škáluje při souběžnosti nad 8 hůř než TP=4 × PP=2, protože náklady na komunikaci all-reduce rostou se stupněm tensor parallelismu. Data z benchmarku ukazují propustnost mezi GPU přes PCIe 19–22 GB/s — dost pro TP=4, ale all-reduce při TP=8 a velkých dávkách tyto linky saturuje. Doporučená konfigurace pro 70B na 8× 4090 je TP=4 × PP=2, jak je uvedeno v I02.

Rozvržení racku

Výpočetní uzel sedí vždy pod switchem a UPS — proudění zepředu dozadu vyžaduje, aby studený vzduch vstupoval z přední strany racku (studená ulička nebo přívod klimatizace místnosti), prošel serverem a vystoupil vzadu do teplé uličky. Viz W05 a I04 k disciplíně proudění vzduchu.

Jump host je 1U nebo malý stroj s výstupem na displej, používaný pro prvotní rozběh, instalaci ovladačů a údržbu, když je hlavní server nedostupný po síti. GPU nepotřebuje. Postačí použitý workstation nebo malý 1U se 16 GB RAM a Gen3 SSD.

Co tato sestava není

Není to desktopový GPU server ve skříni do racku. Otevřená desktopová sestava typu tower — GPU na riser kartě, bez skříně, ventilátory mířící do stropu — není to, co je zde popsáno. Desktopové sestavy jsou v pořádku pro vývoj; nejsou dimenzovány na trvalý provoz 24/7 a neposkytují řízené proudění zepředu dozadu, které udržuje GPU na stabilní provozní teplotě po celé týdny.

Není to NVLink cluster. RTX 4090 (spotřebitelská / workstation třída) NVLink nemá. Přenosy mezi GPU jdou přes PCIe rychlostí 19–22 GB/s, ne 900 GB/s. To stačí pro inferenční serving s TP=4 a je to reálné omezení pro trénink s TP=8. Pokud je vaším workloadem náročný distribuovaný trénink modelu 70B+, RTX Pro 6000 Blackwell (s podporou NVLink ve své multi-GPU edici) nebo platforma s NVSwitch mění matematiku — ale i cenu. Viz N03.

Nejsou to redundantní zdroje. Konfigurace se dvěma zdroji je rozdělená distribuce napájení: zdroj A napájí GPU 0 a 1 (plus základní desku), zdroj B napájí GPU 2 a 3. Pokud selže zdroj A, přijdete o dvě GPU a základní desku. Nic se automaticky nepřepne. Je to poctivé dvojité napájení — vyrovnává zátěž větví a snižuje riziko jednoho bodu selhání oproti jednomu velkému zdroji, ale není to redundance N+1. Viz W04.

Není to náhrada cloudu pro všechno. Pokud je hlavním workloadem vaší laboratoře jedno volání modelu desetkrát denně, TCO on-prem neospravedlní. Tato sestava se vrátí oproti výdajům za cloudová API tehdy, když provozujete trvalou inferenci pro více klientů, pravidelně modely doladujete nebo fungujete pod omezeními na rezidenci dat. Viz T02 k podrobné matematice.

Proč právě tyto volby

AMD EPYC 7542 jako hostitelské CPU. 32jádrový EPYC poskytuje 128 PCIe 4.0 linek přímo z CPU, což stačí pro 4× GPU na x16 bez bifurkace, plus síťovou kartu, úložiště a PCIe switch pro rozšíření. EPYC je v tomto měřítku standardní platformou pro multi-GPU AI servery z dobrého důvodu: Intel Xeon se stejným počtem jader nabízí méně PCIe linek, což u konfigurací se 4+ GPU vynucuje kompromisy v bifurkaci. Viz W02 k aritmetice počtu linek.

512 GB systémové RAM. Flotila je dodávána s 512 GB (8× 64 GB), což překračuje nominální specifikaci 256 GB. Je to záměr: načítání velkých modelů při startu kontejneru, prefetch datasetů pro trénink i stránkovací cache operačního systému spotřebovávají RAM, kterou VRAM nenahradí. U vLLM se zapnutým swapem KV cache je systémová RAM přímo využitelná jako přetok — 4 GB swapu na GPU vyžaduje 16 GB rezervy systémové RAM. 512 GB tuto rezervu poskytuje a navíc zbývá na Isaac Sim, který může během tréninku politiky držet 10–30 GB stavu simulace v systémové RAM.

2 TB NVMe scratch. Benchmark ukazuje 4,589 MB/s sekvenčního čtení — dost rychle na načtení modelu 70B FP8 (~75 GB) do 20 sekund. Pro laboratoř, která modely často střídá (vývojový workflow, A/B testování inferenčních stacků), záleží na době načtení. Pomalejší SATA SSD tento čas na každou výměnu zdvojnásobí až ztrojnásobí.

Proudění vzduchu v racku zepředu dozadu. Nejčastější chyba u prvních sestav: desktopová orientace (nasávání z boku, výfuk nahoru a dozadu) v uzavřeném racku nefunguje. Výpočetní uzel musí používat řízené proudění odpovídající konvenci studené a teplé uličky v racku. Viz I01 a W05.

Upřímný pohled na hardware roku 2026

Toto je referenční sestava pro květen 2026. RTX 4090 není nejnovější GPU volbou Kentina — RTX 5090 (32 GB VRAM, architektura Blackwell, sm_120) a RTX Pro 6000 Blackwell (96 GB VRAM) jsou dostupné a výrazně mění kalkulaci VRAM na kartu. Uzel se 4 GPU RTX Pro 6000 Blackwell dá 384 GB VRAM — dost na pohodlné hostování Qwen 2.5 VL 72B ve FP8 na čtyřech kartách — za poměrně vyšší cenu na kartu.

Co se mezi generacemi nemění: architektonický vzor. Hostitelské AMD EPYC, multi-GPU přes PCIe, šasi s prouděním zepředu dozadu, dva zdroje, Ubuntu 24.04, vLLM v Dockeru, Prometheus + DCGM exporter. Tento vzor zůstal konzistentní napříč dvěma generacemi GPU a přežije i tu další. Kusovník bude levnější a rychlejší; vzor platí dál.

---

Toto je součást Kentino Wiki, referenční série o AI výpočetním výkonu, robotice a systémech, které je propojují. Komentáře a opravy uvítáme na info@kentino.com.