NVIDIA DGX Spark: Offizielle Acht-Knoten-Cluster mit 1 TB Speicher

Der Speicher ist der größte Gewinn

Laut NVIDIA bietet ein einzelner DGX Spark 128 GB Unified Memory. Vier Knoten kommen auf 512 GB, acht Knoten auf 1 TB. Diese Kapazität reicht für Modelle, die auf einem Vier-Knoten-System bisher nicht gestartet wären, darunter das vollständige GLM 5.3 (753B) von Z.ai.

NVIDIA zufolge läuft der komplette GLM-5.3-Checkpoint auf dem Cluster mit 8x 128 GB. Damit gehört er zu den größten offenen Modellen, die sich lokal bereitstellen lassen. In NVFP4 umfasst das Modell rund 470 GB. In einem frühen Beispiel betrieb das Unternehmen GLM 5.3 Flash auf acht Knoten und maß in der Generierung etwa 80 Token pro Sekunde. Das sei für interaktive lokale Entwicklung mit einem Mixture-of-Experts-Modell der Spitzenklasse geeignet, so NVIDIA.

Für das vollständige Modell meldet NVIDIA bei Messungen mit MTP3 und Prefill bei einer Eingabesequenzlänge von 8K einen Prefill von 1.600 Token pro Sekunde auf allen getesteten Concurrency-Stufen. Der gesamte Decode-Durchsatz steigt von 31 Token pro Sekunde bei Concurrency eins auf 51 bei vier und 67 bei acht, während der Decode-Durchsatz pro Nutzer von 31 auf 21 und dann auf 18 sinkt.

RoCEnante: ein Collective-Backend für Spark

Bei Tensor-paralleler Inferenz entfällt ein erheblicher Teil der Zeit auf kollektive Operationen wie All-Reduce. Für Cluster mit Switch-Anbindung evaluiert NVIDIA ein auf Spark optimiertes Backend namens RoCEnante. Es zielt auf das Muster aus kleinen Nachrichten, niedriger Concurrency und überschaubarer Rank-Anzahl, das beim Tensor-parallelen Decode auf lokaler KI-Hardware typisch ist.

Das Backend führt einen All-to-All-Austausch mit anschließender lokaler Reduktion durch, koordiniert von einem einzigen GPU-Kernel. Jeder Rank teilt seine Eingabe mit allen anderen Ranks und addiert die Eingaben lokal. Das bedeutet weniger Kommunikationsschritte als beim Ring-All-Reduce, bei dem Daten in mehreren Runden zwischen Nachbarn weitergereicht werden. Der Preis dafür ist mehr Datenbewegung, weshalb der Ansatz bei größeren Nachrichten oder mehr Knoten seinen Vorteil verliert.

Bei Qwen3.8-27B-NVFP4 ohne Speculative Decoding meldet NVIDIA mit RoCEnante auf acht Knoten eine 4,43-fache Decode-Beschleunigung, ohne das Backend sind es 3,05x. Das Unternehmen spricht von 45 % besserer Skalierungseffizienz. Auf vier Knoten sieht NVIDIA bei NVFP4 rund 5 % mehr Prefill- und 21 % mehr Decode-Durchsatz, auf acht Knoten beim nicht quantisierten Modell etwa 18 % mehr Decode-Durchsatz.

Das Backend ist in FlashInfer integriert und weicht transparent auf NCCL aus, falls sein Starttest fehlschlägt. Es funktioniert nur in Topologien mit Switch, weil es einen direkten Punkt-zu-Punkt-Austausch zwischen allen Knoten braucht. NVIDIA betont, dass es kein Ersatz für NCCL ist. NCCL bleibt die unterstützte Standardlösung und die bessere Wahl bei hoher Concurrency, größeren Clustern oder Ring-Topologien. Der ursprüngliche One-Shot-All-Reduce-Ansatz stammt aus der Community (Jason Cook/el8).

Skalierung von einem bis acht Knoten und die Wahl der Topologie

Um die Cluster-Skalierung isoliert zu betrachten, ließ NVIDIA ein dichtes Qwen3.8-27B-Modell (NVFP4) ohne Speculative Decoding auf ein bis acht Knoten laufen, mit llama-benchy bei 8192 Eingabe-Token, 256 Ausgabe-Token und Concurrency 1. Der Decode-Durchsatz stieg von 11,86 Token pro Sekunde auf einem Knoten auf 52,58 auf acht Knoten mit Switch, ein Plus um das 4,43-Fache. Der Prefill legte von 2.635 auf 5.105 Token pro Sekunde zu, das entspricht dem 1,94-Fachen.

• Zwei Knoten, Direktverbindung: 21,71 Decode-Token pro Sekunde (1,838x).
• Vier Knoten, physischer Ring: 32,82 (2,77x). Vier Knoten, Switch mit RoCEnante: 36,34 (3,06x).
• Acht Knoten, physischer Ring: 40,11 (3,38x). Acht Knoten, Switch mit RoCEnante: 52,58 (4,43x).

Welche Topologie die beste ist, hängt laut NVIDIA vom Workload ab. Ein physischer Ring liefert einen hervorragenden Decode-Durchsatz, wenn ein einzelnes Modell auf alle Knoten verteilt wird. Ein Ring ohne Switch senkt zudem die Kosten und vereinfacht die Einrichtung, was das Unternehmen für Enthusiasten und kleine Installationen als attraktiv bezeichnet. Einen Switch braucht man, um einen Cluster in unabhängige Gruppen aufzuteilen, etwa in zwei Vierergruppen, oder um Workloads auszuführen, die direkte Any-to-any-Konnektivität erfordern, darunter MPI-basiertes Clustering.

Multi-Modell-Routing und lokales Pre-Training

NVIDIA beschreibt außerdem NeMo Switchyard, das Anfragen zwischen Modell-Pools auf einem gemeinsam genutzten Acht-Knoten-Cluster verteilt. Laut Unternehmen erreichte es in einem Tool-Use-Benchmark die Qualität eines reinen Qwen-Betriebs und steigerte den aggregierten Durchsatz um bis zu das Dreifache, wenn der Großteil des Datenverkehrs auf ein kleineres Modell wechselt.

Beim Training erzielte das Pre-Training eines nanochat-Modells von Grund auf auf acht Knoten nach Angaben von NVIDIA eine 7,79-fache Beschleunigung bei 97,4 % Skalierungseffizienz. Das Unternehmen sieht darin eine nahezu lineare Trainingsleistung für kleine Modelle auf dem Schreibtisch.

Was das für Entwickler bedeutet

Das Update richtet sich an Entwickler, die mit sehr großen offenen Modellen arbeiten, mehrere Modelle gleichzeitig betreiben oder mit verteiltem Training experimentieren wollen, ohne die lokale Hardware zu verlassen. NVIDIA Sync und der Cluster Assistant übernehmen Einrichtung und Geräteverwaltung des Clusters. Die Unterstützung für Acht-Knoten-Cluster in NVIDIA Sync soll laut NVIDIA bis Jahresende folgen. Das Unternehmen verweist auf Anleitungen zum Verbinden mehrerer Spark-Rechner, zum Bereitstellen von LLMs mit vLLM auf DGX Spark und auf eine Netzwerk-Anleitung, die mit einem Zwei-Knoten-Aufbau beginnt.

Alle Zahlen stammen aus NVIDIAs eigenen Benchmarks. Das Unternehmen weist darauf hin, dass NCCL bei hoher Concurrency und größeren Clustern die bessere Option bleibt. Die Ergebnisse hängen daher von Topologie und Workload ab.