DGX Spark VRAM: was in 128 GB Unified Memory passt und was sich darauf feinabstimmen lässt

Wie viel VRAM hat der DGX Spark

Der DGX Spark hat 128 GB Unified Memory (LPDDR5x), die sich die GPU mit der CPU teilt; einen eigenen Grafikspeicher (VRAM) gibt es daher nicht, und auf dem System mit 128 GB meldet das Betriebssystem davon etwa 119 bis 122 GiB. NVIDIAs Portierungsleitfaden schreibt, das System nutze „eine Unified-Memory-Architektur (UMA), bei der sich die GPU den Systemspeicher (DRAM) mit der CPU und anderen Recheneinheiten teilt“. Es sind 128 GB LPDDR5x an einer 256 Bit breiten Schnittstelle (NVIDIA nennt auch eine Konfiguration mit 64 GB, die seit dem 23. Oktober 2026 nur bei OEM-Partnern erhältlich ist), und der Arm-Prozessor mit 20 Kernen, DGX OS, die Desktop-Sitzung und die GPU schöpfen alle aus diesem einen Pool. Abgesehen von einer Reserve für die Anzeige, standardmäßig 2 GB, seit NVIDIAs Release vom Juli 2026 per BIOS auf 4 GB umstellbar und seit dem Release vom Oktober 2026 auf einem Spark ohne angeschlossenen Bildschirm bis hinunter zu 512 MB, ist nichts für Grafik reserviert, und auch für das Modell ist kein fester Anteil vorgesehen. Speicherbandbreite, TDP und CUDA-Kerne stehen in unseren technischen Daten des DGX Spark.

NVIDIA dokumentiert zwei Folgen, auf die neue Nutzer früh stoßen. Erstens kann nvidia-smi auf dieser Plattform die gesamte GPU-Speichernutzung nicht melden: Laut der Seite mit den bekannten Problemen zeigt das Werkzeug „Memory-Usage: Not Supported“ an, obwohl der GPU-Speicher je Prozess aufgeführt wird, weil eine integrierte GPU keinen eigenen Framebuffer hat, den es zählen könnte. Zweitens warnt der Portierungsleitfaden, die von cudaMemGetInfo gemeldete Speichergröße könne kleiner sein als der tatsächlich belegbare Speicher, da die CPU zusätzliche DRAM-Seiten freigeben könne, und hält Entwickler dazu an, den vom Betriebssystem rückholbaren Speicher zu berücksichtigen, statt sich allein auf diesen Aufruf zu verlassen.

Damit liefert keines der beiden Werkzeuge, die sonst zeigen, ob ein Modell passt, hier einen korrekten Wert: nvidia-smi meldet keinen Gesamtwert, und cudaMemGetInfo meldet zu wenig. NVIDIA dokumentiert auch das umgekehrte Problem. Das Unsloth-Playbook warnt, man könne „auf Speicherprobleme stoßen, selbst wenn man innerhalb der Speicherkapazität von DGX Spark bleibt“, weil viele Anwendungen noch an UMA angepasst werden, und nennt eine einzeilige Abhilfe, die den Puffer-Cache leert: sync, dann eine 3 in /proc/sys/vm/drop_caches schreiben. Ein Out-of-Memory-Fehler auf dem DGX Spark bedeutet deshalb nicht immer, dass der Speicher voll ist.

NVIDIAs RTX Spark ist eine eigene Plattform für Notebooks und kompakte Desktop-Rechner; laut NVIDIAs Pressemitteilung vom 16. Oktober 2026 sind RTX-Spark-Notebooks „ab heute weltweit erhältlich“. Laut Produktseite hat auch sie bis zu 128 GB Unified Memory (LPDDR5X) und damit keinen eigenen Grafikspeicher, und laut NVIDIAs Portierungsleitfaden ist ein Teil dieses Speichers allein der CPU vorbehalten. Die Zahlen in diesem Artikel gelten für den DGX Spark.

Wie viel von den 128 GB nutzbar ist

Wir haben bei NVIDIA keine Angabe zur nutzbaren Kapazität gefunden und keine Zeile „X GB für die GPU verfügbar“ auf der Produktseite, im User Guide, im Portierungsleitfaden oder in den Release Notes; behandeln Sie jede genannte Zahl deshalb als Schätzung. Was NVIDIA veröffentlicht, ist die Standardeinstellung für den Speicher in seinen Playbooks für vLLM und TensorRT-LLM.

Die Werte 0,4, 0,7, 0,8 und 0,9 sind NVIDIAs eigene Einstellungen: im Startskript für einen Spark, auf das das vLLM-Playbook auf build.nvidia.com verweist (aktualisiert am 14. September 2026), im vLLM-Playbook auf GitHub (aktualisiert am 12. Juni 2026) und im TensorRT-LLM-Playbook (aktualisiert am 28. April 2026). Die Spanne von 102 bis 115 GB ist die Rechnung dieses Artikels aus den Einstellungen 0,8 und 0,9 und keine veröffentlichte Spezifikation; der Wert 0,7 aus dem vLLM-Skript für einen Spark ergibt etwa 90 GB.

Planen Sie 102 bis 115 GB als Budget für Gewichte und KV-Cache zusammen ein und überlassen Sie die übrigen 13 bis 26 GB dem Betriebssystem DGX OS, der Desktop-Sitzung, dem Seiten-Cache und den Prozessen auf den zwanzig Arm-Kernen. Wenn Sie die Zahl weitergeben, nennen Sie die Begründung mit, denn sie ändert sich, sobald NVIDIA eine Voreinstellung im Playbook ändert. Ein Anteil über NVIDIAs Voreinstellungen kann auf einem Spark, der nur Modelle bereitstellt, Platz für mehr Cache schaffen, auch wenn NVIDIAs aktuelles Playbook keinen höheren Wert vorschlägt; auf einem Spark, den jemand auch als Workstation nutzt, führt er zu dem oben beschriebenen Out-of-Memory-Zustand.

Wenn Sie nicht sicher sind, ob Ihr Modell und Ihre Kontextlänge in dieses Budget passen, schicken Sie uns beides zusammen mit der geplanten Genauigkeit, und wir prüfen vor der Bestellung, ob es passt.

Byte je Parameter, und was „bis zu 200 Milliarden Parameter“ bedeutet

Die Dimensionierung allein über die Gewichte ist eine Rechnung, die jeder nachvollziehen kann: Parameter mal Byte je Parameter. BF16 und FP16 sind zwei Byte, FP8 ist eines, und die 4-Bit-Formate sind ein halbes Byte plus ihre Blockskalierungen: 4,25 Bit je Gewicht bei MXFP4 und 4,5 bei NVFP4, etwa 0,53 und 0,56 Byte. Schicken Sie das Arbeitsbudget von oben durch diese Rechnung, mit 110 GB als Mittelwert.

Nur Gewichte: kein KV-Cache, keine Aktivierungen, kein Framework-Overhead. Das ist die Rechnung dieses Artikels aus NVIDIAs Speicherangabe und den üblichen Werten für Byte je Parameter, keine Tabelle von NVIDIA.

NVIDIAs Ankündigung zum Start und die Produktseite sagen beide, die Maschine mit 128 GB führe Inferenz auf Modellen mit bis zu 200 Milliarden Parametern aus; für die Konfiguration mit 64 GB nennt die Produktseite 100 Milliarden. Zweihundert Milliarden Parameter zu je einem halben Byte wären 100 GB; mit den Blockskalierungen von MXFP4 oder NVFP4 belegen sie 106 bis 112 GB. Bei einem Arbeitsbudget von 102 bis 115 GB bleiben damit höchstens etwa 9 GB für den KV-Cache, Aktivierungen und Overhead, am unteren Ende der Spanne nichts. Die Aussage stimmt also nur in 4 Bit, und auch dann nur knapp. In BF16 fasst dasselbe System etwa 55 Milliarden Parameter, weit weniger als die angegebenen 200 Milliarden.

NVIDIAs eigene Dokumentation zeigt, wo die Grenze für einen Spark liegt. Die Tabelle der validierten Modelle für TensorRT-LLM führt Llama-3.3-70B-Instruct, Qwen3-32B und Nemotron-3-Super-120B als NVFP4-Checkpoints für die unterstützte Hardwareplattform und markiert genau einen Eintrag als Multi-Node: Qwen3-235B-A22B, ein Mixture-of-Experts-Modell mit 235 Milliarden Parametern. Nach NVIDIAs eigener Liste braucht ein 235B-Modell also mehr als einen Spark.

Als konkrete Beispiele nennt NVIDIA GPT-OSS-120B und FLUX 2, das 90 GB braucht, um vollständig geladen zu werden. Ein Modell mit 90 GB passt in die 128 GB, lässt aber sehr wenig für alles andere übrig. Die größeren Modelle passen erst mit einem 4-Bit-Format wie NVFP4, das laut NVIDIAs Playbook zur Quantisierung etwa 3,5-mal weniger Speicher als FP16 und etwa 1,8-mal weniger als FP8 braucht, wobei die Modellgenauigkeit meist um weniger als ein Prozent von FP8 abweicht.

KV-Cache: wie Kontextlänge und gleichzeitige Nutzer den Speicherbedarf erhöhen

Die Gewichte sind der Teil des Budgets, der sich von einer Modellkarte ablesen lässt. Der andere Teil ist der KV-Cache, der linear mit der Kontextlänge und mit der Zahl gleichzeitiger Sequenzen wächst. Deshalb passt ein Deployment, das bei einem Prompt mit 2.048 Token lädt, bei 32.000 Token mit acht Nutzern nicht mehr in den Speicher. Unser VRAM-Leitfaden enthält die vollständige Formel (Schichtzahl, Key- und Value-Köpfe, Kopfdimension, Byte je Element, Sequenzlänge und Batchgröße); hier zählt, dass der Cache weder vernachlässigbar noch eine feste Größe ist.

Drei Fälle bei einem Arbeitsbudget von 110 GB zeigen die Wirkung. Ein Modell mit 70 Milliarden Parametern in NVFP4 hat in NVIDIAs Checkpoint etwa 43 GB Gewichte und lässt etwa 67 GB übrig; das ist viel Cache und eine bequeme Last für einen Spark. GPT-OSS-120B, ein Mixture-of-Experts-Modell mit 117 Milliarden Parametern und etwa 65 GB in OpenAIs Checkpoint, lässt etwa 45 GB übrig, genug Cache für ein kleines Team von Chat-Nutzern, wie unser Beitrag zu einem DGX Spark im Team durchrechnet. FLUX 2, das laut NVIDIA 90 GB braucht, um vollständig geladen zu werden, lässt etwa 20 GB übrig. Ein Modell mit 200 Milliarden Parametern in 4 Bit lässt höchstens wenige GB übrig oder passt gar nicht; das reicht für eine Vorführung, aber nicht für einen Dienst. Modelle aus dem Jahr 2026 folgen derselben Rechnung: Nemotron 3.5 Super VL, ein Mixture-of-Experts-Modell mit 120 Milliarden Parametern, im Oktober 2026 mit 75,0 GB in NVFP4 veröffentlicht, lässt auf einem Spark mit 128 GB etwa 35 GB übrig, und NVIDIA nennt einen DGX Spark unter seinen Zielsystemen; Nemotron 3.5 Bolt 74B-A9B mit 149,8 GB in BF16 braucht zwei Spark-Systeme.

NVIDIAs Zahlen sind nur mit ihren Testbedingungen aussagekräftig. NVIDIAs Inferenzangaben zum DGX Spark vom Oktober 2025 stehen alle unter „ISL|OSL = 2048|128, BS=1“, also eine Eingabe von 2.048 Token, 128 erzeugte Token und eine Anfrage zur Zeit; das ist ein kleiner Kontext und ein einziger Nutzer. Bei langen Kontexten und gleichzeitigen Anfragen entscheidet der KV-Cache und nicht die Gewichte darüber, was passt. NVIDIAs eigener Test dieses Falls, veröffentlicht im März 2026, endet bei vier gleichzeitigen Aufgaben: Mit Qwen3 Coder Next in FP8 auf vLLM, Prompts von 32K Token und Antworten von 1K Token ergaben eine, zwei und vier gleichzeitige Aufgaben Gesamtlaufzeiten von 35, 54 und 91 Sekunden.

Volles Fine-Tuning, LoRA und QLoRA auf einem DGX Spark

NVIDIAs Produktseite sagt „KI-Modelle mit bis zu 70 Milliarden Parametern feinabstimmen“, ohne die Methode zu nennen. NVIDIAs Playbook zum Fine-Tuning mit PyTorch nennt sie in seinen veröffentlichten Skripten: Llama3_3B_full_finetuning.py, Llama3_8B_LoRA_finetuning.py und Llama3_70B_qLoRA_finetuning.py. Wie groß das Modell sein darf, das Sie feinabstimmen, hängt von der Methode ab.

Token pro Sekunde in der Spitze aus NVIDIAs Performance-Blog, von NVIDIA berechnet als (batch_size × steps × sequence_length) geteilt durch die gesamte Trainingszeit, bei Sequenzlänge 2.048, Batchgröße 8 (4 beim 8B-LoRA-Lauf), einer Epoche und 64 Schritten. Das sind die Werte aus der Tabelle des Blogs; sein Fließtext nennt für dieselben Läufe höhere Spitzenwerte, wie unser Artikel zum Fine-Tuning erläutert.

Wir haben keine Rechnung von NVIDIA gefunden, die diese Grenzen für den DGX Spark begründet; die folgende Rechnung ist daher unsere und sollte als unsere zitiert werden. Ein volles Fine-Tuning in BF16 mit dem Adam-Optimizer braucht je Parameter zwei Byte Gewichte, zwei Byte Gradienten, acht Byte FP32-Momente des Optimizers und vier Byte FP32-Mastergewichte. Das sind etwa 16 Byte je Parameter, bevor eine einzige Aktivierung gespeichert ist. Ein Modell mit 3 Milliarden Parametern braucht damit etwa 48 GB, was mit Platz für Aktivierungen passt. Ein Modell mit 7 Milliarden Parametern braucht etwa 112 GB, was in ein Arbeitsbudget von 102 bis 115 GB nicht mehr passt, sobald Aktivierungen dazukommen. Das erklärt, warum NVIDIAs Beispiel für ein volles Fine-Tuning bei 3B endet, warum LoRA bis 8B reicht und warum 70B nur mit QLoRA möglich ist, wo das eingefrorene Basismodell in 4 Bit rund 40 GB belegt.

Lesen Sie die Durchsatzspalte als reale Laufzeit und nicht als Punktzahl. Bei 759,79 Token pro Sekunde dauert eine Million Trainings-Token im 70B-QLoRA-Lauf etwa 22 Minuten, und hundert Millionen Token dauern auf einem Spark etwa anderthalb Tage. Das begrenzt, wie viele Experimente ein Team in einer Woche fährt, und es passt dazu, wie NVIDIA die Maschine positioniert: lokal Prototypen bauen und feinabstimmen, dann die Arbeit für den Umzug in DGX Cloud oder eine andere beschleunigte Infrastruktur bewerten.

NVIDIA veröffentlicht auch den Stack, mit dem sich diese Zahlen nachstellen lassen: Das Playbook führt die Skripte im hauseigenen PyTorch-Container aus (25.11-py3 in der GitHub-Fassung) und installiert transformers, peft, datasets, trl und bitsandbytes mit pip.

Speicherbandbreite und Geschwindigkeit der Token-Generierung

Alles bisher betrifft die Kapazität. Die Geschwindigkeit hängt von einer anderen Zahl in derselben Spezifikationszeile ab, der Speicherbandbreite von 273 GB/s, die vorhersagt, wie schnell Token erzeugt werden.

Beim Dekodieren nur eines Datenstroms liest ein dichtes Modell jedes Gewicht einmal je erzeugtem Token, die Obergrenze ist also die Speicherbandbreite geteilt durch die Größe der geladenen Gewichte. Ein dichtes Modell mit 70 Milliarden Parametern in FP8 hat etwa 70 GB Gewichte; 273 geteilt durch 70 ergibt unter vier Token pro Sekunde für einen Nutzer, vor jedem Overhead. In NVFP4 werden je Token etwa 40,6 GB desselben Modells gelesen, die 4-Bit-Schichten plus die Ausgabeschicht in BF16, und die Obergrenze steigt um etwa drei Viertel. Ein Mixture-of-Experts-Modell liest je Token nur seine gemeinsamen Schichten und aktiven Experten, deshalb läuft GPT-OSS-120B mit 65 GB auf der Platte weit schneller, als seine Größe vermuten lässt. Nichts in der Rechenspezifikation ändert eine der beiden Zahlen. Wir haben keine Messung von NVIDIA für ein dichtes 70B-Modell auf einem Spark gefunden; LMSYS hat im Oktober 2025 Llama 3.1 70B in FP8 mit 2,7 Token pro Sekunde gemessen, innerhalb dieser Obergrenze.

NVIDIA-Technikblog, Oktober 2025, gemessen bei ISL|OSL 2048|128 mit Batchgröße 1, mit llama.cpp für die GPT-OSS-Zeilen und TensorRT-LLM für die übrigen. Die drei Mixture-of-Experts-Einträge liegen über dem, was ihre Gesamtparameterzahl nahelegt, weil je Token nur ein Bruchteil der Gewichte gelesen wird.

Die Tabelle stellt den DGX Spark den Karten gegenüber, die ein Käufer als Alternative in Betracht ziehen würde; alle Zahlen stammen von NVIDIAs eigenen Seiten.

NVIDIA-Produktseiten, Oktober 2026. Die Verhältnisse sind die Rechnung dieses Artikels: 1.792 geteilt durch 273 und 4.800 geteilt durch 273.

Der Spark mit 128 GB hat mehr Speicher als eine RTX PRO 6000 Workstation und bewegt ihn 6,6-mal langsamer. Wählen Sie den Spark, wenn das Modell nicht auf eine Karte passt, und eine schnellere Karte, wenn die Antworten zu langsam kommen. Unser Benchmark-Artikel behandelt die Messwerte.

Wir liefern sowohl den DGX Spark als auch die RTX PRO 6000 Blackwell in allen drei Versionen. Nennen Sie uns das Modell und die Zahl der Personen, die es gleichzeitig nutzen, und wir vergleichen beide vor Ihrer Entscheidung anhand Ihrer Zahlen.

Die Angabe von 1 PFLOP wird oft ohne ihre Bedingung zitiert. „Bis zu 1 PFLOP FP4“ ist keine dichte Angabe: Die Fußnote in NVIDIAs Datenblatt lautet „Theoretische FP4-TOPS unter Nutzung der Sparsity-Funktion“, der User Guide nennt ausdrücklich bis zu 1 PetaFLOP bei FP4-Genauigkeit mit Sparsity, und seit der Aktualisierung vom 21. Oktober 2026 trägt auch die Produktseite diese Fußnote an der Zeile „Tensor Performance“. Wir haben bei NVIDIA keine dichte FP4-Zahl für GB10 gefunden; eine Angabe von „1 PetaFLOP“ ohne den Hinweis auf Sparsity sollte daher nicht als dichte Spezifikation gelesen werden. Die Geschwindigkeit der Token-Generierung sagt sie ohnehin nicht voraus; das tut die Speicherbandbreite von 273 GB/s.

Zwei oder mehr DGX-Spark-Systeme koppeln

Der DGX Spark wird oft so beschrieben, als sei er auf zwei Systeme begrenzt. NVIDIAs Clustering-Dokumentation schreibt, er unterstütze „bis zu drei DGX-Spark-Systeme, direkt über Kabel verbunden, und bis zu vier Systeme bei Verwendung eines Switches“. NVIDIA liefert eigene Playbooks für zwei Spark-Systeme, für drei in einer Ringtopologie und für vier über einen Switch, dazu einen NCCL-Leitfaden, der ausdrücklich zwei, drei oder vier Spark-Systeme behandelt. Zwei gekoppelte Spark-Systeme sind der häufige Fall. Mit NVIDIAs Playbooks und dem Cluster Assistant werden bis zu vier unterstützt, und NVIDIA hat die Unterstützung von Clustern mit bis zu acht Spark-Systemen in manueller Konfiguration angekündigt (NVIDIA-Blog, 21. Oktober 2026).

Die Verbindung ist eine direkte 200-GbE-QSFP-Strecke zwischen den ConnectX-7-Ports, mit freigegebenen Kabeln, die nach Teilenummer benannt sind, und einem RoCE-Gerät neben jeder Ethernet-Schnittstelle. NVIDIAs eigener RDMA-Write-Benchmark meldet 92,57 und 97,28 Gb/s über die beiden logischen Strecken, zusammen 189,85 Gb/s, also etwa 95 Prozent der Nennrate von 200 Gb/s; mit diesem gemessenen Wert sollten Sie planen. Wegen der Unified-Memory-Architektur wird GPUDirect RDMA nicht unterstützt: Auf festgepinnte Gerätespeicherbereiche können weder der CPU-Komplex noch PCI-Express-Geräte kohärent zugreifen, Zero-Copy-Wege von der Netzwerkkarte in den GPU-Speicher gibt es also nicht. Unser Artikel zu zwei Knoten behandelt die Verkabelung.

Ein zweiter Spark bringt vor allem weitere 128 GB Speicher; die Geschwindigkeit je Anfrage kann nur mit Tensor-Parallelismus steigen, und auch dann höchstens teilweise. NVIDIAs gemessener Wert für zwei Spark-Systeme ist Qwen3 235B in NVFP4 mit 11,73 Token pro Sekunde; das Modell lässt sich also laden, läuft aber langsam.

Bei der Größenangabe für mehrere Spark-Systeme nennen NVIDIAs eigene Seiten für die Kopplung von zwei Systemen unterschiedliche Zahlen, und ein Käufer sollte beide kennen. Stand Oktober 2026 nennt die aktuelle Produktseite zum DGX Spark bis zu 400 Milliarden Parameter für zwei Systeme mit 128 GB und bis zu 700 Milliarden für vier. NVIDIAs eigene Markdown-Spiegelung dieser Seite, das Datenblatt und die Hardware-Übersicht des User Guide (aktualisiert am 21. Oktober 2026) nennen weiterhin zwei Systeme und bis zu 405 Milliarden Parameter. Die aktuelle Seite ist diejenige, die zur Clustering-Dokumentation und zum NCCL-Playbook für vier Spark-Systeme passt; behandeln Sie also 400 Milliarden auf zwei Systemen und 700 Milliarden auf vier als die aktuellen Aussagen und 405 Milliarden auf zwei als die Zahl, die NVIDIAs Datenblatt und Dokumentation weiterhin nennen. Beide Aussagen setzen 4-Bit-Gewichte voraus. Bei 4,5 Bit je Gewicht belegen 700 Milliarden Parameter etwa 394 GB der 512 GB von vier Systemen und 400 Milliarden etwa 225 GB der 256 GB von zwei.

Für Modelle, die nicht in 128 GB passen, nennt unser Leitfaden zu den LLM-Hardware-Anforderungen nach Modell die kleinste Konfiguration mit RTX PRO 6000 oder H200 NVL für jedes Modell.

Was wir liefern

Wir liefern den NVIDIA DGX Spark in der Founders Edition (128 GB, 4 TB) EU-weit unter einem Vertrag und auf einer Rechnung, mit Herstellergarantie. Wir liefern auch die Karten, mit denen dieser Artikel ihn vergleicht, die RTX PRO 6000 Blackwell in allen drei Versionen und die H200 NVL, als Karten oder in KI-Servern, die wir auf Bestellung bauen. Mit Modell, Genauigkeit, Kontextlänge und der Zahl gleichzeitiger Nutzer machen wir vor Ihrer Bestellung dieselbe Speicherrechnung mit Ihren Zahlen; die Antwort kann ein DGX Spark sein, zwei oder vier gekoppelte Spark-Systeme oder ein GPU-Server.

FAQ