Auf einem DGX Spark mit 128 GB Unified Memory laufen offene Modelle bis in die Klasse um 120 Milliarden Parameter, wenn sie in 4 Bit oder kleiner vorliegen. Nach Herstellerangaben und Dateigrößen passen Qwen3.8-27B, Muse Glimmer 30B, Gemma 4 (31B und 26B-A4B), gpt-oss-120b, Mistral Small 4 und die drei Nemotron-3.5-Modelle Super, Bolt und Lightning. Nvidia selbst nennt für ein Gerät mit 128 GB Modelle bis 200 Milliarden Parameter. Nicht auf ein einzelnes Gerät passen die großen offenen Modelle dieses Herbstes wie DeepSeek V4, Kimi K3, Muse Spark Open oder Mistral Large 4. Auf meinem eigenen DGX Spark lief Qwen3.8-27B bei meiner Messung im August 2026 unter SGLang mit 50,7 Tokens pro Sekunde. Welches der anderen Modelle bei mir am schnellsten und am zuverlässigsten arbeitet, zeigt die Messreihe in diesem Beitrag. Drei der Kandidaten, gpt-oss-120b, Mistral Small 4 und Nemotron 3.5 Super, messe ich nicht selbst. Für sie nenne ich veröffentlichte Messungen Dritter auf dem DGX Spark.
Das Kurzfazit meiner Messreihe vom 3. und 4. November 2026: Am schnellsten war Nemotron 3.5 Lightning mit 80,4 Tokens pro Sekunde bei deutschem Fließtext und, mit dem Entwurfsmodell DSpark, 144,1 bei Code. Die meisten der sechs Qualitätsaufgaben, je fünf, bestanden Gemma 4 31B, Muse Glimmer 30B und Qwen3.8-27B ohne Entwurfsmodell. Für deutsche Texte lag Gemma 4 31B vorn, als einziges Modell mit bestandener Kundenmail und bestandener Zusammenfassung, mit 22,2 Tokens pro Sekunde aber langsam. Für Coding bleibt Qwen3.8-27B mit DFlash2 stark: 50,1 Tokens pro Sekunde bei Code, Python-Aufgabe und Agentenlauf bestanden.
Ich betreibe mein Business mit einer Belegschaft aus fünfzehn KI-Mitarbeitern auf Claude-Basis. Der DGX Spark daneben ist mein Testfeld für die Frage, wie weit lokale Modelle ohne Cloud kommen. Was das Gerät selbst kann und wo seine Fallen liegen, steht in DGX Spark im Test: lohnt sich der Kauf?. Hier geht es um die Frage danach: welches Modell darauf. Alles zu lokaler KI sammle ich auf der Seite KI.
Was auf den DGX Spark passt: die Rechnung vorab
Der DGX Spark hat nominal 128 GB Unified Memory, mein System meldet davon rund 119 GB als nutzbar. CPU und GPU teilen sich diesen Speicher. Nvidia schreibt auf der Produktseite: „Test, validate, and inference with AI models up to 200 billion parameters.“ Für zwei verbundene Geräte nennt Nvidia bis 400 Milliarden, für vier bis 700 Milliarden Parameter.
Für die Auswahl rechne ich grob so: Gewichte in 4 Bit brauchen etwa ein halbes Byte je Parameter, ein Modell mit 120 Milliarden Parametern also um die 60 bis 75 GB. Dazu kommt der Speicher für den Kontext, und der wächst mit jeder Anfrage, die das Modell gleichzeitig hält. Das ist eine Faustregel, keine Messung.
Eine eigene Regel engt das weiter ein. Unter SGLang setze ich --mem-fraction-static nie über 0,50, weil eine zu großzügige Zuweisung auf dem Unified Memory den ganzen Rechner einfrieren kann. Dieselbe Grenze gilt bei mir auch für vLLM (--gpu-memory-utilization), denn die Falle liegt im gemeinsamen Speicher, nicht in der Software. Rechnerisch bleiben damit knapp 60 GB für Gewichte und Kontext. Drei Kandidaten liegen mit ihren Gewichten darüber: gpt-oss-120b mit 65,2 GB, Mistral Small 4 in NVFP4 mit 70,8 GB und Nemotron 3.5 Super in NVFP4 mit 75,0 GB, jeweils die Dateigrößen auf Hugging Face. Diese drei messe ich deshalb nicht selbst, warum genau, steht weiter unten bei den Fremdmessungen. Dazu kommt: Neben Qwen laufen auf meiner GPU weitere Dienste, etwa Whisper large-v3 für die Spracherkennung mit 3 bis 4 GB und eine Sprachausgabe. Auch ihr Speicher fehlt dem Testmodell, solange sie laufen.
Zu groß für ein einzelnes Gerät sind nach den Modellkarten die Modelle ab einigen hundert Milliarden Parametern: DeepSeek-V4-Pro mit 1,6 Billionen, Kimi K3 mit 2,8 Billionen, Muse Spark Open mit 816 Milliarden und Mistral Large 4 mit rund einer Billion Parametern. Inzwischen liegt mit Kimi K3.1 Pro ein weiteres Modell dieser Klasse auf Hugging Face, ebenfalls mit rund 2,8 Billionen Parametern (Stand 15.11.2026). Die laufen im Rechenzentrum oder über einen Cloud-Dienst, nicht auf deinem Schreibtisch.
Die Kandidaten: neun Modelle nach Herstellerangaben
Auf die Liste kommen die Modelle, die nach Herstellerangaben in den Speicher passen und unter einer Lizenz stehen, die auch kommerzielle Nutzung erlaubt. Sechs davon habe ich selbst gemessen, für gpt-oss-120b, Mistral Small 4 und Nemotron Super nenne ich Fremdmessungen. Die Werte in dieser Tabelle stammen aus den Modellkarten und Dateilisten auf Hugging Face sowie aus der Ollama-Bibliothek, Stand 26.10.2026, am 15.11.2026 erneut geprüft. Meine eigenen Werte stehen in den Ergebnistabellen weiter unten.
Zu den Lizenzen: Apache 2.0 erlaubt die kommerzielle Nutzung. Für Nemotron 3.5 Super schreibt Nvidia auf der Karte der NVFP4-Fassung: „This model is ready for commercial or non-commercial use.“ Alle drei Nemotron-Modelle stehen unter derselben Lizenz OpenMDW-1.1. Das ist meine Lesart der Lizenzangaben, keine Rechtsberatung. Wie sich die Lizenzen offener Modelle im Detail unterscheiden, steht in meinem Beitrag über Open-Weight-Lizenzen.
Der Messaufbau
Jede Zahl in den beiden Ergebnistabellen stammt aus diesem Aufbau, er gilt für die sechs Modelle, die ich selbst messe. Ändere ich etwas daran, steht es in der Zeile dabei.
Gerät. Ein DGX Spark mit GB10-Chip, 128 GB Unified Memory nominal, rund 119 GB nutzbar, DGX OS auf Basis von Ubuntu 24.04. Ich habe auf dem Gerät keine Administratorrechte ohne Passwort, deshalb läuft jedes Testmodell als eigener Container oder Benutzerdienst auf einem eigenen Port. Es läuft immer nur ein Sprachmodell zur Zeit. Für die Läufe der anderen Modelle halte ich meinen produktiven Qwen-Server an. Das unterbricht meinen eigenen Betrieb, ein Neustart dauert 5 bis 12 Minuten, deshalb messe ich in einem festen Zeitfenster. Die übrigen Dienste auf der GPU, darunter Spracherkennung und Sprachausgabe, liefen während aller Läufe weiter und belegten zusammen rund 12 GiB.
Laufzeit. Gibt es für ein Modell ein offizielles Rezept für SGLang, nutze ich SGLang, so wie bei meinem Qwen-Aufbau. Für die Nemotron-Modelle nutze ich Nvidias Rezepte für den DGX Spark, aber mit meiner Speichergrenze von 0,50, für Muse Glimmer Nvidias NVFP4-Fassung. Gibt es kein passendes Rezept, nehme ich Ollama mit dem Standard-Tag der Bibliothek. Die Ollama-Version auf meinem Spark kann ich ohne Administratorrechte nicht aktualisieren. Lädt sie ein neues Modell nicht, läuft Ollama in einem Container. Die Laufzeit und ihre Version stehen in jeder Zeile.
Speicher. Höchstens 0,50: unter SGLang als --mem-fraction-static, ausdrücklich gesetzt, unter vLLM als --gpu-memory-utilization. Nvidias vLLM-Rezept für Lightning setzt 0,85. Diesen Wert übernehme ich nicht. Welchen Wert ich je Modell gefahren habe, steht in der Tabelle.
Geschwindigkeit. Decode in Tokens pro Sekunde: 300 Tokens Ausgabe, ein Stream, abgerufen von meinem Mac über Tailscale, wie bei meiner Qwen-Messung im August. Prefill in Tokens pro Sekunde und die Zeit bis zum ersten Token: ein Prompt mit rund 7.000 Tokens, je nach Tokenizer 6.770 bis 7.332. Jede Messung läuft dreimal, in der Tabelle steht der Median.
Gleiche Bedingungen. Meine Qwen-Messung im August lief ohne Thinking und mit dem Entwurfsmodell DFlash2 für spekulatives Decoding. Im neuen Aufbau messe ich jedes Modell einmal ohne spekulatives Decoding. Liefert der Hersteller ein Entwurfsverfahren mit, also DFlash2 bei Qwen, DFlash bei Muse Glimmer oder MTP, DSpark und LiLiCorr bei den Nemotron-Modellen, kommt ein zweiter Lauf damit dazu. Denken bzw. Reasoning ist bei allen Modellen aus oder auf der niedrigsten Stufe.
Speicherbedarf und Kontext. Die Größe der Gewichte auf der Platte, der belegte Arbeitsspeicher während des Laufs und der eingestellte Kontext. Zusätzlich prüfe ich, ob das Modell mit 128.000 Tokens Kontext startet.
Qualität. Sechs feste Aufgaben aus meinem Alltag, für jedes Modell derselbe Wortlaut, alle auf Deutsch:
- Eine Kundenmail aus fünf Stichpunkten schreiben (Ton, Rechtschreibung, alle Punkte enthalten).
- Ein deutsches Dokument von rund sechs Seiten zusammenfassen und fünf Kontrollfragen dazu beantworten (Fakten richtig).
- Werkzeuge aufrufen: JSON nach einem vorgegebenen Schema für drei Funktionen, dabei eine absichtlich fehlerhafte Werkzeug-Antwort (erkennt das Modell den Fehler und versucht es neu).
- Eine Python-Funktion schreiben, für die Tests vorgegeben sind (laufen die Tests durch).
- Ein Agentenlauf im Terminal-Agenten Pi: eine kleine Änderung über zwei Dateien in einem Test-Repository (Tests grün, Zahl der Schritte).
- Eine Tabelle aus einem Screenshot auslesen (nur Modelle mit Bild-Eingabe).
Jede Aufgabe bewerte ich als bestanden, teilweise oder nicht bestanden, nach Kriterien, die vor dem ersten Lauf feststehen. Eine Gesamtpunktzahl in Prozent rechne ich bewusst nicht aus. Dafür sind sechs Aufgaben zu wenige.
Download. Die fünf neuen Modelle, die ich selbst messe, bringen zusammen rund 110 GB an Gewichten mit. Dazu kommen Container-Images und Entwurfsmodelle, allein das SGLang-Image für meinen Qwen-Server hat 39 GB. Deshalb lade ich nacheinander und lösche jedes Testmodell nach seiner Messung wieder. Die beiden Gemma-Modelle kamen mit rund 8 MB/s herunter, 18 GB in 37 Minuten.
Abweichungen vom Plan. Einiges lief anders als oben beschrieben, die Werte in den Tabellen gelten für diesen tatsächlichen Aufbau:
- Alle vLLM-Modelle liefen mit vLLM 0.33.0 statt der Versionen aus Nvidias Rezepten.
- Die Gemma-Modelle liefen in einem Ollama-Container mit Version 0.40.13, weil das Ollama auf meinem Spark (0.20.7) Gemma 4 nicht lädt. Sie liefen in 4 Bit (Q4_K_M) über llama.cpp, die übrigen Modelle in NVFP4 über SGLang oder vLLM. Geschwindigkeit und Speicher sind deshalb Werte des jeweiligen Gesamtaufbaus, kein reiner Modellvergleich.
- Qwen ohne Entwurfsmodell lief ohne torch.compile und mit einem auf 150.000 Tokens begrenzten Cache, weil der erste Start mit den Standardwerten zu viel Speicher belegte.
- Mit Entwurfsmodell habe ich nur Qwen (DFlash2) und Lightning (DSpark) gemessen. Muse Glimmer mit DFlash und Bolt mit LiLiCorr fehlen, weil das Zeitfenster auf dem Gerät nicht reichte.
- Zusätzlich zum deutschen Fließtext habe ich die Ausgabe einmal mit Code gemessen (300 Tokens, eine kleine Python-Klasse mit Tests), weil spekulatives Decoding stark vom Inhalt abhängt. Der Fließtext bleibt der Hauptwert.
- Bolt ist beim ersten Agentenlauf mit einem Speicherzugriffsfehler der Laufzeit abgestürzt. Das ist kein Modellergebnis, deshalb habe ich den Lauf nach einem Neustart einmal wiederholt.
Drei Modelle, die ich nicht selbst messe: Fremdmessungen
gpt-oss-120b, Mistral Small 4 und Nemotron 3.5 Super messe ich nicht selbst. Das hat zwei Gründe. Erstens die Speichergrenze: Mit 0,50 bleiben rechnerisch knapp 60 GB, die Gewichte der drei liegen mit 65,2, 70,8 und 75,0 GB darüber. Die Fremdmessungen unten zeigen, dass sie im Betrieb noch mehr belegen, bei Mistral Small 4 rund 99 GB, bei Nemotron Super fast 100 GiB. Zweitens der laufende Betrieb: Auf dem Gerät läuft mein produktiver Qwen-Server, dazu Spracherkennung und Sprachausgabe. Für eines dieser Modelle müsste ich das alles für viele Stunden anhalten, dazu kommt der Download von 65 bis 75 GB je Modell.
Für diese drei nenne ich deshalb veröffentlichte Messungen Dritter auf dem DGX Spark bzw. einem Rechner mit GB10-Chip, jede als Fremdmessung gekennzeichnet, mit Datum und Aufbau. Nachgeprüft habe ich keine davon. Die Aufbauten unterscheiden sich von meinem, vergleiche die Zahlen deshalb nur grob mit meinen eigenen Werten.
Zwei Dinge fallen auf. gpt-oss-120b liegt in der Fremdmessung mit nur 5,1 Milliarden aktiven Parametern im Bereich meines Qwen-Werts vom August, seine Gewichte sind aber fast dreimal so groß. Nemotron Super braucht mit Nvidias eigenem Rezept praktisch das ganze Gerät, das Rezept setzt 0,75 statt meiner 0,50, und der Autor der Messung schreibt, das heiße „dedicating the entire DGX Spark to this model“.
Ergebnisse: Geschwindigkeit, Speicher, Kontext
Den Decode-Wert vom August habe ich in meinem Beitrag DGX Spark im Test: lohnt sich der Kauf? beschrieben. Den Prefill habe ich erst am 24.10.2026 selbst gemessen: Ein Prompt mit rund 125.000 Tokens ohne Cache brauchte 123 Sekunden, also rund 1.000 Tokens pro Sekunde, während andere Dienste auf derselben GPU liefen. Die rund 1.500 Tokens pro Sekunde für den Prefill nennt das Setup-Rezept, dem ich folge, gemessen habe ich sie nicht. Damit alle Zeilen vergleichbar sind, habe ich Qwen im neuen Aufbau noch einmal gemessen, einmal mit und einmal ohne Entwurfsmodell. Die Werte für gpt-oss-120b, Mistral Small 4 und Nemotron Super stehen oben bei den Fremdmessungen.
¹ vLLM reserviert mit 0,50 immer rund die Hälfte des Geräts für Gewichte, Kontext-Cache und Graphen. Die Zahl zeigt diese Reservierung, nicht den tatsächlichen Bedarf. Für den Bedarf zählen die Gewichte plus der Kontext.
Jeder Wert ist der Median aus drei Läufen, gemessen am 3. und 4. November 2026, ohne Denken bzw. auf der niedrigsten Stufe. Drei Dinge fallen auf. Erstens hängt spekulatives Decoding stark am Inhalt: Qwen mit DFlash2 schafft bei Code 50,1 Tokens pro Sekunde und liegt damit beim Augustwert von 50,7, bei deutschem Fließtext aber nur bei 18,2. Ohne Entwurfsmodell sind es 12,6, egal bei welchem Inhalt. Bei Lightning bringt DSpark für Code fast das Doppelte, für Fließtext kaum etwas. Zweitens ist der Prefill ohne Entwurfsmodell schneller, bei Qwen 2.058 statt 1.432 Tokens pro Sekunde, weil kein Entwurfsmodell mitrechnet. Drittens ist Lightning mit Abstand am schnellsten, es hat nur 3 Milliarden aktive Parameter, kann aber keine Bilder verarbeiten. Die vLLM-Rezepte für Muse Glimmer und die Nemotron-Modelle liefen auch mit meiner Speichergrenze von 0,50 und starteten alle mit 131.072 Tokens Kontext. Eine Nachmessung am 4. November auf meinem inzwischen anders eingestellten Qwen-Dienst ergab 20,8 Tokens pro Sekunde bei Fließtext und 51,2 bei Code. Ob der Unterschied von der Einstellung oder von der Tagesform kommt, lässt sich mit je einem Lauf nicht sagen.
Ergebnisse: die sechs Qualitätsaufgaben
Für gpt-oss-120b, Mistral Small 4 und Nemotron Super gibt es hier keine eigenen Ergebnisse, weil ich sie nicht selbst betreibe.
Was auffiel: Bei der Kundenmail erfand Muse Glimmer eine „Bestellung“, die es nicht gab, und Lightning einen „von Ihnen gewünschten“ Termin. Bei den Kontrollfragen schrieben beide Qwen-Läufe den richtigen Rechenweg 30 minus 10 minus 4 auf und kamen trotzdem auf 26 statt 16. Nach der absichtlich fehlerhaften Werkzeug-Antwort haben Qwen ohne Entwurfsmodell, Muse Glimmer und beide Nemotron-Modelle es erneut versucht und die Mail erst nach dem erfolgreichen Termin geschickt. Qwen mit DFlash2 und Gemma 4 31B schickten die Mail schon im selben Schritt wie den gescheiterten ersten Versuch. Beide Gemma-Modelle meldeten den Fehler ehrlich, versuchten es aber nicht noch einmal. Die Python-Aufgabe und den Agentenlauf in Pi haben alle sieben Läufe bestanden, Qwen mit DFlash2 in 23 Sekunden, Bolt in knapp sechs Minuten.
Welches Modell für welchen Zweck
Zwei Dinge folgen schon aus den Modellkarten. Brauchst du Bild-Eingabe, etwa für Screenshots oder gescannte Belege, fallen gpt-oss-120b und Nemotron 3.5 Lightning weg, beide verarbeiten nur Text. Brauchst du sehr langen Kontext, nennen Qwen3.8-27B und die Nemotron-Modelle Super und Lightning bis zu einer Million Tokens, Muse Glimmer dagegen 131.072 und mehr. Wie viel davon auf dem Gerät tatsächlich nutzbar ist, hängt am Speicher und zeigt die Spalte „Startet mit 128k“.
Aus meinen Messwerten folgt je Zweck:
- Deutsche Texte und Mails: Gemma 4 31B hat als einziges Modell Kundenmail und Zusammenfassung bestanden. Dafür brauchst du Geduld: 22,2 Tokens pro Sekunde und 11,7 Sekunden bis zum ersten Token bei rund 7.000 Tokens Eingabe.
- Coding und Agentenläufe: Qwen3.8-27B mit DFlash2 schafft 50,1 Tokens pro Sekunde bei Code und hat den Agentenlauf in Pi mit 5 Werkzeugaufrufen in 23 Sekunden erledigt. Lightning mit DSpark ist bei Code mit 144,1 noch schneller, hat aber die Mail nur teilweise und die Zusammenfassung nicht bestanden.
- Lange Dokumente: Hier gibt es keinen klaren Sieger. Lightning liest mit 5.756 Tokens pro Sekunde am schnellsten ein, hat aber nur 3 von 5 Kontrollfragen richtig beantwortet. Muse Glimmer und Gemma 4 31B hatten alle fünf richtig, lesen mit 1.121 bzw. 614 Tokens pro Sekunde aber deutlich langsamer ein.
- Schnelle Antworten nebenher: Gemma 4 26B-A4B mit 68,0 Tokens pro Sekunde bei Fließtext und 19,4 GiB Speicher, bei vier von sechs bestandenen Aufgaben.
Für Coding auf dem DGX Spark spricht nach diesen Werten weiter am meisten für Qwen3.8-27B mit DFlash2.
Was diese Messung nicht zeigt
Es ist ein Gerät, eine Softwareversion je Laufzeit und eine Handvoll Aufgaben aus meinem Alltag. Mit einem neuen Treiber, einer neuen SGLang-Version oder anderen Quantisierungen sehen die Zahlen anders aus. Ein Modell, das bei meinen sechs Aufgaben schwach ist, kann bei deinen stark sein. Nimm die Tabellen deshalb als Ausgangspunkt für deinen eigenen Test, nicht als Rangliste.
Häufige Fragen
Welches ist das beste Modell für den DGX Spark?
Das hängt davon ab, wofür du es brauchst. Für Bild-Eingabe kommen nur die Modelle mit Bild-Encoder infrage, für lange Dokumente die mit großem Kontext.
In meinem Aufbau gab es keinen Gesamtsieger. Je fünf von sechs Aufgaben bestanden Gemma 4 31B mit 22,2 Tokens pro Sekunde, Qwen3.8-27B ohne Entwurfsmodell mit 12,6 und Muse Glimmer 30B mit 12,2. Qwen mit DFlash2 bestand vier Aufgaben und ist bei Code mit 50,1 Tokens pro Sekunde rund viermal so schnell wie der Lauf ohne Entwurfsmodell, der zusätzlich ohne torch.compile lief.
Wie groß darf ein Modell auf dem DGX Spark sein?
Nvidia nennt für ein Gerät mit 128 GB Modelle bis 200 Milliarden Parameter. In der Praxis zählt die Größe der Gewichte plus der Speicher für den Kontext. Bei mir bleiben unter SGLang mit meiner 0,50-Regel rechnerisch knapp 60 GB, das reicht für alle Modelle der 30B-Klasse in 4 Bit.
Läuft gpt-oss-120b auf dem DGX Spark?
Ja. Das llama.cpp-Projekt hat es auf einem DGX Spark gemessen: 58,7 Tokens pro Sekunde ohne Vorkontext und 42,8 bei 32.768 Tokens Vorkontext, Stand 05.02.2026. Das ist eine Fremdmessung. Selbst messe ich gpt-oss-120b nicht, weil die Gewichte mit 65,2 GB über meine Speichergrenze von 0,50 gehen.
Ollama oder SGLang auf dem DGX Spark?
Für Qwen3.8-27B habe ich im August 2026 unter SGLang 50,7 Tokens pro Sekunde gemessen, unter vLLM mit MTP 24 bis 26. Ollama ist einfacher einzurichten und für einen schnellen Test gut. Für den Dauerbetrieb mit einer Schnittstelle für mehrere Werkzeuge bleibe ich bei SGLang.
Laufen DeepSeek V4 oder Mistral Large 4 auf dem DGX Spark?
Nicht auf einem einzelnen Gerät. DeepSeek-V4-Pro hat laut Modellkarte 1,6 Billionen Parameter, Mistral Large 4 laut Mistral rund eine Billion. Selbst in 4 Bit sind das mehrere hundert Gigabyte: Die NVFP4-Fassung von Mistral Large 4 auf Hugging Face ist 610 GB groß, ein Vielfaches dessen, was ein DGX Spark hat.
Wie du weitermachst
Wenn du den DGX Spark noch nicht hast, lies vor dem Kauf DGX Spark kaufen: Preis und Alternativen und Eigener KI-Server: Hardware und Kosten. Wie du ein Modell unter Ollama, vLLM oder SGLang zum Laufen bringst, steht in Lokale KI einrichten: Ollama bis SGLang. Einen Überblick über alle offenen Modelle, auch die zu großen, gebe ich in meinem Vergleich der Open-Source-KI-Modelle. Den direkten Vergleich der Modelle der 30B-Klasse findest du in Muse Glimmer vs Qwen 3.8 vs Gemma 4. Was Mistral Small 4, Ministral und Large 4 technisch und bei der Lizenz mitbringen, steht in Mistral lokal betreiben: Modelle und Lizenzen.
