NVIDIA DGX Spark

Der KI-Mini-PC im Praxiseinsatz

NVIDIA verspricht mit dem DGX Spark nichts weniger als den "kleinsten KI‑Supercomputer der Welt". Grundlage ist der GB10‑Superchip mit integriertem Arm‑Prozessor und Blackwell‑GPU, dazu 128 GB an LPDDR5X‑Speicher, der CPU und GPU gemeinsam zur Verfügung steht. In Kombination mit NVFP4‑Präzision wirbt NVIDIA mit bis zu einem PetaFLOP an KI‑Leistung und der Möglichkeit, Sprachmodelle mit rund 70 Milliarden Parametern feinzutunen und Varianten mit bis zu etwa 200 Milliarden Parametern lokal für die Inferenz zu betreiben. Wir haben versucht, den DGX Spark in den Redaktionsalltag einzubinden und geschaut, an welcher Stelle eine lokale KI hier sinnvoll sein kann.

Interessant wird der DGX Spark damit überall dort, wo große Modelle ohne Cloud laufen sollen – aus Gründen der Datensouveränität, niedriger Latenz oder schlicht, um nicht ständig GPU‑Zeit im Rechenzentrum buchen zu müssen. Das System kommt mit vorinstalliertem DGX OS, CUDA‑ und CUDA‑X‑Bibliotheken sowie NVIDIAs AI‑Software‑Stack und zielt explizit auf Entwickler, Forscher und Unternehmen, die lokale LLM‑Entwicklung, Fine‑Tuning und Inferenz mit offeneren Modellen ausprobieren wollen.

Der DGX Spark kann größere Modelle tragen als gängige Endkunden-Hardware, kann beim Token‑Durchsatz aber langsamer sein. Dies ist ein Kompromiss, der die Debatte eröffnet, für welche Szenarien sich lokale KI auf einem Mini‑Supercomputer wie dem DGX Spark wirklich lohnt.

Aber fangen wir einmal vorne an: Vorgestellt wurde der DGX Spark auf der GTC 2025 im März des vergangenen Jahres. Ursprünglich plante NVIDIA wohl, ihn schon im Frühsommer ausliefern zu können. Aufgrund nie durch NVIDIA bestätigter Probleme in der Fertigung des GB10-Chips verzögerte sich die Auslieferung der ersten Modelle aber bis in den Spätsommer und Herbst 2025. Alle technischen Details zum gemeinsam mit MediaTek entwickelten SoC findet ihr in einem gesonderten Artikel. Interessant wird dieser sicherlich noch einmal werden, wenn er als N1/N1X auch in den ersten Notebooks landen sollte. Eine offizielle Vorstellung dessen steht aber noch aus.

Den DGX Spark gibt es als Founders Edition von NVIDIA. Den Preis musste man kürzlich auf 4.800 Euro anheben. OEM-Partner wie ASUS (Ascent GX10), Dell, Lenovo und Gigabyte bieten eigene Versionen des GB10-Systems an. Diese unterscheiden sich allerdings nur im Gehäuse und der Kühlung. Hinsichtlich der Leistung gibt es keinerlei Unterschiede. Bei einer zweiten Generation ist mit mehr Vielfalt zu rechnen.

Den GB10-Chip verpackt NVIDIA zusammen mit einer NVMe-SSD mit 4 TB und vor allem den 128 GB LPDDR5X in einem Gehäuse mit kompakten Abmessungen von 150 x 150 x 50,5 mm. Dem Speicher kommt aber nicht nur wegen der Speicherkapazität eine besondere Rolle zu, sondern auch wegen des 256 Bit breiten Speicherinterfaces mit einer Speicherbandbreite von 273 GB/s. Im Hinblick auf den SoC und dessen Funktionen sind sicherlich die Strix-Halo-APUs von AMD sowie die M4/5-Serie von Apple die Gegenspieler. Bei AMD ist die Speicherbandbreite identisch. Apple kann mit bis zu 614 GB/s glänzen.

Aber an dieser Stelle sei gleich erwähnt, dass dies kein Vergleichstest werden wird. Einen solchen können wir an dieser Stelle nicht leisten, teilweise aus mangelnder Vergleichs-Hardware, aber auch, weil die Systeme derart spezialisiert und abgeschottet gestaltet sind, dass ein direkter Vergleich unter vollständig identischer Vergleichsbasis nur schwer möglich ist.

Zurück zum DGX Spark: Das Design erinnert an den ersten DGX-Server – nur eben deutlich kleiner, inzwischen schneller und effizienter. Auf der Rückseite befinden sich alle Anschlüsse. Dazu gehören 4x USB Typ-C, 1x RJ45 für ein 10GbE, 2x ConnectX-7 (200GbE) sowie einmal HDMI 2.1a. Auf der Rückseite zu finden, ist auch der Ein/Ausschalter.

Per Wi-Fi 7 ist eine drahtlose Anbindung des DGX Spark an das heimische Netzwerk möglich. Maus und Tastatur können per Bluetooth 5.4 gekoppelt werden.

Für die Inbetriebnahme wichtig ist der Punkt, dass nur USB-Anschlüsse zur Verfügung stehen und so sollte die Peripherie entweder bereits Typ‑C‑fähig sein oder es sollte ein Adapter vorliegen. Die Einrichtung kann aber auch headless über das Netzwerk erfolgen.

Das externe Netzteil zum DGX Spark bietet eine Ausgangsleistung von 240 W. Der SoC im Mini-System ist auf 140 W festgelegt. Insofern ist noch reichlich Luft für den Verbrauch der I/O-Komponenten vorhanden.

Erste Schritte mit dem DGX Spark

Egal in welcher Form die Ersteinrichtung stattfinden soll, ein Einrichtungsassistent führt Schritt für Schritt durch Sprach‑ und Zeitzonenauswahl, Annahme der Lizenzbedingungen, das Anlegen eines Benutzerkontos sowie die WLAN‑ oder Ethernet‑Konfiguration. Alternativ lässt sich der DGX Spark als Netzwerk‑Appliance aufsetzen: Beim ersten Start spannt er einen eigenen WLAN‑Hotspot auf, dessen SSID, Passwort und die URL der Weboberfläche auf der beiliegenden Quick‑Start‑Karte vermerkt sind. Über ein Notebook oder einen PC verbindet man sich mit diesem Hotspot, ruft die Setup‑Seite im Browser auf und durchläuft dort denselben Assistenten, bis sich das System ins eigene Heim‑ oder Firmennetz einbindet und der Hotspot automatisch wieder abgeschaltet wird.

Nach Abschluss der Einrichtung steht der DGX Spark sowohl klassisch als Desktop‑System mit grafischer Oberfläche als auch per SSH, Remote‑Desktop, DGX Dashboard oder über die NVIDIA‑Sync‑App im lokalen Netzwerk für KI‑Workloads zur Verfügung.

Verwendet haben wir den DGX Spark sowohl als Netzwerk‑Appliance, um zum Beispiel vom Arbeits-Notebook darauf zuzugreifen, aber auch mittels Direktzugriff mit Maus, Tastatur und angeschlossenem Monitor. Beides kann ein sinnvoller Praxiseinsatz sein.

Über das Dashboard, welches lokal oder per Netzwerk aufgerufen werden kann, können die wichtigsten Funktionen des DGX Spark überwacht und Software-Updates installiert werden.

Playbooks ausprobiert

Nun ist nicht jeder ein KI-Forscher und setzt regelmäßig entsprechende Systeme auf. Insofern sind hier einige Hürden vorhanden, die NVIDIA umgehen wollte. Mithilfe der sogenannten Playbooks will NVIDIA die Installation verschiedenster Anwendungsbeispiele vereinfachen. Zu einigen dieser Beispiele kommen wir jetzt.

In den Playbooks ist eine ausführliche Beschreibung der Funktion zu finden, auch mit entsprechenden Warnhinweisen, und im zweiten Tab zu jedem Playbook gibt es auch jeweils eine ausführliche Anleitung. Diese nennt alle Details und beschreibt Schritt für Schritt, mit Befehlszeile für das Terminal, den Weg zum fertig konfigurierten Workload.

Vieles dreht sich natürlich um die inzwischen hunderttausenden an LLMs, die verfügbar sind. Sie variieren stark in Modellgröße (von wenigen Milliarden bis hin zu hunderten Milliarden oder mehr Parametern), was Rechenbedarf, Latenz und Kontextlänge ebenso beeinflusst wie die erreichbare Modellgüte.

Große Unterschiede gibt es bei Trainingsdaten-Menge und -Zusammensetzung (Web‑Scrapes, kuratierte Datensätze, synthetische Daten), beim eigentlichen Pretraining vs. nachgelagertem Fine-Tuning bzw. RLHF für bestimmte Aufgaben oder Domänen. Viele Modelle werden zusätzlich über parameter-effiziente Methoden wie LoRA/QLoRA angepasst, bei denen der Großteil der Gewichte eingefroren und nur kleine Adapter auf quantisierten Basisgewichten trainiert werden, was Speicher und Rechenleistung spart. Schließlich differenzieren sich LLMs durch Modalität (rein Text vs. multimodal mit Bild, Audio, Video), Spezialisierung (z.B. Code-, Medizin-, Rechtsmodelle) und den Grad an Offenheit (Open Source vs. proprietär), was sie für sehr unterschiedliche Einsatzszenarien optimiert.

Daher ist es zunächst einmal wichtig, den DGX Spark mit den gewünschten LLMs zu versorgen. Diese können dann beispielsweise im LMStudio, sei es lokal auf dem DGX Spark oder remote per LMLink verwendet werden.

Verbunden werden kann der DGX Spark auch per NVIDIA Sync. Damit kann der Zugriff dann so erfolgen, als säße man direkt vor dem KI-Minisystem und zudem ist es möglich, darüber macOS-Anwendungen, an den DGX Spark zu koppeln bzw. Rechenaufgaben auszulagern. Ein Beispiel, welches wir dahingehend ausprobiert haben, ist Bildgenerierung per ComfyUI unter macOS, die eigentliche Generierung fand allerdings auf dem DGX Spark statt.

Um den GB10-Chip auch einmal anderweitig auszulasten, haben wir zudem Single-Cell-RNA-Sequencing durchlaufen lassen. Auch dazu gibt es ein entsprechendes Playbook.

Sehr viel Zeit haben wir allerdings mit den eben schon erwähnten LLMs verbracht. Im Journalismus gibt es eine ganze Reihe neuer Arbeitsweisen, in der LLMs unterstützen können. Besonders deutlich wird das bei Routineaufgaben und stark strukturierten Inhalten: Sportergebnisse, Wetterdaten, Börsenkurse oder Verkehrsmeldungen lassen sich aus Datenquellen automatisiert in Texte übersetzen, die im Redaktionsalltag bisher viel Zeit kosten. Gleichzeitig unterstützen Modelle die sprachliche Ausformulierung von Meldungen, bieten Alternativen für Teaser und Überschriften an und helfen, Inhalte schnell in unterschiedliche Textlängen und Formate zu bringen.

In der Recherche fungieren LLMs zunehmend als Assistenzsysteme. Sie können große Dokumentmengen vorsortieren. Gerade bei Datenlecks und umfangreichen Aktenbeständen erleichtern sie die erste Sichtung, indem sie Muster und Auffälligkeiten markieren, die anschließend journalistisch geprüft werden. Auch Transkription und Zusammenfassung sind inzwischen Standard: Interviews, Pressekonferenzen oder längere Reports werden automatisch in Text umgewandelt, in Stichpunkte überführt und zu verwertbaren Kurzfassungen kondensiert.

Damit diese Möglichkeiten verantwortungsvoll genutzt werden können, müssen Redaktionen jedoch ihre Strukturen anpassen. Es braucht klare Richtlinien, welche Aufgaben automatisiert werden dürfen, wie mit Fehlern umzugehen ist und an welchen Stellen Transparenz gegenüber dem Publikum geboten ist.

Kritisch ist dabei vor allem, dass LLMs grundsätzlich mit Unsicherheiten arbeiten: Halluzinationen, mangelnde Quellenangaben und Verzerrungen aus den Trainingsdaten können zu Fehl- oder Desinformation führen, wenn Ergebnisse ungeprüft übernommen werden. Hinzu kommen ethische und rechtliche Fragen, etwa der Umgang mit urheberrechtlich geschütztem Material und mit personenbezogenen Daten. Entscheidend wird daher sein, dass der Einsatz von LLMs stets als Werkzeug im Dienst journalistischer Standards verstanden wird – und nicht umgekehrt die Standards an die Bequemlichkeit der Technologie angepasst werden.

Für ein paar LLMs haben wir die Leistung in Form der Tokens pro Sekunde im Vergleich zu einem MacBook Pro mit M3 Pro aufgenommen. Die großen Modelle lassen sich in den dort vorhandenen, 18 GB großen LPDDR5X-Speicher gar nicht erst laden. Hier sind die 128 GB des DGX Spark natürlich von Vorteil. Zudem spuckt dieser in etwa doppelt so viele Tokens pro Sekunde aus.

Wichtig ist auch die Time to First Token (TTFT) und auch hier liefert der DGX Spark die schnellere Reaktion. Einzig für das Nemotron-3-Nano-Modell kann der MacBook Pro mithalten.

Der Hype um OpenClaw

Der aktuelle Hype rund um OpenClaw speist sich vorwiegend aus dem Versprechen, leistungsfähige KI-Modelle besonders effizient und hardwareunabhängig lokal ausführen zu können – ein Ansatz, der die Einstiegshürden für anspruchsvolle Workloads deutlich senkt. Gerade im Kontext wachsender Skepsis gegenüber Cloud-Abhängigkeiten trifft OpenClaw damit den Nerv der Zeit und positioniert sich als flexible Alternative für Entwickler und Power-User, die maximale Kontrolle über ihre KI-Infrastruktur anstreben.

Zur GTC 2026 präsentierte NVIDIA mit NemoClaw eine Referenzplattform für OpenClaw. OpenShell soll dabei als Softwarewerkzeug sicherstellen, dass OpenClaw keinerlei Daten aus den geschlossenen Systemen heranziehen kann. Zur Installation auf dem DGX Spark wird ein entsprechendes Playbook bereitgestellt.

Im praktischen Einsatz spielt OpenClaw seine Stärken vor allem dort aus, wo lokale Rechenleistung, Flexibilität und Datenkontrolle gefragt sind. Ein typisches Szenario ist die lokale Code-Assistenz: Entwickler können große Sprachmodelle direkt auf der eigenen Workstation betreiben, um Code zu analysieren, zu generieren oder zu dokumentieren – ohne Quellcode an externe Dienste übertragen zu müssen. Gerade in sensiblen Projekten oder Unternehmensumgebungen ist das ein klarer Vorteil gegenüber klassischen Cloud-Lösungen.

Ein weiteres Beispiel findet sich in der Content-Produktion. Kreative Anwender nutzen OpenClaw, um Bild-, Video- oder Textmodelle lokal auszuführen und individuell anzupassen. Dadurch lassen sich etwa Bildgeneratoren gezielt auf eigene Stilrichtungen trainieren.

Darüber hinaus eignet sich OpenClaw für Edge- und Offline-Szenarien. In Umgebungen mit eingeschränkter oder bewusst isolierter Netzwerkanbindung – etwa in der Industrie, im Außeneinsatz oder in sicherheitskritischen Bereichen – können KI-Modelle vollständig autark betrieben werden. OpenClaw fungiert hier als flexible Laufzeitumgebung, die unterschiedliche Modelle effizient orchestriert und auf die verfügbare Hardware abstimmt.

Erfahrungswerte mit Soft- und Hardware

Die Inbetriebnahme von Hard- und Software ist dank der ausführlichen Anleitung von NVIDIA schnell und einfach möglich. Je nach gewünschter KI-Anwendung kann es zwischen zehn Minuten und mehreren Stunden dauern, ob diese installiert ist. Im Falle großer LLMs spielt dabei natürlich auch der Download eine gewisse Rolle. Ein Linux-System sollte dem Nutzer eines DGX Spark natürlich ebenfalls nicht ganz fremd sein. Wir konnten die für uns interessanten Playbooks allesamt lauffähig bekommen.

Ob und welchen Anwendungsfall man nun für den DGX Spark hat, lässt sich meist sehr individuell feststellen. KI-Forscher und solche, die große Modelle lokal ausführen und feinjustieren wollen, dürften die Hauptanwender sein.

Vorstellbar ist beispielsweise, dass der DGX Spark im Netzwerk eingebunden als Netzwerk‑Appliance auf entsprechende Aufgaben diverser Clients wartet. Anstatt vom Notebook einen der KI-Clouddienste in Anspruch zu nehmen, gehen die Anfragen an den DGX Spark.

Der Idle-Verbrauch von 55 W könnte man dem System noch als Negativpunkt ankreiden. NVIDIA hat inzwischen mehrfach Systemupdates veröffentlicht, so ganz in den Griff bekommen hat man dies aber nicht. Während unserer Versuche mit dem DGX Spark bewegte sich die Leistungsaufnahme des Systems zwischen 55 und 130 W. Dieser Verbrauch muss der Nutzung eines KI-Clouddienstes natürlich ebenfalls gegenübergestellt werden.

Update:

Wegen der hohen Idle-Leistungsaufnahme waren wir mit NVIDIA in Kontakt und haben mit dem letzten Software-Updates, welches zwischenzeitlich erschienen ist, noch einmal nachgemessen:

• Idle (Maus und Tastatur per USB, Monitor an HDMI): 31,9 W
• Idle (ohne Maus und Tastatur): 28,4 W
• Idle (ohne Maus, Tastatur und Monitor): 25,3 W

Da zwischenzeitlich der USB-C-Hub als mögliche Fehlerquelle identifiziert wurde, haben wir auch ohne diesen sowie Headless, sprich ohne Monitor, gemessen. Mit 25 bis 32 W in den verschiedenen Konfigurationen liegen wir nun eher im erwarteten Bereich.

Finale Einschätzung

Mit der zunehmenden Verbreitung generativer KI-Modelle stellt sich für viele ambitionierte Anwender die Frage, ob Cloud-Dienste langfristig die optimale Lösung bleiben – oder ob sich der Schritt hin zur lokalen Ausführung lohnt. Systeme wie der NVIDIA DGX Spark zeigen, dass sich professionelle KI-Infrastruktur zunehmend in Richtung kompakter, leistungsfähiger Desktop-Lösungen entwickelt.

Ein zentraler Vorteil lokaler KI-Modelle liegt in der Datenhoheit. Während Cloud-basierte Dienste zwangsläufig eine Übertragung sensibler Daten erfordern, verbleiben diese bei einer lokalen Ausführung vollständig auf dem eigenen System. Gerade für semiprofessionelle Anwender – etwa in der Content-Produktion, Softwareentwicklung oder im Forschungsumfeld – kann dies ein entscheidender Faktor sein. Hinzu kommt die Unabhängigkeit von externen Anbietern: Weder Nutzungsbeschränkungen noch API-Kosten oder Verfügbarkeitsprobleme spielen eine Rolle, sobald das Modell lokal betrieben wird.

Auch aus Performance-Sicht ergeben sich klare Vorteile. Latenzen durch Netzwerkkommunikation entfallen vollständig, was insbesondere bei interaktiven Anwendungen – etwa Code-Assistenz, Bildgenerierung oder lokalen Chatbots – zu einem deutlich flüssigeren Arbeitsweise führt. Gleichzeitig lassen sich Modelle individuell anpassen, feinjustieren oder sogar vollständig offline betreiben.

Häufig auch angeführt werden die Kosten für Cloud-basierte Dienste. Mit kleiner SSD-Kapazität ist eine der Varianten des DGX Spark von einem der Hardwarepartner ab 3.340 Euro zu finden. ChatGPT Pro kostet 229 Euro, das kleinere Abo 23 Euro. Googles Gemini ist für 22 und 275 Euro zu bekommen – je nach Anforderung. Gehen wir also einfach von 200 Euro je Monat aus, so ist eine Nutzung von 1 1/2 Jahren notwendig, damit sich die Investition in einen DGX Spark rechnet. Hier nicht eingerechnet sind natürlich der Aspekt der Datenhoheit sowie die Tatsache, dass die Modelle lokal im Zweifel responsiver arbeiten.

Nicht zuletzt eröffnet die lokale KI-Ausführung auch mehr Spielraum für eigene Experimente. Anwender sind nicht auf vorgegebene Modelle oder Plattformen beschränkt, sondern können verschiedene Architekturen testen, eigene Workflows entwickeln und tief in die Optimierung einsteigen. Gerade in einer Phase, in der sich KI-Technologien rasant weiterentwickeln, ist diese Flexibilität ein nicht zu unterschätzender Vorteil.

4.300 Euro für einen DGX Spark von NVIDIA in der Founders Edition sind sehr viel Geld. Wer aber auch keinen konkreten Anwendungsfalls hat, für den ist diese Hardware auch einfach nichts. Die lokale Ausführung von KI-Workflows hat ohne Frage Vorteile – sowohl in der Leistung, wie auch der Datenhoheit. Der DGX Spark kann zudem eine Art Sprungbrett für KI-Workflows sein, die dann vom kompakten KI-System auf Cloud-Hardware übertragen werden können.