Stavba inferenčného servera s 576 GB VRAM: denník nasadenia
Zdieľať
Väčšina článkov o serveroch opisuje stroj, ktorý bol objednaný. Tento opisuje stroj, ktorý bol postavený — vrátane dvoch vecí, ktoré na ňom boli zlé pri prvom zapnutí, a jednej, ktorú sme nikdy úplne nevysvetlili.
Zostava: 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
Postavené a uvedené do prevádzky: august 2026, dielňa Kentino, Praha · Stav: dodané
Myslíme si, že toto je užitočnejší článok. Zoznam dielov dokáže skopírovať hocikto.
Čo to je
Šesť kariet RTX PRO 6000 Blackwell Max-Q, každá so 96 GB, na dvojpätičkovej platforme EPYC Rome s 512 GB ECC pamäte. 576 GB VRAM v jednom boxe, čo stačí na udržanie modelu so 753 miliardami parametrov v 4-bitovej kvantizácii a ešte zostane miesto na milión tokenov kontextu.
Na variante Max-Q záleží. Pri 300 W na kartu namiesto 600 sa šesť kariet zmestí do tepelnej a elektrickej obálky, ktorú dielňa — a neskôr serverovňa — dokáže reálne uniesť. Nameraný príkon zo siete pri plnej záťaži bol ~2.9 kW, teda asi 80 % jedného okruhu 16 A/230 V.
Šasi je náš vlastný 7U dizajn: dva nezávisle chladené bloky po štyroch GPU pozíciách, takže žiadna karta nestojí vo výfuku viac než troch ostatných.
Prvá chyba: dve GPU potichu bežali na polovičnej rýchlosti
Systém nabehol, všetkých šesť kariet sa vyčíslilo, nvidia-smi vyzeral bezchybne.
Dve z nich bežali na PCIe Gen4 x8 namiesto x16.
Nič nehlásilo chybu. Ovládač bol spokojný, karty fungovali, inferencia bežala. Jediný spôsob, ako to zistiť, bolo odmerať priepustnosť host-to-device pre každú kartu a všimnúť si, že dve z nich vracajú 13.9 GB/s tam, kde ostatné vracali 27.7.
Príčinou bola chyba fyzickej vrstvy na dvoch konektoroch šasi — nie karty, nie doska, nie konštrukcia riserov. Obe linky sme presunuli na náhradné konektory a všetkých šesť potom pod záťažou potvrdilo Gen4 x16. Oba podozrivé konektory sú menovite zaznamenané v zostavovom protokole a po celú životnosť stroja zostanú nepoužité.
GPU, ktoré trénuje na polovičnej šírke liniek, sa samo neohlási. Ak Váš proces uvádzania do prevádzky nemeria priepustnosť PCIe na kartu pod záťažou, túto chybu expedujete a nikdy sa o nej nedozviete.
Druhá chyba: ECC vzorec, ktorý nebol o pamäti
V priebehu uvádzania do prevádzky začali dva moduly DIMM logovať opraviteľné ECC chyby. Opraviteľné znamená, že ich hardvér zachytil a opravil: žiadna strata dát, žiadne nesprávne výsledky, žiadny vplyv na žiadny výpočet. Dva moduly hlásiace chyby však bežne znamenajú dva moduly na výmenu.
Nevymenili sme ich a dôvod je tá zaujímavejšia časť.
Udalosti boli od seba vzdialené 4 h 30 min a 4 h 01 min a každá sa prejavila na oboch moduloch v tej istej sekunde. Dva nezávisle na hrane fungujúce pamäťové moduly nezlyhávajú v takmer pevnom intervale a už vôbec nezlyhajú v tej istej sekunde trikrát za sebou. Takto nevyzerá degradujúci kremík. Takto vyzerá podpis niečoho vonkajšieho a periodického.
Interval zodpovedal vysokovýkonovej spínanej záťaži v prostredí dielne. Potom sme spustili ~20 hodín inštrumentovaného soak testu pod trvalou reálnou záťažou, s minútovou telemetriou na všetkých šiestich GPU, CPU, pamäti, diskoch a v logu udalostí BMC. Nula ECC udalostí.
Moduly teda zostali.
Čo hovoríme opatrne: udalosti sme nikdy nekorelovali so zaznamenaným cyklom predpokladaného zdroja. Priradenie príčiny je úsudok, nie dôkaz. Pozorovanie, interval a testovacie okno sme zákazníkovi nahlásili a otvorene sme povedali, že nejde o preukázanú príčinu. Ak bola príčina v prostredí, so strojom neputuje — a dvadsať hodín ticha pod záťažou je dobrý dôkaz, nie záruka.
Jedna praktická poznámka, ktorá nás stála čas: táto platforma používa spracovanie chýb
primárne vo firmvéri, takže ECC počítadlá na strane Linuxu ukazujú nulu bez ohľadu na to, čo sa deje.
Stav pamäte treba čítať z logu udalostí BMC. Ak sledujete edac a nič iné, nesledujete nič.
Čo stroj skutočne dokáže
Všetky hodnoty namerané na tomto konkrétnom systéme, nie z katalógového listu.
Výkon a konzistencia
| Meranie | Výsledok |
|---|---|
| FP16 hustý matmul, na kartu | 291–302 TFLOPS (rozptyl 3.5 % naprieč šiestimi) |
| Priepustnosť VRAM, na kartu | ~1,471 GB/s (rovnomerné na 0.2 %) |
| Šesťcestná dátovo paralelná inferencia | 3,859 tok/s · 90.8 % efektivita škálovania |
| Rozptyl medzi replikami naprieč šiestimi GPU | 0.45 % |
Ten polpercentný rozptyl naprieč šiestimi kartami je číslo, na ktorom nám záleží najviac. Znamená, že žiadna karta potichu nezaostáva — a má zmysel len preto, že sa najprv našla vyššie opísaná chyba PCIe.
Inferencia veľkých modelov
GLM-5.2 — 753 miliárd parametrov (40 B aktívnych), 4-bit, 341 GB rezidentne naprieč šiestimi kartami:
| Súbežné požiadavky | 1 | 4 | 16 | 32 | 48 |
|---|---|---|---|---|---|
| Generovanie tok/s | 38.0 | 78.5 | 117–120 | 148.1 | 172.2 |
Na tomto hardvéri sa dá načítať aj natívny kontext modelu s 1,048,576 tokenmi — 494 GiB VRAM, pričom na najtesnejšej karte zostáva 6.6 GiB voľných. Funguje to, ale je to tenká rezerva a povedali sme to.
Doladenie prefill mikro-dávky (-b/-ub 4096) zdvihlo spracovanie promptu zo 403 na
606 tok/s, teda o 50 % za zmenu jedného riadka. Špekulatívne dekódovanie pridalo
+53 % pri jednom prúde, ale stálo 6 % pri dávkovej práci s dlhými promptmi, takže sa zapína
podľa workloadu, nie globálne.
Záťažový test
810,033 matmulov naprieč šiestimi GPU pri 100 % záťaži. Nula výpočtových chýb. Špička
88 °C, trvalých 300 W na kartu, žiadne tepelné škrtenie — clocks_event_reasons po celý čas hlásil
Not Active.
Kde je tento stroj na hrane a povedali sme to
Tepelná rezerva je ~2 °C. Špička 88 °C oproti bodu škrtenia ~90 °C, pri okolitej teplote 28–33 °C v neklimatizovanej dielni v auguste. V miestnosti pod 25 °C je rezerva pohodlná. V teplej nie je. Trvalé reálne workloady dosiahli rovnaké teploty ako syntetický záťažový test, takže nejde o obavu platnú len pre syntetiku.
Zjavnou pákou je obmedzenie príkonu GPU — 260 W namiesto 300 W. Nemerali sme, čo to na tomto stroji stojí na priepustnosti, takže sme to neodporúčali tak, akoby sme to merali. Otestujte si to na vlastnom workloade.
Softvérový stack je špecifický a krehký. GLM-5.2 nepobeží pod vLLM ani
SGLang na tejto generácii GPU — tri samostatné obmedzenia na strane upstreamu. Funkčnou cestou je llama.cpp.
Inštalácia vLLM navyše nesie lokálny patch, ktorý opravuje pád pri súbežnosti s kvantizovanými modelmi, a
tento patch neprežije pip install -U vllm.
Zafixujte si verzie.
Dve pätice znamenajú NUMA. Priepustnosť host-to-device sa delí podľa pätice: GPU 0–2 na
jednej, 3–5 na druhej, s približne 20 % penalizáciou pri hostiteľských bufferoch alokovaných na nesprávnom uzle. Nie je
to chyba — je to fyzika — ale tam, kde na priepustnosti host↔device záleží, musíte pripínať cez numactl.
Jeden test je naozaj nedokončený. Záverečnú kombinovanú fázu maximálnej záťaže CPU+GPU prerušila porucha rozvodu elektriny v dielni. ~20 hodín zmiešanej záťažovej výdrže pokrýva reálny prevádzkový prípad, takže sme nahlásili medzeru namiesto toho, aby sme výdržové behy potichu prelepili na chýbajúci test.
Prečo chyby zverejňujeme
Protokol o uvedení do prevádzky, ktorý tvrdí, že všetko prešlo, Vám nepovie nič o ľuďoch, ktorí ho napísali. Každý stroj tejto zložitosti má pri prvom zapnutí niečo zlé. Otázka je, či sa to nájde na našom stole alebo vo Vašom racku.
Pri tejto zostave to boli dva konektory, ktoré degradovali štvrtinu GPU fabric na polovičnú rýchlosť, neviditeľne pre každý stavový ukazovateľ v systéme. Nájsť to si vyžiadalo meranie a oprava trvala desať minút.
Presne na to je uvádzanie do prevádzky.