DGX B200: Viel Leistung, hoher Preis für den Standort

Rund 14,3 kW pro System, 1.440 GB GPU-Speicher und 144 PFLOPS bei FP4: Die Datenblattwerte des NVIDIA DGX B200 sind eindeutig. Die Beschaffungsentscheidung fällt trotzdem an Stromkreis, Kühlung und gemessener Auslastung.

Das Wichtigste in Kürze

Verwandt: Der Kapazitätsdruck im Markt trifft dieselben Fragen aus der Einkaufsperspektive. Wer Compute mietet statt kauft, verlagert die Strom- und Kühlfrage zum Anbieter. In der eigenen Kalkulation bleibt sie als Preisbestandteil trotzdem stehen.

14,3 kW sind eine Gebäudefrage, keine IT-Frage

Die Leistungsangabe ist der Punkt, an dem die meisten Planungen kippen. Rund 14,3 kW für ein einzelnes System bedeuten, dass ein Rack mit zwei oder drei Einheiten bereits jenseits dessen liegt, was klassische Colocation-Verträge pro Höheneinheit vorsehen. Viele bestehende Verträge sind auf 5 bis 10 kW pro Rack ausgelegt. Wer drei DGX-Systeme plant, holt sich die Zusage des Betreibers vor der Bestellung schriftlich ein. Eine mündliche Auskunft aus dem Vertriebsgespräch trägt diese Investition nicht.

Dazu kommt die Frage der Zuleitung. 14,3 kW wollen redundant versorgt werden, wenn der Betrieb den Ausfall eines Strangs überstehen soll. Der Verbrauch bleibt dabei gleich, der Anspruch an die Verteilung steigt deutlich. Wer sich hier allein auf eine A-Seite verlässt, betreibt eine Hoffnung und kein Redundanzkonzept. Für die USV-Auslegung gilt dasselbe: Die Anlaufspitzen eines vollbestückten GPU-Systems folgen keinem linearen Verlauf.

Die Wärme geht denselben Weg. Praktisch jedes Watt elektrische Leistung landet als Abwärme im Raum. Bei 14,3 kW pro System ist Luftkühlung möglich, sie braucht dafür aber eine ordentliche Kaltgang-Einhausung und ausreichend Volumenstrom. Wer mehrere Systeme in benachbarte Racks stellt, lässt die Temperaturverteilung im Bestand vor der Bestellung messen. Ein einzelner Hotspot im Kaltgang kostet mehr Performance, als jede Treiberoptimierung zurückholt.

1.440 GB Speicher sind der interessantere Wert

Für Entwickler und Plattformteams ist der GPU-Speicher relevanter als die Rechenleistung. 1.440 GB über acht GPUs hinweg bedeuten, dass große Modelle in ein einziges System passen, ohne über mehrere Knoten verteilt zu werden. Das klingt nach einem Detail, markiert aber den Unterschied zwischen einem überschaubaren Deployment und einem verteilten Setup mit Kommunikations-Overhead, zusätzlichen Fehlerquellen und einem Betriebsteam, das Netzwerktopologien debuggen muss.

Die 64 TB/s Speicherbandbreite stützen denselben Punkt. Bei Inferenzlasten mit großen Modellen ist die Bandbreite häufig die begrenzende Größe. Die reine Rechenleistung steht dann bereits zur Verfügung und wartet auf Daten. Wer heute mit Batch-Größen kämpft, weil der Speicher knapp ist, bekommt hier den direkteren Nutzen als aus jeder FLOPS-Angabe.

Was 144 PFLOPS tatsächlich bedeuten

Die Spitzenzahl gilt für FP4, also eine sehr niedrige Präzisionsstufe. Das ist für Inferenz mit quantisierten Modellen relevant und dort auch legitim. Für Training in höherer Präzision fällt der Wert deutlich ab. Wer Vergleichstabellen zwischen Generationen oder Anbietern liest, prüft bei jeder Zahl die Präzisionsstufe mit. Ohne diese Angabe bleibt ein PFLOPS-Wert reines Marketing.

Dasselbe gilt für die genannten Faktoren: dreifache Trainings- und 15-fache Inferenzleistung gegenüber der Vorgängergeneration. Beide Werte stammen vom Hersteller und beziehen sich auf definierte Workloads. Ob die eigene Last diesem Profil ähnelt, entscheidet, ob der Faktor in der Praxis ankommt. Ein Team mit vielen kleinen Modellen und unregelmäßiger Nachfrage sieht davon wenig.

Netzwerk und Softwarestack entscheiden über die Anlaufzeit

Ein DGX-System ist keine Insel. Trainingsdaten müssen ankommen, Checkpoints müssen weg. Wer die Speicheranbindung nicht auf das Leistungsniveau der GPUs auslegt, betreibt teure Rechenleistung im Wartezustand. Vor der Beschaffung gehört deshalb die Frage geklärt, ob die vorhandene Storage-Infrastruktur den Durchsatz liefert, den acht GPUs gleichzeitig anfordern. In vielen Bestandsumgebungen lautet die ehrliche Antwort: nein. Die Nachrüstung kostet dort einen relevanten Teil des Hardwarebudgets.

Der Softwarestack ist der zweite Zeitfresser. CUDA-Versionen, Treiberstände, Container-Images und Framework-Kompatibilität bestimmen, wie viele Wochen zwischen Anlieferung und produktiver Last liegen. Wer bestehende Pipelines migriert, prüft die Versionsmatrix früh. Ein Modell, das auf der Vorgängergeneration lief, benötigt auf der neuen Plattform in der Regel angepasste Versionsstände. Diese Bindung an den Stack ist übrigens der Grund, warum Hardware dieser Klasse weniger austauschbar ist, als Finanzierungsmodelle gern unterstellen.

Die Auslastungsfrage ist die wirtschaftliche Frage

Ein System dieser Klasse rechnet sich über die Auslastung. Der Anschaffungspreis ist dabei nur der Einstiegsposten. Bei rund 14,3 kW Dauerlast entstehen laufende Energiekosten, die über eine mehrjährige Nutzungsdauer eine eigene Größenordnung erreichen. Diese Kosten fallen unabhängig davon an, ob die GPUs rechnen oder im Leerlauf stehen, wenn auch in unterschiedlicher Höhe. Wer keine belastbare Prognose über die dauerhafte Nachfrage im eigenen Haus hat, kauft ein Auslastungsrisiko.

Die ehrliche Vorabprüfung besteht aus drei Punkten. Erstens: Wie viele GPU-Stunden verbraucht das Team heute tatsächlich, gemessen und nicht geschätzt? Zweitens: Wie verteilt sich diese Last über Tage und Wochen, gibt es also Spitzen mit langen Leerlaufphasen? Drittens: Was kostet dieselbe Kapazität gemietet, inklusive der Betriebsarbeit, die im eigenen Rechenzentrum anfällt? Wer diese drei Zahlen nicht hat, verschiebt die Beschaffung und misst zuerst.

Die Frageliste vor der Bestellung

Sechs Punkte gehören geklärt, bevor eine Bestellung rausgeht. Trägt der Stromkreis 14,3 kW pro System redundant? Ist die Kühlleistung im Zielrack gemessen oder nur kalkuliert? Liefert die Storage-Anbindung genug Durchsatz für acht GPUs unter Volllast? Passt der geplante Workload zur FP4-Spitzenleistung oder rechnet das Team in höherer Präzision? Existiert eine Versionsmatrix für den bestehenden Softwarestack? Und gibt es gemessene Auslastungsdaten aus dem laufenden Betrieb statt der Prognose aus dem Projektantrag?

Wer alle sechs Punkte beantworten kann, hat eine belastbare Entscheidungsgrundlage. Wer bei zwei oder mehr Punkten passen muss, schließt zuerst diese Lücken. Die Spezifikationen sind eindeutig. Die Konsequenzen für den eigenen Betrieb bleiben offen. Genau dort liegt die Arbeit.

Drei Prüfungen mit klarem Stop-Signal

Die sechs Fragen oben lassen sich auf drei Prüfungen verdichten, die vor der Bestellung abgeschlossen sein sollten. Jede hat ein Ergebnis, bei dem die Beschaffung wartet statt weiterläuft.

Häufige Fragen

Bildquelle: KI-generiert (August 2026)