Ehrlich gesagt, war ich überrascht. Als ich zwei DGX-Spark-Einheiten in einem Cluster verband und DeepSeek-V4-Flash ausführte, war das Ergebnis 1,78x schneller in der Gesamtgenerierungszeit (tatsächliche Wanduhrzeit) im Vergleich zum Mac Studio M3 Ultra – das heißt, es erledigte die Aufgabe in etwa der Hälfte der Zeit. Und das, obwohl der DGX Spark das offizielle FP8-Modell ohne zusätzliche Quantisierung ausführte.
Während ich diese Benchmarks durchführte, hatte ich das Gefühl, dass der Punkt, den ich immer wieder betont habe, erneut durch Zahlen untermauert wurde. Nämlich:
Die LLM-Leistung kann nicht allein anhand der Decodiergeschwindigkeit (Tokens pro Sekunde, TPS) basierend auf der Speicherbandbreite gemessen werden.
GPU-Rechenleistung, Knoten-zu-Knoten-Kommunikation, Speicherhierarchie, Quantisierungsqualität, Kontextlänge, Parallelverarbeitung und so weiter – die „Balance" all dieser Faktoren bestimmt die tatsächliche Benutzererfahrung. Und der DGX Spark hatte einfach eine bessere Balance.
Der verwendete Benchmark: shi3z's Coding-Benchmark
Für die Messung habe ich den Coding-Benchmark aus shi3z's japanischem LLM-Benchmark verwendet. Die Aufgabe besteht darin, „eine Chat-App, die auf React läuft, in einem einzigen Generierungsdurchlauf zu vervollständigen." Der generierte Code wird tatsächlich in Docker gestartet und automatisch mit Playwright auf Login, Freunde, DM und Echtzeit-Updates getestet, mit einer Funktionsbewertung von bis zu 80 Punkten.
Die Ergebnisse der Ausführung von DeepSeek-V4-Flash Q4 (4-Bit-Quantisierung) auf einem Mac Studio M3 Ultra über antirez' ds4-Inferenz-Engine sind in shi3z's Repository aufgelistet. Die folgende Tabelle vergleicht diese Ergebnisse mit den diesmaligen Ergebnissen des 2-Einheiten-DGX-Spark-Clusters + offizielles FP8.
Benchmark-Ergebnisse
Warum es „bei tok/s verliert, aber bei der Wanduhrzeit gewinnt"
Wenn Sie in die Tabelle schauen und denken: „Moment, der Mac ist bei tok/s schneller", haben Sie recht. Betrachtet man nur die momentane Geschwindigkeit des Ausgebens eines Tokens (Decode-TPS), ist das Mac Studio M3 Ultra 1,58x schneller. Dies ist auf die enorme Speicherbandbreite von Apple Silicon zurückzuführen.
Allerdings gibt es hier eine Falle. Um dieselbe Chat-App mit „80/80 perfekter Punktzahl" zu vervollständigen, schrieb der Mac 8.036 Tokens, während der DGX Spark 2.866 Tokens schrieb. Das ist ein Unterschied von etwa 2,8x.
Beide verwendeten DeepSeek-V4-Flash ohne offizielle Qualitätsminderung, aber es liegt nahe zu interpretieren, dass die Mac-Seite, quantisiert auf Q4, redundant wurde, während die Spark-Seite, die in voller Qualität FP8 läuft, prägnant blieb. Es ist ein bekanntes Phänomen, dass sich die Auswirkung der Quantisierung auf die Ausgabeverteilung nicht in der Decodiergeschwindigkeit zeigt, aber leise die Generierungsstrategie beeinflusst.
Daraus ergibt sich folgende Berechnung:
Tatsächliche Wanduhrzeit = (Ausgabetokens) ÷ (tok/s)
Mac: 8.036 ÷ 26,2 = 307 Sekunden Wir: 2.866 ÷ 16,6 = 172 Sekunden
Bei tok/s zu verlieren, aber bei der Wanduhrzeit zu gewinnen, bedeutet, „die gleiche richtige Antwort in weniger Schritten zu erreichen." In der Praxis erleben Menschen die „Zeit bis zur Fertigstellung der Aufgabe", nicht die momentanen tok/s.
Verwendete Konfiguration
- Hardware: DGX Spark × 2 (NVIDIA GB10, Blackwell-basiert, 128 GB Unified Memory pro Stück)
- Knotenverbindung: Direktverbindung über ConnectX-7 200 Gbps RoCE (Tensor Parallel = 2, PyTorch Distributed Backend)
- Inferenz-Engine: Aidens Rezept, das b12x (eine Reihe von GB10-spezifischen CuTe-DSL-Kernels) in vLLM 0.21.1dev integriert.
- Modell: DeepSeek-V4-Flash offizielles FP8 (154 GB, FP8-Attention, MXFP4 MoE – dies ist das offizielle, von DeepSeek veröffentlichte Format)
- Kontext: 524.288 Tokens (512K), Util 0,82, KV-Cache 19,85 GiB, Gleichzeitigkeit 3,89×
- Multi-Token Prediction (MTP): Spekulative Dekodierung mit einer Akzeptanzrate von etwa 62 % (Geschwindigkeitsgewinn ohne Einbußen bei der Ausgabequalität)
Ein genauerer Blick auf die Leistung
Über die Zahlen in diesem Benchmark hinaus habe ich separate Messungen der reinen Decodier- und Prefill-Geschwindigkeiten durchgeführt:
- Reine Decodiergeschwindigkeit (Kurzer Text, exklusive TTFT): Stabil bei etwa 39 tok/s
- Prefill-Geschwindigkeit (Großer Kontext): 1.277 tok/s (Das ist etwa 6,5x schneller als die 196 tok/s der alten Konfiguration ohne b12x-Kernels)
- Decodieren mit langem Kontext: Selbst als ich von 8K → 64K → 128K → 256K → 512K → 768K erhöhte, fiel die Decodiergeschwindigkeit nicht stark ab; tatsächlich beschleunigte sie sich (106 tok/s bei 768K). Dies liegt daran, dass DeepSeek's Sparse Attention (DSA) nativ in den b12x-Kernels implementiert ist, was die Aufmerksamkeitsberechnungen nahezu unabhängig von der Kontextlänge macht.
Dies ist ein Ergebnis mit „Keine Quantisierung, volle Qualität"
Ein weiterer Punkt, den ich betonen möchte, ist, dass die DGX-Spark-Seite keine zusätzliche Quantisierung am Modell vorgenommen hat. Wir haben die offiziellen 154 GB, die auf HuggingFace verteilt sind, so geladen, wie sie sind, und sie im offiziellen Quantisierungsformat von DeepSeek ausgeführt: FP8-Attention + MXFP4 MoE.
In der Welt der lokalen LLMs ist es zum Allgemeinwissen geworden, riesige Modelle auf IQ2 (2-Bit) oder Q4 zu komprimieren, um sie zum Laufen zu bringen, aber diese kosten definitiv Qualität. Tatsächlich habe ich zuvor die IQ2XXS (2-Bit)-Version von DeepSeek-V4-Flash ausprobiert und bei demselben Benchmark ein Ergebnis von 55/80 + Agentenverhaltenszusammenbruch gesehen. Quantisierung ist kein kostenloses Mittagessen.
Eine Konfiguration, die mit zwei DGX Sparks 256 GB Unified Memory sichern kann, macht die Option, „riesige Modelle in voller Qualität auszuführen", erstmals Realität. Ich denke, dies ist ein bedeutenderer Fortschritt, als die Zahlen vermuten lassen.
Warum Sparks „Balance" funktioniert hat
Aufschlüsselung der technischen Elemente, die dieses Ergebnis unterstützt haben:
- b12x-Kernel-Suite: Vier Arten von Kernels (NVFP4 fused MoE GEMM, NVFP4 dense GEMM, FP8 paged attention und sparse MLA attention), die speziell für GB10 / SM12.x mit CuTe DSL geschrieben wurden. Anders als der MARLIN-Pfad im allgemeinen vLLM berechnen diese direkt im fusionierten Modus, ohne zu dequantisieren.
- 200 Gbps RoCE-Direktverbindung: Obwohl TP=2-Knoten-zu-Knoten-All-Reduce zweimal pro Schicht stattfindet, hält die 200-Gbps-Direktverbindung die effektive Latenz gering, sodass sie kein Engpass für die Dekodierung wird.
- 128 GB Unified Memory × 2: Ein Vorteil von Grace Blackwell, das HBM und DDR nicht trennt. Es erlaubt, das 154 GB große offizielle FP8-Modell wie besehen auf zwei Einheiten aufzuteilen, mit genügend Platz für einen 19,85 GiB KV-Cache für einen 512K-Kontext.
- Native Implementierung von DeepSeek Sparse Attention (DSA): Die b12x-Kernels behandeln korrekt das Design, bei dem die Aufmerksamkeitskomplexität nicht von der Kontextlänge abhängt, indem sie GB10s native Sparse-Operationen nutzen. Dies führte zu dem Ergebnis, dass die Decodiergeschwindigkeit nicht mit der Kontextlänge einbricht.
Mit anderen Worten: Wenn nur eines dieser Elemente – Speicherbandbreite, Rechenleistung, Knotenkommunikation, Optimierung für lange Kontexte oder Quantisierungsqualität – herausragend gewesen wäre, hätte dieses Ergebnis nicht erzielt werden können. Spark bietet alle diese Elemente auf einem höheren Niveau als jede Einzelmaschinenkonfiguration in derselben Preisklasse. Dies ist die wahre Natur seiner „Balance".
Was ändert sich in der Praxis?
Um über die abstrakte Theorie hinauszugehen, hier einige konkrete Vorteile:
- Zusammenfassung und Code-Analyse riesiger Dokumente werden realistisch: Mit einem 512K-Kontext und einer Prefill-Geschwindigkeit von 1.277 tok/s können Sie ein ganzes Buch (~300.000 Tokens) in etwa 4 Minuten laden und zusammenfassen.
- Agenten-Schleifen bleiben nicht stecken: Mit 3,89× Gleichzeitigkeit können Sie Chat und Langform-Zusammenfassung gleichzeitig ausführen (z. B. mit Hermes Agent), ohne dass die Dekodierung zusammenbricht.
- Kein „Agent redet nur" auf Grund von Quantisierungsfehlern: Dies ist eine Falle, in die ich bei IQ2-Serien-Modellen oft getappt bin; mit voller Qualität passiert es einfach nicht.
- Wettbewerbsfähig mit dem Mac beim Stromverbrauch: Der Gesamtstromverbrauch von zwei GB10s während der Inferenz liegt bei etwa 100W–140W, was nahe am Mac Studio M3 Ultra bei Volllast liegt. Angesichts der 1,78-fachen Leistung ist die Energieeffizienz auch nicht schlecht.
Fazit: Die Ära, LLM-Leistung allein an TPS zu messen, ist vorbei
Die momentane Geschwindigkeit des Ausgebens eines Tokens – Decode-TPS – ist sicherlich eine wichtige Metrik. Sie ist jedoch wie die „Höchstgeschwindigkeit eines 100-Meter-Sprints." Was in der Praxis benötigt wird, ist die „Zeit, um zur gleichen richtigen Antwort zu gelangen", die „Qualität der Antwort", „wie viele gleichzeitig laufen können", „wie lang ein Kontext sein kann" und „ob Agentenschleifen funktionieren." Dies sind die Gesamtpunktzahlen.
Was dieses Ergebnis gezeigt hat, ist, dass der DGX Spark beginnt, sich in dieser Gesamtpunktzahl abzusetzen. Wir sind in eine Ära eingetreten, in der man ein riesiges Modell in offizieller Qualität, mit langem Kontext, unter Beibehaltung der Agentenkompatibilität, mit der 1,78-fachen Wanduhrzeit eines Mac Studio ausführen kann, indem man einfach zwei Einheiten in einem Cluster verbindet.
In den letzten Jahren sagten die Leute: „Bei LLMs geht es nur um Speicherbandbreite" und „Decode-TPS ist alles", aber nachdem ich den Spark tatsächlich ausgeführt habe, habe ich das Gefühl, dass meine Behauptung, „Balance ist praktische Leistung", endlich durch Zahlen bewiesen wurde.
Der RTX Spark wurde auch angekündigt, und es hat den Anschein, dass die Dinge sich stärker aufheizen als erwartet (obwohl die Stimmung vielleicht abkühlt, sobald der Preis bekannt ist...). Ich habe hohe Erwartungen, dass die Community wächst und sich mehr Optimierung und Know-how ansammelt!
Jensen ist wirklich erstaunlich... Wird seine Herrschaft noch lange andauern?
**
**
**
**
**
Bonus
Scharfsinnige Leser könnten diese Kritik haben:
„Wäre es dann nicht ein fairer Vergleich, wenn Sie das rohe offizielle FP8 auch auf dem Mac Studio ausführen würden?"
„Ist der Vergleich nicht unfair? Das Mac Studio wurde nur redundant, weil es auf Q4 quantisiert wurde. Wenn Sie das rohe offizielle FP8 auf dem Mac Studio ausführen würden, wäre es dann nicht auf dem gleichen Spielfeld in Bezug auf die Qualität?" Dies ist eine berechtigte Frage.
Um es direkt zu sagen: Derzeit gibt es keine Möglichkeit, das „rohe offizielle FP8 + MXFP4 MoE" auf einem Mac Studio mit praktikabler Geschwindigkeit auszuführen.
- Erstens gibt es keine kompatible Inferenz-Engine.
Es scheint keine Engine zu geben, die DeepSeek-V4-Flashes offizielles Format (FP8-Attention + MXFP4 MoE + Lightning Indexer + DSA Sparse Attention) auf Apple Silicon vollständig unterstützt (laut einer Claude-Code-Suche).
- MLX (Apples offizielles Apple-Silicon-LLM-Framework): Keine native Implementierung von MXFP4 MoE fused GEMM, kein FP8 paged attention und keine MLX-Implementierung von DeepSeek's DSA Sparse Attention. Wenn man versuchen würde, es auszuführen, müsste man es wahrscheinlich auf bf16 hochstufen.
- llama.cpp: Kann MXFP4 nicht direkt laden, erfordert daher eine erneute Quantisierung zu GGUF = es wird letztendlich zu Q4 / Q5 / IQ2 usw. konvertiert und ist nicht mehr die „rohe offizielle" Version.
- vLLM: Apple-Silicon-Unterstützung ist ohnehin begrenzt, und GB10-spezifische Kernels wie b12x laufen nicht auf einem Mac.
- antirez/ds4: Dies ist eine spezialisierte Engine, die basierend auf MLX speziell für DeepSeek V4 Flash mit der Annahme von Q4 geschrieben wurde. Es ist die derzeit optimale Lösung, um es auf dem Mac Studio auszuführen, aber es ist nicht dafür gebaut, „rohes FP8" zu handhaben.
Die Tatsache, dass antirez eine dedizierte Engine für DeepSeek V4 Flash speziell für Q4 geschrieben hat, spricht Bände darüber, dass es derzeit keinen praktikablen Weg gibt, offizielle Qualität wie besehen auf Apple Silicon auszuführen.
- Selbst wenn es mit bf16-Hochstufung ausgeführt würde, wäre die Bandbreite fast vollständig aufgebraucht.
Angenommen, jemand würde eine MLX-Implementierung erstellen, die offizielle Gewichte auf bf16 hochstuft. Man kann abschätzen, was mit einer groben Bandbreitenberechnung passieren würde:
- DeepSeek-V4-Flash hat eine MoE-Konfiguration mit etwa 30B aktiven Parametern.
- Bei Q4 (4-Bit) belegen aktive Parameter etwa 15 GB, und ds4 erreicht 26,2 tok/s (gemessen).
- Wenn dasselbe Modell mit FP8 (8-Bit) gehalten wird, belegen aktive Parameter etwa 30 GB = 2x Bandbreitenbedarf = theoretisch ~13 tok/s auf derselben Engine.
- Darüber hinaus würde eine Hochstufung auf bf16 in MLX etwa 60 GB für aktive Parameter benötigen = 4x Bandbreitenbedarf = theoretisch ~6,5 tok/s.
- Da die effektive Speicherbandbreite des Mac Studio M3 Ultra bei etwa 800 GB/s liegt, würde das Lesen von 60 GB für jedes Token das Bandbreitenlimit erreichen.
Mit anderen Worten: Die Wahl für „die rohe Qualität" auf Apple Silicon kommt derzeit mit dem Preis, „mehr als die doppelte Geschwindigkeit zu opfern." Das Laufen mit 26,2 tok/s mit ds4 + Q4 war eine praktischere Wahl, als nur 6 tok/s mit vollwertigem bf16 zu bekommen.
- Hier kommt der strukturelle Vorteil von Spark ins Spiel.
Andererseits führt diese DGX-Spark-Konfiguration das „rohe offizielle FP8 + MXFP4 MoE nativ" aus. Dies wird unterstützt durch:
- Die b12x-Suite GB10-spezifischer Kernels, die Implementierungen hat, um NVFP4 fused MoE GEMM und FP8 paged attention „ohne Dequantisierung" auszuführen.
- Dies wurde noch nicht für Apple Silicon geschrieben.
- Daher ist Spark derzeit die einzige realistische Lösung, um „offizielle Qualität wie besehen" und „mit praktikabler Geschwindigkeit" auszuführen.
Zusammenfassend: Wenn man nur die Hardware-Bandbreite betrachtet, ist der absolute Wert des Mac Studio für eine Einheit auf einem ähnlichen Niveau, aber das Vorhandensein oder Fehlen von „Kernel-Implementierungen, die offizielle Quantisierungsformate nativ ausführen" macht einen entscheidenden Unterschied. Sparks Vorteil kommt nicht nur vom Chip, sondern von der gesamten Kombination mit dem GB10-spezialisierten Software-Stack wie b12x.
Wenn jemand in Zukunft MXFP4 fused MoE GEMM, FP8 paged attention und DSA Sparse Attention für Apple Silicon in MLX schreibt, wird diese Prämisse zusammenbrechen. Die Landschaft wird sich je nach Community-Implementierungen ändern. Für den Moment ist es eine Tatsache, dass Spark einen Schritt voraus ist, wenn es um die Kombination von „offizieller Qualität × praktikabler Geschwindigkeit" geht.
Dies sind die Ergebnisse der von Claude Code bereitgestellten Analyse.
