Aufbau eines Inferenz-Servers mit 576 GB VRAM: ein Inbetriebnahme-Protokoll

Die meisten Server-Berichte beschreiben die Maschine, die bestellt wurde. Dieser hier beschreibt die Maschine, die gebaut wurde — einschließlich der beiden Dinge, die beim ersten Einschalten nicht stimmten, und des einen, das wir nie vollständig erklärt haben.

Aufbau: 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
Gebaut und in Betrieb genommen: August 2026, Kentino Werkstatt, Prag · Status: ausgeliefert

Wir halten das für den nützlicheren Artikel. Eine Stückliste kann jeder abschreiben.

Was die Maschine ist

Sechs RTX PRO 6000 Blackwell Max-Q mit je 96 GB auf einer Dual-Socket-EPYC-Rome-Plattform mit 512 GB ECC-Speicher. 576 GB VRAM in einem Gehäuse — genug, um ein Modell mit 753 Milliarden Parametern in 4 Bit vorzuhalten, mit Platz für eine Million Token Kontext.

Die Max-Q-Variante ist entscheidend. Mit 300 W statt 600 W pro Karte passen sechs davon in ein thermisches und elektrisches Budget, das eine Werkstatt — und später ein Serverraum — tatsächlich bereitstellen kann. Die gemessene Leistungsaufnahme an der Steckdose lag unter Volllast bei ~2.9 kW, etwa 80% eines einzelnen 16-A/230-V-Stromkreises.

Das Chassis ist unsere eigene 7U-Konstruktion: zwei unabhängig gekühlte Blöcke mit je vier GPU-Schächten, sodass keine Karte in der Abluft von mehr als drei anderen sitzt.

Der erste Fehler: zwei GPUs liefen unbemerkt mit halber Geschwindigkeit

Das System bootete, alle sechs Karten wurden erkannt, nvidia-smi sah perfekt aus.

Zwei von ihnen liefen mit PCIe Gen4 x8 statt x16.

Nichts meldete einen Fehler. Der Treiber war zufrieden, die Karten arbeiteten, die Inferenz lief. Sichtbar wurde es nur, indem wir die Host-zu-Device-Bandbreite jeder einzelnen Karte maßen und feststellten, dass zwei davon 13.9 GB/s lieferten, wo die übrigen 27.7 erreichten.

Die Ursache war ein Fehler auf der physikalischen Ebene an zwei Chassis-Steckverbindern — nicht an den Karten, nicht am Board, nicht am Riser-Konzept. Beide Verbindungen wurden auf freie Steckverbinder umgelegt, danach bestätigten alle sechs Karten unter Last Gen4 x16. Die beiden verdächtigen Steckverbinder sind in der Build-Akte namentlich festgehalten und bleiben für die gesamte Lebensdauer der Maschine unbelegt.

Eine GPU, die mit halber Lane-Breite trainiert, meldet sich nicht von selbst. Wenn Ihr Inbetriebnahme-Prozess die PCIe-Bandbreite nicht pro Karte unter Last misst, liefern Sie diesen Fehler aus und erfahren nie davon.

Der zweite Fehler: ein ECC-Muster, das gar nicht vom Speicher kam

Mitten in der Inbetriebnahme begannen zwei DIMMs, korrigierbare ECC-Fehler zu protokollieren. Korrigierbar heißt: Die Hardware hat sie erkannt und behoben — kein Datenverlust, keine falschen Ergebnisse, keine Auswirkung auf irgendein Resultat. Zwei Module, die Fehler melden, sind aber normalerweise zwei Module zum Austausch.

Wir haben sie nicht getauscht, und der Grund dafür ist der interessante Teil.

Die Ereignisse lagen 4 h 30 m und 4 h 01 m auseinander, und jedes einzelne trat auf beiden Modulen innerhalb derselben Sekunde auf. Zwei unabhängig voneinander grenzwertige Speichermodule fallen nicht in nahezu festem Intervall aus, und schon gar nicht dreimal hintereinander in derselben Sekunde. So sieht degradierendes Silizium nicht aus. Das ist die Signatur von etwas Externem und Periodischem.

Das Intervall passte zu einer leistungsstarken Schaltlast in der Inbetriebnahme-Umgebung. Anschließend ließen wir rund 20 Stunden instrumentierten Dauerlauf unter anhaltender realer Last fahren, mit minütlicher Telemetrie von allen sechs GPUs, CPU, Speicher, Datenträgern und dem BMC-Ereignisprotokoll. Null ECC-Ereignisse.

Also blieben die Module drin.

Worauf wir ausdrücklich Wert legen: Wir haben die Ereignisse nie gegen einen protokollierten Schaltzyklus der vermuteten Quelle korreliert. Die Zuordnung ist eine Schlussfolgerung, kein Beweis. Wir haben die Beobachtung, das Intervall und das Testfenster an den Kunden gemeldet und klar gesagt, dass es sich nicht um eine belegte Grundursache handelt. War die Ursache umgebungsbedingt, reist sie nicht mit der Maschine mit — und zwanzig Stunden Ruhe unter Last sind ein gutes Indiz, keine Garantie.

Ein praktischer Hinweis, der uns Zeit gekostet hat: Diese Plattform arbeitet mit Firmware-First-Fehlerbehandlung, deshalb stehen die ECC-Zähler auf Linux-Seite auf null, egal was passiert. Der Speicherzustand muss aus dem BMC-Ereignisprotokoll gelesen werden. Wer edac überwacht und sonst nichts, überwacht gar nichts.

Was die Maschine tatsächlich leistet

Alle Werte wurden an diesem konkreten System gemessen, nicht aus einem Datenblatt übernommen.

Rechenleistung und Gleichmäßigkeit

Messung	Ergebnis
FP16-Dense-Matmul, pro Karte	291–302 TFLOPS (3.5% Streuung über sechs Karten)
VRAM-Bandbreite, pro Karte	~1,471 GB/s (einheitlich bis auf 0.2%)
Sechsfach datenparallele Inferenz	3,859 tok/s · 90.8% Skalierungseffizienz
Streuung je Replik über sechs GPUs	0.45%

Diese halbprozentige Streuung über sechs Karten ist die Zahl, die uns am meisten interessiert. Sie bedeutet, dass keine Karte unbemerkt unter ihren Möglichkeiten bleibt — und sie ist nur deshalb aussagekräftig, weil der PCIe-Fehler oben zuvor gefunden wurde.

Inferenz mit großen Modellen

GLM-5.2 — 753 Milliarden Parameter (40 B aktiv), 4 Bit, 341 GB resident über sechs Karten verteilt:

Gleichzeitige Anfragen	1	4	16	32	48
Generierung tok/s	38.0	78.5	117–120	148.1	172.2

Auf dieser Hardware lässt sich außerdem der native Kontext des Modells von 1,048,576 Token laden — 494 GiB VRAM, womit auf der knappsten Karte noch 6.6 GiB frei bleiben. Das funktioniert, ist aber eine schmale Reserve, und das haben wir auch so gesagt.

Das Tuning der Prefill-Micro-Batch-Größe (-b/-ub 4096) hob die Prompt-Verarbeitung von 403 auf 606 tok/s, ein Plus von 50% — für eine Änderung in einer einzigen Zeile. Spekulatives Decoding brachte +53% im Einzelstrom, kostete aber 6% bei Batch-Läufen mit langen Prompts; es wird daher pro Workload aktiviert statt global.

Burn-in

810,033 Matmuls über sechs GPUs bei 100% Last. Null Rechenfehler. Spitzenwert 88 °C, dauerhaft 300 W pro Karte, kein thermisches Throttling — clocks_event_reasons meldete durchgehend Not Active.

Wo diese Maschine knapp ist — und wir es gesagt haben

Die thermische Reserve beträgt ~2 °C. Spitzenwert 88 °C gegenüber einem Throttle-Punkt von ~90 °C, bei 28–33 °C Umgebungstemperatur in einer unklimatisierten Werkstatt im August. In einem Raum unter 25 °C ist reichlich Luft. In einem warmen Raum nicht. Anhaltende reale Workloads erreichten dieselben Temperaturen wie der synthetische Burn-in — das ist also kein rein synthetisches Problem.

Der naheliegende Hebel ist ein GPU-Power-Limit — 260 W statt 300 W. Wir haben nicht gemessen, was das an dieser Maschine an Durchsatz kostet, und haben es deshalb auch nicht so empfohlen, als hätten wir es getan. Messen Sie es gegen Ihren eigenen Workload.

Der Software-Stack ist spezifisch und empfindlich. GLM-5.2 läuft auf dieser GPU-Generation weder unter vLLM noch unter SGLang — drei voneinander unabhängige Upstream-Grenzen. llama.cpp ist der funktionierende Weg. Davon unabhängig enthält die vLLM-Installation einen lokalen Patch, der einen Absturz bei Nebenläufigkeit mit quantisierten Modellen behebt, und dieser Patch überlebt pip install -U vllm nicht. Pinnen Sie Ihre Versionen.

Dual-Socket bedeutet NUMA. Die Host-zu-Device-Bandbreite teilt sich nach Sockel auf: GPUs 0–2 am einen, 3–5 am anderen, mit rund 20% Einbuße für Host-Puffer, die auf dem falschen Knoten liegen. Kein Fehler — Physik — aber dort, wo die Bandbreite zwischen Host und Device zählt, müssen Sie mit numactl pinnen.

Ein Test ist tatsächlich unvollständig. Die abschließende kombinierte Stufe mit maximaler CPU- und GPU-Last wurde durch einen Ausfall der Stromverteilung in der Werkstatt unterbrochen. Die rund 20 Stunden Dauerlauf unter gemischter Last decken den realen Betriebsfall ab, deshalb haben wir die Lücke gemeldet, statt die Dauerläufe stillschweigend als den fehlenden Test auszugeben.

Warum wir die Fehler veröffentlichen

Ein Inbetriebnahme-Bericht, in dem alles bestanden hat, sagt Ihnen nichts über die Leute, die ihn geschrieben haben. An jeder Maschine dieser Komplexität stimmt beim ersten Einschalten etwas nicht. Die Frage ist nur, ob es auf unserer Werkbank gefunden wird oder in Ihrem Rack.

Bei diesem Aufbau waren es zwei Steckverbinder, die ein Viertel der GPU-Anbindung auf halbe Geschwindigkeit drückten — unsichtbar für jede Statusanzeige des Systems. Es brauchte eine Messung, um sie zu finden, und zehn Minuten, um sie zu beheben.

Genau dafür ist die Inbetriebnahme da.