Was wirklich in die 128 GB eines DGX Spark passt, und was sich auf einem Gerät feinabstimmen lässt

Auf dieser Maschine gibt es keine VRAM-Angabe

Jedes GPU-Datenblatt, das ein Ingenieur seit fünfzehn Jahren liest, beginnt mit einer VRAM-Zahl. Der DGX Spark hat keine, und das ist kein Versehen. 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, und der Arm-Prozessor mit 20 Kernen, DGX OS, die Desktop-Sitzung und die GPU schöpfen alle aus diesem einen Pool. Nichts ist für Grafik reserviert, und nichts ist dem Modell garantiert.

Zwei Konsequenzen dokumentiert NVIDIA selbst, und beide begegnen einem am ersten Nachmittag. Die erste: nvidia-smi kann die GPU-Speichernutzung auf dieser Plattform nicht melden. Die Seite mit den bekannten Problemen sagt, das Werkzeug zeige „Memory-Usage: Not Supported“ an, obwohl der GPU-Speicher je Prozess aufgeführt werde, weil eine integrierte GPU keinen eigenen Framebuffer zum Zählen hat. Die zweite: cudaMemGetInfo ist pessimistisch. Der Portierungsleitfaden warnt, 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 mitzudenken, statt sich allein auf diesen Aufruf zu verlassen.

Klar gesagt: Die beiden Instrumente, die sonst die Frage „passt dieses Modell?“ beantworten, geben hier beide die falsche Antwort, das eine, indem es sich verweigert, das andere, indem es zu niedrig antwortet. NVIDIA dokumentiert das Versagen auch in die andere Richtung. Das eigene Unsloth-Playbook führt „Speicherdruck innerhalb der Kapazität“ als bekannten Zustand auf, verursacht dadurch, dass der Puffer-Cache der UMA nicht freigegeben wird, mit einer einzeiligen Abhilfe: sync, dann eine 3 in /proc/sys/vm/drop_caches schreiben. Ein Out-of-Memory-Fehler auf dieser Box ist nicht immer das, wonach er aussieht.

Wie viel von den 128 GB Sie tatsächlich bekommen

NVIDIA veröffentlicht keine Angabe zur nutzbaren Kapazität. Es gibt keine Zeile „X GB für die GPU verfügbar“ auf der Produktseite, im User Guide, im Portierungsleitfaden oder in den Release Notes; wer eine nennt, rät also. Was es gibt, ist das, was NVIDIA in den eigenen Serving-Playbooks als Standard setzt.

Die Werte 0,8 und 0,9 sind NVIDIAs eigene Voreinstellungen. Die Spanne von 102 bis 115 GB ist die Rechnung dieses Artikels daraus und keine veröffentlichte Spezifikation.

Nehmen Sie 102 bis 115 GB als Budget für Gewichte und KV-Cache zusammen und behandeln Sie die übrigen 13 bis 26 GB als Abgabe an DGX OS, die Desktop-Sitzung, den Seiten-Cache und was auch immer diese zwanzig Arm-Kerne gerade tun. Nennen Sie die Zahl mit ihrer Begründung, denn an dem Tag, an dem NVIDIA eine Voreinstellung im Playbook ändert, verschiebt sie sich. Den Anteil Richtung 0,95 anzuheben ist dokumentiert und sinnvoll auf einem Gerät, das Modelle bedient und sonst nichts; auf einem Gerät, das jemand auch als Workstation nutzt, ist es der Weg in den Out-of-Memory-Zustand von oben.

Byte je Parameter, und was 200 Milliarden wirklich heißt

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 etwa ein halbes Byte, bevor die Blockskalierungen mitgezählt werden. 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.

Nun bringen Sie das mit der Schlagzeile zusammen. NVIDIAs Ankündigung zum Start und die Produktseite sagen beide, die Maschine führe Inferenz auf Modellen mit bis zu 200 Milliarden Parametern aus. Zweihundert Milliarden Parameter zu je einem halben Byte sind 100 GB Gewichte, was gegen ein Arbeitsbudget von 102 bis 115 GB zwischen 2 und 15 GB für den KV-Cache, Aktivierungen und Overhead lässt. Die Aussage stimmt, und sie ist eine FP4-Aussage. In BF16 endet dieselbe Box nahe 55 Milliarden Parametern, und das ist im Kopf des Lesers eine andere Maschine.

NVIDIAs eigenes Material bestätigt, wo die Linie für ein einzelnes Gerät liegt, ohne dass jemand uns glauben müsste. 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 genau ein Eintrag in dieser Tabelle ist als Multi-Node markiert: Qwen3-235B-A22B, ein Mixture-of-Experts-Modell mit 235 Milliarden Parametern. NVIDIAs eigene Einkaufsliste sagt also, dass ein 235B-Modell mehr als einen Spark braucht. Dieselbe Seite trägt die Anweisung, vor dem Herunterladen zu bestätigen, dass das gewählte Modell in den verfügbaren Speicher passt.

Das konkrete Beispiel in voller Genauigkeit, das NVIDIA nennt, ist GPT-OSS-120B, oder FLUX 2 mit 90 GB. Neunzig der 128 für ein Modell sind eine nützliche Eichung: bequem innerhalb der Box, und sehr wenig übrig für alles andere. Der Hebel, der das Ganze funktionieren lässt, ist NVFP4, das NVIDIAs Playbook zur Quantisierung mit etwa 3,5-mal weniger Speicher als FP16 und etwa 1,8-mal weniger als FP8 angibt, bei typischerweise unter einem Prozent Genauigkeitsverlust. Einen zweiten Hebel gibt es nicht.

Eine Anmerkung zur Ehrlichkeit der Schlagzeile. NVIDIA hat auch eine niedrigere Zahl für ein einzelnes Gerät veröffentlicht, „Modelle mit 100 Milliarden Parametern auf DGX Spark“, in einem Blogbeitrag vom Januar 2026. Beide Zahlen sind die eigenen; die Zahl von 200 Milliarden steht in der Pressemitteilung zum Start und auf der Produktseite.

Der KV-Cache macht aus einem Modell, das passt, eines, das nicht passt

Die Gewichte sind die Hälfte des Budgets, die sich von einer Modellkarte ablesen lässt. Die andere Hälfte ist der KV-Cache, der linear mit der Kontextlänge und mit der Zahl gleichzeitiger Sequenzen wächst, und darum fällt ein Deployment, das bei einem Prompt mit 2.048 Token fröhlich lädt, bei 32.000 Token mit acht Nutzern um. Unser VRAM-Leitfaden hat die vollständige Formel, Schichtzahl, Key- und Value-Köpfe, Kopfdimension, Byte je Element, Sequenzlänge und Batchgröße; hier zählt sein Fazit, dass der Cache weder ein Rundungsfehler noch ein fester Posten ist.

Drei Fälle gegen ein Arbeitsbudget von 110 GB zeigen es. Ein Modell mit 70 Milliarden Parametern in NVFP4 sind rund 35 GB Gewichte und lässt etwa 75 GB übrig, was viel Cache ist und eine wirklich bequeme Last für ein einzelnes Gerät. Ein Modell mit 120 Milliarden Parametern, das NVIDIA selbst mit 90 GB misst, lässt etwa 20 GB: genug für ein Gespräch mit Arbeitskontext, nicht genug, um ein Team zu bedienen. Ein Modell mit 200 Milliarden Parametern lässt einstellige Gigabyte übrig, was eine Vorführung ist und kein Dienst.

Das ist auch der richtige Ort, NVIDIAs Benchmark-Methodik statt der Benchmark-Zahlen zu lesen. Jede veröffentlichte Inferenzangabe zum DGX Spark trägt „ISL|OSL = 2048|128, BS=1“: eine Eingabe von 2.048 Token, 128 erzeugte Token, eine Anfrage zur Zeit. Das ist ein kleiner Kontext und ein einzelner Nutzer, und nichts in der veröffentlichten Sammlung sagt, was bei langem Kontext unter Gleichzeitigkeit passiert, also genau dort, wo der Cache und nicht die Gewichte entscheidet.

Was ein Gerät tatsächlich feinabstimmen kann

NVIDIAs Produktseite sagt „KI-Modelle mit bis zu 70 Milliarden Parametern feinabstimmen“ und sagt nicht, mit welcher Methode. Das eigene Playbook zum Fine-Tuning mit PyTorch sagt es, und die veröffentlichten Skriptnamen entscheiden die Frage: Llama3_3B_full_finetuning.py, Llama3_8B_LoRA_finetuning.py und Llama3_70B_qLoRA_finetuning.py. Die Leiter hängt an der Methode, nicht an der Parameterzahl.

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.

Warum die Leiter diese Form hat, ist eine Rechnung, die NVIDIA für diese Maschine nicht veröffentlicht, hier ist also unsere, offen, und sie gehört überall dort als unsere gekennzeichnet, wo sie zitiert wird. Ein volles Fine-Tuning in BF16 mit dem Adam-Optimizer trägt je Parameter zwei Byte Gewichte, zwei Byte Gradienten, acht Byte FP32-Momente des Optimizers und vier Byte FP32-Mastergewichte: etwa 16 Byte je Parameter, bevor eine einzige Aktivierung gespeichert ist. Ein Modell mit 3 Milliarden Parametern sind damit etwa 48 GB, was mit Platz für Aktivierungen passt. Ein Modell mit 7 Milliarden Parametern sind etwa 112 GB, was in ein Arbeitsbudget von 102 bis 115 GB nicht mehr passt, sobald Aktivierungen dazukommen. Diese eine Multiplikation erklärt, warum NVIDIAs Beispiel für ein volles Fine-Tuning bei 3B endet, warum LoRA bis 8B reicht und warum 70B nur über QLoRA erreichbar ist, wo die Basis eingefroren in 4 Bit bei rund 35 GB liegt.

Lesen Sie die Durchsatzspalte als reale Laufzeit und nicht als Punktzahl. Bei 759,79 Token pro Sekunde ist eine Million Trainings-Token etwa 22 Minuten auf dem 70B-QLoRA-Lauf, und hundert Millionen Token sind auf einem Gerät eine Aufgabe über mehrere 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.

Der Stack zum Nachstellen ist ebenfalls veröffentlicht, was zählt, wenn Sie die Zahlen wiederholen und nicht nur bewundern wollen: NVIDIAs PyTorch-Container 25.12-py3 mit transformers, peft, datasets, trl 0.26.2 und bitsandbytes 0.49.1, dazu ein im Leitfaden gedruckter Vorbehalt, dass bitsandbytes auf seine CUDA-13.0-Binärdatei gezwungen werden muss, weil CUDA 13.1 noch nicht unterstützt wird. NVIDIA behandelt Out-of-Memory als erwartetes Ergebnis des ersten Laufs und schreibt vor, die Batchgröße oder die Sequenzlänge zu verringern und für einen ersten Versuch LoRA oder QLoRA zu bevorzugen.

Kapazität ist nicht Durchsatz

Alles bisher ist ein Argument über Kapazität, und die Kapazität ist die Hälfte, die das Marketing verkauft. Die andere Hälfte steht in derselben Spezifikationszeile: 273 GB/s. Das ist die Zahl, die vorhersagt, wie schnell Token herauskommen.

Das Dekodieren eines einzelnen Stroms liest jedes Gewicht einmal je erzeugtem Token, die Obergrenze ist also die Speicherbandbreite geteilt durch die Größe der geladenen Gewichte, und die Rechnung ist eine Division. Ein dichtes Modell mit 70 Milliarden Parametern in FP8 sind etwa 70 GB Gewichte; 273 geteilt durch 70 sind unter vier Token pro Sekunde für einen Nutzer, vor jedem Overhead. Dasselbe Modell in NVFP4 mit etwa 35 GB verdoppelt diese Obergrenze. Nichts in der Rechenspezifikation ändert eine der beiden Zahlen, und NVIDIA veröffentlicht für ein dichtes 70B-Modell keine gemessene Zahl für ein einzelnes Gerät, die Division ist also die ehrliche Schätzung, mit der sich arbeiten lässt.

NVIDIA-Technikblog, gemessen bei ISL|OSL 2048|128 mit Batchgröße 1. Die beiden Mixture-of-Experts-Einträge liegen über dem, was ihre Gesamtparameterzahl nahelegt, weil je Token nur ein Bruchteil der Gewichte gelesen wird.

Gegen die Teile, die ein Käufer tatsächlich danebenstellen würde, alle von NVIDIAs eigenen Seiten, ist der Tausch ausdrücklich statt subtil.

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

Der Spark hält mehr Speicher als eine RTX PRO 6000 und bewegt ihn 6,6-mal langsamer. Das ist ein Kauf von Kapazität gegen einen Kauf von Geschwindigkeit, und was richtig ist, hängt davon ab, ob das Problem „das Modell passt nicht“ oder „die Antworten kommen zu langsam“ lautet. Unser Benchmark-Artikel deckt die gemessene Seite ab.

Eine Korrektur gehört hierher, weil sie überall wiederholt wird. „Bis zu 1 PFLOP FP4“ ist keine dichte Angabe. NVIDIAs eigene Fußnote auf der Produktseite lautet „theoretische FP4-TOPS unter Nutzung der Sparsity-Funktion“, und der User Guide schreibt es aus als bis zu 1 PetaFLOP bei FP4-Genauigkeit mit Sparsity. NVIDIA veröffentlicht keine dichte FP4-Zahl für GB10; wer also „1 PetaFLOP“ ohne das Wort Sparsity druckt, druckt eine Marketingzahl als Spezifikation nach. Sie würde die Token-Generierung ohnehin nicht vorhersagen: 273 GB/s tun es.

Wenn ein Gerät nicht reicht, und was ein zweites bringt

Der andere weit verbreitete Fehler ist, dass der DGX Spark bei zwei Geräten ende. Er tut es nicht. 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“, und NVIDIA liefert eigene Playbooks für zwei Geräte, für drei in einer Ringtopologie und für vier über einen Switch, dazu einen NCCL-Leitfaden, der ausdrücklich zwei, drei oder vier Sparks behandelt. Zwei ist der häufige Fall, nicht die Grenze.

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. Nennen Sie den gemessenen Wert statt des Typenschilds: 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. Eine Folge des Entwurfs mit gemeinsamem Speicher reist mit dem Cluster mit: GPUDirect RDMA wird nicht unterstützt, weil festgepinnte Gerätespeicherbereiche weder vom CPU-Komplex noch von PCI-Express-Geräten kohärent gelesen werden können, Zero-Copy-Wege von der Netzwerkkarte in den GPU-Speicher gibt es also nicht. Unser Artikel zu zwei Knoten behandelt die Verkabelung.

Was das zweite Gerät bringt, sind weitere 128 GB, keine höhere Geschwindigkeit. NVIDIAs gemessener Wert für zwei Geräte ist Qwen3 235B in NVFP4 mit 11,73 Token pro Sekunde, und das ist die Form des ganzen Tauschs: Das Modell wird ladbar, es wird nicht schnell.

Bei der Größenangabe für mehrere Geräte widerspricht NVIDIA sich selbst, und ein Käufer sollte es von uns hören, statt es später zu entdecken. Die aktuelle Produktseite zum DGX Spark sagt, die ConnectX-Vernetzung ermögliche die Verbindung von bis zu vier Systemen für Modelle mit bis zu 700 Milliarden Parametern. NVIDIAs eigene Markdown-Spiegelung derselben Produktseite sagt zwei Systeme und bis zu 405 Milliarden Parameter. Beide waren im September 2026 veröffentlicht und erreichbar. Die Formulierung mit vier Geräten ist die, die zur Clustering-Dokumentation und zum NCCL-Playbook für vier Geräte passt, behandeln Sie also 700 Milliarden auf vier Geräten als die aktuelle Aussage und 405 Milliarden auf zweien als ebenfalls veröffentlicht. Die Rechnung bindet beide an 4-Bit-Gewichte und an sonst nichts: 700 Milliarden zu je einem halben Byte sind 350 GB gegen 512 GB in vier Geräten, und 405 Milliarden sind etwa 203 GB gegen 256 GB in zweien.

Eurokommerz liefert DGX Spark-Geräte EU-weit, und wir bemessen den Speicher lieber vor der Bestellung, als ihn danach zu erklären. Schicken Sie uns Modell, Genauigkeit und Kontextlänge, und wir rechnen dieselbe Rechnung auf Ihren Zahlen, einschließlich des Falls, in dem ein Gerät nicht die richtige Maschine ist.

FAQ