DGX Spark: Kleine Maschine, erstaunlich viel lokale KI

Der schönste Moment mit meinen DGX Sparks war zuletzt, als ich einen davon für Qwen nicht mehr brauchte. Das Modell, das zuvor beide Rechner gebunden hatte, lief auf einem Gerät. Der zweite war wieder unabhängig einsetzbar.

So messe ich den Wert dieser Maschinen inzwischen: Welche Arbeit kann ich mit ihnen lokal erledigen, welche Modelle bekomme ich sinnvoll in Betrieb, und wie viel Spielraum bleibt für Neues?

Viel Speicher in einer kompakten Maschine

Die Kombination aus Blackwell-GPU und 128 GB Unified Memory ist für mich der entscheidende Punkt. CPU und GPU greifen auf einen gemeinsamen Speicherpool zu. Damit kann ich Modelle betreiben, deren Gewichte eine einzelne 24-GB-Grafikkarte überfordern würden.

Zur Einordnung: NVIDIA nennt für den DGX Spark 273 GB/s Speicherbandbreite. Viel Kapazität bedeutet also nicht automatisch die höchste Geschwindigkeit bei jedem einzelnen Antwortstrom. Speichergröße, Bandbreite und Rechenleistung beantworten unterschiedliche Fragen. Die technischen Daten stehen bei NVIDIA.

Meine Geräte sind GB10-Maschinen aus dieser Spark/GX10-Klasse. Für konkrete Gehäuse, Anschlüsse und Herstellerdetails zählt das jeweilige Gerät; für meine Serving-Erfahrungen sind vor allem GB10, Arm64, Unified Memory und die passende Software entscheidend.

Welche Modelle bei mir eine Rolle spielen

Bei DeepSeek nutzte ich den Release 0731, also die Version vom 31. Juli.

Ich führe diese Modelle bewusst nicht als gleichzeitig laufende Sammlung auf. Ein großer Speicherpool bleibt endlich. Was installiert ist, was einmal getestet wurde und was gerade warm bereitsteht, sind drei verschiedene Zustände.

Qwen: ein ganzer Rechner wird wieder verfügbar

Bei Qwen3.8 Flash Next zeigt sich für mich, wie viel eine passende Serving-Lösung ausmacht. Der frühere Aufbau nutzte SGLang über zwei Knoten. Heute kombiniert der Einzelgerätebetrieb hybride Quantisierung mit einer separat von der NVMe eingebundenen PLE-Nachschlagetabelle.

So werden Speicherbereiche unterschiedlich behandelt, statt das gesamte Modell nach einem einzigen Schema zu laden. Mein aktueller Dienst auf .170 wurde mit Health- und Modellabfrage geprüft. Die genaue Geschichte beschreibe ich im eigenen Qwen-Beitrag.

Der Gewinn ist ganz praktisch: Der zweite Rechner muss keine Modellhälfte mehr bereitstellen. Zwei unabhängige Instanzen oder ein anderes Modell werden dadurch möglich. Das ist Flexibilität, die mir im täglichen Experimentieren viel bringt.

DeepSeek: warum zwei Sparks trotzdem sinnvoll bleiben

DeepSeek-V4-Flash-0731 war bei mir ein Fall für den Verbund. Das vorhandene Rezept verteilt den Dienst mit Tensor Parallelism auf beide Geräte und enthält modell- und runtimebezogene Anpassungen.

Damit bleibt der Zwei-Geräte-Betrieb interessant. Er erweitert die Möglichkeiten, erhöht aber auch den Aufwand: Netzwerk, passende Builds, Startreihenfolge und Fehleranalyse gehören dazu. Wenn ein Modell auf einem Gerät gut läuft, bevorzuge ich für diesen Zweck die einfachere Aufteilung. Wenn es den Verbund braucht, ist die Verbindung zwischen den Geräten ein wertvoller Teil der Hardware.

In heruntergeladenen Repositories stehen teilweise beeindruckende Durchsatzzahlen. Ich übernehme sie nicht als eigene Messungen. Dafür müssten Hardware, Version, Eingaben, Parallelität und Herkunft der Ergebnisse eindeutig zusammenpassen.

gpt-oss-120b: große Modelle können sich schnell anfühlen

gpt-oss-120b hat mir auf den Sparks besonders wegen der Geschwindigkeit gefallen. Das ist hier meine Praxiseinschätzung, keine neu erhobene Benchmarkzahl.

Das erhaltene Startskript dokumentiert vLLM, ein Kontextlimit von 65.536 Tokens, bis zu acht Sequenzen, Prefix Caching und asynchrones Scheduling. Es zeigt, wie ich das Modell vorgesehen hatte zu betreiben. Eine konkrete Tokens-pro-Sekunde-Angabe leite ich daraus nicht ab.

Für meinen Alltag zählen auch die Zeit bis zum ersten brauchbaren Ergebnis und die Stabilität mehrerer Arbeitsschritte. Ein kurzer Satz, ein langer Entwurf und eine Werkzeugschleife belasten denselben Dienst sehr unterschiedlich.

Was an der Hardware nicht automatisch einfach wird

Unified Memory muss geplant werden. Modellgewichte, Cache, Betriebssystem und temporäre Aktivierungen teilen sich den Pool. Ein Modell, das gerade noch lädt, kann bei einer langen Eingabe trotzdem an Grenzen stoßen.

Außerdem ist GB10 nicht mit jedem als „Blackwell“ bezeichneten Build automatisch abgedeckt. Architektur, Kernel und Runtime müssen zum Gerät passen. Bei neuen Modellarchitekturen kommen Parser, spezielle Attention-Pfade und spekulative Verfahren dazu.

Diese Arbeit ist ein Teil meiner Erfahrung mit den Sparks. Das Gerät liefert die Voraussetzungen; ein zuverlässiger Dienst entsteht erst durch das passende Setup.

Warum ich die Maschinen trotzdem so gut finde

Ich kann lokal Modelle ausprobieren, die über kleine Assistenten deutlich hinausgehen. Ich kann sie an meine Werkzeuge anschließen und für Mails, Textentwürfe, Dokumente oder kleinere Programmierarbeiten einsetzen. Und ich kann eine gefundene Konfiguration warm halten, während ich auf dem anderen Gerät weiterarbeite.

Für die Kaufentscheidung anderer ist das kein allgemeiner Geschwindigkeitsvergleich. Wer nur möglichst schnelle kurze Antworten eines kleinen Modells braucht, hat andere Anforderungen als ich. Mein Schwerpunkt ist der lokale Betrieb großer Modelle mit genug Freiraum für Integration und Experimente.

Genau dafür machen mir die Sparks viel Freude: kompakte Rechner, viel nutzbarer Speicher und inzwischen mehrere Wege, daraus echte Arbeit zu machen.