Vytvoření inferenčního serveru s 576 GB VRAM: Záznam o uvedení do provozu

Většina článků o serverech popisuje objednaný stroj. Tento popisuje stroj, který byl sestaven – včetně dvou věcí, které s ním byly při prvním zapnutí špatně, a té, kterou jsme nikdy plně nevysvětlili.

Postava: 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: dodáno

Myslíme si, že to je užitečnější článek. Kdokoli si může zkopírovat seznam dílů.

Co to je

Šest grafických karet RTX PRO 6000 Blackwell Max-Q, každá o kapacitě 96 GB, na dvoupaticové platformě EPYC Rome s 512 GB paměti ECC. 576 GB paměti VRAM v jednom boxu , což je dostatečné množství pro uložení modelu se 753 miliardami parametrů na 4 bitech s volným prostorem pro milion tokenů kontextu.

Varianta Max-Q je důležitá. S výkonem 300 W na kartu místo 600 se jich šest vejde do tepelného a elektrického obalu, který dokáže poskytnout dílna – a později i serverovna. Výkon při plném zatížení ze zásuvky byl ~2.9 kW , což je asi 80 % výkonu jednoho obvodu 16 A/230 V.

Šasi je našeho vlastního 7U designu: dva nezávisle chlazené bloky se čtyřmi pozicemi pro grafické karty, takže žádná karta neleží ve výfuku více než tří dalších.

První chyba: dvě grafické karty tiše běžící na poloviční rychlosti

Systém se spustil, všech šest karet bylo vyjmenováno, nvidia-smi vypadalo perfektně.

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

Nic nehlásilo chybu. Ovladač byl spokojený, karty fungovaly, inference probíhala. Jediný způsob, jak to zjistit, bylo změřit šířku pásma mezi hostitelem a zařízením na kartu a všimnout si, že dvě z nich vrátily 13.9 GB/s, zatímco ostatní vrátily 27.7.

Příčinou byla chyba fyzické vrstvy na dvou konektorech šasi – ne na kartách, ne na základní desce, ne na rozšiřujícím rozhraní. Oba propojení byla přesunuta na náhradní konektory a všech šest poté při zátěži potvrdilo Gen4 x16. Dva podezřelé konektory jsou v souboru sestavení zaznamenány jménem a ponechány nepoužívané po celou dobu životnosti stroje.

GPU, které trénuje na polovině šířky svého pruhu, se o sobě nijak nehlásí. Pokud váš proces uvádění do provozu neměří šířku pásma PCIe na kartu při zátěži, odešlete tuto chybu a nikdy se o ní nedozvíte.

Druhá chyba: ECC vzor, ​​který nebyl pamětí

Během uvádění do provozu začaly dva moduly DIMM zaznamenávat opravitelné chyby ECC. Opravitelné znamená, že je hardware detekoval a opravil: žádná ztráta dat, žádné špatné odpovědi, žádný dopad na výsledek. Dva moduly hlásící chyby však obvykle znamenají dva moduly k výměně.

Nenahradili jsme je a důvod je zajímavá část.

Události byly od sebe vzdáleny 4 hodiny 30 minut a 4 hodiny 01 minut a každá z nich se aktivovala na obou modulech během stejné sekundy . Dva nezávisle na sobě fungující paměťové moduly neselhávají v téměř pevném intervalu a už vůbec neselhávají ve stejné sekundě třikrát po sobě. Takhle degradující křemík nevypadá. To je znak něčeho vnějšího a periodického.

Interval odpovídal zátěži s vysokým spínacím výkonem v prostředí pro uvedení do provozu. Poté jsme spustili přibližně 20 hodin přístrojového testování při trvalém reálném zatížení s minutovou telemetrií na všech šesti grafických procesorech, CPU, paměti, disku a v protokolu událostí BMC. Nulové události ECC.

Takže moduly zůstaly.

Co pečlivě říkáme: nikdy jsme nekorelovali události se zaznamenaným cyklem předpokládaného zdroje. Atribuce je inference, nikoli důkaz. Zákazníkovi jsme nahlásili pozorování, interval a testovací okno a jasně jsme uvedli, že se nejedná o prokázanou základní příčinu. Pokud byla příčina v prostředí, nepřenáší se se strojem – a dvacet hodin ticha pod zátěží je dobrý důkaz, nikoli záruka.

Jedna praktická poznámka, která nás stála čas: tato platforma používá zpracování chyb s prioritou firmwaru, takže čítače ECC na straně Linuxu odečítají nulu bez ohledu na to, co se děje. Stav paměti je nutné číst z protokolu událostí BMC. Pokud monitorujete edac a nic jiného, ​​nic nesledujete.

Co stroj vlastně dělá

Všechny údaje jsou naměřeny na tomto konkrétním systému, nikoli z datového listu.

Výpočetní a konzistenční

a) Měření dodržování pokynů	Výsledek
FP16 hustý matmul, na kartu	291–302 TFLOPS (3.5 % rozloženo mezi šest)
Šířka pásma VRAM na kartu	~1 471 GB/s (rovnoměrně do 0.2 %)
Šesticestná datově paralelní inference	3,859 tok/s · Účinnost škálování 90.8 %
Rozložení na repliku mezi šest GPU	0.45%

To půlprocentní rozpětí mezi šesti kartami je číslo, které nás zajímá nejvíce. Znamená to, že žádná karta tiše nepodléhá výkonu – a má smysl jen proto, že výše uvedená chyba PCIe byla zjištěna jako první.

Inference z velkých modelů

GLM-5.2 — 753 miliard parametrů (40 B aktivních), 4 bity, 341 GB rezidentní paměti na šesti kartách:

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

Také na tomto hardwaru načte nativní kontext modelu s 1 048 576 tokeny – 494 GiB VRAM, takže na nejmenší kartě zbývá volných 6.6 GiB. To funguje, ale je to malá rezerva a to jsme si říkali.

Ladění mikrodávky předplnění (-b/-ub 4096) zvýšilo rychlost zpracování z 403 na 606 tok/s, což je 50% nárůst pro změnu jednoho řádku. Přidáno spekulativní dekódování +53 % jeden proud ale stojí 6 % u dávkové práce s dlouhými prompty, takže je povolena pro každou úlohu, nikoli globálně.

Vypálení

810 033 matmulů napříč šesti GPU při 100% zatížení. Nulové výpočetní chyby. Maximální teplota 88 °C, trvalý výkon 300 W na kartu, bez tepelného omezení — clocks_event_reasons číst Neaktivní po celou dobu.

Kde je tento stroj těsný, a my jsme to řekli

Teplotní rozpětí je ~2 °C. Maximální teplota 88 °C oproti ~90 °C při teplotě okolí 28–33 °C v nekontrolované dílně v srpnu. V místnosti pod 25 °C je příjemný prostor. V teplé místnosti ne. Dlouhodobé reálné zatížení dosáhlo stejných teplot jako při zapálení syntetických materiálů, takže se nejedná o problém pouze se syntetickými materiály.

Zřejmou překážkou je omezení výkonu grafické karty – 260 W místo 300 W. Na tomto počítači jsme neměřili, kolik to stojí z hlediska propustnosti , takže ho nedoporučujeme, jako bychom to udělali. Porovnejte ho s vaší vlastní zátěží.

Softwarový stack je specifický a křehký. GLM-5.2 na této generaci GPU nepoběží pod vLLM ani SGLang – tři samostatná omezení upstreamu. llama.cpp je pracovní cesta. Samostatně instalace vLLM obsahuje lokální záplatu opravující pád při souběžném používání kvantovaných modelů. ta záplata nepřežije pip install -U vllmPřipněte si své verze.

Dvojitá zásuvka znamená NUMA. Šířka pásma mezi hostitelem a zařízením se dělí podle socketu: GPU 0–2 na jednom, 3–5 na druhém, s přibližně 20% penalizací za alokaci vyrovnávacích pamětí hostitele na nesprávném uzlu. Není to chyba – z fyziky – ale musíte to s ním spojit. numactl kde záleží na šířce pásma hostitele a zařízení.

Jeden test je skutečně neúplný. Poslední kombinovaná fáze maximálního zatížení CPU+GPU byla přerušena poruchou napájecího zařízení v dílně. Přibližně 20 hodin vytrvalostního testování se smíšenou zátěží pokrývá skutečný provozní případ, takže jsme tuto mezeru nahlásili, místo abychom tiše přeznačili vytrvalostní běhy na chybějící test.

Proč zveřejňujeme chyby

Zpráva o uvedení do provozu, která uvádí vše, co bylo schváleno, vám neřekne nic o lidech, kteří ji napsali. Každý stroj této složitosti má při prvním zapnutí něco v nepořádku. Otázkou je, jestli se to najde na našem stole nebo ve vašem racku.

V této sestavě dva konektory snižovaly rychlost čtvrtiny GPU fabric na polovinu, což nebylo vidět pro žádný stavový indikátor v systému. Zjištění trvalo měřením a oprava deset minut.

K tomu slouží uvedení do provozu.