Opbygning af en 576 GB VRAM-inferensserver: En idriftsættelseslog

De fleste serverbeskrivelser beskriver den maskine, der blev bestilt. Denne beskriver den maskine, der blev bygget – inklusive de to ting, der var galt med den, da den først blev tændt, og den, vi aldrig forklarede fuldt ud.

Build: 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
Bygget og idriftsat: august 2026, Kentino workshop, Prag · Status: leveret

Vi synes, det er den mest brugbare artikel. Alle kan kopiere en stykliste.

Hvad er det

Seks RTX PRO 6000 Blackwell Max-Q-kort, 96 GB hver, på en dual-socket EPYC Rome-platform med 512 GB ECC-hukommelse. 576 GB VRAM i én boks , hvilket er nok til at rumme en model med 753 milliarder parametre ved 4-bit med plads til en million konteksttokens.

Max-Q-varianten er vigtig. Med 300 W pr. kort i stedet for 600 passer seks af dem ind i en termisk og elektrisk kuvert, som et værksted – og senere et serverrum – faktisk kan levere. Vægeffekten ved fuld belastning måltes til ~2.9 kW , omkring 80 % af et enkelt 16 A/230 V kredsløb.

Chassiset er vores eget 7U-design: to uafhængigt kølede blokke med fire GPU-båse, så intet kort sidder i udstødningen på mere end tre andre.

Den første fejl: to GPU'er kører stille og roligt på halv hastighed

Systemet startede op, alle seks kort var opregnet, nvidia-smi så perfekt ud.

To af dem kørte på PCIe Gen4 x8 i stedet for x16.

Intet rapporterede en fejl. Driveren var tilfreds, kortene virkede, inferensen kørte. Den eneste måde at se det på var at måle vært-til-enhed-båndbredden pr. kort og bemærke, at to af dem returnerede 13.9 GB/s, hvor de andre returnerede 27.7.

Årsagen var en fejl i det fysiske lag på to chassisstik – ikke kortene, ikke bundkortet, ikke riserdesignet. Begge links blev flyttet til ekstra stik, og alle seks blev derefter bekræftet som Gen4 x16 under belastning. De to mistænkte stik er registreret ved navn i byggefilen og forbliver ubrugte i maskinens levetid.

En GPU, der træner med halvdelen af ​​sin banebredde, giver ikke sig selv besked. Hvis din idriftsættelsesproces ikke måler PCIe-båndbredden pr. kort under belastning, vil du udløse denne fejl, og du ved aldrig.

Den anden fejl: et ECC-mønster, der ikke var hukommelsen

Halvvejs gennem idriftsættelsen begyndte to DIMM'er at logge korrigerbare ECC-fejl. Korrigerbar betyder, at hardwaren registrerede og rettede dem: intet datatab, ingen forkerte svar, ingen indflydelse på noget resultat. Men to moduler, der rapporterer fejl, er normalt to moduler, der skal udskiftes.

Vi erstattede dem ikke, og årsagen er den interessante del.

Hændelserne fandt sted med 4 timer og 30 minutter og 4 timer og 01 minuts mellemrum , og hver begivenhed blev aktiveret på begge moduler inden for samme sekund . To uafhængigt marginale hukommelsesmoduler fejler ikke med et næsten fast interval, og de fejler bestemt ikke i samme sekund tre gange i træk. Det er ikke sådan, nedbrydende silicium ser ud. Det er kendetegnende for noget eksternt og periodisk.

Intervallet matchede en høj effekt switching belastning i idriftsættelsesmiljøet. Vi kørte derefter ~20 timers instrumentbaseret soak under vedvarende reel belastning, med telemetri pr. minut på alle seks GPU'er, CPU, hukommelse, disk og BMC-hændelsesloggen. Nul ECC-hændelser.

Så modulerne blev.

Hvad vi er omhyggelige med at sige: Vi har aldrig korreleret hændelserne med en logget cyklus af den mistænkte kilde. Tilskrivningen er inferens, ikke bevis. Vi rapporterede observationen, intervallet og testvinduet til kunden og sagde tydeligt, at det ikke er en bevist rodårsag. Hvis årsagen var miljømæssig, rejser den ikke med maskinen - og tyve timers stilhed under belastning er godt bevis, ikke en garanti.

En praktisk bemærkning, der kostede os tid: denne platform bruger Håndtering af firmware-først fejl, så Linux-sidede ECC-tællere viser nul uanset hvad der sker. Hukommelsestilstanden skal læses fra BMC-hændelsesloggen. Hvis du overvåger edac og intet andet, du overvåger ingenting.

Hvad maskinen rent faktisk gør

Alle tal er målt på dette specifikke system, ikke fra et datablad.

Beregning og konsistens

Mål	Resultat
FP16 tæt matmul, pr. kort	291–302 TFLOPS (3.5% fordelt på seks)
VRAM-båndbredde, pr. kort	~1,471 GB/s (jævnt til 0.2%)
Seksvejs dataparallel inferens	3,859 tok/s · Skaleringseffektivitet på 90.8 %
Pr. replika fordelt på tværs af seks GPU'er	0.45%

Den halve procent fordelt på seks kort er det tal, vi er mest interesserede i. Det betyder, at ingen kort stille og roligt underpræsterer – og det er kun meningsfuldt, fordi ovenstående PCIe-fejl blev fundet først.

Stormodel-inferens

GLM-5.2 — 753 milliarder parametre (40 B aktive), 4-bit, 341 GB resident på tværs af seks kort:

Samtidige anmodninger	1	4	16	32	48
Generation tok/s	38.0	78.5	117-120	148.1	172.2

Den indlæser også modellens native 1,048,576-token-kontekst på denne hardware — 494 GiB VRAM, hvilket efterlader 6.6 GiB fri på det strammeste kort. Det virker, men det er en tynd margen, og det sagde vi.

Justering af præfyldningsmikrobatchen (-b/-ub 4096) hævede hurtig behandling fra 403 til 606 tok/s, en gevinst på 50% for en ændring på én linje. Spekulativ afkodning tilføjet +53% enkeltstrøm men koster 6 % på batcharbejde med lange prompter, så det er aktiveret pr. arbejdsbyrde i stedet for globalt.

Indbrænding

810,033 matmuls på tværs af seks GPU'er ved 100% belastning. Nul beregningsfejl. Peak 88 °C, vedvarende 300 W pr. kort, ingen termisk throttling — clocks_event_reasons læse Ikke aktiv hele vejen igennem.

Hvor denne maskine er stram, og det sagde vi

Termisk margin er ~2 °C. Peak 88 °C mod et ~90 °C drosselspunkt, ved en omgivende temperatur på 28-33 °C i et ukontrolleret værksted i august. I et rum under 25 °C er der et behageligt rum. I et varmt rum er der ikke. Vedvarende reelle arbejdsbelastninger nåede de samme temperaturer som syntetisk indbrænding, så dette er ikke et problem udelukkende ved syntetiske processer.

Det oplagte greb er en GPU-strømbegrænsning – 260 W i stedet for 300 W. Vi har ikke målt, hvad det koster i gennemstrømning på denne maskine , så vi anbefalede det ikke, som om vi havde gjort. Sammenlign det med din egen arbejdsbyrde.

Softwarestakken er specifik og skrøbelig. GLM-5.2 kører ikke under vLLM eller SGLang på denne GPU-generation — tre separate upstream-begrænsninger. llama.cpp er arbejdsstien. Separat indeholder vLLM-installationen en lokal patch, der retter et nedbrud under samtidighed med kvantiserede modeller, og den plet overlever ikke pip install -U vllmFastgør dine versioner.

Dobbelt sokkel betyder NUMA. Båndbredde fra vært til enhed opdeles efter socket: GPU'er 0-2 på den ene, 3-5 på den anden, med en straf på cirka 20% for værtbuffere allokeret på den forkerte node. Ikke en fejl - fysik - men du skal fastlåse med numactl hvor vært↔enhedsbåndbredde betyder noget.

Én test er virkelig ufuldstændig. Den sidste kombinerede CPU+GPU maksimale belastningsfase blev afbrudt af en fejl i værkstedets strømfordelingsudstyr. De ~20 timers udholdenhedstest med blandet belastning dækker det faktiske driftstilfælde, så vi rapporterede hullet i stedet for stille og roligt at omdøbe udholdenhedskørslerne til den manglende test.

Hvorfor vi offentliggør fejlene

En idriftsættelsesrapport, der siger, at alt er bestået, fortæller intet om de personer, der skrev den. Enhver maskine af denne kompleksitet har noget galt med sig første gang, den tændes. Spørgsmålet er, om den bliver fundet på vores bænk eller i dit rack.

På denne build var det to stik, der forringede en fjerdedel af GPU-strukturen til halv hastighed, usynlige for alle statusindikatorer på systemet. Det tog måling at finde og ti minutter at reparere.

Det er dét, idriftsættelse er til for.