NVIDIA DGX Spark einrichten: 128 GB in 12 Schritten

Nvidia hat mit der DGX Spark einen Computer auf den Markt gebracht, der aussieht wie ein kleiner Router und trotzdem ein Sprachmodell mit bis zu 200 Milliarden Parametern lokal verarbeiten kann. Für Entwickler in Österreich, die keine Cloud-Rechnung für jedes Experiment sehen wollen, ist das ein ernstzunehmendes Angebot. Diese Anleitung zeigt Schritt für Schritt, wie die Einrichtung ab dem ersten Bootvorgang abläuft, welche Software vorinstalliert ist und wie zwei Geräte zu einem Cluster für größere Modelle verbunden werden. Am Ende steht ein funktionierendes Praxisprojekt: ein lokaler KI-Assistent mit eigener Wissensdatenbank, der komplett ohne Internetverbindung läuft.

Was ist die NVIDIA DGX Spark und für wen lohnt sich das Gerät?

Die DGX Spark ist Nvidias erster Versuch, einen vollwertigen KI-Supercomputer auf Schreibtischgröße zu schrumpfen. Im Zentrum steht der GB10 Grace-Blackwell-Superchip, eine gemeinsame Entwicklung von Nvidia und MediaTek, gefertigt im 3-Nanometer-Prozess von TSMC. Auf einem einzigen Package sitzen eine 20-Kern-Arm-CPU und eine Blackwell-GPU, verbunden über NVLink-C2C. Beide Komponenten teilen sich 128 GB LPDDR5X-Speicher, sodass es keine strikte Trennung zwischen System-RAM und Grafikspeicher gibt, wie man sie von klassischen Gaming-PCs kennt.

Das Ziel ist klar umrissen: Entwickler, Forschungsteams und kleine Unternehmen sollen große Sprachmodelle lokal trainieren, feinabstimmen und ausführen können, ohne für jede Testreihe eine Cloud-GPU zu mieten. Wer regelmäßig mit Modellen im Bereich von 20 bis 120 Milliarden Parametern arbeitet, bekommt hier eine Maschine, die unter dem Schreibtisch steht und trotzdem GPU-Rechenleistung liefert, die sonst nur in Rechenzentren zu finden ist. Wichtig zur Einordnung: DGX Spark ist die Linux-Variante dieser Grace-Blackwell-Plattform und kommt fertig von Nvidia. Die Windows-Variante desselben Chips trägt den Namen RTX Spark und wird von Partnern wie Dell, HP oder Lenovo in eigene Geräte eingebaut.

Der Rechner trug intern lange den Codenamen Project DIGITS, bevor Nvidia ihn unter dem Namen DGX Spark auf den Markt brachte. Für heimische IT-Abteilungen ist vor allem ein Aspekt interessant, den Cloud-Anbieter nicht bieten können: Modelle, Trainingsdaten und Prompts verlassen das eigene Netzwerk nicht. Wer mit sensiblen Kundendaten, medizinischen Aufzeichnungen oder unveröffentlichter Forschung arbeitet, muss bei einer lokal betriebenen DGX Spark keine Datenübertragung an einen externen Anbieter rechtfertigen. Das macht das Gerät besonders für Universitäten, Kliniken und Kanzleien attraktiv, die aus Datenschutzgründen ohnehin auf lokale Verarbeitung angewiesen sind. Kleine Softwarefirmen wiederum nutzen die DGX Spark häufig als Entwicklungsmaschine, auf der neue KI-Funktionen getestet werden, bevor sie später auf größere Rechenzentrums-GPUs wie die H200 oder B200 skaliert werden.

Typische Einsatzszenarien in der Praxis

In der Praxis kristallisieren sich drei wiederkehrende Nutzungsmuster heraus. Das erste ist die lokale Feinabstimmung: Ein Team nimmt ein offenes Basismodell und trainiert es mit eigenen, oft vertraulichen Daten weiter, etwa mit internen Support-Tickets oder Vertragsdokumenten, ohne dass diese Daten für ein Cloud-Training hochgeladen werden müssen. Das zweite Muster ist die Entwicklung und der Test von KI-Anwendungen, bevor sie produktiv auf größere Infrastruktur ausgerollt werden. Da DGX Spark denselben Software-Stack aus CUDA, TensorRT-LLM und NIM nutzt wie die großen DGX-Systeme im Rechenzentrum, lässt sich Code nahezu unverändert übernehmen, sobald ein Projekt skaliert werden muss.

Das dritte Muster betrifft Forschungsgruppen an Universitäten und Fachhochschulen, die mit begrenztem Budget Zugang zu Rechenleistung brauchen, die sonst nur über geteilte Cluster oder kostenpflichtige Cloud-Kontingente verfügbar wäre. Ein einzelnes Gerät auf dem Labortisch erlaubt es Studierenden und Forschenden, mit großen Modellen zu experimentieren, ohne auf eine zentrale Rechenzentrumsressource warten zu müssen. Für alle drei Szenarien gilt: Je näher die Zielumgebung später an Nvidias eigenem Software-Stack liegt, desto größer der Vorteil gegenüber einer Lösung auf Basis von Consumer-Grafikkarten oder Apple Silicon.

Technische Daten der DGX Spark im Detail

Die folgende Tabelle fasst die offiziellen Spezifikationen aus dem Nvidia-Datenblatt und dem DGX-Spark-Benutzerhandbuch zusammen. Diese Werte sind wichtig, um später einschätzen zu können, welche Modellgrößen realistisch laufen und wo die Grenzen liegen.

Komponente	Spezifikation
Chip	GB10 Grace-Blackwell-Superchip (Nvidia + MediaTek, TSMC 3nm)
CPU	20 Arm-Kerne: 10x Cortex-X925 bis 4,0 GHz + 10x Cortex-A725 bis 2,8 GHz
GPU	Blackwell-Architektur, 48 SMs, 6.144 CUDA-Kerne, 5. Generation Tensor Cores
KI-Rechenleistung	bis zu 1 PFLOP FP4 (mit Sparsity), native NVFP4-Unterstützung
Arbeitsspeicher	128 GB LPDDR5X, 256-Bit-Interface, 273 GB/s Bandbreite
Speicher	1 TB oder 4 TB NVMe M.2 mit Selbstverschlüsselung
Netzwerk	1x 10-GbE RJ-45, ConnectX-7 Smart NIC mit 2x QSFP à 200 Gbit/s, Wi-Fi 7, Bluetooth 5.3
Anschlüsse	4x USB-C, 1x HDMI 2.1a
Leistungsaufnahme	240-W-Netzteil, real rund 195 W unter Volllast laut Testmessungen
Abmessungen	150 x 150 x 50,5 mm, rund 1,2 kg

Auffällig ist die Speicherbandbreite von 273 GB/s. Das liegt deutlich unter dem, was HBM-Speicher in Rechenzentrums-GPUs wie der H200 leistet. Ein rund 24 MB großer L2-Cache auf der GPU gleicht das für viele Inferenz-Szenarien teilweise aus, laut Messungen von ServeTheHome auf eine effektive Bandbreite von bis zu 600 GB/s. Für dichte, unquantisierte 70B-Modelle bleibt die Bandbreite trotzdem der limitierende Faktor, dazu später mehr im Benchmark-Abschnitt.

CPU und GPU im Detail

Die 20 Arm-Kerne der Grace-CPU sind bewusst asymmetrisch aufgeteilt: Zehn schnelle Cortex-X925-Kerne übernehmen rechenintensive Aufgaben wie Datenvorverarbeitung, während zehn effizientere Cortex-A725-Kerne Hintergrundprozesse abarbeiten. Beide Kerntypen unterstützen die ARMv9.2-A-Befehlssatzerweiterung mit SVE2, BF16 und i8mm, wodurch selbst die CPU kleinere KI-Berechnungen übernehmen kann, statt jede Anfrage an die GPU weiterzureichen. Die Blackwell-GPU selbst bringt 48 Streaming-Multiprozessoren und 6.144 CUDA-Kerne mit, dazu Tensor Cores der fünften Generation mit nativer FP4-Unterstützung. Diese Kombination ist der Grund, warum Nvidia für die DGX Spark eine KI-Rechenleistung von bis zu einem Petaflop im FP4-Modus angibt.

Speicher, Anschlüsse und Netzwerk

Der 128 GB große LPDDR5X-Speicher ist über NVLink-C2C kohärent zwischen CPU und GPU aufgeteilt, es gibt also keinen Kopiervorgang zwischen System-RAM und Grafikspeicher wie bei klassischen PCIe-Grafikkarten. Für Netzwerkanbindung sorgt neben einem 10-GbE-Port die integrierte ConnectX-7-Smart-NIC mit zwei QSFP-Anschlüssen zu je 200 Gbit/s, die vor allem für die Kopplung zweier Geräte gedacht ist. Wi-Fi 7 und Bluetooth 5.3 runden die drahtlose Anbindung ab, während vier USB-C-Ports und ein HDMI-2.1a-Ausgang für Peripherie und Bildschirm sorgen.

Preis und Verfügbarkeit in Österreich

Nvidia selbst nennt bislang nur einen US-Preis. Die Founders-Edition mit 4 TB Speicher listete im September 2026 bei 4.699 US-Dollar und war laut einer Marktübersicht Anfang September bereits ausverkauft. Eine offizielle Preisangabe in Euro für Österreich oder die EU liegt noch nicht vor, Käufer müssen aktuell über US-Reseller oder Nvidias eigenen Enterprise-Marktplatz importieren, inklusive Einfuhrumsatzsteuer und eventuellem Zoll. Wer in Österreich kaufen will, sollte bei Fachhändlern nach Lieferterminen fragen, da die Stückzahlen laut den bisherigen Berichten knapp sind.

Für die Kaufentscheidung lohnt sich eine kurze Gegenrechnung mit Cloud-Mietpreisen für vergleichbare Rechenzentrums-GPUs. On-Demand-Instanzen mit einer H200-GPU kosteten laut aktuellen Preisübersichten rund 4,79 US-Dollar pro Stunde, eine B200-Instanz etwa 9,36 US-Dollar pro Stunde. Gerechnet auf den Kaufpreis der DGX-Spark-Founders-Edition von 4.699 US-Dollar amortisiert sich die Anschaffung gegenüber einer gemieteten H200-Instanz nach rund 980 Betriebsstunden, also etwas mehr als sechs Wochen im Dauerbetrieb. Wer nur gelegentlich für einzelne Experimente Rechenleistung braucht, fährt mit stundenweiser Cloud-Miete oft günstiger, wer dagegen dauerhaft lokal entwickelt, holt die Investition vergleichsweise schnell wieder herein.

1 TB oder 4 TB: Welche Speichervariante ist sinnvoll?

Die Entscheidung zwischen den beiden NVMe-Konfigurationen hängt stark davon ab, wie viele Modelle gleichzeitig lokal vorgehalten werden sollen. Ein einzelnes 120B-Parameter-Modell in quantisierter Form belegt bereits mehrere Dutzend Gigabyte, wer zusätzlich mehrere Modellvarianten, Trainingsdatensätze und Container-Images parallel vorhalten will, stößt bei 1 TB schneller an Grenzen als gedacht. Für Teams, die regelmäßig zwischen verschiedenen offenen Modellen wechseln oder eigene Feinabstimmungen speichern, ist die 4-TB-Variante die risikoärmere Wahl, auch wenn sie im Einkauf teurer ist. Wer die DGX Spark dagegen hauptsächlich für ein einzelnes, festes Modell nutzt, kommt mit der kleineren Variante meist gut zurecht.

Konfiguration	Speicher	Preis (USD)	Status September 2026
DGX Spark Founders Edition	4 TB NVMe	4.699 $	Laut Marktbericht kurzzeitig ausverkauft
DGX Spark Basis	1 TB NVMe	kein offizieller Einzelpreis kommuniziert	Verfügbar über Partner-OEMs

Voraussetzungen für die Einrichtung

Bevor der erste Bootvorgang startet, sollte folgende Ausstattung bereitstehen. Die Liste orientiert sich am offiziellen DGX-Spark-Benutzerhandbuch von Nvidia und an Erfahrungsberichten früher Käufer. Wer die Punkte vorab abhakt, spart sich einen zweiten Anlauf mitten in der Ersteinrichtung, etwa weil das passende Kabel oder ein funktionierendes Netzwerk fehlt.

DGX Spark Gerät (1 TB oder 4 TB Variante), im Lieferumfang enthalten: 240-W-Netzteil und Netzkabel
Monitor mit HDMI-2.1-Eingang für die Ersteinrichtung, alternativ ein zweites Gerät im gleichen Netzwerk für den Zugriff per Browser
USB-C-Tastatur und -Maus, oder ein USB-C-Hub mit klassischen USB-A-Peripheriegeräten
Netzwerkverbindung: 10-GbE-Kabel (Cat6a oder besser) oder Wi-Fi-7-fähiger Router
DGX OS 7.4.0 (vorinstalliert, basiert auf Ubuntu 24.04 mit Kernel 6.17)
CUDA 13.0.2 (vorinstalliert als Teil von DGX OS)
Ein kostenloses NVIDIA-Konto für die Aktivierung der 90-tägigen NVIDIA-AI-Enterprise-Testlizenz
Optional für Cluster-Betrieb: ein zweites DGX-Spark-Gerät und ein QSFP-Kabel für die 200-Gbit/s-Verbindung

Schritt 1 bis 5: Auspacken, Verkabeln und DGX OS einrichten

Der Einstieg läuft ähnlich ab wie bei einem Mini-PC, nur dass am Ende ein vollwertiger Linux-Server mit GPU-Beschleunigung steht.

Auspacken und Aufstellen: Das Gehäuse ist mit 150 x 150 x 50,5 mm klein genug für jeden Schreibtisch. Auf ausreichend Luftzirkulation an den Seiten achten, da das Gerät unter Last spürbar warm wird.
Netzteil anschließen: Das mitgelieferte 240-W-Netzteil einstecken. Ein separater Netzschalter fehlt, das Gerät bootet automatisch beim Anlegen der Stromversorgung.
Peripherie verbinden: HDMI-Kabel zum Monitor, USB-C-Tastatur und -Maus anschließen. Wer headless arbeiten will, verbindet stattdessen nur das Netzwerkkabel und ermittelt die IP-Adresse später über den Router.
Netzwerk verbinden: Das 10-GbE-Kabel in den RJ-45-Port stecken oder bei der Ersteinrichtung ein Wi-Fi-7-Netzwerk auswählen.
Erster Bootvorgang: Nach dem Einschalten startet der DGX-OS-7.4-Einrichtungsassistent. Er führt durch Sprachauswahl, Netzwerkkonfiguration, Anlage eines Admin-Benutzerkontos mit SSH-Zugriff und die optionale Aktivierung der NVIDIA-AI-Enterprise-Testlizenz.

Nach Abschluss des Assistenten landet man in einer grafischen Ubuntu-24.04-Oberfläche. Von hier aus lässt sich entweder direkt am Gerät arbeiten oder per SSH von einem anderen Rechner im gleichen Netzwerk zugreifen, was sich für den täglichen Gebrauch deutlich praktischer anfühlt als Tastatur und Monitor am Gerät selbst.

Bei der Wahl zwischen kabelgebundenem 10-GbE-Netzwerk und Wi-Fi 7 lohnt sich ein kurzer Blick auf den geplanten Einsatzzweck. Für das Herunterladen großer Modelldateien, die je nach Parameteranzahl mehrere Dutzend Gigabyte groß sein können, liefert die Kabelverbindung spürbar konstantere Übertragungsraten. Wi-Fi 7 eignet sich dagegen gut für den ersten Testlauf oder wenn kein Netzwerkkabel in Reichweite ist, sollte für den Dauerbetrieb aber möglichst durch eine feste Verbindung ersetzt werden.

Schritt 6 und 7: CUDA, Treiber und AI Enterprise prüfen

Bevor Modelle geladen werden, lohnt sich ein Blick auf die vorinstallierte Software-Basis. DGX OS bringt bereits passende Treiber für die Blackwell-GPU sowie CUDA 13.0.2 mit.

ssh admin@<ip-adresse-der-dgx-spark>

# GPU, Treiber und Speicherbelegung pruefen
nvidia-smi

# CUDA-Version verifizieren
nvcc --version

# Compute Capability der GB10-GPU anzeigen
nvidia-smi --query-gpu=name,compute_cap --format=csv

Eine korrekt eingerichtete DGX Spark zeigt bei nvidia-smi die GB10-GPU mit Compute Capability sm_121 sowie 128 GB Speicher an. Taucht stattdessen eine Fehlermeldung wie “No devices found” auf, ist meist ein fehlgeschlagenes Firmware-Update oder ein noch laufender Ersteinrichtungsprozess die Ursache, dazu mehr im Troubleshooting-Abschnitt weiter unten.

Sicherheitseinstellungen nach der Ersteinrichtung

Da die DGX Spark meist headless im Netzwerk betrieben wird und über SSH erreichbar ist, lohnt sich eine kurze Härtung, bevor produktive Daten oder Modelle auf das Gerät kommen. Passwort-Login über SSH sollte deaktiviert und stattdessen ein Schlüsselpaar verwendet werden. Die integrierte Selbstverschlüsselung der NVMe-SSD schützt bereits die gespeicherten Daten, ersetzt aber keine sauber konfigurierte Firewall für den Netzwerkzugriff.

# SSH-Schluessel vom Client-Rechner auf die DGX Spark kopieren
ssh-copy-id admin@<ip-adresse-der-dgx-spark>

# Passwort-Login serverseitig deaktivieren
sudo sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

# Firewall aktivieren und nur benoetigte Ports oeffnen
sudo ufw allow 22/tcp
sudo ufw allow 11434/tcp
sudo ufw enable

Der Port 11434 wird später von Ollama für die lokale API genutzt und sollte nur dann von außerhalb erreichbar sein, wenn das tatsächlich gebraucht wird. Für reine Einzelplatznutzung reicht es, den Port ausschließlich auf localhost zu binden statt ihn über die Firewall freizugeben.

Die werkseitig aktivierte Selbstverschlüsselung der NVMe-SSD schützt vor allem gegen physischen Diebstahl des Geräts, da die Daten ohne den passenden Schlüssel unlesbar bleiben. Sie ersetzt aber keine Absicherung auf Netzwerkebene: Ein Angreifer, der sich über eine offene SSH-Verbindung oder einen ungeschützten API-Port Zugriff verschafft, kommt an entschlüsselte Daten heran, sobald das System läuft. Wer die DGX Spark in einem gemeinsam genutzten Büronetzwerk betreibt, sollte sie deshalb in ein eigenes VLAN oder Subnetz stellen, statt sie im selben flachen Netzwerk wie Gäste-WLAN oder private Endgeräte zu belassen.

Schritt 8 und 9: Ollama und llama.cpp installieren

Der offizielle Nvidia-Stack aus TensorRT-LLM und NIM-Microservices ist für Produktivbetrieb gedacht, für schnelle Experimente eignen sich Ollama und llama.cpp besser. Beide sind nicht vorinstalliert, laufen aber problemlos auf der DGX Spark, da CUDA und die Treiber bereits bereitstehen.

# Ollama installieren (aktuelle Version von ollama.com)
curl -fsSL https://ollama.com/install.sh | sh

# Dienst starten und Status pruefen
sudo systemctl enable ollama
sudo systemctl start ollama
ollama --version

Für llama.cpp empfiehlt sich der Build direkt aus dem Quellcode, um die CUDA-13-Unterstützung optimal zu nutzen.

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=121
cmake --build build --config Release -j 20

Der Parameter CMAKE_CUDA_ARCHITECTURES=121 entspricht der Compute Capability sm_121 der GB10-GPU und sorgt dafür, dass der Compiler passenden Code für Blackwell erzeugt statt auf eine langsamere generische Fallback-Variante auszuweichen.

Vorinstallierte Software und Erweiterungen im Überblick

Es lohnt sich, zwischen dem offiziellen Nvidia-Stack und selbst installierten Werkzeugen zu unterscheiden, bevor man tiefer in die Praxis einsteigt. DGX OS 7.4.0 bringt bereits CUDA 13.0.2, passende Blackwell-Treiber und Komponenten von NVIDIA AI Enterprise mit, inklusive einer 90-tägigen Testlizenz. Darauf aufbauend bietet Nvidia TensorRT-LLM für optimierte Inferenz sowie NIM-Microservices an, die Modelle in fertige Container mit standardisierter API verpacken. Wer produktiv mehrere Modelle parallel anbieten will, kommt an diesem Container-Ansatz kaum vorbei, da er Versionskonflikte zwischen verschiedenen Frameworks vermeidet.

Ollama und llama.cpp gehören dagegen zur Kategorie der selbst installierten Werkzeuge. Beide sind bei Entwicklern beliebt, weil sie mit wenigen Befehlen ein Modell laden und über eine einfache Kommandozeile oder REST-API ansprechbar machen. Der Nachteil: Anders als die NVIDIA-Container sind sie nicht offiziell für DGX OS validiert, weshalb bei größeren Versionssprüngen gelegentlich Anpassungen nötig werden. Für Experimente und kleinere Teams ist der Aufwand überschaubar, für den Dauerbetrieb mit vielen gleichzeitigen Nutzern empfiehlt sich der Umstieg auf NIM oder TensorRT-LLM.

Ein Mischbetrieb ist in der Praxis üblich: Viele Teams nutzen Ollama für schnelle Prototypen und den täglichen Chat-Zugriff auf ein Modell, während produktive, dauerhaft laufende Dienste über NIM-Container bereitgestellt werden. Diese Trennung hat den Vorteil, dass Experimente mit neuen Modellversionen die stabile Produktivumgebung nicht gefährden, da beide Welten unterschiedliche Abhängigkeiten und Konfigurationsdateien verwenden.

Schritt 10: Erstes großes Sprachmodell laden und testen

Mit den 128 GB einheitlichem Speicher lassen sich deutlich größere Modelle laden als auf jeder Consumer-GPU mit 24 oder 32 GB VRAM. Ein guter Einstieg ist ein offenes 20B- bis 120B-Parameter-Modell.

ollama pull gpt-oss:120b
ollama run gpt-oss:120b "Erklaere in drei Saetzen, wie NVLink-C2C funktioniert."

Ein typisches Ergebnis auf der DGX Spark sieht laut unabhängigen Benchmarks von LocalAIMaster so aus: Beim 120B-Modell “gpt-oss-120b” liefert die Maschine rund 1.956 Tokens pro Sekunde beim Prefill und etwa 60,6 Tokens pro Sekunde bei der Generierung der Antwort. Zum Vergleich: Ein dichtes Llama-3.1-70B-Modell erreicht auf demselben Gerät 803 Tokens pro Sekunde Prefill, fällt bei der Generierung aber auf nur 2,7 Tokens pro Sekunde, weil die Speicherbandbreite bei unquantisierten dichten Modellen dieser Größe zum Flaschenhals wird.

Schritt 11 und 12: Zwei DGX-Spark-Einheiten per ConnectX-7 clustern

Wer Modelle jenseits von 200 Milliarden Parametern ausführen will, kommt an einem zweiten Gerät nicht vorbei. Jede DGX Spark bringt zwei ConnectX-7-QSFP-Ports mit je 200 Gbit/s mit, die genau für diesen Zweck gedacht sind.

Physische Verbindung: Ein QSFP-Kabel zwischen je einem ConnectX-7-Port beider Geräte stecken. Für höhere Ausfallsicherheit lässt sich der zweite Port ebenfalls verbinden.
Netzwerk und Software konfigurieren: Auf beiden Geräten kompatible IP-Adressen im selben Subnetz vergeben und die RDMA-Fähigkeiten der ConnectX-7-Karten aktivieren, bevor ein Framework wie TensorRT-LLM die Modellgewichte über beide Knoten verteilt.

# Auf beiden Geraeten: ConnectX-7-Interface identifizieren
ibdev2netdev
ip addr show

# Statische IP fuer die Cluster-Verbindung setzen (Beispiel Knoten A)
sudo ip addr add 192.168.100.1/24 dev enp1s0f0
sudo ip link set enp1s0f0 up

# Verbindung testen
ping 192.168.100.2

Anschließend übernimmt TensorRT-LLM mit dem Parameter für Tensor-Parallelität die Aufteilung des Modells über beide Knoten, etwa über --tensor-model-parallel-size 2. Für den Alltag reicht ein einzelnes Gerät meist aus, das Cluster-Setup lohnt sich vor allem für Forschungsteams, die mit Modellen jenseits der 200B-Grenze arbeiten.

Wartung und Updates: DGX OS aktuell halten

Wie jeder Linux-Server braucht auch die DGX Spark regelmäßige Updates, sowohl für Sicherheitspatches als auch für neue Treiberversionen. Nvidia liefert Aktualisierungen für DGX OS über die üblichen Ubuntu-Paketquellen aus, ergänzt um ein eigenes Repository für GPU-Treiber und CUDA-Komponenten.

# System- und Treiberpakete aktualisieren
sudo apt update
sudo apt full-upgrade -y

# Aktuell installierte DGX-OS-Version anzeigen
cat /etc/dgx-release

# Nach einem Update pruefen, ob die GPU weiterhin erkannt wird
nvidia-smi

Größere DGX-OS-Versionssprünge, etwa von 7.4 auf eine künftige 7.5-Reihe, bringt Nvidia meist über ein separates Upgrade-Tool statt über den normalen Paketmanager, da dabei auch Firmware-Komponenten der GB10-Plattform aktualisiert werden. Vor einem solchen Sprung empfiehlt sich ein Blick in die offiziellen Release Notes sowie ein Backup wichtiger Modelle und Konfigurationsdateien, falls das Upgrade fehlschlägt und ein Rollback nötig wird.

Benchmarks: Tokens pro Sekunde in der Praxis

Unabhängige Tests zeigen ein differenziertes Bild. Die DGX Spark glänzt bei Prefill-Geschwindigkeit und bei quantisierten oder Mixture-of-Experts-Modellen, verliert aber bei dichten, unquantisierten Modellen im 70B-Bereich deutlich an Tempo.

Modell	Prefill (Tokens/Sek.)	Generierung (Tokens/Sek.)	Quelle
gpt-oss-120b	1.956	60,6	LocalAIMaster
Llama 3.1 70B (dicht)	803	2,7	LocalAIMaster

Eine zweite Quelle, Presenc AI, ordnet die DGX Spark in einer breiteren Modell-Übersicht je nach Größe und Quantisierung in Bereiche von etwa 20 bis 125 Tokens pro Sekunde ein, wobei kleinere und stärker quantisierte Modelle am oberen Ende dieser Spanne liegen. Die Kernaussage für die Praxis: Wer auf Geschwindigkeit optimieren will, sollte quantisierte oder MoE-Modelle bevorzugen statt große dichte Modelle in voller Präzision zu laden.

Warum Prefill so viel schneller ist als die Generierung

Der große Unterschied zwischen Prefill- und Generierungsgeschwindigkeit erklärt sich aus der Arbeitsweise eines Sprachmodells. Beim Prefill verarbeitet die GPU den gesamten Eingabetext parallel in einem einzigen Durchlauf, was sich gut auf die 6.144 CUDA-Kerne verteilen lässt. Bei der Generierung dagegen muss für jedes einzelne Ausgabe-Token ein kompletter Durchlauf durch das Modell erfolgen, wobei jedes Mal die vollen Modellgewichte aus dem Speicher gelesen werden. Genau hier wird die Speicherbandbreite von 273 GB/s zum limitierenden Faktor, besonders bei großen, dichten Modellen wie Llama 3.1 70B ohne Quantisierung.

DGX Spark im Vergleich: RTX-5090-Workstation und Mac Studio

Die naheliegende Frage für Entwickler in Österreich lautet, ob eine DGX Spark einer selbst gebauten RTX-5090-Workstation oder einem Mac Studio vorzuziehen ist. Die Antwort hängt stark von der Modellgröße ab, mit der gearbeitet wird.

Kriterium	DGX Spark	RTX-5090-Workstation	Mac Studio
Speicher für Modelle	128 GB einheitlich (CPU+GPU)	begrenzt durch VRAM der Karte	bis 192 GB einheitlich, je nach Konfiguration
Software-Ökosystem	CUDA, TensorRT-LLM, NIM, volle Nvidia-KI-Suite	CUDA, volle Nvidia-KI-Suite	Kein CUDA, eigenes MLX-Framework
Preis (Einstieg)	4.699 $ (4 TB Founders Edition)	abhängig vom Gesamtsystem, oft im ähnlichen Bereich	ähnlicher Preisrahmen bei High-End-Konfiguration
Stärke	große Modelle, geringer Stromverbrauch	rohe Rechenleistung bei kleineren Modellen, zusätzlich Gaming möglich	Energieeffizienz, macOS-Integration
Schwäche	geringere Speicherbandbreite als HBM-Systeme	VRAM-Obergrenze limitiert Modellgröße	kein natives CUDA/TensorRT-LLM

Für reine Inferenz kleinerer Modelle unter 30B-Parametern liefert eine RTX-5090-Workstation oft die höhere Rohleistung. Sobald Modelle über die VRAM-Grenze einer einzelnen Grafikkarte hinauswachsen, spielt die DGX Spark ihren Vorteil aus: Der gesamte 128-GB-Pool steht ohne Aufteilung zur Verfügung, statt dass ein Modell auf mehrere Karten mit jeweils eigenem Speicher aufgeteilt werden muss. Der Mac Studio bleibt die energieeffizienteste Option, fällt aber aus dem Rennen, sobald ein Projekt auf CUDA-spezifische Bibliotheken wie TensorRT-LLM angewiesen ist, da Apples MLX-Framework ein eigenes Ökosystem ist und nicht direkt mit Nvidia-Werkzeugen kompatibel ist.

Für Entwickler, die ohnehin im Nvidia-Ökosystem arbeiten und mit TensorRT-LLM, NIM oder CUDA-Bibliotheken vertraut sind, ist die DGX Spark der Weg mit dem geringsten Reibungsverlust: Code, der auf einer H100 oder H200 im Rechenzentrum läuft, funktioniert ohne große Anpassungen auch lokal. Wer dagegen bereits eine RTX-5090-Workstation besitzt und nur gelegentlich größere Modelle testen will, kann oft günstiger über kurzzeitige Cloud-Instanzen fahren, statt gleich in ein zusätzliches Gerät zu investieren.

Praxisprojekt: Ein lokaler RAG-Assistent auf der DGX Spark

Als abschließendes Projekt entsteht ein kompletter, lokal laufender Assistent mit eigener Wissensdatenbank (Retrieval-Augmented Generation), der ganz ohne Internetverbindung funktioniert. Das eignet sich für interne Dokumentationen, Support-Wissen oder Forschungsnotizen, die das Haus nicht verlassen sollen.

# Python-Umgebung und Bibliotheken fuer den RAG-Stack
python3 -m venv ~/rag-env
source ~/rag-env/bin/activate
pip install chromadb sentence-transformers ollama

import chromadb
import ollama
from sentence_transformers import SentenceTransformer

embedder = SentenceTransformer("all-MiniLM-L6-v2")
client = chromadb.PersistentClient(path="./wissensbasis")
collection = client.get_or_create_collection("dokumente")

def dokument_hinzufuegen(text, doc_id):
    vektor = embedder.encode(text).tolist()
    collection.add(documents=[text], embeddings=[vektor], ids=[doc_id])

def frage_stellen(frage):
    vektor = embedder.encode(frage).tolist()
    treffer = collection.query(query_embeddings=[vektor], n_results=3)
    kontext = "\n".join(treffer["documents"][0])
    prompt = f"Kontext:\n{kontext}\n\nFrage: {frage}\nAntwort:"
    antwort = ollama.generate(model="gpt-oss:120b", prompt=prompt)
    return antwort["response"]

dokument_hinzufuegen("Die DGX Spark nutzt den GB10 Grace-Blackwell-Superchip mit 128 GB einheitlichem Speicher.", "doc1")
print(frage_stellen("Wie viel Speicher hat die DGX Spark?"))

Dieses Skript legt Dokumente als Vektoren in einer lokalen ChromaDB-Datenbank ab und nutzt das zuvor geladene 120B-Modell über Ollama, um Fragen anhand des gespeicherten Wissens zu beantworten. Ausgeführt auf der DGX Spark liefert der Aufruf typischerweise innerhalb weniger Sekunden eine Antwort, die den korrekten Speicherwert aus dem hinterlegten Dokument zitiert, ganz ohne Cloud-API und ohne dass Daten das Gerät verlassen.

Projekt erweitern: Dokumente automatisch einlesen

Für den echten Einsatz reicht es selten, Dokumente einzeln per Funktionsaufruf hinzuzufügen. Praktischer ist ein Ordner, aus dem alle Textdateien automatisch eingelesen werden, etwa ein Verzeichnis mit internen Handbüchern oder Support-Tickets.

import pathlib

def ordner_einlesen(pfad):
    for datei in pathlib.Path(pfad).glob("*.txt"):
        inhalt = datei.read_text(encoding="utf-8")
        dokument_hinzufuegen(inhalt, datei.stem)
    print(f"Dokumente aus {pfad} wurden in die Wissensbasis aufgenommen.")

ordner_einlesen("./firmenwissen")

Mit dieser Erweiterung lässt sich die Wissensbasis mit wenigen Handgriffen auf hunderte Dokumente skalieren, ohne dass sich am Grundprinzip etwas ändert: Alles bleibt lokal auf der DGX Spark, und jede Anfrage durchläuft zuerst die Vektorsuche in ChromaDB, bevor das Sprachmodell eine Antwort formuliert.

Für den produktiven Einsatz im Team empfiehlt es sich, das Skript hinter einer einfachen REST-API laufen zu lassen, etwa mit FastAPI, statt es nur interaktiv auf der Kommandozeile zu nutzen. So können mehrere Kolleginnen und Kollegen im selben Netzwerk auf dieselbe Wissensbasis zugreifen, ohne dass jeder Einzelne eine eigene Kopie der Modelldateien und der Vektordatenbank vorhalten muss. Wichtig dabei: Die API sollte, wie im Abschnitt zu den Sicherheitseinstellungen beschrieben, nur innerhalb des internen Netzwerks erreichbar sein und nicht ungeschützt ins Internet freigegeben werden.

Die 5 häufigsten Fehler beim Einstieg

Bandbreite mit Rechenzentrums-GPUs verwechseln: Wer 273 GB/s mit den 4,8 TB/s einer H200 vergleicht, wird bei dichten 70B-Modellen enttäuscht. Die DGX Spark ist für Speicherkapazität optimiert, nicht für maximale Bandbreite, und liefert bei dichten Modellen im zweistelligen Milliarden-Bereich spürbar weniger Tokens pro Sekunde als eine Rechenzentrums-GPU mit HBM-Speicher.
Zu große dichte Modelle ohne Quantisierung laden: Ein unquantisiertes 70B-Modell in voller Präzision zu laden, führt schnell zu einstelligen Tokens-pro-Sekunde-Werten, wie die Benchmarks von LocalAIMaster mit nur 2,7 Tokens pro Sekunde bei Llama 3.1 70B zeigen. Quantisierte oder MoE-Varianten wie gpt-oss-120b liefern deutlich bessere Praxiswerte bei ähnlicher Antwortqualität.
ConnectX-7-Konfiguration unterschätzen: Die Cluster-Verbindung zwischen zwei Geräten verlangt korrekt konfiguriertes RDMA und passende IP-Adressen im selben Subnetz. Wer die NVIDIA-DGX-Cluster-Dokumentation überspringt, landet oft bei einer physisch verbundenen, aber softwareseitig funktionslosen Verbindung trotz gestecktem QSFP-Kabel.
AI-Enterprise-Lizenz übersehen: Die vorinstallierte NVIDIA-AI-Enterprise-Suite läuft 90 Tage als Testversion. Wer das nicht im Kalender vermerkt, verliert nach Ablauf unerwartet Zugriff auf bestimmte Enterprise-Funktionen, während CUDA und die Basis-Treiber unabhängig davon weiterlaufen.
Bare-Metal-Installationen statt Containern: Wer PyTorch-Nightlies oder andere Frameworks manuell neben der vorinstallierten CUDA-13.0.2-Umgebung installiert, riskiert Versionskonflikte zwischen system- und nutzerseitig verwalteten Bibliotheken. Nvidia empfiehlt für kritische Workloads die eigenen Container statt einer gemischten Bare-Metal-Umgebung, gerade weil DGX OS die Basispakete zentral pflegt.

Troubleshooting: 9 typische Probleme und Lösungen

nvidia-smi zeigt keine GPU an: Meist deutet das auf einen unterbrochenen Ersteinrichtungsprozess hin. Gerät neu starten und den DGX-OS-Assistenten vollständig durchlaufen lassen, bevor weitere Software installiert wird. Bleibt das Problem bestehen, hilft ein Blick in dmesg | grep nvidia auf Hinweise zu einem fehlgeschlagenen Treiber-Load.
Ollama startet nicht nach der Installation: Mit sudo systemctl status ollama den Dienststatus prüfen. Häufigste Ursache ist ein Port-Konflikt auf 11434, der sich mit sudo lsof -i:11434 aufspüren lässt. Ist der Port durch einen anderen Dienst belegt, hilft ein Neustart dieses Dienstes oder ein alternativer Port über die Umgebungsvariable OLLAMA_HOST.
Modell lädt, aber Antworten sind extrem langsam: Prüfen, ob versehentlich die CPU statt der GPU genutzt wird, etwa mit nvidia-smi während der Inferenz. Fehlt dort eine Prozessauslastung, wurde das Modell ohne GPU-Offloading geladen, oft weil eine CPU-only-Variante des Frameworks installiert wurde.
Speicher läuft während des Ladens eines großen Modells voll: Der 128-GB-Pool wird von System und Modell gemeinsam genutzt. Mit free -h den verfügbaren Speicher vor dem Laden prüfen und bei Bedarf eine stärker quantisierte Modellvariante wählen, statt das System mit einem zu großen dichten Modell zum Absturz zu bringen.
ConnectX-7-Verbindung zwischen zwei Geräten bleibt inaktiv: QSFP-Kabel auf korrekten Sitz prüfen, danach mit ibdev2netdev kontrollieren, ob das Interface überhaupt erkannt wird, bevor die IP-Konfiguration angepasst wird. Häufig liegt es schlicht an einem inkompatiblen oder defekten QSFP-Kabel.
Firmware-Update bleibt hängen: Während eines DGX-OS-Updates niemals das Netzteil trennen. Bei einem Hänger empfiehlt Nvidias Support, mindestens 20 Minuten zu warten, bevor ein harter Neustart erfolgt, da im Hintergrund weiterhin Firmware-Komponenten geschrieben werden können.
llama.cpp-Build schlägt fehl: Meist liegt es an einer falschen CUDA-Architektur-Angabe. Der Wert -DCMAKE_CUDA_ARCHITECTURES=121 muss exakt zur Compute Capability sm_121 der GB10-GPU passen, ein generischer Wert führt zu Kompilierfehlern oder stark reduzierter Leistung.
WLAN-Verbindung bricht unter Last ab: Für dauerhafte KI-Workloads empfiehlt sich grundsätzlich die kabelgebundene 10-GbE-Verbindung statt Wi-Fi 7, besonders beim Laden großer Modelldateien über das Netzwerk, da selbst kurze Aussetzer einen laufenden Download abbrechen können.
SSH-Verbindung wird nach der Härtung verweigert: Wurde PasswordAuthentication deaktiviert, bevor ein SSH-Schlüssel korrekt hinterlegt wurde, bleibt nur der Zugriff über Monitor und Tastatur direkt am Gerät, um die Konfiguration in /etc/ssh/sshd_config wieder zu korrigieren.

Fortgeschrittene Tipps für den Produktivbetrieb

Wer die DGX Spark über die ersten Experimente hinaus produktiv einsetzen will, sollte auf NVIDIA-NIM-Microservices statt auf Einzelskripte setzen. NIM verpackt Modelle in Container mit standardisierten APIs, was den Wechsel zwischen verschiedenen Modellen ohne Codeänderungen erlaubt. Für Teams, die mehrere Nutzer bedienen, lohnt sich außerdem eine Warteschlange vor der Inferenz, etwa über vLLM, um GPU-Ressourcen fair zwischen gleichzeitigen Anfragen aufzuteilen.

Beim Stromverbrauch lohnt sich ein Blick auf die reale Auslastung: Die gemessenen 195 Watt unter Volllast liegen weit unter dem, was eine vergleichbare Multi-GPU-Workstation verbraucht. Für Dauerbetrieb im Homeoffice oder kleinen Büro reicht eine normale Steckdose ohne zusätzliche Absicherung. Wer die 4-TB-Variante nutzt, sollte zusätzlich ein regelmäßiges Backup der Modellbibliothek einrichten, da NVMe-Ausfälle zwar selten, aber bei mehreren hundert Gigabyte an heruntergeladenen Modellen ärgerlich sind.

Für den Dauerbetrieb mit mehreren Nutzern empfiehlt sich außerdem ein einfaches Monitoring der GPU-Auslastung, etwa über ein Cronjob-Skript, das regelmäßig die Ausgabe von nvidia-smi protokolliert. So lässt sich im Nachhinein nachvollziehen, zu welchen Tageszeiten die DGX Spark an ihre Grenzen kommt und ob eine zweite Einheit für den Cluster-Betrieb sinnvoll wäre. Wer die Maschine für mehrere Projekte parallel nutzt, sollte zudem für jedes Projekt eine eigene Python-Umgebung oder einen eigenen Container anlegen, damit unterschiedliche Bibliotheksversionen sich nicht gegenseitig stören.

Zusammengefasst eignet sich die DGX Spark am besten für Teams, die bereits im CUDA-Ökosystem arbeiten und regelmäßig mit Modellen jenseits der üblichen Consumer-VRAM-Grenzen experimentieren. Wer nur gelegentlich ein kleines Modell testen will, kommt mit einer Cloud-Instanz oder einer Consumer-GPU günstiger weg. Wer dagegen Datenschutz, Kontrolle über die eigene Infrastruktur und dauerhaften Zugriff auf große Modelle priorisiert, bekommt mit der DGX Spark ein Gerät, das Rechenzentrums-Software auf Schreibtischgröße bringt.

Häufig gestellte Fragen

Wie viel kostet die NVIDIA DGX Spark aktuell?

Die Founders Edition mit 4 TB Speicher listete im September 2026 bei 4.699 US-Dollar. Einen offiziellen Euro-Preis für Österreich gibt es bisher nicht, Käufer müssen mit Einfuhrumsatzsteuer und Zoll beim Import rechnen.

Welches Betriebssystem läuft auf der DGX Spark?

Vorinstalliert ist DGX OS 7.4.0, eine von Nvidia angepasste Version von Ubuntu 24.04 mit Kernel 6.17, ergänzt um GPU-Treiber, CUDA 13.0.2 und Komponenten von NVIDIA AI Enterprise.

Kann die DGX Spark ein 200-Milliarden-Parameter-Modell ausführen?

Mit 128 GB einheitlichem Speicher lassen sich Modelle bis in diese Größenordnung laden, allerdings meist nur in quantisierter Form. Für Feinabstimmung nennt Nvidia eine praktikable Obergrenze von etwa 70 Milliarden Parametern auf einem einzelnen Gerät.

Was ist der Unterschied zwischen DGX Spark und RTX Spark?

Beide basieren auf demselben Grace-Blackwell-Chip. DGX Spark ist ein fertiges Linux-Gerät direkt von Nvidia für Entwickler, RTX Spark dagegen eine Chip-Plattform, die Hersteller wie Dell oder Lenovo in eigene Windows-Notebooks und Kompaktdesktops einbauen.

Lohnt sich eine DGX Spark gegenüber einer RTX-5090-Workstation?

Das hängt von der Modellgröße ab. Für Modelle, die in den VRAM einer einzelnen RTX 5090 passen, liefert die Workstation oft mehr Rohleistung. Sobald Modelle größer werden, spielt die DGX Spark ihren 128-GB-Speicherpool aus.

Sind Ollama und llama.cpp auf der DGX Spark vorinstalliert?

Nein. Beide Tools müssen manuell installiert werden, laufen aber ohne Probleme, da CUDA 13.0.2 und die passenden Treiber bereits Teil von DGX OS sind.

Wie verbindet man zwei DGX-Spark-Geräte für größere Modelle?

Über die integrierten ConnectX-7-Smart-NICs mit je zwei QSFP-Ports und 200 Gbit/s pro Port. Nach der physischen Verbindung per QSFP-Kabel verteilt ein Framework wie TensorRT-LLM die Modellgewichte per Tensor-Parallelität über beide Knoten.

Wie viel Strom verbraucht eine DGX Spark im Dauerbetrieb?

Das mitgelieferte Netzteil ist auf 240 Watt ausgelegt, unabhängige Testmessungen zeigen unter Volllast einen realen Verbrauch von rund 195 Watt an der Steckdose. Für Dauerbetrieb im Homeoffice oder kleinen Büro ist keine gesonderte elektrische Absicherung nötig.

Eignet sich die DGX Spark auch für kleine Teams ohne eigene IT-Abteilung?

Grundsätzlich ja, da DGX OS die Treiber- und CUDA-Installation bereits übernimmt. Wer allerdings ein Zwei-Geräte-Cluster über ConnectX-7 betreiben will, sollte Grundkenntnisse in Linux-Netzwerkkonfiguration mitbringen oder sich externe Unterstützung holen, da RDMA-Einrichtung keine reine Klickanleitung ist.

NVIDIA DGX Spark einrichten: 128 GB in 12 Schritten [2026]