DGX Spark im Betrieb: was die Maschine nach drei Monaten wirklich kann

Der erste Tag im Rack

Als die Maschine zum ersten Mal bei uns im Rack stand, war das auffälligste an ihr, wie unauffällig sie war. Kein dröhnendes Server-Chassis, kein Rack voller GPUs, sondern ein kompaktes Gerät, das eher nach kräftigem Desktop aussieht als nach Rechenzentrum. Eine knappe Stunde später lief das erste 70-Milliarden-Parameter-Modell darauf, am Stück, ohne Sharding, ohne dass wir irgendetwas über mehrere Karten verteilen mussten. Genau dieser Moment fasst zusammen, worum es bei der DGX Spark geht. Datenblätter erzählen, was eine Maschine können soll; der Alltag erzählt, was sie wirklich tut. Wir betreiben sie seit Monaten für eigene und für Kunden-Workloads, und das hier ist die ehrliche Version, inklusive der Stellen, an denen sie das falsche Werkzeug ist.

Was die Maschine technisch wirklich ist

Die meisten Missverständnisse über die DGX Spark entstehen, weil sie mit der falschen Erwartung gekauft wird. Im Kern steckt ein GB10-Superchip aus der Grace-Blackwell-Klasse: eine Blackwell-GPU und ein Grace-ARM-CPU-Teil auf einem Package, gekoppelt über einen schnellen internen Link. Das Besondere sind die 128 GB Unified Memory auf LPDDR5x-Basis, die sich CPU und GPU physisch teilen. Es gibt keinen getrennten VRAM-Pool, in den du Daten erst über PCIe schaufeln musst, beide Recheneinheiten sehen denselben Speicher. Für die Praxis heisst das: Ein grosses Modell liegt am Stück im Speicher, und du verbringst keine Zeit damit, Gewichte zwischen Host- und GPU-RAM hin- und herzuschieben.

Hier liegt aber auch der Punkt, den man verstehen muss, sonst kauft man falsch. LPDDR5x liefert viel Kapazität, aber deutlich weniger Speicherbandbreite als der HBM3-Speicher einer H100. Die H100 hat weniger Kapazität, dafür ein Vielfaches an Bandbreite. Die Spark tauscht also bewusst Tempo pro Byte gegen Menge an Bytes, keine Schwäche im Design, sondern eine Entscheidung. Ob sie für dich richtig ist, hängt vollständig daran, ob dein Workload Kapazität oder Bandbreite braucht.

Warum das bei LLM-Inferenz so zentral ist, sieht man, wenn man die zwei Phasen auseinanderhält. Das Prefill, bei dem der Prompt eingelesen wird, ist rechenlastig und parallel. Der Decode dagegen, bei dem Token für Token erzeugt wird, ist speicherbandbreiten-limitiert: Für jedes einzelne Token müssen die relevanten Modellgewichte aus dem Speicher gelesen werden. Die Tokens pro Sekunde im Decode hängen damit primär an der Bandbreite, nicht an der rohen Rechenleistung. Deshalb spürst du den HBM-Vorteil der H100 bei kleinen Modellen sofort als höhere Tokens/s, und deshalb relativiert sich dieser Vorteil, sobald das Modell so gross wird, dass es auf der H100 gar nicht mehr am Stück in den Speicher passt.

Das Speicher-Argument, durchgerechnet

Die 128 GB sind der eigentliche Grund, die Maschine überhaupt in Betracht zu ziehen, und es lohnt sich, das in Modellgrössen zu übersetzen. Als grobe Faustregel braucht ein Modell pro Milliarde Parameter etwa 2 GB in 16-bit, rund 1 GB in 8-bit und etwa 0,5 GB in 4-bit, dazu kommt der KV-Cache für den Kontext. Ein 70B-Modell liegt damit in 4-bit bei grob 35 bis 40 GB und in 8-bit bei grob 70 GB, beides passt mit Reserve für Kontext und Batching. Selbst sehr grosse Modelle jenseits von 100B werden quantisiert handhabbar, solange du bei der Präzision Kompromisse eingehst. Du hast also echten Spielraum, mit Modellgrösse und Quantisierung zu spielen, ohne sofort an eine Wand zu laufen.

Dieselbe Rechnung auf einer klassischen Karte erzählt die Gegengeschichte. Auf einer 24- oder 48-GB-Karte ist bei einem 70B-Modell schon in moderater Quantisierung Schluss: Du musst es über mehrere GPUs sharden, mit Tensor-Parallelismus, abgestimmten Treibern und der entsprechenden Verkabelung. Selbst eine 80-GB-H100 trägt ein 70B-Modell zwar, lässt aber bei grösseren Modellen oder grosszügigem KV-Cache wenig Luft. Die Spark ersetzt diese Multi-GPU-Akrobatik durch simple Kapazität: ein Gerät, ein Speicher, kein Sharding. Dieser Wegfall an Komplexität ist im Alltag mehr wert, als das Datenblatt vermuten lässt.

Wo die Maschine im Betrieb glänzt

Nach Wochen Dauerbetrieb kristallisieren sich klare Stärken heraus. Die Zahlen hier sind Grössenordnungen aus unserem Betrieb, keine zertifizierten Benchmarks. Der grösste praktische Gewinn ist banal und wichtig zugleich: Du lädst ein grosses Modell, und es läuft, ohne es zu zerschneiden, ohne Parallelismus-Konfiguration, ohne abgestimmte Multi-GPU-Topologie. Ein anderes Modell ausprobieren heisst, ein anderes Modell laden, nicht die halbe Infrastruktur umbauen. Bei uns hat das die Zeit zwischen „wir wollen Modell X testen“ und „Modell X antwortet“ von Stunden auf Minuten gedrückt.

Damit hängt ein unterschätzter zweiter Vorteil zusammen. Weil grosse Modelle am Stück passen, können Entwickler lokal gegen dasselbe Modell arbeiten, das später produktiv läuft, nicht gegen ein geschrumpftes Surrogat, das sich im Ernstfall anders verhält. Das verkürzt die Schleife zwischen Idee, Test und Deployment spürbar und nimmt eine ganze Klasse von „lief lokal, brach in Prod“-Überraschungen heraus. Für Teams, die Prompts und Pipelines iterieren, ist das oft mehr wert als ein paar Tokens pro Sekunde mehr.

Und dann ist da die Ruhe im Dauerlauf, die uns am meisten überrascht hat. Im Vergleich zu einem rohen Multi-GPU-H100-Setup ist die Spark sparsam und unaufgeregt: Sie zieht in der Grössenordnung eines kräftigen Desktops statt eines Server-Racks, bleibt thermisch und akustisch zurückhaltend und lässt sich entsprechend unkompliziert platzieren. Über die Laufzeit war die Stabilität genau das, was man sich wünscht, sie läuft, ohne dass man nachts daran denken muss. Für konstante Inferenzlast über Wochen ist das die ruhigere Wahl, auch bei der Stromrechnung.

Wo die Grenzen liegen

Ehrlichkeit heisst, die Schwächen genauso klar zu benennen, denn niemand sollte die Maschine für etwas einsetzen, wofür sie nicht gebaut ist. Das Wichtigste vorweg: Die Spark ist kein Trainings-Kraftwerk. Geht es um Fine-Tuning grosser Modelle oder um Training mit hohem Durchsatz, zeigt sie ihre Grenze, weil Training sowohl rechen- als auch bandbreitenhungrig ist und genau die Speicherbandbreite hier der Flaschenhals gegenüber HBM3 wird. Für ernsthafte Trainingslast nimmst du eine H100 bare metal oder mehrere davon, die spielen in einer anderen Liga. Wer trainieren will, ist auf der Spark am falschen Profil.

Auch beim Durchsatz gibt es eine Obergrenze. Bei sehr vielen gleichzeitigen Nutzern und hohem aggregiertem Token-Durchsatz stösst die Maschine früher an Grenzen als ein auf Durchsatz getrimmtes Multi-GPU-Setup, weil sich die Bandbreite, die den Decode limitiert, auf alle parallelen Anfragen aufteilt. Für die meisten produktiven Lasten reicht das komfortabel, für extreme Skalierung mit Tausenden gleichzeitigen Streams brauchst du mehrere Maschinen oder echte HBM-Hardware. Und schliesslich der ehrlichste Punkt: Wenn dein Modell klein genug ist, um ohnehin bequem in den HBM einer H100 zu passen, gibt dir die Spark keinen Vorteil, im Gegenteil, die H100 liefert dank höherer Bandbreite mehr Tokens/s. Der Kapazitätsvorteil verpufft, sobald Kapazität nicht das Problem ist. Ihre Stärke ist die Tiefe in einer Disziplin, nicht die Breite über alle.

Für wen sich die Maschine lohnt

Aus diesem Profil ergibt sich ziemlich klar, wer profitiert. Der ideale Fall: Du betreibst ein grosses, offenes Modell als stabilen Inferenz-Endpoint mit konstanter Last, willst die Kosten planen und deine Daten in der Schweiz halten, und du schätzt es, ein grosses Modell ohne Sharding-Aufwand zu fahren und bei Bedarf zu wechseln. Genau dafür ist die Maschine gebaut, und genau da spielt sie ihren Vorteil voll aus.

Wann du woanders besser aufgehoben bist, lässt sich knapp zusammenfassen:

• Training oder Fine-Tuning grosser Modelle → eine H100 bare metal mit HBM-Bandbreite.
• Extreme Durchsatzspitzen über sehr viele parallele Nutzer → mehrere Maschinen oder dedizierte HBM-Hardware.
• Kurze, unvorhersehbare Lastpeaks → die elastische Cloud, die du minutenweise hoch- und runterfährst.

Den ganzen Abwägungsraum, inklusive Datenhoheit und Kosten, haben wir im Vergleich DGX Spark gegen Cloud-GPU aufgemacht.

Unser Fazit nach Monaten Betrieb

Die DGX Spark macht eine Sache sehr gut: ein grosses Modell ruhig, planbar und souverän in der Schweiz betreiben, ohne Multi-GPU-Zirkus. Sie ist bewusst kein Alleskönner: Sie tauscht Bandbreite gegen Kapazität, und ob das für dich aufgeht, entscheidet dein Workload, nicht das Marketing. Für konstante Inferenz grosser, offener Modelle ist sie die unaufgeregteste Wahl, die wir kennen; für Training und extreme Durchsatzspitzen ist sie es nicht.

Wir mieten sie monatsweise als planbare Pauschale, sodass du den Vorteil ohne Kapitalbindung und ohne Veralterungsrisiko bekommst, die DGX Spark im Detail. Im Zweifel rechnen wir deinen konkreten Fall durch und sagen ehrlich, ob die Spark, eine H100 bare metal oder die Cloud die richtige Wahl ist.