Stavba inferenčního serveru s 576 GB VRAM: zápisky z uvedení do provozu

Většina článků o serverech popisuje stroj, který si někdo objednal. Tenhle popisuje stroj, který byl postaven — včetně dvou věcí, které na něm byly špatně hned při prvním zapnutí, a té jedné, kterou jsme nikdy úplně nevysvětlili.

Sestava: 7U rack · 2× AMD EPYC 7643 (96C/192T) · 512 GB DDR4 ECC · 6× NVIDIA RTX PRO 6000 Blackwell Max-Q, 576 GB GDDR7 · 2 TB + 4 TB NVMe
Postaveno a uvedeno do provozu: srpen 2026, dílna Kentino, Praha · Stav: předáno

Myslíme si, že tohle je užitečnější článek. Soupisku dílů dokáže opsat kdokoli.

Co to je

Šest karet RTX PRO 6000 Blackwell Max-Q, každá s 96 GB, na dvousoketové platformě EPYC Rome s 512 GB paměti ECC. 576 GB VRAM v jedné skříni, což stačí na uložení modelu se 753 miliardami parametrů ve 4bitové kvantizaci a ještě zbude místo na milion tokenů kontextu.

Varianta Max-Q je zásadní. Při 300 W na kartu místo 600 se jich šest vejde do tepelného a elektrického rámce, který dílna — a později i serverovna — dokáže reálně pokrýt. Naměřený příkon ze sítě při plné zátěži byl ~2.9 kW, tedy asi 80 % jednoho okruhu 16 A/230 V.

Šasi je naše vlastní konstrukce ve formátu 7U: dva nezávisle chlazené bloky po čtyřech pozicích pro GPU, takže žádná karta nestojí ve výfuku více než tří dalších.

První závada: dvě GPU tiše běžely na poloviční rychlost

Systém naběhl, všech šest karet se vyčetlo, nvidia-smi vypadal bezchybně.

Dvě z nich běžely na PCIe Gen4 x8 místo x16.

Nic nehlásilo chybu. Ovladač byl spokojený, karty fungovaly, inference běžela. Jediný způsob, jak to odhalit, byl změřit propustnost mezi hostem a kartou zvlášť pro každou kartu a všimnout si, že dvě z nich vrátily 13.9 GB/s tam, kde ostatní vrátily 27.7.

Příčinou byla závada fyzické vrstvy na dvou konektorech šasi — ne karty, ne základní deska, ani konstrukce riserů. Oba spoje jsme přepojili na náhradní konektory a všech šest pak pod zátěží potvrdilo Gen4 x16. Oba podezřelé konektory jsou jmenovitě zapsány ve stavebním protokolu a po celou životnost stroje zůstanou nevyužité.

GPU, které trénuje na poloviční šířce linky, se samo neozve. Pokud Váš postup uvádění do provozu neměří propustnost PCIe jednotlivých karet pod zátěží, tuhle závadu expedujete a nikdy se o ní nedozvíte.

Druhá závada: vzorec ECC chyb, který nebyl v paměti

V průběhu uvádění do provozu začaly dva moduly DIMM hlásit opravitelné ECC chyby. Opravitelné znamená, že je hardware zachytil a opravil: žádná ztráta dat, žádné chybné výsledky, žádný dopad na jakýkoli výpočet. Dva moduly hlásící chyby ale obvykle znamenají dva moduly k výměně.

Nevyměnili jsme je a právě ten důvod je na tom zajímavý.

Události od sebe dělilo 4 h 30 m a 4 h 01 m, a každá se projevila na obou modulech ve stejné sekundě. Dva nezávisle hraniční paměťové moduly neselhávají v téměř pevném intervalu a rozhodně neselžou ve stejné sekundě třikrát po sobě. Takhle nevypadá degradující křemík. Tohle je podpis něčeho vnějšího a periodického.

Interval odpovídal spínání silové zátěže v prostředí, kde stroj běžel. Následně jsme odjeli ~20 hodin instrumentovaného soaku při trvalé reálné zátěži, s telemetrií po minutách ze všech šesti GPU, procesorů, paměti, disků a z event logu BMC. Nula ECC událostí.

Moduly tedy zůstaly.

Co říkáme opatrně: události jsme nikdy nezkorelovali se zaznamenaným cyklem podezřelého zdroje. To přiřazení je úsudek, ne důkaz. Pozorování, interval i časové okno testu jsme zákazníkovi nahlásili a otevřeně řekli, že nejde o prokázanou příčinu. Pokud byla příčina v prostředí, se strojem neputuje — a dvacet hodin ticha pod zátěží je dobrý důkaz, ne záruka.

Jedna praktická poznámka, která nás stála čas: tato platforma používá zpracování chyb firmware-first, takže čítače ECC na straně Linuxu ukazují nulu bez ohledu na to, co se děje. Stav paměti je nutné číst z event logu BMC. Pokud sledujete jen edac a nic jiného, nesledujete nic.

Co stroj doopravdy umí

Všechny údaje jsou naměřené na tomto konkrétním systému, ne opsané z datasheetu.

Výkon a konzistence

Měření	Výsledek
FP16 dense matmul, na kartu	291–302 TFLOPS (rozptyl 3.5 % napříč šesti kartami)
Propustnost VRAM, na kartu	~1,471 GB/s (jednotná na 0.2 %)
Šestinásobně datově paralelní inference	3,859 tok/s · účinnost škálování 90.8 %
Rozptyl mezi replikami na šesti GPU	0.45%

Ten půlprocentní rozptyl napříč šesti kartami je číslo, na kterém nám záleží nejvíc. Znamená, že žádná karta potichu nepodává nižší výkon — a smysl dává jen proto, že se nejdřív našla výše popsaná závada PCIe.

Inference velkých modelů

GLM-5.2 — 753 miliard parametrů (40 B aktivních), 4bitová kvantizace, 341 GB rezidentně napříč šesti kartami:

Souběžné požadavky	1	4	16	32	48
Generování tok/s	38.0	78.5	117–120	148.1	172.2

Na tomto hardwaru načte i nativní kontext 1,048,576 tokenů — 494 GiB VRAM, přičemž na nejtěsnější kartě zbývá volných 6.6 GiB. Funguje to, ale je to tenká rezerva a řekli jsme to nahlas.

Doladění prefill micro-batch (-b/-ub 4096) zvedlo zpracování promptu ze 403 na 606 tok/s, tedy o 50 % za jednořádkovou změnu. Spekulativní dekódování přidalo +53 % u jednoho streamu, ale stálo 6 % u dávkové práce s dlouhými prompty, takže se zapíná podle konkrétního workloadu, ne globálně.

Zátěžový test

810,033 matmulů na šesti GPU při 100% zátěži. Nula výpočetních chyb. Špička 88 °C, trvale 300 W na kartu, žádné tepelné škrcení — clocks_event_reasons hlásil Not Active po celou dobu.

Kde je stroj na hraně a kde jsme to řekli

Tepelná rezerva je ~2 °C. Špička 88 °C proti bodu škrcení kolem 90 °C, při teplotě okolí 28–33 °C v neklimatizované dílně v srpnu. V místnosti pod 25 °C je pohodlná rezerva. V teplé není. Trvalé reálné workloady dosáhly stejných teplot jako syntetický zátěžový test, takže to není starost jen pro syntetiku.

Zjevnou pákou je omezení příkonu GPU — 260 W místo 300 W. Neměřili jsme, kolik to na tomto stroji stojí na propustnosti, takže jsme to nedoporučili, jako bychom to změřili. Otestujte si to proti vlastnímu workloadu.

Softwarový stack je specifický a křehký. GLM-5.2 na této generaci GPU nepoběží pod vLLM ani SGLang — tři samostatná omezení na straně upstreamu. Funkční cestou je llama.cpp. Instalace vLLM navíc nese lokální patch, který opravuje pád při souběhu s kvantizovanými modely, a tento patch nepřežije pip install -U vllm. Verze si zafixujte.

Dva sokety znamenají NUMA. Propustnost mezi hostem a kartou se dělí podle soketu: GPU 0–2 na jednom, 3–5 na druhém, s přibližně 20% penalizací u hostitelských bufferů alokovaných na špatném uzlu. Není to závada — je to fyzika — ale tam, kde na propustnosti host↔karta záleží, musíte pinovat přes numactl.

Jeden test je skutečně nedokončený. Závěrečnou kombinovanou fázi maximální zátěže CPU+GPU přerušila porucha dílenského rozvaděče. ~20 hodin vytrvalostního testu se smíšenou zátěží pokrývá reálný provozní případ, takže jsme tu mezeru nahlásili, místo abychom vytrvalostní běhy potichu přeznačili za chybějící test.

Proč závady zveřejňujeme

Protokol z uvádění do provozu, který říká, že všechno prošlo, Vám o lidech, kteří ho psali, neřekne nic. Každý stroj téhle složitosti má při prvním zapnutí něco špatně. Otázka zní, jestli se to najde na našem stole, nebo ve Vašem racku.

U téhle sestavy to byly dva konektory, které degradovaly čtvrtinu propojení GPU na poloviční rychlost, neviditelné pro každý stavový indikátor v systému. Najít je vyžadovalo měření, opravit deset minut.

Přesně k tomu uvádění do provozu slouží.