Wenn man über die NVIDIA DGX Spark spricht, fallen meist zuerst zwei Dinge. Zum einen die herausragende Spezifikation: 128 GB Arbeitsspeicher in einem Desktop-PC für rund 4,000 US-Dollar – eine Leistung, die vor zwei Jahren noch undenkbar gewesen wäre. Zum anderen das 200-GB-Netzwerk auf der Rückseite. Die Integration eines echten Rechenzentrums-Netzwerks in ein Desktop-Gerät weckt großes Interesse, denn sie impliziert mehr als nur eine schnellere Workstation. Sie ermöglicht die Vernetzung mehrerer Sparks und die physische Replikation – eine Multi-Node-Konfiguration, die bisher ausschließlich in Racks zu finden war.
Diese Studie untersucht diese Fähigkeit. Wir vergleichen die verteilte Inferenz auf allen drei uns vorliegenden OEM-Spark-Implementierungen. Diese sind in Zwei-Knoten-Clustern über ein 200-GbE-Netzwerk verbunden und werden mit verschiedenen Modellvarianten und drei Workload-Formen getestet. Wir treffen zudem eine bewusste methodische Entscheidung hinsichtlich der Modellverteilung auf die beiden Systeme, die von NVIDIAs Standardempfehlung abweicht, und begründen diese mit Daten. Zuvor sind jedoch zwei Kontextfaktoren entscheidend für alles Folgende: das Netzwerk, das Clustering überhaupt erst ermöglicht, und die Gründe für oder gegen dessen Einsatz.
Das 200 GB Fabric
Die Netzwerkimplementierung haben wir bereits in unserem ursprünglichen Test des DGX Spark ausführlich behandelt. Die Grundlagen sind jedoch wichtig und sollten hier noch einmal erläutert werden, da alles in diesem Test darauf aufbaut. Jedes Spark-Gerät verfügt auf der Rückseite über zwei QSFP56-Steckplätze, die von einer integrierten NVIDIA ConnectX-7 SmartNIC angesteuert werden. Theoretisch ermöglichen die beiden Steckplätze eine Gesamtkapazität von 400 Gbit/s, die tatsächliche Obergrenze liegt jedoch bei PCIe: Die ConnectX-7 ist an zwei Gen5 x4-Anschlüsse angebunden, und die Plattform erreicht maximal 200 Gbit/s nutzbare Bandbreite, unabhängig von der Verkabelung der Steckplätze. Ein einzelner bestückter QSFP56-Steckplatz bietet bereits die vollen 200 Gbit/s, die das Gerät unterstützt. Der zweite Port dient daher eher der Flexibilität der Netzwerktopologie als der Erhöhung des Durchsatzes.
Diese Flexibilität zeigt sich in drei gängigen Konfigurationen. Die einfachste ist ein einzelner 200-GB-Port, der als direkte Spark-zu-Spark-Verbindung dient. Dies entspricht der von NVIDIA validierten Zwei-Knoten-Konfiguration und wurde auch für diesen Test verwendet. Die zweite Konfiguration besteht aus zwei 100-GB-Ports, die eine ringförmige Topologie zwischen den Sparks bilden, um ohne Switch ein Cluster zu realisieren. Die dritte Konfiguration ist eine Split-Role-Konfiguration, bei der ein Speicherbereich mit einem anderen Spark für das Clustering verbunden ist, während der andere über NVMe-oF auf Hochgeschwindigkeitsspeicher zugreift. Dies ist hilfreich, wenn die Arbeitsdaten nicht auf den internen NVMe-Speicher des Spark passen.
NVIDIA bietet den Spark in drei Konfigurationen an, die sich direkt an der Netzwerknutzung orientieren. Ein einzelner Spark für den individuellen Desktop-Einsatz, ein validierter Zwei-Spark-Cluster mit direkter 200-GbE-Verbindung für erweiterte Modelle und seit der GTC dieses Jahres eine Vier-Einheiten-Konfiguration, die NVIDIA aufgrund der Nutzernachfrage nach einer Erweiterung der Zwei-Knoten-Grenze öffentlich vorstellte. Die Dual-Spark-Konfiguration wird von NVIDIA aktiv vermarktet, von den meisten Lesern eingesetzt und stellt unserer Ansicht nach die sinnvolle Obergrenze für produktive Inferenzanwendungen auf dieser Hardware dar. Sie dient auch als Grundlage für die umfassenden Benchmarks in diesem Test.
Warum überhaupt Clusterfunken?
Der offensichtliche Grund für die Clusterung von Spark ist derselbe wie bei jedem anderen Cluster: Ein einzelner Server mit 128 GB Speicherplatz reicht nicht für alle relevanten Modelle aus. Die Verteilung eines Modells mit 120 Milliarden Parametern auf zwei Server ermöglicht die Ausführung einer neuen Klasse von Workloads, die sonst nicht möglich wären. Dies ist der wichtigste Anwendungsfall und wird am häufigsten in Demos vorgeführt.
Der weniger offensichtliche, aber für NVIDIAs tatsächliche Kundenbasis auf dieser Plattform wohl wichtigere Grund ist das Lernen. NVIDIA positioniert Spark als Einstiegspunkt. Die offizielle Dokumentation , Beispiel-Notebooks und Partner-Playbooks behandeln das Gerät als Lernwerkzeug. Sie enthalten erstklassige Anleitungen für alles – vom Starten eines vorgefertigten Modells über eine lokale Chat-Oberfläche bis hin zum Ausführen eines Programmierassistenten auf einem gehosteten Endpunkt, dem Feinabstimmen kleiner Modelle und dem Erstellen von End-to-End-Anwendungen in PyTorch und JAX. Die Idee dahinter: Selbst jemand, der noch nie einen CUDA-Kernel geschrieben hat, kann innerhalb eines Wochenendes von Null auf einen funktionierenden KI-Workflow am Schreibtisch gelangen. Dasselbe gilt für Ingenieure außerhalb des ML-Bereichs, die eine in sich geschlossene Sandbox benötigen, die sie vollständig kontrollieren können. Ein Cluster mit zwei Spark-Kernen erweitert diese Lernumgebung auf Multi-Node-Systeme: Dieselbe Person kann nun auch lernen, wie Tensor-Parallelität, Pipeline-Parallelität und Bibliotheken für kollektive Kommunikation in einem realen Netzwerk funktionieren, das echte Engpässe aufdeckt.
Was in NVIDIAs Positionierung jedoch auffällig fehlt, ist die Aussage, dass Spark für produktive Inferenzprozesse geeignet ist. Jensen hat in fast jeder Keynote der letzten Jahre über Hardware-Software-Co-Design gesprochen, und dieses Prinzip gilt auch hier. Jede NVIDIA-Plattform ist für eine bestimmte Arbeitslast optimiert, und Spark ist für individuelle Exploration und Lernen optimiert, nicht für die Verarbeitung von Datenverkehr. Unsere vorherigen Spark-Tests haben bereits gezeigt, dass die Plattform bei den meisten Inferenzaufgaben stark durch die Speicherbandbreite begrenzt ist, und das Netzwerk verstärkt diese Einschränkung noch, sobald Clustering erfolgt. Eine einzelne 200-Gb-Verbindung ist zwar für einen Desktop beeindruckend, aber deutlich langsamer als eine PCIe-Gen5-x16-Verbindung innerhalb eines einzelnen Gehäuses. Und kollektive Kommunikationsmuster, die über ein NVLink-verbrücktes Paar von Rechenzentrums-GPUs reibungslos funktionieren, lassen sich nicht ohne erhebliche Latenzeinbußen auf ein 200-Gb-Netzwerk übertragen.
Das ist der eigentliche Grund, warum NVIDIA die offiziell unterstützte Konfiguration so lange auf zwei Sparks beschränkt hat und warum die Demonstration mit vier Einheiten auf der GTC eher eine Reaktion auf die Nutzernachfrage als eine organische Produkterweiterung war. Nichts hindert den Software-Stack daran, auf vier oder acht Knoten zu laufen, und mehrere Nutzer und Medien haben Ergebnisse von größeren Clustern veröffentlicht. Die Leistungswerte dieser Experimente sind im Allgemeinen nicht schmeichelhaft: Die Infrastruktur zwischen den Knoten wird zum dominierenden Kostenfaktor, die Gesamtleistung sinkt rapide, und darüber hinaus kann der Durchsatz pro Nutzer bei den kleinsten Konfigurationen in den einstelligen Token-pro-Sekunde-Bereich fallen – und zwar für jedes Modell, das groß genug ist, um den Cluster überhaupt zu rechtfertigen. An diesem Punkt ist das Setup eher ein Lernlabor als eine leistungsfähige Plattform.
Nichts davon soll abwertend gemeint sein. Das Clustering von Sparks ist eine hervorragende Methode, um ein intuitives Verständnis für verteiltes Inferenz- und Trainingsverfahren zu entwickeln, das sonst nur durch teure Rechenzentrumshardware zugänglich ist. Der Lerneffekt, Pipeline-Blasen, All-Reduce-Engpässe und Parallelisierungs-Kompromisse auf einem eigenen System zu beobachten, ist enorm. Unser Folgeprojekt sah vor, ein kleines Modell mit einer oder weniger als einer Milliarde Parametern von Grund auf auf einem Dual-Spark-Cluster zu trainieren. Die Konfiguration sollte die Bedingungen eines realen verteilten Pre-Training-Laufs möglichst genau widerspiegeln, um die Einsatzmöglichkeiten dieser Clusterklasse aufzuzeigen. Dieses Projekt ruht derzeit, da wir andere, bereits veröffentlichte Themen bearbeiten und auf die Lieferung unseres neuen 800-Gb-Labor-Core-Switches warten. Wir werden das Projekt wieder aufgreifen, sobald der Laboraufbau abgeschlossen ist.
Im Folgenden konzentrieren wir uns auf den Anwendungsfall, für den die Dual-Spark-Konfiguration am besten zu rechtfertigen ist: die verteilte Inferenz von Modellen, die groß genug sind, um beide Systeme zu benötigen. Die Benchmarks wurden mit allen drei uns vorliegenden OEM-Implementierungen durchgeführt. Bevor wir zu den modellspezifischen Werten kommen, erläutert der nächste Abschnitt, warum wir diese Werte unter einer Pipeline-parallelen Konfiguration und nicht unter der Tensor-parallelen Konfiguration angeben, die in der NVIDIA-Dokumentation standardmäßig verwendet wird.
Performance Testing
Warum wir Pipeline-Parallelität und nicht Tensor-Parallelität melden
Die von NVIDIA veröffentlichten DGX Spark-Anleitungen und der Großteil ihrer Referenzmaterialien beschreiben die Skalierung eines Modells auf zwei Spark-Server mithilfe von Tensorparallelität (TP). TP verteilt jede Matrixmultiplikation auf beide GPUs, sodass jede Schicht gleichzeitig auf beiden Geräten ausgeführt wird. Die Teilergebnisse werden nach jedem Attention- und MLP-Block durch eine All-Reduce-Operation kombiniert. Pipelineparallelität (PP) verfolgt einen anderen Ansatz: Sie teilt das Modell schichtweise in zwei Hälften, platziert die erste Hälfte auf dem einen Server und die zweite Hälfte auf dem anderen. Anschließend werden die Aktivierungen zwischen den beiden Servern gestreamt. Jede Anfrage durchläuft weiterhin das gesamte Modell, aber zu jedem Zeitpunkt führt nur ein Server die Berechnungen für ein bestimmtes Token durch, während der andere den nächsten Microbatch verarbeitet.
Der Kompromiss hängt davon ab, welche Daten über die Leitung übertragen werden. Ein Dual-Spark-Stack verbindet die beiden Systeme über eine ConnectX-7 200-GbE-Verbindung. Diese ist zwar schnell für eine Netzwerkverbindung, aber langsam im Vergleich zur Speicherbandbreite eines einzelnen Spark. Die All-Reduce-Funktion von TP wird zweimal pro Transformer-Schicht ausgeführt. Ein 80-Schichten-Modell mit TP=2 generiert daher 160 Cross-Box-Austausche für jedes einzelne Ausgabetoken, wobei jeder dieser Austausche die nächste Berechnung blockiert. PP=2 übergibt Aktivierungen nur einmal pro Token, und zwar an der Schnittstelle zwischen den beiden Modellhälften. Auf einer 200-GbE-Verbindung mit nicht unerheblicher Latenz ist dieser Unterschied ausschlaggebend.
Unsere Messungen mit dem GPT-OSS-120B bestätigen dies eindeutig. Außerhalb der Batchgröße 1, wo die Arbeitslast zu gering ist, um den Overhead einer der Strategien zu verdecken, übernimmt PP=2 die Führung und behält diese auch bei steigender Parallelität bei. Bei der Arbeitslast „Equal ISL/OSL“ erreicht TP=2 bei einer Batchgröße von 128 252.01 kB/s, während PP=2 auf derselben Hardware auf 554.69 kB/s steigt – ein Vorteil um den Faktor 2.20. Das Szenario „Prefill Heavy“ zeigt ein ähnliches Bild: PP=2 erreicht 310.63 kB/s gegenüber 164.99 kB/s für TP=2. Das Szenario „Decode Heavy“ liegt am nächsten beieinander, aber PP=2 führt weiterhin von Batchgröße 8 bis 64 und gibt den Vorsprung erst bei Batchgröße 128 leicht ab, wo die lange 8-KB-Ausgabe die Pipeline-Kosten erhöht.
TP=2 bietet nur in einem kleinen Bereich Vorteile. Bei einer Batchgröße von 1 liefert TP in jedem Szenario einen kleinen, aber realen Vorteil: 39.55 Token/s gegenüber 28.79 Token/s bei „Equal“, 37.97 Token/s gegenüber 29.60 Token/s bei „Prefill Heavy“ und 39.42 Token/s gegenüber 30.28 Token/s bei „Decode Heavy“. Da nur eine Anfrage in Bearbeitung ist, gibt es keinen zweiten Mikrobatch, der die Pipeline-Stufe im Leerlauf hält. PP zahlt daher in jedem Schritt für einen leeren Slot, während TP beide GPUs für das einzige verfügbare Token nutzen kann. Genau für diesen Anwendungsfall ist die TP-Empfehlung von NVIDIA ausgelegt: interaktives Single-Stream-Serving, bei dem die Latenz der ersten und einzigen Anfrage wichtiger ist als der Gesamtdurchsatz. Bei einer Bereitstellung im Chat-Stil mit einem Benutzer pro Instanz und engen TTFT-Zielen ist TP=2 die richtige Wahl. Dies deckt sich auch mit NVIDIAs Sichtweise auf Spark.
Für Workloads, die Infrastrukturen in großem Umfang bedienen und Batch-Inferenz sowie viele gleichzeitige Anfragen umfassen, ist Pipeline-Parallelität beim Skalieren über mehrere Server hinweg besser geeignet, insbesondere wenn Strategien wie Expert Parallelism nicht zum Einsatz kommen. Das 200-GbE-Fabric kann den Token-basierten All-Reduce-Traffic von TP nicht bewältigen, ohne Rechenkapazität ungenutzt zu lassen. Sobald die Batchgröße 4 oder 8 beträgt, verschwinden die zusätzlichen Kosten von PP im normalen Datenverkehr. Daher werden alle modellbezogenen Werte im weiteren Verlauf dieses Artikels mit TP=1 und PP=2 angegeben. Diese Konfiguration repräsentiert die tatsächliche Leistungsfähigkeit einer Dual-Spark-Bereitstellung unter realen Bedingungen.
Wir haben GPT-OSS-120B bewusst als Beispiel für die TP-vs.-PP-Grafik gewählt, da es die größte Differenz aufweist. Wir möchten jedoch auch zeigen, dass dies nicht für alle Modelle gilt und dass diese Parameter von den Modellparametern abhängen. Llama-3.1-8B-Instruct bei BF16 liefert ein deutlich konservativeres Bild. Das Modell ist klein genug, dass die Berechnung jeder Schicht schnell erfolgt und der gesamte Reduce-Verkehr von TP entsprechend gering ist. Im Gegensatz dazu sind die Koordinationskosten pro Schritt bei PP unabhängig von der Modellgröße fix. Das Ergebnis ist, dass TP=2 über fast den gesamten Batch-Sweep hinweg die Nase vorn hat. Bei Equal ISL/OSL führt TP=2 von Batchgröße 1 (23.2 vs. 13.4 tok/s) bis Batchgröße 32 (388.7 vs. 349.3 tok/s) und verliert die Führung nur bei Batchgröße 64 (524.8 vs. 638.2 tok/s) und Batchgröße 128 (679.2 vs. 1,047.1 tok/s). Prefill Heavy folgt dem gleichen Muster: TP=2 liegt bis Batchgröße 32 vorn, bevor PP=2 bei 64 und 128 die Führung übernimmt. Decode Heavy ist am deutlichsten: TP=2 gewinnt bei jeder Batchgröße und erreicht bei Batchgröße 128 366.7 tok/s gegenüber 330.5 tok/s für PP=2.
Dieses Gegenbeispiel untermauert die zugrundeliegende Mechanik, anstatt sie zu widerlegen. PP=2 ist nur dann im Vorteil, wenn die Batchgrößen hoch genug sind, um die Pipeline vollständig auszulasten und die Kosten der Pipelineblasen vollständig zu amortisieren, und wenn das Modell selbst klein genug ist, dass die All-Reduce-Operationen von TP pro Schicht kostengünstig sind; dieser Wendepunkt verschiebt sich weiter nach hinten. Das Ergebnis für Decode Heavy ist ebenfalls konsistent: Längere Ausgabesequenzen bedeuten mehr Dekodierungsschritte, mehr Pipelineblasen, die sich direkt nacheinander amortisieren, und ein kleineres Zeitfenster für PP, um den Unterschied auszugleichen. Anders ausgedrückt: Dieselbe Physik, die PP bei GPT-OSS-120B mit einer Batchgröße von 128 einen 2.20-fachen Vorteil verschafft, erklärt auch, warum es bei einem 8-B-Modell nur bei den beiden höchsten Batchgrößen gewinnt und nie den Durchlauf mit hohem Dekodierungsaufwand für sich entscheidet.
GPT-OSS-120B
Im Equal ISL/OSL-Vergleich startet Dell bei 67.06 kJ/s und erreicht mit einer Batchgröße von 64 einen Wert von 927.93 kJ/s. GIGABYTE beginnt etwas niedriger mit 65.77 kJ/s, erzielt aber am Ende einen deutlich höheren Wert von 994.53 kJ/s, während HP mit 1,009.75 kJ/s die Spitzengruppe anführt. Der Abstand bleibt über weite Strecken gering, wobei HP ab einer Batchgröße von 32 die Führung übernimmt.
Bei Prefill Heavy steigt der Durchsatz durchweg deutlich stärker an. Dell skaliert von 164.42 TK/s auf 2,097.80 TK/s, GIGABYTE von 162.96 TK/s auf 2,086.72 TK/s, und HP erzielt mit einem Anstieg von 165.95 TK/s auf 2,208.16 TK/s das beste Ergebnis. HP ist bei nahezu allen Chargengrößen führend, während Dell und GIGABYTE eng beieinander liegen, insbesondere bei Chargengrößen von 32 und 64.
Bei der Dekodierlast ist die Gesamtleistung erwartungsgemäß geringer. Dell erreicht Werte zwischen 41.20 und 563.98 kB/s, GIGABYTE zwischen 40.83 und 617.96 kB/s und HP zwischen 41.63 und 593.56 kB/s. GIGABYTE erzielt die besten Ergebnisse bei einer Batchgröße von 64, HP liegt im mittleren Bereich vorn, und Dell bleibt dicht dahinter, fällt aber bei höherer Parallelität leicht zurück.
GPT-OSS-20B
Im Equal ISL/OSL-Vergleich führt Dell den Großteil des Spektrums an und skaliert von 88.73 kJ/s bei einer Batchgröße von 1 auf 1,953.55 kJ/s bei einer Batchgröße von 64. GIGABYTE folgt dicht dahinter mit einem Anstieg von 88.42 kJ/s auf 1,904.62 kJ/s, während HP zwischen 83.49 kJ/s und 1,831.45 kJ/s schwankt. Dell behält insgesamt die stärkste Skalierung im oberen Bereich bei, insbesondere ab einer Batchgröße von 16.
Im Prefill Heavy-Test steigt der Durchsatz bei allen drei Systemen rasant an. Dell erzielt in diesem Test das beste Ergebnis mit einer Steigerung von 216.05 t/s auf 4,261.96 t/s bei einer Chargengröße von 64. GIGABYTE folgt mit 4,011.86 t/s, während HP 3,785.25 t/s erreicht. Bei kleineren Chargengrößen liegen die drei Systeme noch eng beieinander, doch ab einer Chargengröße von 16 kann sich Dell absetzen und seinen Vorsprung bis zum Ende des Tests weiter ausbauen.
Bei Decode Heavy verläuft die Skalierung zwar langsamer, bleibt aber auf allen Plattformen stark. Dell erreicht Werte zwischen 54.88 und 1,173.31 kT/s, GIGABYTE zwischen 55.24 und 1,181.94 kT/s und HP zwischen 53.20 und 1,082.23 kT/s. GIGABYTE liegt bei der höchsten Batchgröße knapp vor Dell, während HP bei höheren Parallelitätsstufen hinter beiden Systemen zurückbleibt.
Llama 3.1 8B Instruct Base
Im Equal ISL/OSL-Test skaliert Dell bei einer Batchgröße von 64 von 27.69 kB/s auf 1,376.38 kB/s und liegt damit knapp vor GIGABYTE mit Werten zwischen 27.23 kB/s und 1,372.27 kB/s. HP folgt im gesamten Testverlauf mit Werten zwischen 26.89 kB/s und 1,235.32 kB/s. Bis zu einer Batchgröße von 16 liegen alle drei Systeme leistungsmäßig sehr nah beieinander, bevor Dell bei höheren Parallelitätsstufen einen leichten Vorsprung herausarbeitet.
Bei Prefill Heavy steigt der Durchsatz mit zunehmender Losgröße rasant an. Dell steigert ihn von 68.60 tk/s auf 2,575.25 tk/s, während GIGABYTE mit einem Anstieg von 67.49 tk/s auf 2,694.25 tk/s bei einer Losgröße von 64 letztendlich das beste Ergebnis erzielt. HP erreicht 2,315.15 tk/s und bleibt damit konkurrenzfähig, liegt aber bei höheren Losgrößen konstant hinter Dell und GIGABYTE zurück. GIGABYTE übernimmt im oberen Bereich die Führung, insbesondere bei Losgrößen ab 64.
Bei Decode Heavy bleibt die Skalierung über den gesamten Testverlauf konstant. Dell erreicht Werte zwischen 17.19 und 726.22 kB/s, GIGABYTE zwischen 16.96 und 720.57 kB/s und HP zwischen 16.79 und 663.31 kB/s. Dell und GIGABYTE liefern über weite Strecken des Tests nahezu identische Ergebnisse, wobei Dell bei höchster Parallelität einen leichten Vorteil hat. HP hingegen fällt bei größeren Batchgrößen leicht zurück.
Llama 3.1 8B Instruct FP4
Im Equal ISL/OSL-Test skaliert Dell von 69.71 TK/s auf 2,849.20 TK/s bei einer Batchgröße von 64, während GIGABYTE mit einem Wachstum von 70.92 TK/s auf 2,912.03 TK/s leicht die Nase vorn hat. HP bleibt wettbewerbsfähig mit Werten zwischen 69.52 TK/s und 2,821.50 TK/s. Die drei Systeme liegen über den gesamten Arbeitsbereich hinweg eng beieinander, lediglich bei höheren Parallelitätsstufen ist eine geringfügige Trennung erkennbar.
Bei Prefill Heavy skaliert das System deutlich stärker, insbesondere bei größeren Chargengrößen. Dell steigert den Durchsatz von 170.09 kT/s auf 4,417.65 kT/s, während GIGABYTE mit einem Anstieg von 173.55 kT/s auf 4,767.43 kT/s bei einer Chargengröße von 64 das beste Ergebnis der Gruppe erzielt. HP skaliert von 170.12 kT/s auf 4,214.57 kT/s. GIGABYTE hebt sich ab einer Chargengröße von 32 deutlich von den anderen ab und liefert den höchsten maximalen Durchsatz bei dieser Arbeitslast.
Bei Decode Heavy bleiben alle drei Systeme über weite Strecken des Tests eng beieinander. Dell erreicht Werte zwischen 43.19 und 1,260.24 kB/s, GIGABYTE zwischen 43.53 und 1,258.05 kB/s und HP zwischen 42.54 und 1,178.74 kB/s. Dell und GIGABYTE wechseln sich je nach Batchgröße an der Spitze ab, während HP bei hoher Parallelität leicht hinter beiden Systemen zurückliegt.
Llama 3.1 8B Instruct FP8
Im Equal ISL/OSL-Test skaliert Dell bei einer Batchgröße von 64 von 46.93 tok/s auf 2,206.52 tok/s, während GIGABYTE zwischen 46.16 tok/s und 2,175.44 tok/s liegt. HP folgt dicht dahinter mit einem Anstieg von 46.40 tok/s auf 2,149.15 tok/s. Die Streuung bleibt während des gesamten Tests gering, wobei alle drei Systeme bis zu einer Batchgröße von 32 ein nahezu identisches Skalierungsverhalten aufweisen.
Bei Prefill Heavy steigt der Durchsatz mit zunehmender Parallelität deutlich stärker an. Dell steigert ihn von 115.85 kB/s auf 3,794.52 kB/s, während GIGABYTE mit einem Anstieg von 113.34 kB/s auf 4,133.76 kB/s bei einer Batchgröße von 64 das beste Gesamtergebnis erzielt. HP erreicht 3,624.73 kB/s. GIGABYTE baut seinen Vorsprung bei höheren Batchgrößen, insbesondere ab einer Batchgröße von 32, deutlich aus.
Bei Decode Heavy bleiben die drei Systeme bei geringer Parallelität eng beieinander, bevor sich bei hoher Parallelität leichte Unterschiede abzeichnen. Dell erreicht Werte zwischen 29.11 und 1,077.07 kB/s, GIGABYTE zwischen 28.64 und 1,068.92 kB/s und HP zwischen 28.68 und 1,000.20 kB/s. Dell behält über den Großteil der Arbeitslast einen knappen Vorsprung, GIGABYTE folgt dicht dahinter, während HP bei größeren Batchgrößen leicht zurückfällt.
Mistral Small 3.1 24B
Im Equal ISL/OSL-Test skaliert Dell bei einer Batchgröße von 64 von 10.41 kB/s auf 498.56 kB/s, während GIGABYTE im oberen Bereich leicht die Nase vorn hat und von 9.76 kB/s auf 509.18 kB/s wächst. HP liegt mit Werten zwischen 9.25 kB/s und 477.25 kB/s etwas dahinter. Der Unterschied zwischen den Systemen bleibt über den gesamten Workload hinweg relativ gering, insbesondere bei niedriger und mittlerer Parallelität.
Bei Prefill Heavy verbessert sich die Skalierung bei allen drei Systemen deutlich. Dell steigert die Leistung von 25.91 kB/s auf 1,079.19 kB/s, während GIGABYTE von 24.25 kB/s auf 1,071.07 kB/s skaliert. HP erreicht 988.82 kB/s bei einer Batchgröße von 64. Dell und GIGABYTE bleiben über den größten Teil des Tests nahezu identisch, wobei Dell bei der höchsten Parallelitätsstufe einen leichten Vorteil aufweist.
Im Dekodier-Schwerpunkt bleibt der Durchsatz insgesamt deutlich geringer, wie bei der dekodierungsintensiven Arbeitslast auf einem größeren Modell zu erwarten war. Dell erreicht Werte zwischen 6.49 und 297.82 kT/s, GIGABYTE zwischen 6.10 und 297.23 kT/s und HP zwischen 5.77 und 276.55 kT/s. Dell und GIGABYTE liegen im gesamten Test fast gleichauf, während HP bei größeren Batchgrößen konstant etwas hinter beiden Systemen zurückbleibt.
Qwen3-Coder 30B A3B Basis
Im Equal ISL/OSL-Verfahren skaliert Dell bei einer Batchgröße von 64 von 59.05 tok/s auf 817.82 tok/s, während GIGABYTE zwischen 59.81 tok/s und 809.88 tok/s liegt. HP liegt mit einem Anstieg von 56.51 tok/s auf 780.21 tok/s leicht hinter beiden Systemen zurück. Die Leistung von Dell und GIGABYTE bleibt über den größten Teil des Testzeitraums nahezu identisch; lediglich bei höheren Batchgrößen treten geringfügige Abweichungen auf.
Im Prefill Heavy-Test steigt der Durchsatz mit zunehmender Parallelität deutlich an. Dell verzeichnet ein Wachstum von 144.81 kJ/s auf 1,756.99 kJ/s, während GIGABYTE die stärkste Skalierung insgesamt erzielt und bei einer Batchgröße von 64 von 147.55 kJ/s auf 1,862.40 kJ/s zulegt. HP erreicht 1,751.17 kJ/s und bleibt damit konkurrenzfähig, liegt aber im oberen Bereich leicht hinter den beiden anderen Systemen zurück. GIGABYTE baut ab einer Batchgröße von etwa 32 einen leichten Vorsprung aus und hält diesen bis zum Ende des Tests aufrecht.
Bei rechenintensiven Dekodierungsaufgaben liegen die drei Systeme über weite Strecken eng beieinander. Dell erreicht Werte zwischen 36.69 und 427.48 kB/s, GIGABYTE zwischen 36.92 und 417.42 kB/s und HP zwischen 35.30 und 403.32 kB/s. Dell behält bei den größten Batchgrößen einen leichten Vorteil, während HP bei dekodierungsintensiven Aufgaben sowohl hinter Dell als auch hinter GIGABYTE zurückbleibt.
Qwen3-Coder 30B A3B FB8
Bei gleicher ISL/OSL-Skalierung skaliert Dell von 98.65 tok/s auf 1,379.26 tok/s bei einer Batchgröße von 64, während GIGABYTE zwischen 100.20 tok/s und 1,308.79 tok/s schwankt. HP bleibt durchweg wettbewerbsfähig und steigert seine Durchsatzrate von 97.06 tok/s auf 1,354.23 tok/s. HP liegt bei einigen kleineren und mittleren Batchgrößen kurzzeitig vorn, Dell erzielt jedoch insgesamt den höchsten Durchsatz im oberen Bereich.
Im Prefill Heavy-Test skaliert der Durchsatz bei allen drei Systemen rasant. Dell steigert ihn von 240.43 TK/s auf 3,041.72 TK/s, während GIGABYTE mit einem Anstieg von 245.92 TK/s auf 3,088.62 TK/s bei einer Batchgröße von 64 das beste Gesamtergebnis erzielt. HP erreicht 2,857.80 TK/s. GIGABYTE baut ab einer Batchgröße von 4 einen deutlichen Vorsprung aus und hält diesen bis zum Ende des Tests.
Im Bereich Decode Heavy weist Dell die stärkste Skalierung im oberen Leistungsbereich auf. Dell erreicht Werte zwischen 60.91 und 705.77 kB/s, während GIGABYTE von 61.53 bis 639.80 kB/s und HP von 59.85 bis 635.25 kB/s skaliert. HP liegt bei kleineren Batchgrößen kurzzeitig vorn, doch Dell zieht bei höherer Parallelität davon und erzielt schließlich den höchsten Dekodierungsdurchsatz der Gruppe.
Zusammenfassung der Spitzenleistung von Doppelzündsystemen
Die folgende Tabelle fasst den maximalen Token-Ausgabedurchsatz zusammen, der während der Tests mit verteiltem PP=2 auf den Dual-Spark-Systemen von Dell, GIGABYTE und HP beobachtet wurde. Jeder Wert stellt den höchsten gemessenen Ausgabedurchsatz (Token/s) dar, der für das jeweilige Workload-Szenario bei der getesteten Batchgröße erreicht wurde. Fettgedruckte Werte kennzeichnen das leistungsstärkste System innerhalb des jeweiligen Workload-Szenarios.
| Modell | Szenario (BS – 64) | Dell Spitzenleistung | GIGABYTE Spitzenleistung | Spitzenleistung in PS |
|---|---|---|---|---|
| GPT-OSS-Modelle | ||||
| GPT-OSS-120B | Gleiche ISL/OSL | 463.97 Zeichen/s | 497.26 Zeichen/s | 504.88 Zeichen/s |
| GPT-OSS-120B | Vorfüllen schwer | 419.56 Zeichen/s | 417.34 Zeichen/s | 441.63 Zeichen/s |
| GPT-OSS-120B | Decode Heavy | 451.18 Zeichen/s | 494.37 Zeichen/s | 474.85 Zeichen/s |
| GPT-OSS-20B | Gleiche ISL/OSL | 976.77 Zeichen/s | 952.31 Zeichen/s | 915.72 Zeichen/s |
| GPT-OSS-20B | Vorfüllen schwer | 852.39 Zeichen/s | 802.37 Zeichen/s | 757.05 Zeichen/s |
| GPT-OSS-20B | Decode Heavy | 938.65 Zeichen/s | 945.55 Zeichen/s | 865.78 Zeichen/s |
| Lama-Modelle | ||||
| Llama-3.1-8B-Anweisung | Gleiche ISL/OSL | 689.53 Zeichen/s | 687.48 Zeichen/s | 618.87 Zeichen/s |
| Llama-3.1-8B-Anweisung | Vorfüllen schwer | 515.45 Zeichen/s | 539.27 Zeichen/s | 463.39 Zeichen/s |
| Llama-3.1-8B-Anweisung | Decode Heavy | 581.43 Zeichen/s | 576.91 Zeichen/s | 531.07 Zeichen/s |
| Llama-3.1-8B-FP4 | Gleiche ISL/OSL | 1427.39 Zeichen/s | 1458.86 Zeichen/s | 1413.51 Zeichen/s |
| Llama-3.1-8B-FP4 | Vorfüllen schwer | 884.22 Zeichen/s | 954.23 Zeichen/s | 843.57 Zeichen/s |
| Llama-3.1-8B-FP4 | Decode Heavy | 1008.98 Zeichen/s | 1007.23 Zeichen/s | 943.73 Zeichen/s |
| Llama-3.1-8B-FP8 | Gleiche ISL/OSL | 1105.42 Zeichen/s | 1089.85 Zeichen/s | 1076.68 Zeichen/s |
| Llama-3.1-8B-FP8 | Vorfüllen schwer | 759.50 Zeichen/s | 827.40 Zeichen/s | 725.51 Zeichen/s |
| Llama-3.1-8B-FP8 | Decode Heavy | 862.33 Zeichen/s | 855.81 Zeichen/s | 800.78 Zeichen/s |
| Mistral- und Qwen-Modelle | ||||
| Mistral-Small-3.1-24B | Gleiche ISL/OSL | 249.77 Zeichen/s | 255.09 Zeichen/s | 239.09 Zeichen/s |
| Mistral-Small-3.1-24B | Vorfüllen schwer | 216.01 Zeichen/s | 214.38 Zeichen/s | 197.92 Zeichen/s |
| Mistral-Small-3.1-24B | Decode Heavy | 238.44 Zeichen/s | 237.97 Zeichen/s | 221.41 Zeichen/s |
Fazit
Die wichtigste Erkenntnis dieser Testreihe hat wenig damit zu tun, welcher OEM bei welcher Arbeitslast die Nase vorn hatte. Über alle getesteten Modelle und Arbeitslasten hinweg lagen die drei Spark-Implementierungen von Dell, GIGABYTE und HP leistungsmäßig nahe beieinander. Bei bestimmten Chargengrößen zeigten sich leichte Vorteile, aber keine Plattform konnte sich klar durchsetzen und keine fiel dauerhaft zurück. Käufer, die zwischen den drei Modellen wählen, sollten ihre Entscheidung eher auf Gehäusedesign, Wärmeverhalten, Garantiebedingungen und Supportbeziehungen stützen als auf Benchmark-Differenzen, die die Schwankungen widerspiegeln, die jedes Desktop-System unter Dauerlast aufweist.
Das interessantere Ergebnis ist methodischer Natur. Auf der 200-GbE-Verbindung zwischen zwei Spark-Servern ist die Wahl zwischen Tensor- und Pipeline-Parallelität wichtiger als jegliche Unterschiede zwischen den drei OEMs. Für Batch-Inferenz bei jeder vernünftigen Parallelität ist Pipeline-Parallelität die bessere Wahl. Der Datenverkehr pro Schicht (alle Reduce-Operationen) bei TP=2 übersteht die Übertragung über eine ConnectX-7-Verbindung nicht, ohne dass Rechenleistung im Leerlauf verbleibt. Die zusätzlichen Kosten der Pipeline-Parallelität bei PP=2 amortisieren sich im stationären Datenstrom, sobald der Batch die Pipeline füllt. NVIDIAs Dokumentation verwendet standardmäßig TP aus gutem Grund: Ihr Hauptaugenmerk für Spark liegt auf interaktivem Single-Stream-Serving mit kurzen TTFTs (Time-to-Flight), und genau hier ist TP=2 eindeutig im Vorteil. Sobald die Arbeitslast eher der Bereitstellung von Infrastruktur als einer Chat-Oberfläche ähnelt, kehrt sich die Rechnung um.
Diese Umkehrung verdeutlicht, was Spark ist und was nicht. Ein Spark-Cluster mit zwei Knoten ist eine Entwicklungs- und Lernplattform, die es einem einzelnen Entwickler ermöglicht, das Verhalten verteilter Inferenzprozesse direkt in einem Netzwerk zu beobachten, das schnell genug ist, um ein reales Rechenzentrums-Fabric zu simulieren, aber gleichzeitig so eingeschränkt, dass die Engpässe sichtbar werden, die in Produktionsumgebungen im großen Maßstab umgangen werden.
Größere Spark-Konfigurationen sind aufgrund ihrer spezifischen Workloads und Parallelisierungsstrategien, die auf diese Größenordnung abgestimmt sind, eine eingehende Untersuchung wert und sind in unserer Roadmap vorgesehen. Unabhängig davon konzentriert sich das nächste Experiment, das diesem folgt, von der Inferenz auf das Training: Ein Modell mit weniger als einer Milliarde Parametern wird von Grund auf auf einem Dual-Spark-Cluster trainiert, der so konfiguriert ist, dass er die verteilten Vortrainingsbedingungen wesentlich größerer Systeme widerspiegelt. Diese Arbeit pausiert derzeit, bis die optische Schnittstelle für unseren neuen 800-Gb-Labor-Core-Switch verfügbar ist. Wir gehen davon aus, die Ergebnisse zu veröffentlichen, sobald der neue Core online ist.
Amazon