Wenn die GPU vom Bus überfahren wird: Strom, Hitze und andere Lektionen aus unserem 8×3090-Rig

NVIDIA hat für einen Totalausfall auf dem PCIe-Bus eine bemerkenswert bildhafte Formulierung: GPU has fallen off the bus. In unseren Logs erschien die etwas technischere Variante NVRM: GPU lost from the bus [NV_ERR_GPU_IS_LOST]. Inhaltlich meinen beide dasselbe. Eine Grafikkarte, die eben noch Teil eines acht GPUs großen Verbunds war, ist für das Betriebssystem plötzlich nicht mehr erreichbar.

Im Deutschen klingt es fast so, als sei die GPU nicht vom Bus gefallen, sondern von ihm überfahren worden. Nach mehreren Wochen Fehlersuche fühlte sich diese Übersetzung jedenfalls angemessen an.

Im ersten Teil dieser Serie beschreiben wir, wie wir sieben RTX 3090 und eine RTX 3090 Ti auf einem Supermicro H12SSL-i untergebracht und mit vier Netzteilen versorgt haben. Dieser zweite Teil beginnt dort, wo ein Aufbauartikel gewöhnlich endet: Der Rechner bootet, nvidia-smi zeigt acht Karten, das Modell lädt – und trotzdem ist das System noch lange nicht stabil.

Die Steckdose sieht das ganze Rig

GPU-Telemetrie ist nützlich, erfasst aber nicht den gesamten Rechner. Sie zeigt weder den Wirkungsgrad der Netzteile noch den Verbrauch von CPU, Mainboard, Arbeitsspeicher, Lüftern und Laufwerken. Deshalb messen wir die Leistungsaufnahme mit einem Tasmota-Strommesser vor dem kompletten Rig. Die Messwerte laufen über MQTT in unser Monitoring.

Im Leerlauf nimmt das System ungefähr 450 Watt auf. Während der Inferenz springt die Kurve je nach Modellbelegung, Promptphase und Parallelität deutlich nach oben. Kurze Spitzen reichen bis ungefähr 3.100 Watt. Das Diagramm zeigt einen normalen Arbeitstag: längere Phasen mit laufenden Modellen, Unterbrechungen, wechselnde Lasten und dazwischen die gut sichtbare Idle-Basis.

Die beiden Einheiten verdienen eine saubere Trennung. Watt beschreibt die momentane Leistung. Kilowattstunden messen die über einen Zeitraum bezogene Energie. Über die letzten sieben Tage lag unser Durchschnitt bei 19,754 kWh pro Tag. Auf 24 Stunden verteilt entspricht das einer mittleren Dauerleistung von rund 823 Watt:

19,754 kWh / 24 h = 0,823 kW ≈ 823 W

Schon der Leerlaufanteil ist beträchtlich. Würde das Rig 24 Stunden ohne Modelllast bei 450 Watt durchlaufen, ergäbe das 10,8 kWh pro Tag. Der Sieben-Tage-Wert enthält darüber hinaus die produktiven Inferenzphasen. Für Stromkosten lässt sich daraus leicht mit dem eigenen Tarif weiterrechnen; wir verzichten bewusst auf einen Eurobetrag, der je nach Vertrag und Standort schnell irreführend wäre.

Die 3,1-kW-Spitzen sind ebenfalls kein theoretischer Wert aus acht GPU-TDPs, sondern am Gesamtanschluss beobachtete kurze Ereignisse. Gerade solche Lastwechsel sind für die Stromverteilung relevant. Ein Netzteil kann auf dem Typenschild großzügig dimensioniert wirken und trotzdem in einer konkreten Gruppierung, mit bestimmten Kabeln und transienten Lasten Probleme zeigen.

Vier Netzteile – und trotzdem ein Stromproblem

Unser Aufbau verteilt die zusätzlichen 6-/8-Pin-Anschlüsse der GPUs heute auf vier Quellen. Das 1200-W-ATX-Netzteil versorgt außerdem Mainboard, CPU und den Slotstrom aller acht Karten. Ein HP-Netzteil mit 1200 Watt hängt an drei GPUs, das 1600-W-HP-Modul an drei weiteren und ein vorhandenes 750-W-HP-Netzteil an der letzten Karte.

Diese Verteilung ist das Ergebnis einer Fehlersuche. Ursprünglich lagen die zusätzlichen Anschlüsse von vier GPUs am 1600-W-Servernetzteil. Sporadisch meldete sich eine Karte aus dem Verbund ab. Das Fehlerbild deutete zunächst auf die Datenverbindung: Riserkontakt, PCIe-Adapter, Busfehler oder Treiber waren plausible Kandidaten. Schließlich verschwand aus Sicht des Betriebssystems eine PCIe-Komponente. Warum sollte ausgerechnet das Netzteil schuld sein?

Die Umverteilung einer GPU auf das noch vorhandene 750-W-HP-Modul beseitigte genau dieses Fehlerbild. Daraus folgt keine allgemeine Regel, nach der ein 1600-W-Netzteil grundsätzlich keine vier RTX 3090 versorgen könnte. Belegt ist etwas engeres und für uns praktisch Wichtigeres: Dieser Versorgungszweig war in unserer damaligen Verkabelung und Lastverteilung nicht stabil. Nach der Entlastung war er es.

Die Episode zeigt, warum die Summe der Nennleistungen nur die halbe Geschichte erzählt. Unsere vier Netzteile kommen zusammen auf 4.750 Watt Typenschildleistung. Das Rig zieht nicht dauerhaft 4.750 Watt, und die Zahl sagt nichts darüber aus, wie gleichmäßig die Last auf einzelne Kabel, Breakout-Ausgänge und GPUs verteilt ist. Bei acht Karten sollte deshalb nicht nur die Gesamtsumme stimmen. Auch die Zuordnung muss unter realer Last funktionieren.

Der Sommer ist ein sehr ehrlicher Benchmark

Der erste Rahmen brachte alle Karten schnell in Betrieb, stellte sie aber zu dicht nebeneinander. Im Winter kann ein solcher Aufbau noch unauffällig wirken. Im Sommer steigt die Ansaugtemperatur, und jede GPU erhält einen Teil der Abluft ihrer Nachbarin. Inzwischen stehen mehrere Ventilatoren direkt vor dem Rig. Parallel bauen wir einen neuen Rahmen mit größeren Abständen.

Das thermische Problem lässt sich nicht zuverlässig an einer einzigen Temperatur festmachen. Bei RTX-3090-Karten ist besonders der GDDR6X-Speicher relevant. In einem dokumentierten Fall lag die GPU-Kerntemperatur nur bei ungefähr 76 °C, während der Speicherbereich bereits thermisch begrenzte. Der Kerntakt fiel bis auf 300 MHz. Die Inferenzgeschwindigkeit eines TP4-Qwen-Setups sank dabei von ungefähr 65 auf 17 Token pro Sekunde.

Aus Anwendungssicht ist das ein unangenehmer Fehler: Nichts muss abstürzen. Das Modell antwortet weiter, nur plötzlich viermal langsamer. Wer ausschließlich prüft, ob der Container läuft und alle GPUs in nvidia-smi erscheinen, findet dafür keine Erklärung.

Wir beobachten deshalb mehrere Werte gemeinsam:

• GPU-Kerntemperatur,
• Memory-Junction- beziehungsweise Speichertemperatur, soweit verfügbar,
• aktuellen SM-Takt,
• Leistungsaufnahme je Karte,
• NVIDIA-Throttle-Reasons,
• Inferenzdurchsatz über einen längeren Zeitraum.

Kurze Benchmarks reichen für diese Diagnose nicht aus. Eine Karte kann einen 30 Sekunden langen Test bei vollem Takt absolvieren und erst nach langem Prefill oder mehreren Minuten Decode thermisch einbrechen. Für unsere Praxis ist ein echter Agentenlauf oder ein 100k-Kontext-Test deshalb oft aussagekräftiger als ein kurzer Prompt mit 256 Ausgabetokens.

Power-Limits: wenig Verlust, mehr Reserve

Als Sicherheitsnetz betreiben wir die RTX 3090 mit einem Power-Limit von ungefähr 250 Watt und die RTX 3090 Ti mit ungefähr 300 Watt. Ein systemd-Dienst setzt diese Werte beim Booten erneut, weil Power-Limits einen Neustart nicht automatisch überleben müssen.

Die Auswirkung auf unsere gemessene Inferenzleistung ist kleiner als die Differenz der Wattzahlen vermuten lässt. Im Single-Stream-Betrieb war praktisch kein Verlust messbar: ungefähr 82,4 statt 83 Token pro Sekunde in der betreffenden Konfiguration. Unter vier parallelen Streams kostete das Limit rund vier Prozent. Gleichzeitig blieb eine Problemkarte ungefähr acht Grad kühler.

Der Grund liegt im Workload. Decode großer LLMs ist auf diesen Karten häufig durch Speicherbandbreite und Kommunikation begrenzt, nicht durch dauerhaft maximalen GPU-Core-Takt. Das Power-Limit kappt vor allem kurze Prefill- und Lastspitzen. Es ersetzt weder Luftstrom noch gute Kontakte, schafft aber thermische und elektrische Reserve zu sehr geringen Kosten im Durchsatz.

Diese Werte sind Messungen auf unserem Rig, keine allgemeine Garantie für jede 3090 und jedes Modell. Andere Kernels, längere Prefill-Phasen oder rechenintensivere Workloads können anders reagieren. Die Kombination aus Temperatur, Takt und tatsächlicher Tokenrate bleibt der Maßstab.

Wenn Kabel auf Kabel drücken

Der hartnäckigste Busfehler saß an GPU 2, physisch in SLOT4 mit der PCI-Adresse 42:00.0. Unter Multi-Agent-Last sammelte diese Position zunächst PCIe-AER-Fehler. Später verschwand die Karte vollständig vom Bus. Weil sich ein solcher Ausfall von der Softwareseite aus dramatisch äußert, begann auch die Fehlersuche zunächst dort.

Wir testeten verschiedene KV-Konfigurationen, Treiberpfade und Parallelisierungsvarianten. Die Stromverteilung wurde verändert. Das PCIe-Datenkabel wurde mit einer anderen Position getauscht. Schließlich tauschten wir sogar die GPU-Karte selbst. Der Fehler blieb an der Position. Damit waren Modell, Quantisierung und konkrete GPU als Ursache weitgehend ausgeschlossen.

Die Lösung war mechanisch: Auf dem Riserkabel dieser Position lag Druck von benachbarten Kabeln. Dieser Druck belastete die Steckverbindung. Unter hoher Last wurde aus dem grenzwertigen Kontakt zunächst ein PCIe-Replay-Problem und schließlich ein Bus-Abwurf. Nachdem wir das Kabel entlastet und die Führung mit kleinen Stützen stabilisiert hatten, lief ein elfminütiger Multi-Agent-Stresstest mit 43 Messpunkten bei drei gleichzeitig aktiven Requests durch. Dabei traten weder neue AER-Fehler noch ein Bus-Abwurf auf, obwohl GPU 2 Leistungsspitzen bis ungefähr 320 Watt erreichte.

Das ist der Grund, weshalb wir bei Riserkabeln nicht zu den billigsten Varianten greifen. Ein voll angebundener PCIe-4.0-Link ist empfindlicher als eine langsame Mining-Verbindung. Teure Riser sind allerdings keine Versicherung gegen schlechte Montage. Kabelradius, Zug, seitlicher Druck und die Abstützung der Stecker bleiben Teil der Konstruktion.

Ein weiterer Fehler war weniger subtil: Ein benötigter x8-zu-x16-Adapter funktionierte schlicht nicht. Solche Adapter waren notwendig, um GPUs an den beiden physischen x8-Anschlüssen passend anzuschließen. Auch hier sah das Systemproblem zunächst größer aus als das defekte Teil. Ein schwarzes Stück Platine besitzt keine Statusseite und schreibt keine hilfreiche Logmeldung. Es sorgt nur dafür, dass an anderer Stelle viel geloggt wird.

Was „vom Bus gefallen” technisch bedeutet

PCI Express besitzt mit AER, dem Advanced Error Reporting, eigene Fehlerzähler. Unter Linux lassen sie sich für eine PCI-Adresse beispielsweise so ansehen:

sudo lspci -s 42:00.0 -vvv | grep 'CESta:'

Bei unserem Riserproblem zeigte sich eine klare Eskalation. Zunächst erschien Timeout+: Ein erwarteter Abschluss beziehungsweise Replay kam nicht rechtzeitig an. Unter weiterer Last folgte Rollover+, der Fehlerzähler war also bereits übergelaufen. Danach konnte die GPU vollständig verschwinden. lspci zeigte dann unter anderem Unknown header type 7f, der Treiber meldete:

NVRM: GPU lost from the bus [NV_ERR_GPU_IS_LOST]

In anderen Absturzketten sahen wir Xid 13 und Xid 154. Diese Codes sind keine vollständige Ursachendiagnose. Sie markieren, an welcher Stelle NVIDIA beziehungsweise der Kernel den Fehler bemerkte. Ein Xid kann durch einen Softwarefehler ausgelöst werden, aber ebenso das Folgeereignis einer instabilen PCIe-Verbindung sein.

Besonders tückisch ist die Zeit vor dem vollständigen Abwurf. nvidia-smi kann noch acht Karten melden, der Container kann als running erscheinen und die API kann ihren Port offen halten. Intern wartet ein Worker bereits auf Daten, die über den fehlerhaften Link nicht mehr rechtzeitig eintreffen. Die Anwendung sieht dann einen RPC-Timeout oder eine tote Engine, obwohl die eigentliche Ursache unterhalb von Docker und vLLM liegt.

Auch die Wiederherstellung hängt von dieser Grenze ab. Ist nur die Inferenz-Engine nach einem Timeout gestorben, genügt häufig ein Neustart des Containers. Fehlt die GPU dagegen im PCIe-Baum oder zeigt lspci den Header 7f, kann Docker nichts reparieren. Dann muss zuerst der mechanische beziehungsweise elektrische Fehler behoben und der Host sauber neu gestartet werden. Nach dem Boot prüfen wir nicht nur, ob acht GPUs wieder in nvidia-smi stehen. Wir kontrollieren auch die AER-Bits und belasten den betroffenen Pfad erneut. Ein System, das im Leerlauf acht Karten aufzählt, hat damit nur die erste Hälfte des Tests bestanden.

Linkbreite ist nicht gleich Linkgesundheit

Bei PCIe-Diagnosen führen zwei scheinbar eindeutige Anzeigen leicht in die falsche Richtung:

1. 2,5 GT/s beziehungsweise Gen1 im Idle: Das kann normales Link-Powersaving sein. Viele unserer GPUs reduzieren im Leerlauf die Verbindungsgeschwindigkeit und trainieren unter Last wieder auf Gen4 hoch.
2. x8 mit dem Zusatz downgraded: SLOT2 und SLOT4 sind auf dem H12SSL-i nativ x8. Manche Werkzeuge vergleichen mit der x16-Fähigkeit der GPU und nennen x8 deshalb „downgraded”, obwohl der Slot genau so ausgelegt ist.

Entscheidend ist der Zustand unter Last. Wir prüfen deshalb nicht nur LnkSta, sondern übertragen Daten gezielt zu jeder GPU. Ein gesunder Link lag in unseren Tests in der Größenordnung von 25 GB/s. Ein fehlerhafter Pfad brach auf ungefähr 0,08 GB/s beziehungsweise 80 MB/s ein. Der Rechner stürzte dabei nicht zwingend ab. Der gesamte Pipelineverbund wurde lediglich auf die Geschwindigkeit seiner langsamsten Stufe reduziert. Eine Inferenz, die vorher ungefähr 80 Token pro Sekunde erreichte, fiel in einem solchen Fall auf etwa drei.

Für Multi-GPU-Systeme ist ein individueller H2D-Bandbreitentest deshalb eines der wertvollsten Diagnosewerkzeuge. Er beantwortet eine einfache Frage: Erreicht jede GPU über ihren tatsächlichen Pfad eine plausible Host-to-Device-Rate? Durchschnittswerte über alle Karten können einen einzelnen defekten Link verbergen.

Unser Dashboard: nicht nur hübsche Balken

Mit acht GPUs, vier Netzteilen und mehreren Modellen wird die Kommandozeile schnell unübersichtlich. Wir haben deshalb ein Dashboard gebaut, das den Zustand des gesamten Rigs zusammenführt. Es zeigt CPU, RAM, Speicherplatz, belegten VRAM, Gesamtleistung, Temperaturen, GPU-Auslastung, PCIe-Linkstatus, AER-Markierungen und die aktuelle Modellverteilung. Modelle lassen sich darüber außerdem bequem starten und stoppen.

Die gezeigte Momentaufnahme ist ein gutes Beispiel für einen produktiven Zustand: Das Rig zieht insgesamt ungefähr 1.958 Watt, 187,7 von 192 GB VRAM sind belegt und alle acht GPUs arbeiten. Qwen3.6-27B-FP8 nutzt die GPUs 0, 1, 2 und 5; Laguna S 2.1 liegt auf 3, 4, 6 und 7. Die Kerntemperaturen reichen ungefähr von 57 bis 73 °C.

Gleichzeitig meldet der PCIe-Bereich Fehlerbits für vier GPUs. Das bedeutet nicht automatisch, dass gerade vier Karten ausfallen. AER-Bits können nach einem Ereignis gesetzt bleiben. Wichtig sind Veränderung und Lastbezug: Kommt ein neues Timeout+ hinzu? Geht eine Position auf Rollover+? Steigt der Zähler genau dann, wenn mehrere Requests gleichzeitig laufen? Das Dashboard macht solche Zusammenhänge sichtbar, ersetzt aber nicht ihre Interpretation.

Auch die bei GPU 2 sichtbare aktive Breite von x4 ist eine Beobachtung, keine Mainboard-Spezifikation. SLOT4 ist nativ x8 angebunden. Eine unter Last ausgehandelte geringere Breite gehört deshalb auf die Prüfliste. Genau für solche Abweichungen zeigt das Dashboard aktive und maximal gemeldete Linkbreite getrennt an.

Die Modellplatzierung ist ebenfalls mehr als Inventar. Wenn eine Vierergruppe langsamer wird, können wir sofort sehen, welche physische Karte, welcher Slot und welches Modell beteiligt sind. Damit verbindet das Dashboard drei Ebenen, die bei der Fehlersuche sonst getrennt erscheinen: Anwendung, GPU-Telemetrie und PCIe-Hardware.

P2P: Die naheliegende Optimierung, die alles schlimmer machte

Unser Rig besitzt kein NVLink, und die acht GPUs verteilen sich über vier PCIe-Root-Complexes. Der intuitive Gedanke lautet, Peer-to-Peer-Zugriffe zwischen den Karten freizuschalten, damit Daten nicht über Host-Speicherpfade laufen müssen. Wir haben dafür einen gepatchten NVIDIA-Open-Treiber getestet, der GeForce-P2P als verfügbar meldete.

Das Ergebnis war schlechter als ein sauber deaktivierter P2P-Pfad. Über die Root-Complex-Grenzen lieferten BAR1-Transfers teilweise Nullen. Bei vLLM entstanden Hänger und Engine-Abstürze; bei einem ik_llama-Pfad zeigte sich korrupter Output mit Nullbytes. Ein Topologietest konnte „P2P OK” melden, während die transportierten Daten unbrauchbar waren.

Unser produktiver Weg verwendet deshalb den proprietären Stock-Treiber 580.126.20 und vermeidet P2P bewusst. Für vLLM gehören dazu unter anderem:

NCCL_P2P_DISABLE=1
NCCL_CUMEM_ENABLE=0
VLLM_ALLREDUCE_USE_SYMM_MEM=0
--disable-custom-all-reduce

Der letzte Schalter ist wichtig, weil vLLMs eigener Custom-All-Reduce-Pfad nicht allein durch NCCL_P2P_DISABLE=1 gestoppt wird. Auf einer anderen Topologie mit PCIe-Switches oder professionellen GPUs kann P2P sinnvoll sein. Auf unserem Vier-Root-Complex-GeForce-Rig ist der robuste Host-/NCCL-Pfad die bessere Wahl.

Eine zweite Treiberlektion war ebenso konkret: Nach jedem Treiberwechsel rebooten wir den Host vollständig. Live-Wechsel per modprobe -r und erneutem Laden hinterließen GPU-, UVM-, DMA- oder BAR-Zustände, bei denen vLLM noch plausibel arbeitete, rohe Host-Staging-Pfade aber deterministisch korrupte Tokens erzeugten. Ein sauberer Neustart reparierte das. nvidia-smi allein hatte den inkonsistenten Zustand nicht verraten.

Nicht jedes langsame System hat ein GPU-Problem

Während der Arbeit am Rig fiel außerdem die Netzwerkverbindung zeitweise von Gigabit auf 100 Mbit/s zurück und wechselte zwischen beiden Geschwindigkeiten. Ursache war ein defektes Kabel an eno1. Nach dem Austausch gegen ein Cat6-Kabel liefen Modellkopien wieder mit ungefähr 112 MB/s.

Für die reine Decode-Rate eines bereits geladenen Modells war das nicht der zentrale Engpass. Für Downloads, Modellstarts und verteilte Arbeitsabläufe fühlte sich das System dennoch unnötig langsam an. Diese Nebenepisode passte gut zum restlichen Projekt: Bei einem komplexen Rig ist die auffälligste Komponente nicht automatisch die schuldige.

Der zweite Rahmen wird weniger fotogen – und besser

Unser nächster Aufbau bekommt mehr Abstand zwischen den GPUs, klarere Kabelwege und feste Entlastungspunkte für die Riser. Die Ventilatoren sollen Luft durch definierte Zwischenräume bewegen, statt gegen eine nahezu geschlossene Wand aus Backplates zu arbeiten. Netzteilgruppen und GPU-Positionen werden so beschriftet, dass sich eine Warnung aus dem Dashboard direkt zu Kabel, Breakout-Ausgang und physischem Slot verfolgen lässt.

Das Monitoring bleibt Teil der Konstruktion. Temperaturen, Takt und Tokenrate zeigen thermische Probleme; AER-Zähler und Bandbreitentests zeigen die Gesundheit der PCIe-Pfade; der Tasmota-Zähler erfasst das Verhalten des gesamten Systems. Keine dieser Messungen genügt allein. Zusammen machen sie aus acht gebrauchten Grafikkarten ein betreibbares Rechensystem – und halten sie hoffentlich weit genug von jenem Bus fern, unter den NVIDIA sie so gern fallen lässt.