NVIDIA DGX Spark im Test: Die KI-Appliance bringt Rechenzentrumsfunktionen auf Desktops

NVIDIA DGX Spark markiert einen Wendepunkt in der zugänglichen KI-Infrastruktur. Im bahnbrechenden Dokument „Attention is All You Need“, das 2017 die Transformer-Architektur vorstellte, basierte dies auf einer P100-Serverkonfiguration mit acht GPUs, die Dutzende Kilowattstunden verbrauchte und erheblichen Platz im Rechenzentrum beanspruchte. Heute bietet DGX Spark überlegene Rechenleistung in einem kompakten 240-Watt-Desktop-Formfaktor. Diese dramatische Entwicklung in Energieeffizienz und Formfaktorkomprimierung macht KI-Funktionen, die früher nur in Rechenzentren verfügbar waren, für einzelne Forscher, kleine Teams und verteilte Entwicklungsorganisationen zugänglich.

Was Spark von früheren Desktop-KI-Lösungen unterscheidet, ist sein umfassender Ansatz für den gesamten Entwicklungszyklus. Anstatt Kompromisse zwischen Experimentieren, Feinabstimmung und Bereitstellung zu erzwingen, bietet Spark echte Leistungsfähigkeit in allen Phasen. Die 128 GB große Unified-Memory-Architektur ermöglicht die vollständige Feinabstimmung von Modellparametern, die auf herkömmlichen Workstations Cloud-Ressourcen erfordern würden, und liefert gleichzeitig einen Durchsatz von Hunderten von Token pro Sekunde, der für Batch-Inferenz-Workloads, einschließlich der Generierung synthetischer Daten, geeignet ist. Dank der Integration von ConnectX-7-Netzwerken mit 200 GB Fabric-Kapazität können Unternehmen mehrere Spark-Systeme für noch umfangreichere Modellexplorationen clustern. Wie wir zeigen werden, ist jedoch auch eine einzelne Einheit bemerkenswert leistungsfähig.

Wichtige Erkenntnisse

• Rechenzentrumsleistung in einem Desktop: GB10 Grace Blackwell in einem 1.13-Liter-Gehäuse mit 240 W, zum Preis von 3,999 US-Dollar, mit einer Sparse-Leistung von bis zu 1 PetaFLOP FP4.

• Speicher, der Arbeitsabläufe verändert: 128 GB einheitlicher Speicher ermöglichen die Feinabstimmung aller Parameter von 8B-Modellen vor Ort und Hochdurchsatz-Inferenz. Beim Testen erreichten Llama 3.1 8B FP4 bei 128 gleichzeitigen Zugriffen ca. 924 tok/s und Qwen3 Coder 30B-A3B FP8 bei Batch 64 ca. 483 tok/s.

• Bereit zum Skalieren und Anschließen von schnellem Speicher: Integriertes ConnectX-7 bietet 200G-Fabric für Clustering oder NVMe-oF. Das interne 2242 Gen5 NVMe ist praktisch, aber für hohe I/O-Leistung begrenzt, daher ist externes NVMe-oF über RDMA der bessere Weg für einen nachhaltigen Durchsatz.

• Softwarereife vom ersten Tag an: Wird mit DGX OS, CUDA, cuDNN, TensorRT, AI Workbench, Containern und Workflow-Playbooks geliefert, sodass Teams sofort echte Workloads ausführen können.

• Bewährte Leistung in der Praxis: MAMF hat ~99.8 TFLOPs BF16 und ~207.7 TFLOPs FP8 gemessen. GDSIO-Lesevorgänge erreichten intern einen Spitzenwert von ~11.4 GiB/s, wobei über dem 200G-Fabric eine höhere Obergrenze erwartet wird.

Was ist DGX Spark und wer sollte es in Betracht ziehen?

NVIDIA DGX Spark ist im Grunde eine komplette KI-Entwicklungsplattform und nicht nur eine GPU-Komponente. Sein Herzstück ist der GB10 Grace Blackwell Superchip, der eine GPU mit Blackwell-Architektur und Tensor-Cores der fünften Generation mit einer 20-Kern-Arm-CPU (10× Cortex-X925 + 10× Cortex-A725) integriert, die über NVLink-C2C verbunden ist. Diese kohärente Verbindungsarchitektur ermöglicht laut NVIDIA eine bis zu fünfmal höhere Bandbreite als PCIe Gen 5 und schafft so eine einheitliche Rechenstruktur anstelle separater Verarbeitungsdomänen. 

Um Benutzern den Einstieg zu erleichtern, liefert NVIDIA das auf Ubuntu Desktop basierende DGX OS mit dem kompletten vorkonfigurierten KI-Software-Stack aus, einschließlich CUDA, cuDNN, TensorRT, NVIDIA Container Runtime und AI Workbench. Dadurch entfallen die typischen Treiberprobleme und der Aufwand für die Umgebungskonfiguration, die bei benutzerdefinierten Workstation-Builds auftreten. Das System bietet flexible Bereitstellungsparadigmen: Schließen Sie Peripheriegeräte an und nutzen Sie es als kompakte Workstation mit dem vollständigen Ubuntu-Desktop-Erlebnis oder stellen Sie es als Headless-Netzwerkgerät bereit, das über NVIDIA Sync zugänglich ist und eine nahtlose Integration mit JupyterLab, VS Code, Cursor IDE und SSH-Terminals ermöglicht. 

Dies ist eine speziell entwickelte Infrastruktur für KI-Praktiker, Forscher, die Sprachmodelle optimieren, Datenwissenschaftler, die RAPIDS-Workflows beschleunigen, Entwickler, die agentenbasierte Systeme implementieren, oder Teams, die im kleinen Maßstab mit Architekturen mit ablativen Modellen experimentieren. Spark richtet sich an Fachleute, die ernsthafte KI-Rechenleistung ohne Rechenzentrumskomplexität benötigen.

NVIDIA DGX Spark – Technische Daten

Normen	Details
Architektur
GPU	NVIDIA Blackwell-Architektur
CPU	20-Kern-Arm (10x Cortex-X925 + 10x Cortex-A725)
Tensorkerne	5th Generation
RT-Kerne	4th Generation
NVENC / NVDEC	1×/1×
Memory
System Memory	128 GB LPDDR5X (einheitlicher Systemspeicher)
Speicherschnittstelle	256-bit
Speicherbandbreite	273 GB / s
Leistung
FP4	bis zu 1 PetaFLOP (mit Sparsity)
Lagerung
Lagerung	1 TB oder 4 TB NVMe M.2 (selbstverschlüsselt)
Konnektivität
USB	4× Typ-C USB 3.2 Gen 2×2 (20 Gbit/s)
Ethernet	1× 10GbE RJ-45
NIC	ConnectX-7 Smart NIC – 2x 200G QSFP (Ermöglicht eine maximale Bandbreite von 200G)
Wireless	Wi-Fi 7, Bluetooth 5.3
Audioausgang	HDMI-Mehrkanal-Audioausgang
Display-Anschlüsse	1× HDMI 2.1a
Mechanisch
Abmessungen	150 × 150 × 50.5 mm (5.9 × 5.9 × 1.98″)
Gewicht	1.2 kg
Energieverbrauch	240 W

NVIDIA DGX Spark Design und Build

Der NVIDIA DGX Spark setzt NVIDIAs unverwechselbare Industriedesignsprache fort und verfügt über ein kompaktes Gehäuse, das das Erscheinungsbild der größeren DGX-Systeme widerspiegelt. Die Frontplatte verfügt über kleine Griffaussparungen, eine Anspielung auf die Griffe der originalen DGX-Geräte in voller Größe, und ein goldgesprenkeltes Metallic-Finish, das eine edle, hochwertige Textur erzeugt, akzentuiert durch das ikonische grüne NVIDIA-Logo.

Der DGX Spark misst 150 × 150 × 50.5 mm (5.9 × 5.9 × 1.98 Zoll) und wiegt 1.2 kg (2.6 Pfund). Das ergibt ein Innenvolumen von 1.13 Litern. Damit liegt er klar in der 1-Liter-Klasse der Small-Form-Factor-PCs. Trotz seines minimalen Platzbedarfs fühlt sich das System dank eines Gehäuses aus Vollmetalllegierung, das gleichzeitig als passiver Wärmeverteiler dient, kompakt und robust an, sodass Form und Funktion im Mittelpunkt stehen.

Die Stromversorgung erfolgt über ein externes 240-W-USB-C-Netzteil, das im Bild neben dem Hauptgerät zu sehen ist. Das Netzteil ist kompakt und solide verarbeitet, verfügt über einen Standard-C5-Stecker (Kleeblatt) für den AC-Eingang und passt zum klaren, effizienten Design des DGX Spark.

Auf der Rückseite des DGX Spark ist die gleiche goldgesprenkelte Strukturoberfläche wie auf der Vorderseite zu sehen, wodurch das Design des gesamten Gehäuses einheitlich bleibt. Von links gesehen befindet sich der Einschaltknopf neben vier USB-C-Anschlüssen, von denen einer die Stromversorgung des Geräts übernimmt. Es folgen ein HDMI 2.1a-Ausgang und ein 10 GbE RJ-45-Anschluss. Interessant sind die dualen 200 GbE QSFP56-Schnittstellen, die von einer integrierten NVIDIA ConnectX-7 SmartNIC angesteuert werden.

Auf den ersten Blick könnte man annehmen, dass der Spark eine Konnektivität von 400 Gbit/s ermöglicht. Aufgrund von PCIe-Einschränkungen ist er jedoch nur in der Lage, 200 Gbit/s bereitzustellen. Um mehr zu erfahren, haben wir uns die Topologie des Spark genauer angesehen:

Mit lstopo beobachten wir die beiden Verbindungen der CX7-Netzwerkkarte. Elektrisch ist die CX7 über zwei Gen5 x4-Links verbunden. Innerhalb des Betriebssystems erscheinen diese Verbindungen als vier Schnittstellen, die jeweils eine maximale Bandbreite von 200G unterstützen. Aufgrund der begrenzten Testzeit konnten wir außerhalb unserer NVMe-oF-Tests, die später im Artikel beschrieben werden, nicht alle Netzwerk-Eigenheiten dieser Plattform entdecken. Wir planen jedoch, diese Plattform weiter zu erforschen und werden zukünftige Artikel veröffentlichen, die ihre Möglichkeiten, wie beispielsweise die Gruppierung mehrerer Sparks zu einem Mini-Cluster, genauer erläutern. 

Bei der Betrachtung anderer angeschlossener Geräte folgt als nächstes die winzige M.2-SSD im Formfaktor 2242, die mit Gen5 x4 verbunden ist, gefolgt vom Realtek RJ45 10GbE-Controller, der mit einer PCIe Gen4 x1-Verbindung verbunden ist, und dem MediaTek Wi-Fi-Controller, der mit einer PCIe Gen3 x1-Verbindung verbunden ist.

Was die CPU betrifft, enthält der Spark einen 20-Kern-Arm-Prozessor mit einer heterogenen Big-Little-Architektur, ähnlich den neuesten Prozessoren von Intel. Er besteht aus zehn Cortex-A725-Effizienzkernen und zehn Cortex-X925-Performancekernen, die auf zwei L3-Cache-Cluster aufgeteilt sind. Der erste Cluster (8 MB L3) enthält die CPUs 0–4 (Cortex-A725, max. 2808 MHz) und die CPUs 5–9 (Cortex-X925, max. 3900 MHz), während der zweite Cluster (16 MB L3) die CPUs 10–14 (Cortex-A725, max. 2860 MHz) und die CPUs 15–19 (Cortex-X925, max. 3978–4004 MHz) enthält. Jeder Kern verfügt über private 64 KB L1-Daten- und 64 KB L1-Befehlscaches, der L2-Cache unterscheidet sich jedoch je nach Kerntyp erheblich: Die effizienten Cortex-A725-Kerne haben 512 KB L2-Caches, während die leistungsstarken Cortex-X925-Kerne deutlich größere 2 MB L2-Caches haben (viermal größer). Die schnellsten Kerne sind die CPUs 15–19, die sowohl vom größeren 16 MB L3-Cache als auch von höheren Frequenzen profitieren, wobei CPU 19 mit 4004 MHz der Kern mit der höchsten Leistung ist. Diese unterschiedlichen Leistungs-/Frequenzstufen werden in der oben gezeigten Topologie durch die gestrichelten Linien auf dem Kern angezeigt.

Wir drehen den DGX Spark um; das einzige sichtbare Kunststoffteil ist die Bodenabdeckung, die magnetisch an der Unterseite des Gehäuses befestigt ist. Dieses Design hält das Äußere sauber und ermöglicht gleichzeitig einen schnellen Zugriff auf das Innere. Nach dem Entfernen der magnetischen Basis werden vier Schrauben freigelegt, die den Zugang zum Hauptfach ermöglichen.

Im Inneren ist eine Antennenverkabelung zu erkennen, die zum oberen Teil des Geräts führt. Dies bestätigt die Integration von Wi-Fi 7 und Bluetooth 5.3. Dies bietet flexible Netzwerkoptionen, die insbesondere für mobile oder Laboranwendungen nützlich sind, bei denen kein kabelgebundener Zugriff möglich ist.

Ebenfalls sichtbar ist die Speicherlösung des Geräts, eine PCIe Gen5 2242 M.2 SSD, ein seltener Formfaktor für solch leistungsstarke Hardware. Die hier gezeigte Konfiguration enthält in unserer Konfiguration ein 4 TB Samsung NVMe-Laufwerk.

Bei genauerem Hinsehen entdeckt man das Herzstück des DGX Spark: den NVIDIA Grace Blackwell GB10 Superchip. Flankiert wird der GB10 Superchip von acht verlöteten LPDDR5X-Systemspeichern mit einer Bandbreite von 273 GB/s, die einen schnellen Datenzugriff sowohl bei CPU- als auch bei GPU-Operationen gewährleisten.

Direkt neben dem Chip befindet sich die CX7-Netzwerkkarte, die, wie bereits erwähnt, 200G-Konnektivität bietet. Dadurch können Benutzer den Spark an Hochgeschwindigkeitsspeicher anschließen oder sogar mehrere Spark-Instanzen zu einem Cluster zusammenfassen. NVIDIA hat einen Cluster aus zwei Sparks validiert und verkauft ihn, der direkt verbunden werden kann, um noch größere KI-Modelle zu unterstützen.

Wenn Sie die Platine schließlich umdrehen, werden alle PCIe-Anschlüsse sichtbar, einschließlich der PCIe Gen5 x4 2242 M.2 SSD und des PCIe Gen3x1 MediaTek Wi-Fi-Adapters.

Wo Spark unverzichtbar wird: Die moderne KI-Entwicklungsanwendung

Der DGX Spark erweist sich in mehreren unterschiedlichen professionellen Kontexten als besonders überzeugend und profitiert jeweils von seiner einzigartigen Kombination aus einheitlichem Speicher, kompaktem Formfaktor und umfassender Softwareintegration.

Beschleunigung der Datenwissenschaft: Von Pandas zur Produktion

Für Datenwissenschaftler bedeutet NVIDIA DGX Spark eine deutliche Verbesserung der Workflow-Geschwindigkeit und des Arbeitserlebnisses. Das ConnectX-7-Netzwerk mit 200 Gbit/s Bandbreite in Kombination mit CUDA X-beschleunigten Bibliotheken transformiert die Datenvorverarbeitung. KI und Data Science basieren auf der Grundlage guter Dateneingabe und -ausgabe. Die zeitaufwändigste Phase jedes herkömmlichen ML-Projekts ist traditionell die Datenbereinigung und Merkmalsextraktion. Herkömmliche Workflows beinhalten typischerweise das Laden von Datensätzen in Tools wie Pandas und das Durchführen von Transformationen auf CPU-Kernen, was im Allgemeinen langsam ist. Auch manuelle Exploration und Merkmalsentwicklung können erhebliche Hindernisse darstellen. Spark ermöglicht durchgängige GPU-Beschleunigung durch RAPIDS.

Ein typisches Data-Science-Szenario in Unternehmen umfasst Feature Engineering für Datensätze im Bereich von 40 bis 80 GB: Zusammenführen mehrerer Tabellen, Berechnen von Aggregationen über Zeitfenster hinweg, Handhabung der kategorischen Kodierung und Normalisieren von Verteilungen. Auf einer CPU-Infrastruktur kann diese Vorverarbeitung Stunden dauern. Mit RAPIDS cuDF, das den gesamten Datensatz in den 128 GB großen einheitlichen Speicher von Spark lädt, sind diese Vorgänge in Minutenschnelle und mit mindestens 10-facher Beschleunigung abgeschlossen. Das anschließende Modelltraining profitiert gleichermaßen, egal ob klassisches ML mit cuML oder Deep Learning mit PyTorch, und beseitigt den traditionellen Engpass, bei dem Datenwissenschaftler auf die Infrastruktur warten, anstatt Hypothesen zu iterieren.

Synthetische Datengenerierung: Robotik und Simulation

Die Integration von RT-Cores der vierten Generation positioniert Spark einzigartig für einen neuen Workflow: die Generierung synthetischer Daten für das Training von Weltmodellen. Das Training robuster Manipulationsrichtlinien erfordert traditionell Zehntausende von realen Demonstrationen, was unerschwinglich teuer und zeitaufwändig ist. Fotorealistische Simulationen auf Plattformen wie Isaac Sim oder Omniverse bieten eine Alternative, doch das Rendern von Raytracing-Bildern mit physikalisch akkurater Beleuchtung, Reflexionen und Materialien erforderte bisher teure Workstation-GPUs wie NVIDIAs L40 und RTX 6000 Ada.

Spark konsolidiert diesen Workflow. RT-Cores ermöglichen OpenUSD-Workloads die Generierung synthetischer Daten, während Tensor-Cores für die KI-Inferenz in einem Blueprint/Workflow eingesetzt werden. Früher setzten Unternehmen häufig mehrere Maschinen für das Rendering und einen separaten, für Inferenz optimierten Server ein. Jetzt ist dies mit einem einzigen 240-W-Gerät möglich. Für Robotik-Startups, Universitätslabore oder Automobilhersteller, die sich mit autonomer Manipulation beschäftigen, reduziert diese Integration Entwicklungszeit und Investitionsaufwand erheblich.

 

Wir haben zuvor ähnliche Pipelines zur Generierung synthetischer Daten mit dedizierten L40S-Rendering-Systemen in Kombination mit H100 für die Inferenz in unserem frühere Abdeckung von NVIDIA L40S. Die architektonische Konsolidierung dieser Funktionen in einer einheitlichen Entwicklungsanwendung des GB10 stellt eine überzeugende Weiterentwicklung dieses Workflows dar. Wir planen, in einer kommenden Analyse die Leistung des Spark RT Core mit diesen diskreten Konfigurationen weiter zu testen und dabei Rendering und andere Workloads für repräsentative Robotermanipulationsszenarien zu untersuchen.

Die Vibe-Coding-Revolution

Andrej Karpathy, ehemaliger KI-Direktor bei Tesla und Gründungsmitglied von OpenAI, prägte den Begriff „Vibe Coding“, um einen neuen Ansatz für die schnelle Softwareentwicklung mit KI-Unterstützung zu beschreiben. Anstatt Code Zeile für Zeile zu schreiben, nutzt Vibe Coding LLMs als interaktive Paarprogrammierer: Sie beschreiben Funktionalität in natürlicher Sprache, erstellen ein Implementierungsgerüst, iterieren durch Konversationsverfeinerung und erstellen schnell Funktionsprototypen. Dieser Workflow transformiert die Programmierung von der bewussten Konstruktion zur geführten Konversation mit einer KI, die Kontext, APIs und Architekturmuster versteht und es einzelnen Entwicklern ermöglicht, bemerkenswert komplexe Systeme in beispielloser Geschwindigkeit zu erstellen.

Das Ausmaß der Einführung von KI-gestützter Codierung wird durch OpenRouter-Nutzungsrankings, wo codierungsorientierte Modelle das Inferenzvolumen durchgängig dominieren. Technische Fachkräfte, die primäre Zielgruppe des Vibe-Codings, agieren typischerweise als Power-User und führen mehrere Codieragenten parallel in verschiedenen Kontexten aus. Und da Open-Weight-Modelle zunehmend mit proprietären Alternativen auf Schlüsselmaßstäbe, Entwickler untersuchen lokale Inferenzbereitstellungen, um Ratenbegrenzungen zu beseitigen, die Verfügbarkeit während kritischer Entwicklungsfenster sicherzustellen und die Codevertraulichkeit für proprietäre Projekte zu wahren.

Die Community r/LocalLLaMA präsentiert beeindruckende individuelle Lösungen, von Multi-GPU-Workstations bis hin zu mit Klebeband zusammengeflickten Servern mit lokalen Modellen, verteilter Inferenz auf Consumer-Hardware und aufwendigen Kühllösungen für eine dauerhaft hohe Datendurchsatzrate. Diese Konfigurationen bergen jedoch erhebliche Hürden: Investitionskosten von oft mehreren zehntausend Dollar, ein erheblicher Stromverbrauch, Herausforderungen beim Wärmemanagement, die dedizierte Räume anstelle von Standardbüros erfordern, und erhebliches technisches Know-how für Konfiguration, Optimierung und Fehlerbehebung.

Spark verändert dieses Wertversprechen grundlegend. Für 3,999 US-Dollar mit 128 GB Unified Memory bietet es eine beeindruckende Modellinferenzleistung in einem leisen, kompakten und energieeffizienten Gerät mit nur 240 Watt Verbrauch. Nutzer, die eine lokale Infrastruktur für Programmierassistenten aufbauen möchten, benötigen keine aufwendigen Homelabs mehr, die Kilowattstunden verbrauchen und viel Wärme erzeugen. Der validierte Appliance-Ansatz mit vorkonfiguriertem DGX OS eliminiert die Konfigurationskomplexität, die die lokale LLM-Bereitstellung bisher auf Nutzer mit fundierten Linux- und CUDA-Kenntnissen beschränkte.

Spark beseitigt nicht nur Infrastrukturprobleme, sondern berücksichtigt auch kritische Aspekte rund um Code-Datenschutz und Modellanpassung. Cloudbasierte Programmierassistenten übertragen zwangsläufig Quellcode an Remote-Server, was für Unternehmen, die mit proprietären Algorithmen, sicherheitskritischer Infrastruktur oder regulierten Daten arbeiten, nicht sinnvoll ist. Lokale Inferenz auf Spark stellt sicher, dass der Code die Entwicklungsumgebung nie verlässt. Darüber hinaus ermöglicht die Speicherkapazität von 128 GB eine vollständige Parameterfeinabstimmung von Programmiermodellen, sodass erfahrene Entwickler Modelle auf interne Codebasen spezialisieren können. Diese Funktion ist besonders wertvoll für Unternehmen mit domänenspezifischen Sprachen, benutzerdefinierten Frameworks oder Architekturmustern, die in öffentlichen Trainingsdaten unzureichend repräsentiert sind.

Feinabstimmung mit NVIDIA NeMo auf DGX Spark

Der einheitliche 128-GB-Speicher von DGX Spark ermöglicht eine vollständige Parameterfeinabstimmung von 8B-Modellen, für die traditionell teure Cloud-Setups mit mehreren GPUs erforderlich waren. Die vollständige Feinabstimmung von Qwen3 8B mit standardmäßiger Adam-Optimierung erfordert etwa 132 GB (16 GB Modellgewichte, 96 GB Optimiererzustände, 16 GB Gradienten plus Aktivierungen) und übertrifft damit duale H100-80-GB-Konfigurationen. Durch die Verwendung des speichereffizienten 8-Bit-Adam werden die Anforderungen je nach Batchgröße auf etwa 70 GB reduziert, was bequem in den Speicherpool von Spark passt. Dies ist wichtig, da die vollständige Feinabstimmung bei komplexen Denkaufgaben eine um 4–6 % bessere Genauigkeit als LoRA bietet. Während cloudbasierte 2× H100-80-GB-Setups mit verteilter Trainingskomplexität etwa 5 USD pro Stunde kosten, bietet Spark Einzelsystemtraining für eine einmalige Investition von 3,999 USD.

NVIDIA NeMo Automodel eliminiert Reibungsverluste im Enterprise-Trainingsframework, indem es Day-0-Support für jedes Hugging Face-Modell ohne Checkpoint-Konvertierung bietet. Laden Sie Qwen3 8B direkt vom HuggingFace Hub und konfigurieren Sie die Feinabstimmung über YAML-Dateien, die Datensatzquellen, Optimierereinstellungen und LoRA-Ziele angeben. NeMo automatisiert verteiltes Checkpointing mit Safetensor-Kompatibilität, implementiert fusionierte CUDA-Kernel für 2- bis 5-fache Beschleunigung und übernimmt die Gradientenakkumulation.

Bildgenerierung mit komfortabler Benutzeroberfläche

ComfyUI bietet eine knotenbasierte grafische Oberfläche, die Stable Diffusion und verwandte Diffusionsmodelle in hochgradig anpassbare kreative Pipelines transformiert. Im Gegensatz zu herkömmlichen webbasierten Oberflächen, die Komplexität hinter vereinfachten Parameterreglern abstrahieren, verwendet ComfyUI eine visuelle Graphenarchitektur, in der Benutzer Workflows durch die Verbindung diskreter Funktionsknoten erstellen, die jeweils spezifische Operationen wie Modellladen, Prompt-Kodierung, Latent Diffusion Sampling, VAE-Dekodierung oder Upscaling-Transformationen darstellen. Dieses modulare Design ermöglicht eine granulare Kontrolle über die gesamte Generierungspipeline und macht jeden Rechenschritt transparent und anpassbar. Darüber hinaus können Benutzer mehrere Modelle verketten, benutzerdefinierte Sampling-Pläne implementieren oder erweiterte Techniken wie ControlNet-Anleitungen integrieren, was in vereinfachten Oberflächen nicht möglich wäre.

Auf DGX Spark nutzt ComfyUI die Tensor-Cores der Blackwell-GPU für beschleunigtes Diffusions-Sampling und schließt Generationen je nach Sampling-Komplexität typischerweise in 15–30 Sekunden ab. Die 128 GB große Unified-Memory-Architektur erweist sich als besonders vorteilhaft, da sie mehrere Checkpoint-Modelle, LoRA-Adapter und VAE-Decoder gleichzeitig im Speicher hält und so den Nachlade-Overhead eliminiert, der VRAM-beschränkte Systeme plagt. Benutzer können praktisch unbegrenzt KI-Grafiken lokal generieren, frei von API-Ratenlimits, Cloud-Kosten pro Generation und Datenschutzbedenken, die mit proprietären kreativen Workflows verbunden sind. Das Workflow-Persistenzmodell bietet zusätzlichen operativen Mehrwert: Komplette Pipelines werden in JSON-Dateien serialisiert, die versionskontrolliert, teamübergreifend geteilt oder als Metadaten direkt in generierte Bilder eingebettet werden können. Dies ermöglicht Reproduzierbarkeit, die für Unternehmen, die synthetische Dataset-Pipelines erstellen oder konsistente künstlerische Stile über generierte Assets hinweg beibehalten, von entscheidender Bedeutung ist.

NVIDIA DGX Spark-Leistungstests

vLLM Online Serving – LLM-Inferenztest

vLLM ist die beliebteste Hochdurchsatz-Inferenz- und Serving-Engine für LLMs. Der vLLM Online-Serving-Benchmark ist ein Leistungsbewertungstool, das die realen Serving-Fähigkeiten dieser Inferenz-Engine bei gleichzeitigen Anfragen misst. Es simuliert Produktionslasten, indem Anfragen an einen laufenden vLLM-Server mit konfigurierbaren Parametern wie Anfragerate, Ein-/Ausgabelänge und Anzahl gleichzeitiger Clients gesendet werden. Der Benchmark misst wichtige Kennzahlen wie Durchsatz, d. h. Token pro Sekunde, Zeit bis zum ersten Token und Zeit pro Ausgabe-Token und hilft Anwendern, die Leistung von vLLM unter verschiedenen Lastbedingungen zu verstehen.

Wir haben die Inferenzleistung anhand einer umfassenden Reihe von Modellen getestet, die die gängigsten Architekturen und Modelltypen in heutigen Produktionsbereitstellungen repräsentieren.

Mischung von Expertenmodellen

Wir haben den Qwen3 Coder 30B-A3B evaluiert, eines der beliebtesten Codierungsmodelle für lokale Inferenzimplementierungen. Diese Sparse-Architektur behält eine volle Modellgröße von 30 Milliarden Parametern bei BF16-Präzision bei und aktiviert dabei nur 3 Milliarden Parameter pro generiertem Token. Wir haben sowohl das Standardmodell als auch eine quantisierte FP8-Variante von Qwen getestet. Das quantisierte FP8-Modell zeigt erhebliche Leistungssteigerungen: Es erreicht 46.5 tok/s bei Parallelität 1 und skaliert auf beeindruckende 482.6 tok/s bei Batchgröße 64. Das Standard-BF16-Modell liefert 27.8 tok/s bei Parallelität 1 und erreicht 166.2 tok/s bei Batchgröße 64 – eine fast dreifache Leistungsdifferenz.

Dichte Modelle

Dichte Modelle repräsentieren die konventionelle LLM-Architektur, bei der alle Parameter und Aktivierungen während der Inferenz berücksichtigt werden, was zu einer rechenintensiveren Verarbeitung im Vergleich zu ihren spärlichen Gegenstücken führt. Um die Leistungsmerkmale über verschiedene Modellskalen und Quantisierungsstrategien hinweg umfassend zu bewerten, haben wir fünf dichte Modellkonfigurationen verglichen.

Unsere Testsuite umfasste Mistral Small 3.1 24B von Mistral AI mit BF16-Präzision sowie eine dynamisch quantisierte Mistral Small 3.1 24B FP8-Variante von RedHat AI. Die dynamische Quantisierung nutzt selektive Gewichtungsquantisierungstechniken, um das Verhältnis zwischen Leistung und Genauigkeit zu optimieren. Dabei wird die Präzision strategisch reduziert und gleichzeitig die Modellverschlechterung minimiert. Wir ergänzten diese größeren, dichten Modelle durch Meta Llama 3.1 8B-Evaluierungen in drei Präzisionsformaten: der Standardkonfiguration BF16 sowie den quantisierten FP8- und FP4-Versionen von NVIDIA. Diese Modellauswahlstrategie ermöglicht einen direkten Leistungsvergleich über verschiedene Modellskalen hinweg und isoliert gleichzeitig die Auswirkungen der progressiven Quantisierung auf den Inferenzdurchsatz.

Leistungsanalyse: Große, dichte Modelle

Der Mistral Small 3.1 24B mit BF16-Präzision weist einen Basisdurchsatz von 5.3 tok/s bei Parallelität 1 auf und skaliert auf beachtliche 158.9 tok/s bei 128 gleichzeitigen Anfragen. Die dynamisch quantisierte FP8-Variante zeigt mit 8.8 tok/s moderate Zugewinne bei geringerer Parallelität, liefert aber im großen Maßstab einen überzeugenden Leistungsmultiplikator von 2x und erreicht 319.7 tok/s bei 128 gleichzeitigen Anfragen – was die Effektivität der dynamischen Quantisierung für Hochdurchsatz-Serving-Szenarien unterstreicht.

Leistungsanalyse: Kompakte dichte Modelle

Die Llama 3.1 8B-Architektur weist deutlich unterschiedliche Leistungsmerkmale über verschiedene Quantisierungsstrategien hinweg auf. Bei BF16-Präzision liefert das Modell 13.6 tok/s bei Parallelität 1 und steigert sich auf 408.6 tok/s bei 128 gleichzeitigen Anfragen. Der Übergang zur FP8-Quantisierung ergibt 23.2 tok/s und 752.8 tok/s bei Parallelitätsstufen 1 bzw. 128 – was einer Durchsatzsteigerung von 84 % im großen Maßstab entspricht. Die FP4-Konfiguration steigert die Leistung weiter und erreicht 34.1 tok/s und 924.1 tok/s bei gleichen Parallelitätsstufen. Dies zeigt, dass aggressive Quantisierungsstrategien eine 2.3-fache Leistungssteigerung gegenüber der Basispräzision liefern können, während gleichzeitig eine akzeptable Modellqualität für viele Produktionsarbeitslasten erhalten bleibt.

Mikroskalierungs-Datentyp

Mikroskalierung ist ein fortschrittlicher Quantisierungsansatz, der feinkörnige Skalierungsfaktoren auf kleine Gewichtungsblöcke anwendet, anstatt große Parametergruppen gleichmäßig zu quantisieren. NVIDIAs NVFP4-Format implementiert diese Technik durch eine blockierte Gleitkommadarstellung, bei der jeder Mikroskalenblock mit 8–32 Werten einen gemeinsamen Exponenten als Skalierungsfaktor hat. Dieser granulare Ansatz bewahrt die numerische Präzision bei gleichzeitiger 4-Bit-Darstellung und erhält so den für Transformer-Architekturen wichtigen Dynamikbereich. Das Format ist in NVIDIAs Tensor Core-Architektur integriert und ermöglicht effiziente Berechnungen mit gemischter Genauigkeit und sofortiger Dekomprimierung bei Matrixoperationen.

Wir haben die GPT-OSS-Modelle von OpenAI auf 20B- und 120B-Parameterskalen mithilfe der NVFP4-Quantisierung evaluiert. Das 20B-Parametermodell erreicht 39.7 tok/s bei Parallelität 1 und skaliert auf 611.7 tok/s bei 128 gleichzeitigen Anfragen. Die 120B-Parametervariante liefert 31.4 tok/s bei Parallelität 1 und 162.7 tok/s bei 64 gleichzeitigen Anfragen.

Hinweis: Der Ausgabedurchsatz ist der Durchsatz über alle Anfragen hinweg und nicht der Durchsatz pro Anfrage.

Aufgrund der begrenzten Zeit konnten wir unsere TensorRT-Tests nicht abschließen. Halten Sie Ausschau nach Folgebeiträgen mit dem Spark, in denen wir die Leistung auf weiteren Inferenz-Frameworks untersuchen werden.

Vorfüllen und Dekodieren schwerer Inferenzen

Die LLM-Inferenz lässt sich grundsätzlich in zwei unterschiedliche Rechenphasen zerlegen, die jeweils deutlich unterschiedliche Leistungsmerkmale und Ressourcennutzungsmuster aufweisen. Die Vorfüllphase verarbeitet die gesamte Eingabeaufforderung in einem einzigen parallelen Vorgang und berechnet dabei die Aufmerksamkeitsmechanismen für alle Eingabetoken gleichzeitig – ein rechenintensiver Vorgang, der Tensorkerne und Recheneinheiten vollständig auslastet. Im Gegensatz dazu generiert die Dekodierungsphase Ausgabetoken autoregressiv, d. h. jeweils ein Token durch sequenzielle Vorgänge, die zwar eine geringere Rechenintensität aufweisen, aber erhebliche Anforderungen an die Speicherbandbreite stellen, da das Modell wiederholt auf Gewichte und den wachsenden Schlüssel-Wert-Cache zugreifen muss. Dadurch entstehen grundlegend unterschiedliche Engpassprofile: Vorfüllvorgänge sind typischerweise rechenintensiv, während Dekodierungsvorgänge speicherbandbreitenintensiv werden und daher besonders anfällig für Einschränkungen des Speichersubsystems sind.

Wir haben umfassende Tests mit zwei unterschiedlichen Workload-Profilen durchgeführt: dekodierungsintensive Inferenz mit 512 Eingabetoken und 8,192 Ausgabetoken sowie vorfüllintensive Inferenz mit 8,192 Eingabetoken und 512 Ausgabetoken. Die Leistungscharakteristik zeigt die erwarteten architektonischen Kompromisse: Spark zeigt einen konkurrenzfähigen Durchsatz bei vorfüllintensiven Workloads, bei denen die Rechenressourcen den primären Engpass darstellen, zeigt jedoch eine reduzierte Leistung bei dekodierungsintensiven Szenarien. Dieser Leistungsunterschied entspricht genau den Einschränkungen der Speicherbandbreite. Die sequenzielle Natur der Dekodierungsvorgänge und die intensiven Speicherzugriffsmuster legen die Bandbreitenbeschränkungen der Spark-Architektur direkt offen. Diese Ergebnisse liefern einen wichtigen Kontext für die Interpretation der MAMF-Messungen im nächsten Abschnitt, da beide Benchmark-Suites die Speicherbandbreite durchgängig als den grundlegenden leistungsbegrenzenden Faktor bei Inferenzbereitstellungen in der realen Welt identifizieren.

Maximal erreichbare Matmul-FLOPS (MAMF)

MAMF (Maximum Achievable Matmul FLOPS) ist eine praktische Leistungsmetrik, die die realistische Spitzenanzahl an Gleitkommaoperationen pro Sekunde misst, die auf Machine-Learning-Beschleunigern bei Matrixmultiplikationen erreicht werden können. Sie bietet einen genaueren Benchmark als die theoretischen Spitzen-FLOPS, die oft in Hardwarespezifikationen angegeben werden. Wir verwenden die mamf-finder-Benchmark von Stas Beckman.

Bei BF16-Präzision beobachten wir einen MAMF von 99.8 TFLOPs, während FP8 (E4M3) einen MAMF von 207.7 TFLOPs aufweist. Aus Zeitgründen konnten wir keine umfassende FP4-MAMF-Charakterisierung durchführen. Extrapoliert man jedoch die beobachteten präzisionsbasierten Skalierungsmuster, erwarten wir eine zusätzliche Leistungssteigerung von 2× gegenüber FP8, was ca. 400 TFLOPs für dichte FP4-Operationen ergibt. Unter Berücksichtigung der strukturierten Sparsity-Optimierung von 2:1 entspricht dies etwa 80 % der theoretischen FP4-Leistung und erreicht ca. 800 TFLOPs bei spärlicher Rechenlast. Es ist wichtig zu beachten, dass diese MAMF-Messungen aus vielen Gründen, auf die wir in diesem Test nicht eingehen, unter den theoretisch angegebenen Spezifikationen liegen können.

GPU-Direktspeicher

Einer der Tests, die wir mit dem Spark durchgeführt haben, war der MagnumIO GPU Direct Storage (GDS)-Test. GDS ist eine von NVIDIA entwickelte Funktion, die es GPUs ermöglicht, die CPU zu umgehen, wenn sie auf Daten zugreifen, die auf NVMe-Laufwerken oder anderen Hochgeschwindigkeitsspeichern gespeichert sind. Anstatt Daten über die CPU und den Systemspeicher zu leiten, ermöglicht GDS die direkte Kommunikation zwischen GPU und Speichergerät, wodurch die Latenz deutlich reduziert und der Datendurchsatz verbessert wird.

So funktioniert GPU Direct Storage

Wenn eine GPU Daten verarbeitet, die auf einem NVMe-Laufwerk gespeichert sind, müssen die Daten normalerweise zuerst durch die CPU und den Systemspeicher laufen, bevor sie die GPU erreichen. Dieser Prozess führt zu Engpässen, da die CPU zum Mittelsmann wird, was zu Latenz führt und wertvolle Systemressourcen verbraucht. GPU Direct Storage beseitigt diese Ineffizienz, indem es der GPU ermöglicht, über den PCIe-Bus direkt vom Speichergerät auf Daten zuzugreifen. Dieser direkte Pfad reduziert den mit der Datenbewegung verbundenen Overhead und ermöglicht schnellere und effizientere Datenübertragungen.

KI-Workloads, insbesondere solche mit Deep Learning, sind äußerst datenintensiv. Das Training großer neuronaler Netzwerke erfordert die Verarbeitung von Terabyte an Daten, und jede Verzögerung bei der Datenübertragung kann zu einer Unterauslastung der GPUs und längeren Trainingszeiten führen. GPU Direct Storage bewältigt diese Herausforderung, indem es sicherstellt, dass die Daten so schnell wie möglich an die GPU übermittelt werden, wodurch Leerlaufzeiten minimiert und die Rechenleistung maximiert werden.

Darüber hinaus ist GDS besonders vorteilhaft für Workloads, die das Streamen großer Datensätze beinhalten, wie etwa Videoverarbeitung, Verarbeitung natürlicher Sprache oder Echtzeit-Inferenz. Durch die Reduzierung der Abhängigkeit von der CPU beschleunigt GDS die Datenbewegung und gibt CPU-Ressourcen für andere Aufgaben frei, was die Gesamtsystemleistung weiter verbessert.

GDSIO – Intern 4 TB M.2

Die NVIDIA DGX Spark bietet eine interessante Speicherauswahl. Aus Platzgründen hat sich NVIDIA für die weniger verbreitete Gen5 2242 M.2 SSD entschieden. Für Leser, die mit diesem SSD-Typ nicht vertraut sind: Es handelt sich um eine kürzere 42-mm-Version im Vergleich zur 80-mm-Version, die im Desktop-Bereich üblicher ist. Es gibt weniger Laufwerksoptionen, wobei 4 TB die maximale Kapazität in dieser Größe darstellt. Das Hauptproblem ist jedoch die Leistung. Bei kleinen SSDs wie den Modellen 2242 und 2230 steht die Größe im Vordergrund, während die Laufwerksgeschwindigkeit eine untergeordnete Rolle spielt. Sie sind häufig in tragbaren Spielkonsolen, Tablets und einigen Notebooks zu finden.

Auf der 2230- und 2242-SSD-Platine ist nicht viel Platz, sodass weniger Raum für Controller, DRAM und NAND-Pakete bleibt. Einige dieser Nachteile konnten wir bei unseren Tests beobachten. Bei der Anwendung unserer GDSIO-Workload auf einem 1-TB- oder 128-GB-Footprint blockierte die SSD und erforderte ein neues Spark-Image. Durch die Reduzierung des Test-Footprints auf 64 GB sowie die Reduzierung der höheren Thread-Anzahl konnte dieses Problem umgangen werden. Diese Probleme treten bei gängigeren Hochleistungs-SSDs mit 80 mm im Allgemeinen nicht auf.

Bei der Betrachtung der sequentiellen Leseleistung des internen Laufwerks sehen wir den höchsten Durchsatz bei einer Blockgröße von 1 MB mit 16 Threads, wobei 11.4 GiB/s erreicht werden.

Bei der sequentiellen Schreibleistung erreicht das Laufwerk den höchsten Durchsatz bei einer Blockgröße von 32 KB und 128 Threads. Bei größeren Blockgrößen scheint die Leistung zu stagnieren und liegt im Durchschnitt bei etwa 8.3 GiB/s.

Käufern, die NVIDIA DGX Spark für anspruchsvollere Entwicklungsarbeiten erwerben möchten, insbesondere Unternehmen, die möglicherweise kleine Cluster daraus erstellen, empfehlen wir dringend, die integrierte 200-GB-NVIDIA ConnectX-7-Netzwerkkarte zu nutzen.

GDSIO – NVMe-oF über RDMA

Für NVMe-oF-RDMA-Tests mit dem NVIDIA DGX Spark nutzten wir die Software von PEAK:AIO, um ein NVMe-oF-Ziel auf einem Dell PowerEdge R770 mit sechs Micron 9550 3.84 TB SSDs zu erstellen und über RDMA zu verbinden. Wie bereits erwähnt, hat die CX7-Netzwerkkarte des Spark ihre Macken, und aus Zeitgründen konnten wir den Spark nur mit 100G-Konnektivität testen. Sowohl der Spark als auch PEAK:AIO erreichen deutlich höhere Werte. Wir werden in späteren Artikeln weitere Speicher- und Netzwerktests mit dem Spark durchführen.

Bei der Betrachtung der sequentiellen Leseleistung des internen Laufwerks sehen wir den höchsten Durchsatz bei einer Blockgröße von 128 KB mit 32 Threads, wodurch 12.1 GiB/s erreicht werden.

Bei der sequentiellen Schreibleistung erreicht das Laufwerk den höchsten Durchsatz bei einer Blockgröße von 128 KB und 16 Threads. Bei größeren Blockgrößen scheint die Leistung zu stagnieren und liegt im Durchschnitt bei etwa 11.3 GiB/s.

Diese Ergebnisse weisen viele Nuancen auf. Aus den oben genannten zeit- und netzwerkbezogenen Gründen erreichen wir nur die Hälfte des theoretischen Maximums. Darüber hinaus wird der höchste Durchsatz bei einer Blockgröße von 128 KB von mehreren Faktoren beeinflusst, wie z. B. den von uns verwendeten Enterprise-Laufwerken oder der Art und Weise, wie PEAK:AIO diese IO verarbeitet. Ihre Ergebnisse können variieren, und wir beabsichtigen, in Zukunft durch Tests mit Spark weitere Ergebnisse zu erzielen.

Day-One-Software-Ökosystem

NVIDIA und andere Anbieter haben erheblich in die Softwarereife investiert. Dies stellt einen deutlichen Unterschied zu typischen Hardware-Launches dar, bei denen Early Adopters mit unvollständiger Dokumentation und fehlenden Tools zu kämpfen haben. Spark wird mit umfassenden Playbooks eingeführt, die gängige Workflows abdecken: ComfyUI für Diffusionsmodelle, TRT-LLM für optimierte Inferenz, Ollama mit Open WebUI für lokale Modellbereitstellung, Unsloth für die Feinabstimmung und Multi-Agenten-Architekturen mit LangGraph.

Diese Softwarereife verändert die Evaluierungserfahrung. Anstatt tagelang Umgebungen zu konfigurieren, können Entwickler sofort beurteilen, ob Spark ihren Anforderungen entspricht, indem sie repräsentative Workloads ausführen. Die Spielbücher Stellen Sie nicht nur Anweisungen bereit, sondern auch containerisierte Umgebungen, Beispieldatensätze und erwartete Leistungsmetriken.

Verfügbarkeit und OEM-Systeme

Die NVIDIA Founders Edition ist für 3,999 US-Dollar in der 4-TB-Konfiguration bestellbar und ab dem 15. Oktober allgemein erhältlich. Neben NVIDIAs eigenem Gerät erscheinen auch mehrere GB10-Desktops der großen OEMs. Die Kernhardware wird bei allen OEMs weitgehend ähnlich sein, es besteht jedoch möglicherweise ein geringer Spielraum für Differenzierungen. Die meisten Preisunterschiede dürften jedoch bei der Speicherauswahl liegen. Es gibt bereits zahlreiche Ankündigungen, darunter den Dell Pro Max mit GB 10, die Lenovo ThinkStation PGX, den Acer Veriton GN100 und den ASUS Ascent GX10.

Fazit

Der NVIDIA DGX Spark stellt einen grundlegenden Wendepunkt im Zugänglichkeitsparadigma fortschrittlicher KI-Computerinfrastruktur dar. Durch die Konsolidierung der Funktionen des GB10 Grace Blackwell Superchips – 128 GB einheitlicher Speicher, 1 PetaFLOP Sparse FP4-Leistung, RT-Cores der vierten Generation und ConnectX-7-Netzwerk – in einem 240-W-Gerät mit 1.13 Litern Hubraum zum Preis von 3,999 US-Dollar hat NVIDIA die Barrieren, die KI-Funktionen der Rechenzentrumsklasse bisher von einzelnen Forschern und kleinen Entwicklungsteams trennten, effektiv niedergerissen.

Der validierte Appliance-Ansatz adressiert einen hartnäckigen Knackpunkt bei der Bereitstellung von KI-Infrastrukturen: den operativen Aufwand für die Pflege benutzerdefinierter Konfigurationen. Unternehmen, die Spark-Einheiten einsetzen, profitieren von NVIDIAs umfassenden Tests und Validierungen des gesamten Stacks, einschließlich DGX OS, CUDA-Toolkit, Framework-Containern und Hardware-Firmware. Dadurch entfällt der Konfigurationsaufwand, der bei benutzerdefinierten Workstation-Builds auftritt. Das integrierte Update-Management, die Systemüberwachung und die JupyterLab-Bereitstellung des DGX Dashboards reduzieren den operativen Aufwand zusätzlich, während die automatische SSH-Schlüsselverteilung und das Tunnelmanagement von NVIDIA Sync den Fernzugriff reibungslos gestalten. Für skalierende Unternehmen bedeutet dies ein messbar schnelleres Onboarding: Neue Forscher erhalten standardisierte Hardware, verbinden sich über die validierte Zwei-Knoten-Clusterkonfiguration mit der bestehenden Infrastruktur und beginnen innerhalb weniger Stunden mit der produktiven Arbeit, anstatt erst Tage nach der Behebung von Treiberkonflikten oder der Netzwerkkonfiguration.

DGX Spark bietet bereits echte KI-Leistung in einem kompakten, leisen Gerät. Unsere ersten Ergebnisse zeigen, warum es für Teams wichtig ist, die hohe Leistungsfähigkeit ohne Rechenzentrums-Overhead benötigen. Die Entwicklung steht erst am Anfang. Wir planen, unsere Tests mit dem 200G-Fabric, NVMe-oF-Zielen und Multi-Node-Clustering auszuweiten, um Skalierungseffizienz, größere Modell-Footprints und gemeinsam genutzte Speicherarchitekturen zu untersuchen. Mit der Weiterentwicklung des Software- und Partner-Ökosystems erwarten wir, dass sich Spark-Implementierungen von leistungsstarken Einzelknoten-Setups zu eng integrierten Mini-Clustern mit hohem Durchsatz entwickeln, die diese Plattform weiter verbessern.

Produktseite

Spark-Demos