Zum Hauptinhalt springen
DGX Spark verfügt über 128 GB gemeinsamen Speicher, der sowohl von der Grace-CPU als auch von der Blackwell-GPU genutzt wird. Dieser Speicher reicht für dichte Modelle bis zu einer Größe von etwa 70B bei einer Quantisierung von 4 Bit aus; ebenso für MoE-Modelle mit insgesamt bis zu 120B Parametern bei NVFP4. Doch nicht jedes Modell ist in jeder Quantisierung nutzbar, und nicht jeder Laufzeitumgebung wird die Struktur des gemeinsamen Speichers gleichermaßen unterstützt. Auf dieser Seite erfahren Sie, welche Modelle funktionieren, welche unter Einschränkungen laufen und welche überhaupt nicht verwendet werden können.

​
Kurzfassung

Ein einzelnes DGX Spark-System kann dichte Modelle bis zu einer Größe von etwa 70B bei Q4 verarbeiten sowie MoE-Modelle mit insgesamt bis zu 120B Parametern bei NVFP4. MoE-Modelle eignen sich besonders gut, da pro Token nur ein Teil der Parameter aktiviert wird, was bei gleichem Speicherbedarf eine höhere Durchsatzrate ermöglicht.

​
Wie wird das 128 GB an Speicher genutzt?

DGX Spark verfügt über keinen dedizierten VRAM. Die Grace-CPU und die Blackwell-GPU teilen sich einen einzigen Speicherpool mit 128 GB Kapazität, der über einen Interconnect mit 273 GB/s Bandbreite verbunden ist. Beim Laden eines Modells nutzen 3 Komponenten diesen Speicherpool:
  1. Modellgewichte – der größte fixe Verbrauch, abhängig von der Anzahl der Parameter sowie der gewählten Quantisierung.
  2. KV-Cache – dessen Größe von der Kontextlänge sowie der Anzahl gleichzeitiger Anfragen abhängt. Weitere Details zur Berechnung finden Sie unter DGX Spark Memory Tuning.
  3. System- und CUDA-Overhead – typischerweise beträgt dieser Verbrauch bei DGX OS, der CUDA-Laufzeitumgebung sowie den CUDA-Graphen von vLLM etwa 4 bis 8 GB.
Nach Abzug des System-Overheads bleibt somit ein praktisch nutzbarer Speicherbereich von etwa 115 bis 120 GB für Modellgewichte und KV-Cache übrig.
DeepSeek-V4-Flash-0731 does not fit on 1 Spark. 2 Sparks provide enough aggregate memory to shard its published 162–167 GB weight floor, but published dual-Spark evidence is community-tested and needs 0731 revalidation. Start at 32K–128K context and read DeepSeek V4 Flash local hardware before configuring a cluster.

​
Kompatibilität mit dichten Modellen

Dichte Modelle aktivieren bei jedem Token sämtliche Parameter. Infolgedessen wachsen sowohl der Gewichtsspeicherbedarf als auch die Rechenlast proportional zur Anzahl der Parameter – ein 70B dichtes Modell benötigt etwa doppelt so viel Speicher und doppelt so viele Rechenoperationen wie ein 35B dichtes Modell. Auf dem DGX Spark lassen sich dichte Modelle bis zu einer Größe von 70B bei einer Quantisierung von 4 Bit nutzen; die gleichzeitige Verarbeitung mehrerer Anfragen wird jedoch durch die Belastung des KV-Caches eingeschränkt.
Bei Qwen3-32B zeigen Community-Benchmarks auf derselben Hardware erhebliche Unterschiede in der Leistung (9 gegenüber 44 Tokens pro Sekunde). Diese Unterschiede resultieren aus Einstellungen zur Flash-Attention-Technik sowie dem verwendeten Quantisierungsverfahren. Testen Sie Ihre spezifische Konfiguration, bevor Sie sich für eine Deployment-Option entscheiden.
Ein 70B dichtes Modell im NVFP4-Format benötigt ca. 35 GB Speicherplatz für die Gewichte; zusätzlich verbraucht jeder gleichzeitig aktive Nutzer zusätzlichen KV-Cache-Speicher. Laut Community-Erfahrungen ist die maximale Anzahl gleichzeitiger Nutzer auf 5 bis 10 begrenzt, danach reagiert das System nicht mehr. Bei Multi-User-70B-Anwendungen empfiehlt sich die Nutzung von zwei DGX Sparks.

​
Einschränkungen bei dichten Modellen im Zusammenhang mit dem Unified Memory

  • ChatGPT-OSS-20B auf Ollama weist zwar eine GPU-Auslastung von 89% auf, doch die Latenzzeiten sind inakzeptabel. Die Community empfiehlt daher den Wechsel zu vLLM oder SGLang für dieses Modell.
  • Qwen3.6-27B at NVFP4 is estimated to achieve 40–55 tok/s for a single user, based on similar dense models in the 27–32B range. The wide spread reflects differences in quantization backend and flash attention settings. With ~14–15 GB for weights, you have ample room for long context on a single Spark.
  • 70B dichte Modelle funktionieren zwar, stellen jedoch die praktische Obergrenze für dichte Architekturen auf einem einzelnen Spark dar. Der KV-Cache pro gleichzeitiger Anfrage ist dabei der limitierende Faktor, nicht der Speicherbedarf der Gewichte.
  • Bei dichten Modellen mit einer Größe über 70B ist ein Cluster aus zwei Spark-Systemen erforderlich. Weitere Informationen finden Sie unter Ein oder zwei DGX Sparks.

​
Kompatibilität von MoE-Modellen

MoE-Modelle stellen die ideale Wahl für DGX Spark dar. Alle Expertengewichte werden in den Arbeitsspeicher geladen, doch pro Token aktiviert sich lediglich ein Teil davon – dadurch erhalten Sie die Leistungsfähigkeit eines großen Modells bei gleichzeitig geringen Rechenkosten.
Gemma-4-26B-A4B-it lässt sich auf DGX Spark nicht nutzen, da der gpu_memory_utilization-Parameter von vLLM bei der Start-Profilierung im Rahmen des Unified Memory (SM121) nicht berücksichtigt wird. Infolgedessen reagiert das System nicht mehr. Als Abhilfe muss die NVFP4-Quantisierung explizit eingesetzt werden; laut Berichten aus der Community ist diese Lösung jedoch bis Mitte 2026 noch unvollständig. Verfolgen Sie die Entwicklungen unter vLLM-Problem #46307.

​
Hinweise zur Leistung von MoE-Modellen

  • Qwen3.5-35B-A3B erreicht bei NVFP4 eine konstante Geschwindigkeit von 47 bis 50 Tokens pro Sekunde für einen einzelnen Nutzer. Die Zeit bis zum ersten Token verringert sich dabei von 3 Sekunden (Ollama) auf nur noch 0.12 Sekunden bei Verwendung von vLLM.
  • Qwen3.6-35B-A3B liefert mit der Standardversion von vLLM eine konstante Geschwindigkeit von 47 bis 50 Tokens pro Sekunde für einen Nutzer. Mittels des Atlas-Engines (reine Rust/CUDA-Implementierung) steigt die Geschwindigkeit auf bis zu ~120 Tokens pro Sekunde – das entspricht einer Steigerung um 2.8x im Vergleich zur Standardversion – und es werden bis zu 1M Tokens als Kontext verarbeitet.
  • Qwen3.5-122B-A10B hält eine Geschwindigkeit von ~30 Tokens pro Sekunde bei JSON-KIE-Aufgaben aufrecht; die Erfolgsrate bei der Verarbeitung liegt bei 100% Prozent. Unter einer Last von 100K gleichzeitigen Anfragen kommt es jedoch zu Leistungseinbrüchen.
  • GLM-4.5-Air mit 106B MoE-Elementen und 12B aktiven Parametern gilt in der Community als das optimale Modell für DGX Spark. Es passt zudem gut in das verfügbare Speicherbudget.
GLM-4.6 (insgesamt 357B Einheiten / 32B davon aktiv) lässt sich nicht auf einem einzigen DGX Spark betreiben. Bei einer Quantisierung der Stufe Q4 werden rund 178 GB benötigt – das übersteigt das verfügbare Speichervolumen von 128 GB bei weitem. Auf Hardware mit 128 GB empfiehlt sich stattdessen die Nutzung von GLM-4.5-Air. Eine vollständige Übersicht der Varianten finden Sie unter GLM-Familie.

​
Vergleich verschiedener Quantisierungsformate auf Basis von SM121

Der Blackwell-GPU-Chip in DGX Spark basiert auf der SM121-Architektur. Nicht alle Quantisierungsformate werden nativ unterstützt.
NVFP4 ist die empfohlene Standardeinstellung für DGX Spark. Diese Methode wird vom SM121-Hardwaremodul nativ unterstützt, führt zu einer Verringerung der Speichergröße um 75% bei geringem Qualitätsverlust und ist sowohl mit vLLM als auch mit dem Atlas-Engine kompatibel. Nutzen Sie GGUF Q4_K_M ausschließlich, wenn Sie llama.cpp oder Ollama einsetzen.

​
Begrenzungen der Kontextlänge

Die Kontextlänge beeinflusst unmittelbar den Speicherbedarf des KV-Caches, wodurch weniger Speicherplatz für Modellgewichte zur Verfügung steht. Auf DGX Spark wird der KV-Cache aus demselben 128-GB-Pool gespeichert, der auch für Modellgewichte, den CUDA-Laufzeitumgebung sowie das Betriebssystem genutzt wird. Die Nutzung eines FP8-KV-Caches (--kv-cache-dtype fp8) reduziert diese Werte um die Hälfte, wobei die Qualität nur um weniger als 2% nachlässt; dadurch lässt sich der verfügbare Kontext effektiv verdoppeln. Für detaillierte Berechnungen zur Größenbestimmung des KV-Caches sowie zu Anpassungsparametern siehe DGX Spark Memory Tuning.

​
Kimi K3 auf DGX Spark

Kimi K3 does not fit on any practical DGX Spark cluster. The model’s 2.8T total parameters (~50B active per token through Stable LatentMoE) need about 1.4 TB at the native MXFP4 precision. Eight DGX Sparks pool 1 TB and still fall 376 GB short. NVIDIA documents Spark clusters up to 4 nodes (512 GB), and Moonshot recommends a supernode with 64 or more accelerators for K3. For the full calculation, see the Kimi K3 hardware deep dive. Derzeit passen auf Spark nur die oben aufgeführten Modelle: bis zu etwa 70B Parameter bei rein dichten Architekturen in Q4-Präzision sowie bis zu 120B Parameter bei MoE-Modellen in NVFP4-Präzision pro einzelnem Knoten. Unter Was statt Kimi K3 laufen lässt? finden Sie die optimale Wahl je nach Anzahl der Spark-Knoten.

​
Qwen3.8 feasibility

The Qwen3.8 flagship shipped in August 2026 as Qwen3.8-2.4T-A95B: a Mixture-of-Experts model with 2.4 trillion total parameters and 95B active per token, text-only, released under Qwen’s custom qwen3.8-max license. The generation also includes Qwen3.8-27B (released 2026-08-14, Apache-2.0), a dense vision-language model that does fit a single Spark — see the verdict below the cluster math.

​
Speicheranforderungen je nach Quantisierung

Berechnungen zum reinen Gewichtsspeicher (ohne KV-Cache, CUDA-Graphen sowie System-Overhead): Even at the most aggressive quantization, a single DGX Spark cannot run Qwen3.8-2.4T-A95B. This is a multi-node model that requires at least 10 Sparks at Q4 — and realistically 20+ Sparks at FP8 for reasonable KV cache headroom.

​
Dimensionierung eines Multi-Knoten-Clusters

Bei MoE-Modellen werden alle Expertengewichte in den Arbeitsspeicher geladen, obwohl pro Token nur ein Teil davon aktiv wird. Qwen3.8-2.4T-A95B aktiviert 95B von insgesamt 2.4T Experten, doch die erforderlichen 1.2 TB an Speicherplatz bei Q4 stellen eine harte Untergrenze dar. Der Vorteil von MoE-Modellen liegt in der Rechenleistung – weniger FLOPs pro Token – nicht im Speicherbedarf.

​
Status der Laufzeitunterstützung

Qwen stellt neben den 2.4T-Gewichten auch Server-Einrichtungsanleitungen für vLLM, SGLang und TokenSpeed bereit. Unterstützung für llama.cpp, Ollama sowie LM Studio ist bislang nicht dokumentiert; die hybride Architektur aus Gated DeltaNet und Gated Attention erfordert spezielle Kernel-Anpassungen, bevor eine GGUF-basierte Nutzung möglich wird.

​
Das Qwen3.8-Modell, das auf einem einzigen Spark-System läuft

Qwen3.8-27B stellt das Einzelrechner-Modell dieser Generation dar: ein dichtes 27B Vision-Language-Modell, das am 2026-08-14 unter der Apache-2.0-Lizenz veröffentlicht wurde. Jede offizielle Präzisionsvariante passt problemlos in einen Spark – die 55.6 GB große BF16-Version lässt sich direkt nutzen, während die offizielle 30.9 GB große FP8-Version etwa 90 GB des insgesamt 128 GB großen Speicherpools für den KV-Cache freilässt. Betreiben Sie das Modell mittels vLLM oder SGLang; bislang existieren keine GGUF- oder NVFP4-Varianten. Alle Details zu Speicheranforderungen finden Sie auf der Qwen3.8-Modellseite; nach erfolgter Prüfung werden dort auch getestete Spark-Konfigurationen aufgeführt.

​
GLM-5.2 feasibility

​
Bewerten Sie MoE-Modelle nicht allein anhand aktiver Parameter

Aktive Parameter beeinflussen lediglich die Rechenlast pro Token, nicht die minimale Speichermenge für Gewichte. GLM-5.2 verwendet insgesamt 753B Parameter; laut Hugging Face sind es 753,329,940,480 verteilt auf 78 Schichten, wobei pro Token 8 von 256 Experten aktiv werden sowie zusätzlich 1 gemeinsame Parameter. Die theoretische Untergrenze bei exakt 4 Bits pro Gewicht ergibt sich daraus.
Dies entspricht etwa 3-fach dem Speicherbedarf von einem einzelnen DGX Spark mit 128 GB; folglich reichen 1 Sparks nicht aus. Selbst 2 Sparks mit jeweils 256 GB verfügen allein für die Gewichte nicht über genügend Kapazität. Erst 3 Sparks erreichen theoretisch die erforderliche Menge von 384 GB, doch für Format-Metadaten, das Betriebssystem, Laufzeitpuffer sowie KV-Cache bleiben nur noch etwa 7 GB GB übrig – was in der Praxis unbrauchbar ist. Erst mit 4 Sparks und jeweils 512 GB wird ein echter Puffer erreicht. Für FP8 wären allein für die Gewichte 753 GB Sparks nötig, was einem Bedarf von 6 Sparks ohne jegliche Zusatzlast entspricht.
Man sollte nicht behaupten, dass GLM-5.2 auf 1 bzw. 2 Sparks bei INT4 oder FP8 ausgeführt werden kann – die angegebenen Größenangaben des 753B-Checkpoints widersprechen dies. Ebenso sollte man nicht allein aufgrund der Parameteranzahl eine 1M-Kontextlänge auf einem 4-Spark-Cluster versprechen. Zuerst müssen die verfügbaren Download-Dateien, die Laufzeitunterstützung sowie der tatsächliche Verbrauch des KV-Caches überprüft werden.

​
Empfohlene Modelle nach Anwendungsfall

Haben Sie ein Modell ausgewählt? Verbinden Sie es nun.

Weisen Sie Ihrer DGX Spark Deployment einen authentifizierten Endpunkt unter https://api.tokios.com zu – dabei sind keine eingehenden Ports erforderlich; der Vorgang dauert etwa 5 Minuten.

​
Entscheidung zwischen Geschwindigkeit und Modellgröße

Der grundlegende Kompromiss bei DGX Spark besteht zwischen Modellleistung und Durchsatzgeschwindigkeit:
  • Falls Geschwindigkeit im Vordergrund steht (zum Beispiel bei Codierungsagenten oder interaktiven Chats): Wählen Sie ein 35B-MoE-Modell im NVFP4-Format. Sie erhalten so 47 bis 50 Tokens pro Sekunde – bzw. 120 Tokens pro Sekunde bei Verwendung von Atlas –, was ein sofortiges Antwortverhalten gewährleistet.
  • Falls Qualität im Vordergrund steht (bei komplexen logischen Aufgaben oder Forschungszwecken): Wählen Sie das größtmögliche passende Modell – etwa Qwen3.5-122B-A10B oder GLM-4.5-Air – und akzeptieren Sie dabei einen Durchsatz von 25 bis 30 Tokens pro Sekunde.
  • Falls die gleichzeitige Nutzung durch mehrere Personen im Vordergrund steht (zum Beispiel bei Teamumgebungen): Bleiben Sie bei einem 35B-MoE-Modell und nutzen Sie den FP8-KV-Cache, um die Anzahl gleichzeitiger Nutzer zu maximieren. Die zugrundeliegenden Berechnungen finden Sie in der Dokumentation DGX Spark Memory Tuning.

​
Überprüfen Sie die Kompatibilität auf Ihrer Spark-Instanz

Community-Benchmarks liefern zwar wertvolle Hinweise, doch Ihre spezifische DGX OS-Version, der CUDA-Treiber sowie die verwendete vLLM-Version können abweichendes Verhalten zeigen. Führen Sie folgende Tests durch, bevor Sie sich für ein Modell entscheiden:
  1. Prüfen Sie den verfügbaren Speicher vor dem Start:
  2. Starten Sie das Modell mit konservativen Einstellungen:
  3. Erhöhen Sie max-model-len schrittweise, bis Sie den gewünschten Kontextumfang oder die erforderliche Speichernutzung erreichen.
  4. Überwachen Sie das System während der Inferenz:
  5. Benchmark-Durchsatz:
Falls das System in irgendeinem Schritt nicht mehr reagiert, führen Sie einen Neustart durch und verringern Sie gpu_memory_utilization um 0.05.

​
Stellen Sie Ihr Modell mithilfe von Tokios bereit.

Sobald Ihr Modell auf dem DGX Spark mittels vLLM, Ollama oder llama.cpp läuft, können Sie es über einen einzigen authentifizierten Endpunkt bereitstellen, ohne eingehende Ports öffnen zu müssen. Der Tokios-Connector initiiert die Verbindung vom Spark aus und stellt Ihnen einen OpenAI- sowie Anthropic-kompatiblen API-Schlüssel unter https://api.tokios.com zur Verfügung. Weitere Informationen zur vollständigen Einrichtung finden Sie unter Ihren DGX Spark in einen privaten Endpunkt umwandeln. Alternativ können Sie direkt zu ein Modell registrieren gehen, um Ihre lokale Upstream-Modell-ID mit einem Deployment-Namen zu verknüpfen.

vLLM auf dem DGX Spark

Schrittweise Anleitung zur Installation von vLLM samt NVFP4-Einstellungen für verschiedene Modellgrößen.

Speichereinstellungen für den DGX Spark

Größenanpassung des KV-Caches, Abwägungen bei Batch-Größen sowie Parameteranpassungen für 128 GB Speicher.

Ein oder zwei DGX Sparks?

Wann ist es sinnvoll, einen zweiten Spark hinzuzufügen, um verteilte Inferenzprozesse für Modelle zu ermöglichen, die mehr als 1 Knoten erfordern.

Grundlagen zur Quantisierung

Informieren Sie sich über NVFP4, AWQ, FP8 sowie GGUF, bevor Sie sich für ein Format entscheiden.