#16 · Aufrüsten: Das Monster-Rig mit bis zu 19 GPUs

Unser Dienst für lokale Sprachmodelle läuft seit Ende August auf einem neuen Board, und seit dem 4. September hängen zehn RTX 3090 daran statt acht. Alle zehn arbeiten. Das ist der eigentliche Anlass für den ganzen Umbau: Lokale Modelle sind bei uns inzwischen Werkzeug im Tagesgeschäft, ein Dienst, gegen den mehrere Entwickler gleichzeitig mit ihren Coding-Agenten arbeiten. Um diesen Dienst selbst — zwei Cluster aus je vier Karten hinter einem eigenen Proxy — ging es im vorigen Artikel. Hier geht es um das Blech darunter.

Vier Dinge kann der neue Aufbau, die der alte nicht konnte:

• Platz für bis zu 19 Grafikkarten statt für acht.
• Bis zu zehn Karten an einer einzigen CPU. Das Board hat zwei davon, und ein Modell in unserer Größe muss deshalb nie über die Grenze zwischen ihnen hinweg rechnen. Warum das so viel ausmacht, steht weiter unten.
• Eine robustere Anbindung. Die Karten hängen über SlimSAS-Kabel und eine kleine Adapterplatine am Board. Der alte Aufbau nutzte die breiten PCIe-Flachbandkabel, die extrem anfällig fürs Verbiegen sind. Dazu dürfen die SlimSAS-Kabel länger sein, und erst das macht einen Aufbau über mehrere Ebenen überhaupt möglich.
• Der Sprung von acht auf zehn Karten.

Dazwischen liegen gut zehn Tage Fehlersuche, drei Karten, die wir für tot hielten, zwei Absturzserien, eine Karte, die wir aufschrauben mussten — und ein Verdacht, den wir eine Zeit lang selbst hatten: dass die neue Plattform schlicht langsamer sei als die alte. Er war falsch. Wie wir ihn losgeworden sind, ist der lehrreichste Teil der Geschichte.

Warum ein Board mit 19 Anschlüssen

19 ist keine gerundete Zahl. So viele SlimSAS-Buchsen sitzen auf der Platine: schmale Kabelanschlüsse, über die je acht PCIe-Bahnen aus einer der beiden CPUs herausgeführt werden. Ein Kabel und eine Adapterplatine — zusammen ein Riser — machen daraus einen Steckplatz für eine Grafikkarte. Neun dieser Buchsen hängen an der ersten CPU, zehn an der zweiten. Die Zuordnung ist fest verdrahtet und im BIOS nicht änderbar.

Die Alternative wäre gewesen, alle zwei Ausbaustufen die Plattform zu wechseln: neues Board, neue CPU, neuer Speicher, jedes Mal für ein paar Karten mehr. Ein Board mit 19 Anschlüssen beendet dieses Karussell für die absehbare Zeit. Der nächste Ausbauschritt ist eine Karte, kein neuer Rechner.

Umsonst sind die 19 Anschlüsse vermutlich nicht zu haben. Im Blockdiagramm des Handbuchs führen einige der Leitungen, die sonst die beiden CPUs miteinander verbinden, stattdessen zu Steckplätzen. Wie schmal die Verbindung zwischen den Sockeln dadurch ausfällt, steht nicht im Handbuch, und nachgemessen haben wir es bisher nicht. Diese Vermutung ist einer der Gründe, warum wir die Karten eines Modells ohnehin lieber an einer CPU halten.

Das neue Gehäuse: Aluminium statt Holz

Der bisherige Rahmen steht auf einer Holzplatte, und die Karten stecken darin viel zu eng nebeneinander. Was das kostet, steht im Protokoll: Zwei Karten drosselten unter Dauerlast, während alle anderen zwischen 51 und 65 °C blieben und ungebremst durchliefen. Die eine hing bei 73 °C, die andere bei 81 °C — beide weit unter den 95 °C, ab denen der Rechenkern drosselt. Ausgelöst hat die Bremse der Speicher: Beim 3090 sitzt der GDDR6X beidseitig auf der Platine und riegelt bei rund 110 °C ab. Die Lüfter der betroffenen Karten drehten da bereits mit 74 bis 78 Prozent.

Unangenehm daran ist, dass GeForce-Karten die Speichertemperatur überhaupt nicht melden: Die entsprechende Abfrage liefert schlicht N/A. Im normalen Monitoring ist das Problem damit unsichtbar. Der einzige verlässliche Hinweis ist ein Statusfeld, in dem die Karte den Grund ihrer Drosselung meldet — darauf muss man erst einmal kommen. Bemerkbar macht sich der Effekt trotzdem, denn die vier Karten einer Gruppe warten bei jedem Rechenschritt aufeinander, und die langsamste gibt das Tempo für alle vor.

Der Entwurf ganz oben plant deshalb deutlich mehr Abstand zwischen den Karten ein. Gebaut wird der Rahmen aus Aluminiumprofilen statt aus Holz, weil 18 Grafikkarten ein Gewicht ergeben, bei dem ein Holzrahmen nicht mehr die richtige Antwort ist. 18, nicht 19: Der neunzehnte Anschluss bleibt unbesetzt, weil hier die Mechanik früher an ihre Grenze kommt als das Board.

Drei tote Karten — und keine war defekt

Noch während wir die Modelldaten vom alten Rig herüberkopierten, fiel die erste Karte aus. Der NVIDIA-Treiber schreibt bei solchen Ereignissen eine Fehlernummer ins Systemprotokoll, ein sogenanntes Xid. Hier war es Xid 79, „fallen off the bus“: Die Karte war für den Treiber schlicht verschwunden. Kurz darauf meldeten alle übrigen Karten Xid 154, „Node Reboot Required“ — ab da ist Weiterbetrieb nicht mehr vertrauenswürdig.

Am Morgen darauf, acht Minuten nach einem Neustart, traf es in derselben Sekunde zwei weitere Karten: Eine fiel von acht auf vier PCIe-Bahnen zurück, die andere verlor die Verbindung ganz. Drei Karten binnen eines Tages, alle auf benachbarten Positionen im Rahmen. Das sah nach Hardwareschaden aus.

Beim Umbau fand sich die Ursache: ein loser Kontakt am PCIe-Stromstecker. Das Kabel selbst war in Ordnung, es saß nur nicht fest. Nach dem Neustecken liefen beide Karten vom Morgen wieder mit voller Anbindung und ohne Fehler, und der Steckplatz, an dem zwei Karten hintereinander gestorben waren, trägt heute eine dritte ohne Auffälligkeit.

Bleibt die erste Karte, die vom Vortag. Die hatten wir als Totalausfall abgeschrieben und ausgebaut. Sie ist inzwischen die zehnte Karte im Rig und läuft fehlerfrei. Damit ist der Befund vollständig: Keine einzige Karte war defekt, kein Steckplatz war defekt. Sämtliche Ausfälle hingen an Steckern und Kabeln.

Drei Punkte daraus haben wir uns notiert:

• Xid 79 heißt hier fast immer Kontaktproblem. Vor jeder Reklamation erst die Strom- und Datenstecker an beiden Enden nachdrücken.
• Vier statt acht Bahnen ist das Frühwarnzeichen. Die Übertragungsrate einer PCIe-Verbindung wird im Leerlauf zum Stromsparen heruntergefahren, die Zahl der Bahnen nicht. Jede halbierte Breite ist deshalb ein Befund. Aufgetreten ist das zweimal, beide Male an einer Verbindung, die kurz darauf ausfiel oder gerade ausgefallen war.
• Ein räumliches Muster ist ein starkes Signal. Alle drei Ausfälle lagen auf benachbarten Positionen. Das wies auf die Verkabelung dieser Ecke hin — und dort lag es dann auch.

Wie man den Steckplatz einer toten Karte findet

Das ist schwieriger, als es klingt. GPU-Index und PCI-Adresse verschieben sich, sobald eine Karte wegfällt: Alle folgenden Adressen rücken nach vorn, dieselbe physische Karte trägt danach eine andere. Die UUID, die unveränderliche Kennung einer Karte, wäre stabil — nur meldet eine tote Karte keine mehr. Wer mit dem Schraubendreher vor dem Rahmen steht, hat damit nichts in der Hand.

Brauchbar ist stattdessen der Root-Port: der Anschlusspunkt in der CPU selbst, an dem die acht PCIe-Bahnen herauskommen. Er ist fest mit genau einer Buchse auf der Platine verdrahtet, verschiebt sich nie und bleibt sichtbar, auch wenn die Karte daran tot ist. Zusätzlich trägt jeder Root-Port eine Steckplatznummer, die die Board-Firmware selbst vergibt und die den Namen der Buchse direkt kodiert. Ein kleines Inventurskript liest das aus und gibt je Steckplatz Buchsenname, zuständige CPU, Anbindungsbreite und Lebendstatus aus. Über mehrere Umbauten hinweg hat sich das gehalten; bei einem davon vergab das System die gesamte PCI-Nummerierung neu, und die Firmware-Nummern stimmten weiterhin. Aus dieser Ausgabe zählt in der Praxis vor allem eine Unterscheidung: Taucht eine Buchse gar nicht mehr in der PCI-Liste auf, kam überhaupt keine Verbindung zustande — Kabel, Strom oder Karte. Ist sie da und die Karte antwortet nicht, war die Karte da und ist im Betrieb gestorben. Das sind zwei verschiedene Suchen.

Die Buchse, die nach hinten auswich

Eine Karte hat uns danach noch länger beschäftigt: Sie meldete sich immer wieder ab. Wir hielten zunächst die Stromversorgung für die Ursache. Das war falsch, und gefunden haben wir es erst, als wir die Karte aufgeschraubt haben. Bei diesem Gigabyte-Modell drückten sich die Kontaktstifte der PCIe-Strombuchse beim Einstecken der Stromkabel nach hinten aus dem Gehäuse der Buchse heraus. Ein sicherer Kontakt kam so nicht mehr zustande.

Die Buchse sitzt bei diesem Modell auf einer eigenen kleinen Baugruppe mit Kabelbaum, die sich tauschen lässt; ein Anbieter verlangt für eines der beiden Teile rund 18 Euro. Unsere Lösung war einfacher: Stromkabel einstecken, dann von hinten einen hitzebeständigen, aushärtenden Kunststoffkleber in die Öffnungen laufen lassen. Seitdem sitzt die Verbindung.

Der Neustart, der nichts hinterließ

Die zweite Ausfallserie begann Ende August an einem anderen Steckplatz und sah völlig anders aus. Der Server startete beim Laden des Modells hart neu — ohne Kernelmeldung, ohne Fehlernummer, ohne Absturzprotokoll. Das Log bricht mitten im Satz ab. Von außen wirkt das wie ein Stromausfall. Weil die Container so eingestellt waren, dass sie sich selbst wieder hochfahren, wiederholte sich das fünfmal in 23 Minuten. Ein Neustart kostet auf diesem Board 1 Minute 37 Sekunden, gemessen mit neun Karten, und gut eine Minute davon entfällt allein auf die Firmware, die laut Handbuch rund 90 Sekunden auf den Management-Controller des Boards wartet. Bei einer Fehlersuche, die überwiegend aus Neustarts besteht, merkt man das deutlich.

Der Kernel schwieg, weil er keine Gelegenheit mehr bekam. Der Grund stand in einem Register, in dem die CPU den Anlass des vorigen Resets festhält:

x86/amd: Previous system reset reason [0x08000800]:
         an uncorrected error caused a data fabric sync flood event

Ein Sync Flood ist AMDs Notabschaltung. Tritt im Data Fabric — dem internen Verbindungsnetz der CPU, das Kerne, Speichercontroller und PCIe zusammenschaltet — ein unkorrigierbarer Fehler auf, hält die Maschine sofort an, ohne dem Betriebssystem noch etwas mitzuteilen. Seitdem sehen wir nach jedem unerklärten Reset zuerst in dieses Register.

Die Eingrenzung lief über Tauschversuche: jeweils drei bekannt stabile Karten plus eine Verdächtige. Eine Kombination stürzte reproduzierbar nach 35 Sekunden ab, alle anderen liefen durch. Damit war der verdächtige Platz gefunden, und die eigentliche Arbeit fing an. An einem Steckplatz hängen nämlich drei verdächtige Teile: die Karte, der Steckplatz selbst und der Riser dazwischen, also Kabel plus Adapterplatine. Wir haben jedes davon einzeln getauscht. Gen4 steht in der Tabelle für die vierte PCIe-Generation, mit der das Board die Karten normalerweise anbindet, Gen3 für die vorige mit der halben Übertragungsrate.

Weder die Karte noch der Steckplatz waren defekt, dasselbe Ergebnis wie bei der ersten Serie. Der Fehler saß im Riser, und dort überwiegend im Kabel: Die neue Platine machte aus „immer kaputt“ nur „gelegentlich kaputt“, erst das neue Kabel machte den Platz sauber.

Die dritte Zeile ist trotzdem die praktisch interessanteste. Auf Gen3 zurückgeschaltet war der Fehler sofort weg, und gekostet hat das nichts: Unser Dienst bewegt über eine solche Verbindung rund 270 MB/s, Gen3 liefert auf acht Bahnen etwa 8 GB/s. Das sind unter vier Prozent Auslastung. Wenn ein Riser Gen4 nicht sicher schafft, ist die halbe Übertragungsrate für diese Last also eine brauchbare Notlösung. Sie überlebt allerdings keinen Neustart, das BIOS setzt danach wieder Gen4.

Warum die CPU beim GPU-Rechnen mitrechnet

Dass eine CPU über den Durchsatz eines GPU-Dienstes mitentscheidet, klingt zunächst falsch. Der Grund liegt in einer Eigenschaft von GeForce-Karten: Sie können untereinander keine Daten direkt austauschen. Im Serientreiber ist dieser Weg für GeForce nicht freigeschaltet; das Werkzeug, das die Verbindungen zwischen den Karten anzeigt, meldet für jedes Kartenpaar „chipset not supported“. Daran ändert kein BIOS-Schalter etwas. Auf dem alten Rig war die Funktion ebenfalls abgeschaltet, sie ist also eine Konstante zwischen beiden Plattformen.

Die Folge trifft den Kern der Arbeit. Unser Dienst läuft mit Tensor-Parallelität über vier Karten: Jede Gewichtsmatrix ist in vier Teile zerlegt, und nach jedem Rechenschritt führen die vier Karten ihre Zwischenergebnisse zusammen, damit alle mit demselben Stand weiterrechnen. Ohne direkten Weg zwischen den Karten läuft dieses Zusammenführen über den Hauptspeicher des Rechners. In der üblichen Ringform sind das über vier Karten sechs aufeinanderfolgende Stufen, und jede Stufe ist eine Runde Karte → Hauptspeicher → Karte.

Dazu kommt spekulatives Dekodieren: Ein kleines Entwurfsmodell schlägt acht Tokens auf einmal vor, das große Modell prüft sie in einem Durchgang. Ein solcher Prüfschritt sieht bei diesem Modell so aus:

64 Schichten × 2 Zusammenführungen × 6 Ringstufen
    = 768 Runden über den Hauptspeicher je Prüfschritt

Bei rund 29 Prüfschritten je Sekunde sind das etwa 22.000 solcher Runden pro Sekunde. Was hier zählt, ist die Latenz jeder einzelnen Runde. Die Speicherbandbreite ist bei vier Karten nur zu rund 12 Prozent ausgelastet, die PCIe-Bandbreite zu 2,7 Prozent.

Der Denkfehler mit den 12 Prozent

Genau diese 12 Prozent haben uns in die Irre geführt. Die Auslastung sah unkritisch aus, also schien mehr Speicherbandbreite nichts zu bringen, und ein Ausbau des Arbeitsspeichers rutschte auf der Liste nach unten. Bis zum 4. September lief das Rig deshalb mit einem einzigen bestückten Speicherkanal je CPU und 61 GiB.

Der Fehler steckt im Wort „Durchschnitt“. Ein Speicherkanal ist ein eigener Pfad vom Controller zu den Riegeln; bei nur einem bestückten Kanal gibt es keine Parallelität, jede Anforderung wartet in derselben Schlange vor demselben Controller. Bei 22.000 kleinen Runden pro Sekunde entscheidet diese Wartezeit über den Durchsatz. Dazu wächst der Verkehr zwischen den Karten etwa mit dem Quadrat ihrer Anzahl: Der Sprung von vier auf zehn Karten in einer Gruppe entspricht grob der sechsfachen Last am Hauptspeicher, bei einem Kanal rund 70 Prozent Auslastung. Diese Zahl ist gerechnet, nicht gemessen. Die Lehre taugt trotzdem über dieses Rig hinaus: Eine niedrige Bandbreitenauslastung ist kein Beleg dafür, dass mehr Speicherkanäle nutzlos sind. Bei latenzgebundenen Lasten mit vielen kleinen Übertragungen ist die Zahl der Kanäle für sich genommen ein Faktor.

Ausgebaut ist der Speicher inzwischen: von zwei auf sechs Riegel, zwei Kanäle an der ersten CPU, vier an der zweiten, zusammen 184 GB. Ob acht Kanäle je Sockel noch etwas bringen, haben wir nicht gemessen — der Engpass wirkt behoben.

Alles auf einen Sockel

Die zweite Hälfte der Sanierung war die Verteilung der Karten. Überschreitet eine Kartengruppe die Sockelgrenze, kommt bei einem Teil der Runden über den Hauptspeicher der Umweg über die zweite CPU hinzu — genau die Verbindung, die auf diesem Board möglicherweise schmaler ausfällt als üblich.

Neun der zehn Karten hängen inzwischen an der zweiten CPU. Für den Dienst haben wir zusätzlich feiner sortiert: Einer der beiden Cluster belegt die einzige Vierergruppe im Rig, in der alle sechs Kartenpaare über dieselbe Host-Bridge laufen — die Verteilerstufe in der CPU, an der mehrere Steckplätze hängen. In jeder anderen Vierergruppe müsste mindestens ein Paar einen weiteren Umweg nehmen.

Der Rückstand, den es nicht mehr gibt

Ende August sah es eine Weile so aus, als hätten wir uns mit dem Board etwas eingehandelt. Derselbe Dienst, dieselben physischen Karten, dieselbe Konfiguration bis auf den Zufalls-Seed — und der Median lag auf dem neuen Rig 11,7 Prozent unter dem des alten. Diese Zahl steht inzwischen unter einem Vorbehalt, der alles an ihr verändert: Sie wurde in einem Zustand gemessen, den es nicht mehr gibt.

Sieben nutzbare Karten, ein einziger Speicherkanal je CPU, Kartengruppen quer über beide Sockel, ein defektes Kabel im Aufbau und zwei drosselnde Karten: Unter diesen Bedingungen war die Messung eine Momentaufnahme der Baustelle, keine Aussage über die Plattform.

Nach der Sanierung erreichen beide Cluster über 120 tok/s und liegen damit auf dem Niveau des alten Rigs. Eine Einzelmessung im Kurzlauf ergab 120,69 tok/s gegen früher 124,29 — 2,9 Prozent Unterschied. Bei einer Streuung von ±13 tok/s ist das kein nachweisbarer Effekt — und eine einzelne Messung bleibt es ohnehin.

Der Vollständigkeit halber die ursprüngliche Messreihe. Verglichen wurde gegen das Vorgängerboard — ein Einzelsockel-System mit einem EPYC 7443P der Zen3-Generation und fünf bestückten Speicherkanälen — mit demselben Modell, denselben Karten und byteidentischer Konfiguration: 555 von 555 Startargumenten gleich, nur der Zufalls-Seed unterschied sich. Das alte Rig kam in der Produktion über 15 Läufe auf einen Median von 114,09 tok/s, das neue im defekten Zwischenzustand über 21 Läufe auf 100,74 tok/s. Diese Zahlen beschreiben das Rig vor dem Speicherausbau, vor der Umverkabelung und mit drei fehlenden Karten; als Plattformvergleich taugen sie nicht.

Was aus der Reihe bleibt, ist die Messdisziplin. Über 54 Einzelläufe streuen die Werte zwischen 71,98 und 122,32 tok/s, bei einer Standardabweichung von 11,20 tok/s. Wer drei Läufe je Konfiguration misst, hat einen Standardfehler von rund 6,5 und ein Vertrauensintervall von ±13 tok/s. Effekte unter 15 Prozent sind darin unsichtbar. Ende August haben wir trotzdem mehrfach aus Dreierstichproben Ursachen abgeleitet, die sich später als Streuung herausstellten. Seitdem gilt für dieses Rig: mindestens 10 bis 15 Läufe je Konfiguration, bei kontrolliert gleicher Ausgangstemperatur.

Die Erklärung, an der wir am längsten hingen, war die CPU-Generation. Zen2 hat konstruktionsbedingt eine höhere Speicherlatenz als Zen3, der Boost-Takt liegt niedriger, und bei rund 22.000 Runden über den Hauptspeicher je Sekunde sollte sich das bemerkbar machen. Wir haben ernsthaft über einen Tausch auf zwei CPUs der 7003-Serie nachgedacht. Diese Erklärung wird nicht mehr gebraucht: Sie sollte die 11,7 Prozent deuten, und die gibt es nicht mehr. Die architektonischen Unterschiede zwischen den beiden Generationen bleiben real, in diesem Lastprofil kosten sie offenbar nichts Messbares. Der CPU-Tausch ist damit vom Tisch.

Ausprobiert und verworfen haben wir auf dem Weg dorthin einiges:

Stand heute

Zehn Karten in Betrieb, alle mit voller Anbindung, kein Treiberfehler im Protokoll: vier ASUS, drei Gigabyte, drei NVIDIA Founders, darunter eine 3090 Ti. Neun hängen an der zweiten CPU, eine steckt noch an der ersten. Sie umzuziehen steht auf der Liste, denn solange sie dort sitzt, würde ein Modell über alle zehn Karten zwangsläufig die Sockelgrenze überschreiten.

Was ein Sockelübergang wirklich kostet, wissen wir bis heute nicht. Der Messplan steht: Zwei Karten bleiben in beiden Konfigurationen dieselben, damit der Sockelwechsel die einzige Variable ist, mindestens zehn Läufe je Seite bei gleicher Ausgangstemperatur und mit Temperaturprotokoll.

Offen ist außerdem das Gehäuse. Solange die Karten im alten Rahmen so eng stehen, ist die elfte Karte keine gute Idee; die beiden Karten, die unter Dauerlast gedrosselt haben, waren die Warnung. Der Ausbau geht deshalb in dieser Reihenfolge weiter: erst Aluminium und Abstand, dann Karten.