Zwei Mac Studios clustern oder 512 GB kaufen? Lokale LLMs auf dem M5 Ultra im Faktencheck

Kurzantwort vorweg: Ja, zwei Mac Studios mit je 256 GB lassen sich seit macOS 26.2 über Thunderbolt 5 mit RDMA koppeln und gemeinsam ein Modell hosten, das auf einen allein nicht passt. Aber: Der Cluster ist Ende Oktober 2026 vor allem ein Werkzeug für mehr Kapazität, nicht für mehr Tempo. Für das derzeit spannendste offene Modell, DeepSeek V4.1 Flash 1017, reicht ein einzelner M5 Ultra mit 256 GB. Er erreicht in Messungen der Entwickler rund 90 bis 100 Tokens pro Sekunde beim Generieren und 3.000 bis knapp 3.900 Tokens pro Sekunde beim Einlesen langer Prompts. Die bisher öffentlich dokumentierten Cluster-Messungen mit diesem Modell liegen zwischen 16 und 36 Tokens pro Sekunde, für zwei M5 Ultras mit funktionierendem RDMA gibt es noch keine veröffentlichte Messung. Unsere Empfehlung lautet deshalb: einen 256er kaufen und den zweiten erst dann, wenn ein Modell ihn wirklich braucht. Der 512er lohnt sich nur noch als Versicherung.

Stand dieser Analyse: 31. Oktober 2026. Die Engine-Landschaft für Apple Silicon ändert sich gerade im Wochentakt. Wir nennen deshalb bei jeder Zahl Hardware, Modellpaket und Quelle und trennen Gemessenes klar von Berichtetem und Geschätztem.

Die Technik: RDMA über Thunderbolt 5

Bis Ende 2025 war das Clustern von Macs eher ein Experiment. Die Verbindung lief über TCP, und jeder Sprung zwischen zwei Rechnern kostete rund 300 Mikrosekunden Latenz. Für Verfahren, bei denen die Maschinen pro Token dutzendfach Daten austauschen, war das zu langsam.

Mit macOS 26.2 hat Apple einen RDMA-Treiber für Thunderbolt 5 eingeführt. RDMA steht für Remote Direct Memory Access: Ein Rechner kann direkt in den Speicher des anderen schreiben, ohne den Umweg über den Netzwerkstack. Laut Jeff Geerling sinkt die Latenz damit auf unter 50 Mikrosekunden, der praktische Durchsatz liegt bei 50 bis 60 Gbit/s. Apples Machine-Learning-Framework MLX nutzt den Treiber ab Version 0.30.1 über das Kommunikations-Backend jaccl.

Zwei Arten, ein Modell zu verteilen

• Pipeline-Parallelisierung: Das Modell wird der Tiefe nach geteilt. Mac 1 rechnet die ersten Schichten, Mac 2 die restlichen. Zwischen den Rechnern wandert pro Token nur ein kleines Zwischenergebnis. Das ist robust, auch über langsame Verbindungen, bringt aber beim Generieren praktisch kein Tempo, weil die Schichten weiter nacheinander laufen. Vorteile zeigt es nur beim Einlesen sehr langer Prompts, weil sich Abschnitte überlappen lassen. Apple misst bei 64.000 Tokens bis zu 1,8-fache Geschwindigkeit.
• Tensor-Parallelisierung: Jede einzelne Schicht wird der Breite nach auf beide Rechner verteilt. Beide rechnen gleichzeitig, müssen sich dafür aber pro Token und Schicht abstimmen. Ohne RDMA frisst die Kommunikation den Gewinn auf. Mit RDMA ist das der Weg zu echtem Tempogewinn.

Was Apple selbst misst

Apple hat am 15. Oktober 2026 eigene Messungen auf dem M5 Ultra veröffentlicht. Die Decode-Geschwindigkeit in Tokens pro Sekunde:

Die Lesart ist eindeutig: Pipeline bringt Kapazität, Tensor-Parallelisierung bringt Kapazität und Tempo, bei zwei Rechnern etwa den Faktor 1,6 bis 1,8. Genau diese Unterscheidung entscheidet später darüber, ob sich ein Cluster lohnt.

Was man für den Aufbau braucht

• RDMA muss auf jedem Mac einmalig im Recovery-Modus mit rdma_ctl enable aktiviert werden.
• Die Macs werden direkt per Thunderbolt-5-Kabel verbunden, bei mehr als zwei Rechnern jeder mit jedem. Nicht geeignet ist der Thunderbolt-5-Port neben dem Ethernet-Anschluss. Apple nutzt in seinen Tests zwei Kabel pro Verbindung, um die Bandbreite zu verdoppeln.
• Alle Rechner brauchen exakt dieselbe macOS-Version. Updates werden also künftig immer gemeinsam eingespielt.
• Ein häufiger Stolperstein aus der Praxis: Hat der Thunderbolt-Link nur eine automatisch vergebene 169.254-Adresse, fällt die Verbindung unbemerkt auf LAN oder sogar WLAN zurück. Abhilfe schafft eine manuelle IPv4-Adresse auf dem Thunderbolt-Port beider Macs, etwa 10.10.0.1 und 10.10.0.2.

Die Speicherrechnung: Was passt in 2 × 256 GB?

Ein Mac mit 256 GB stellt der GPU nicht die vollen 256 GB zur Verfügung. macOS braucht selbst Speicher, und das GPU-Limit muss per sudo sysctl iogpu.wired_limit_mb angehoben werden. Ein Anwender betreibt zwei M5 Ultras ohne Monitor mit manuell gesetzten 250 GB pro Gerät. Realistisch bleiben im Cluster also rund 450 bis 500 GB für Gewichte, KV-Cache und Arbeitspuffer. Das ist unsere Schätzung, kein Herstellerwert.

Die Faustformel für die Gewichte lautet: Parameter mal Bits pro Gewicht geteilt durch acht.

* Mit den Skalierungsfaktoren des NVFP4-Formats kommt Apple für Muse Spark Open auf rund 493 GB.

Das Ergebnis: Mit 3 bis 3,5 Bit pro Gewicht passt die gesamte Modellklasse von 750 bis 820 Milliarden Parametern in zwei 256er. Modelle mit mehr als einer Billion Parametern passen nicht. Für die Vier-Bit-Variante von Muse Spark Open nennt Meta zwei Mac Studios mit je 512 GB.

Fallstudie: DeepSeek V4.1 Flash 1017

DeepSeek hat am 17. Oktober 2026 ein Update seines Flash-Modells veröffentlicht, mit offenen Gewichten unter MIT-Lizenz. Das Modell ist für lokale Hardware aus mehreren Gründen besonders:

• Architektur: Es ist das erste DeepSeek-Modell mit einer kausalen Encoder-Decoder-Architektur. 40 Schichten sind in 20 Encoder- und 20 Decoder-Schichten aufgeteilt. Der Backbone hat 552 Milliarden Parameter, aktiv sind nur 8 Milliarden pro Token beim Einlesen und 16 Milliarden beim Generieren.
• Winziger KV-Cache: Laut Modellkarte braucht der KV-Cache nur 890 Bytes pro Token. Selbst eine Million Tokens Kontext belegt damit unter einem Gigabyte. Der Kontext ist bei diesem Modell nicht der Engpass, nur die Gewichte sind es.
• Gesamtgröße: Hugging Face zählt 763 Milliarden Parameter. Die Differenz zum Backbone stammt vermutlich aus Zusatzkomponenten wie den Engram-Tabellen, dem Vision-Encoder und den Schichten für spekulatives Decoding. Die beiden Engram-Dateien sind zusammen gut 200 GB groß und können auf der SSD bleiben.
• Bereits nativ in 4 Bit: DeepSeek liefert die Experten schon im Format FP4 aus, den Rest in FP8. Die übliche Ersparnis durch eine 4-Bit-Quantisierung gibt es bei diesem Modell deshalb nicht.

Wie gut sind die Quants?

Wer ein 552B-Modell auf einen einzelnen 256er bringen will, muss unter 3 Bit pro Gewicht gehen. Entscheidend ist, wie viel Qualität das kostet. Die folgenden Werte stammen aus den Veröffentlichungen der jeweiligen Ersteller und sind gegen das native 1017-Modell gemessen. Top-1 bedeutet: Wie oft wählt der Quant dasselbe nächste Token wie das Original. KLD misst die Abweichung der Wahrscheinlichkeitsverteilungen, niedriger ist besser.

Die Messmethoden unterscheiden sich je nach Ersteller, die Zahlen sind deshalb nicht auf die Nachkommastelle vergleichbar. Drei Befunde sind trotzdem belastbar:

1. Das Format zählt mehr als die Bitzahl. EXL3-Builds um 2,8 bpw liegen praktisch auf Original-Niveau. Beim sudoingx-Build lagen HumanEval+, MBPP+ und IFEval innerhalb der Messstreuung des nativen Modells. Einfache MLX-Quants bei vergleichbarer Größe weichen um eine Größenordnung stärker ab.
2. Deutsch leidet zuerst. Beim Rapid-MLX-Build bleibt die Abweichung bei Code (KLD 0,055) und Mathematik (0,063) gering, bei allgemeinem Chat steigt sie auf 0,14 bis 0,18. Nicht-englische Texte und Nischenwissen driften am stärksten. Beim REAP-Build sinkt die Übereinstimmung bei mehrsprachigen Texten auf 52 %. Wer auf Deutsch arbeitet, sollte Quants gezielt mit eigenen deutschen Prompts testen.
3. Die schnellsten Mac-Zahlen stammen von einem Paket ohne veröffentlichte Qualitätswerte. Das Sushi-STQ-Format speichert die Experten wie EXL3 im effizienten Trellis-Verfahren. Das spricht für eine gute Qualität pro Bit. 1,75 bpw sind aber sehr wenig. Solange keine KLD-Werte vorliegen, gilt: selbst messen.

Die Engines: Stand Ende Oktober 2026

Das Tempo ist beachtlich. DeepSeek veröffentlichte 1017 am 17. Oktober. Fünf Tage später lief es in mlx-serve über zwei Macs verteilt, am 28. Oktober kam das Plugin-System mit dem Sushi-Kern. Im Plugin-Repository folgten innerhalb weniger Tage mehrere Optimierungen, die das Einlesen langer Prompts jeweils um 4 bis 16 % beschleunigten. Wichtig für die Einordnung des Risikos: Die Grundlage, also RDMA in macOS und jaccl in MLX, kommt offiziell von Apple. Die Community-Projekte bauen darauf auf.

Gemessen: ein M5 Ultra gegen den Cluster

Ein einzelner M5 Ultra mit 256 GB

Die belastbarsten Zahlen stammen aus den Pull Requests des Plugin-Repositorys. Die Bedingungen: M5 Ultra mit 256 GB, macOS 27.2, Sushi-STQ-1,75-bpw-Paket, alle 384 Experten pro Schicht im RAM, eine Anfrage gleichzeitig.

Für die Experten stehen dabei rund 198 GB zur Verfügung, genug für alle 384 Experten jeder Schicht. Mit einem 3,0-bpw-Paket im nativen Modellcode von mlx-serve wurden etwas früher 56,8 tok/s ohne und 48 bis 82 tok/s mit spekulativem Decoding gemessen, abhängig von der Textart. Inzwischen haben die mlx-serve-Entwickler auf X einen Benchmark mit dem Paket DeepSeek-V4.1-Flash-1017-iQ-MLX-3.0bpw auf einem M5 Ultra mit 256 GB veröffentlicht. Die Bedingungen laut Screenshot: Greedy Decoding, eine Anfrage, Median aus drei Läufen nach einem Warmup.

Die Kontextlänge der Prefill-Messung geht aus dem Screenshot nicht hervor. Für Agenten-Arbeit und deutsche Texte ist der Wert für neuen Text der realistischere.

Unabhängig davon bestätigt ein Community-Build auf Basis von TensorFold die Größenordnung: Auf einem einzelnen 256-GB-M5-Ultra misst er 67,5 bis 94,4 tok/s mit spekulativem Decoding und 1.093 bis 1.392 tok/s Prefill bei kaltem Prompt, inklusive Bildeingabe, Tool-Calls und 1 Mio. Tokens Kontext.

Was Cluster-Messungen mit DeepSeek V4.1 bisher zeigen

Für zwei M5 Ultras mit funktionierendem RDMA haben wir bis Redaktionsschluss keine veröffentlichte Messung gefunden. Es gibt aber drei aufschlussreiche Datenpunkte:

• 2× M5 Ultra 256 GB, oMLX (Bug-Report vom 20. Oktober): Anfangs 1 tok/s, nach Korrekturen in Version 0.7.2 dann 16,7 tok/s. Dieser Wert ist aber nicht repräsentativ: Laut Maintainer lief die Verbindung über einen normalen TCP-Ring statt über RDMA, weil die Adresse auf der Thunderbolt-Bridge statt auf dem Thunderbolt-Port lag. Mit 256 GB pro Mac passte bei diesem Paket zudem nur Tensor-Parallelisierung, die Engram-Tabellen bleiben dabei auf der SSD.
• 2× M3 Ultra über Thunderbolt, oMLX 0.7.3rc1 (Release Notes, Paket oQ4e): Pipeline 32,4 bis 34,3 tok/s, Tensor-Parallelisierung 24,3 bis 25,4 tok/s. Ein einzelner M3 Ultra kommt mit demselben Paket laut denselben Release Notes auf 34,3 tok/s. Der Cluster ist hier also bestenfalls gleich schnell, mit Tensor-Parallelisierung sogar langsamer.
• 3× M5 Max mit je 128 GB, native Gewichte, RDMA (experimenteller Aufbau): 35,6 tok/s für eine einzelne Anfrage.

mlx-serve teilt DeepSeek V4.1 im Cluster laut Code-Beschreibung nach Schichten auf, also per Pipeline. Nach Apples Messungen bringt das beim Generieren keinen Tempogewinn.

Die Einordnung: Für DeepSeek V4.1 gibt es bislang keinen öffentlichen Beleg, dass ein Cluster schneller ist als ein einzelner Rechner. Ein plausibler Grund: Mit nur 16 Milliarden aktiven Parametern pro Token ist die Rechenarbeit pro Schicht klein, der Abstimmungsaufwand zwischen den Rechnern bleibt aber gleich. Apple beobachtet denselben Effekt in seinen Messungen: Dichte Modelle skalieren über mehrere Rechner besser. Neue Messungen erscheinen derzeit fast täglich. Bei Cluster-Zahlen lohnt deshalb immer der Blick auf drei Details: Lief die Verbindung über RDMA, welches Paket wurde genutzt, und bei welcher Kontextlänge wurde gemessen? Für 1017 bleibt das Fazit: Das Modell passt auf einen Rechner, und dort läuft es heute am schnellsten.

Zum Vergleich auf NVIDIA-Seite: Zwei DGX Sparks schaffen 1017 mit dem EXL3-Build bei 2,8 bpw und nahezu Original-Qualität mit rund 104 tok/s bei Code, 58 bei Prosa und 144 bei strukturierter Ausgabe. Wie sich ein 4×-DGX-Spark-Cluster im Eigenbetrieb schlägt, haben wir hier gemessen.

512 GB oder zwei mal 256 GB?

Apple hat die 512-GB-Konfiguration am 28. Oktober freigeschaltet, mit 7 bis 8 Wochen Lieferzeit. In den USA kostet sie 22.299 Dollar, genau 11.500 Dollar mehr als dieselbe Konfiguration mit 256 GB. In Deutschland kostet ein M5 Ultra mit 36-Kern-CPU, 80-Kern-GPU, 256 GB und 1 TB SSD nach den von Macwelt genannten Aufpreisen 12.429 Euro. Einen Euro-Preis für die 512-GB-Variante konnten wir zum Redaktionsschluss nicht verifizieren.

Ein 512er kostet damit ungefähr so viel wie zwei 256er.

Die Vergleichsgrafik „Two 256GB M5 Ultras beat one 512GB“

Auf X kursiert eine Grafik, nach der zwei 256er einen 512er klar schlagen: rund 215 bis 245 statt 135 TFLOPS, 1,9 bis 2,2 statt 1,2 TB/s, bei DeepSeek V4.1 Flash 75 bis 100 statt 45 bis 60 tok/s und bei GLM-5.3 55 bis 70 statt 33 bis 40 tok/s. Die Grundrichtung teilen wir: Für Modelle, die einen 512er wirklich brauchen und deren Engine Tensor-Parallelisierung über RDMA beherrscht, sind zwei 256er die bessere Wahl. Als Messung taugt die Grafik aber nicht:

• Keine Angaben zur Messung: Engine, Quantisierung und Kontextlänge fehlen. Die Werte sind mit Tilde und als Spannen angegeben, die Cluster-Werte liegen durchgehend beim etwa 1,7-Fachen der Einzelwerte. Das ist genau der Faktor, den Apple für dichte Modelle misst. Es handelt sich also offenbar um eine Hochrechnung.
• Der Einzelwert für DeepSeek V4.1 passt nicht zu den Messungen: Ein M5 Ultra mit 256 GB, also derselbe Chip wie im 512er, schafft mit einem 3-Bit-Paket 92 tok/s. Ein 512er wäre mit demselben Paket genauso schnell. Die 45 bis 60 tok/s ergeben allenfalls Sinn, wenn auf dem 512er eine höher präzise und damit langsamere Variante läuft. Dann vergleicht die Grafik aber unterschiedliche Quantisierungen.
• Der Cluster-Wert entspricht einem einzelnen 256er: Die 75 bis 100 tok/s für zwei Rechner misst ein einzelner M5 Ultra mit 256 GB heute schon. Bei DeepSeek V4.1 bringt der zweite Rechner nach aktuellem Stand also kein Tempo, sondern nur Platz für eine höhere Präzision.

Ein verbreiteter Denkfehler

Ein 512er macht dasselbe Modell nicht schneller. Chip und Speicherbandbreite sind identisch mit dem 256er. Wer den zusätzlichen Speicher für eine höhere Präzision nutzt, wird beim Generieren sogar langsamer, weil pro Token mehr Bytes gelesen werden müssen. 1017 in 4 Bit läuft auf dem 512er also langsamer als in knapp 3 Bit auf dem 256er.

Was für den 512er übrig bleibt

Wer bereit ist, Modelle der 750B-Klasse mit 3 bis 3,5 Bit zu betreiben, bekommt mit zwei 256ern dieselbe Kapazität. Als echter Vorteil des 512ers bleibt dann nur die Unabhängigkeit vom Cluster-Support: Er führt jedes Modell aus, das die Engine überhaupt unterstützt. Dazu kommt der Ausbaupfad auf 1 TB mit zwei 512ern, etwa für Muse Spark Open in 4 Bit.

Werden die Engines besser? Ja, aber nicht überall

Software-Fortschritt hilft den beiden Varianten unterschiedlich.

Was Engines verbessern können:

• Bessere Quants: Dieselbe Qualität mit weniger Bits macht 256 GB für immer größere Modelle ausreichend. Das spricht gegen den Aufpreis für 512 GB.
• SSD-Streaming: Engines lesen zu große Teile des Modells bei Bedarf von der SSD. mlx-serve betreibt so GLM-5.3 mit 744 Milliarden Parametern auf einem einzelnen 256-GB-Mac.
• Cluster-Support für mehr Modelle: Jede Erweiterung macht zwei 256er nützlicher.
• Effizientere Tensor-Parallelisierung: mehr Gewinn pro zusätzlichem Rechner.

Was Engines nicht ändern können:

• Die Speicherbandbreite pro Mac: Das Generieren ist durch sie begrenzt, 1,2 TB/s bleiben 1,2 TB/s.
• Die Thunderbolt-Verbindung: Latenz und ein praktischer Durchsatz von 50 bis 60 Gbit/s begrenzen, wie gut Tensor-Parallelisierung skaliert.
• Die Anzahl der Rechner: Gängige Engines wie exo setzen für Tensor-Parallelisierung Zweierpotenzen voraus, also 2 oder 4 Rechner. Ein Full Mesh ist durch die Thunderbolt-Ports begrenzt.
• Das Wachstum der Modelle: Muse Spark Open hat 816 Milliarden Parameter, DeepSeek V4 Pro hatte 1,6 Billionen, und DeepSeek hat ein V4.1 Pro in Aussicht gestellt.

Unter dem Strich spricht der Software-Fortschritt eher für den schrittweisen Kauf von 256ern als für den 512er.

SSD-Streaming und Verschleiß

Wer Modelle per Streaming von der SSD betreibt, fragt sich zu Recht, ob das die SSD verschleißt. Die kurze Antwort: Das Streaming selbst nicht. Flash-Zellen nutzen sich durch Schreiben ab, nicht durch Lesen. Häufiges Lesen kann benachbarte Zellen minimal beeinflussen. Der Controller frischt betroffene Blöcke dann im Hintergrund auf, was im Vergleich zu normaler Nutzung vernachlässigbar ist.

Geschrieben wird an drei Stellen: beim Auslagern von Arbeitsspeicher (Swap), beim Speichern von Gesprächsständen im Prompt-Cache und beim Herunterladen von Modellen. Apple veröffentlicht keine Haltbarkeitswerte. Wir rechnen deshalb mit einem typischen Wert für TLC-SSDs von etwa 600 TB Schreibvolumen pro TB Kapazität, für eine 4-TB-SSD also rund 2.400 TB. Das ist eine Annahme, keine Herstellerangabe.

Die Cache-Werte sind grobe Beispielrechnungen. Bei DeepSeek V4.1 sind 128.000 Tokens Gesprächsstand wegen des kleinen KV-Caches nur rund 110 MB groß.

Das eigentliche Risiko ist Swap durch ein zu knapp gesetztes Speicherbudget. Weil sich die SSD im Mac Studio nicht einfach selbst tauschen lässt, lohnt die Kontrolle:

1. Nach dem Einrichten mit brew install smartmontools und smartctl -a disk0 die Werte „Percentage Used“ und „Data Units Written“ notieren.
2. Nach vier Wochen erneut messen. Steigt „Percentage Used“ um mehr als 1 % pro Monat, ist meist Swap die Ursache.
3. Während der Inferenz sysctl vm.swapusage beobachten und bei wachsendem Wert das Speicherbudget der Engine senken.

Der größere Nachteil des Streamings ist ohnehin das Tempo. Die Geschwindigkeit hängt dann vom Lesedurchsatz der SSD ab. Sushi erreicht mit 1017 auf einem M5 Max mit 128 GB per Streaming 76,6 tok/s bei Code und 49,3 bei Prosa, ein M5 Ultra mit dem kompletten Modell im RAM liegt deutlich darüber.

Unsere Empfehlung

1. Jetzt einen M5 Ultra mit 256 GB kaufen (36-Kern-CPU, 80-Kern-GPU, mindestens 4 TB SSD für mehrere Modellpakete). Für DeepSeek V4.1 Flash 1017 reicht er vollständig, mit mlx-serve und dem Plugin sushi_ds41 oder mit Sushi direkt.
2. Quant-Qualität selbst prüfen, vor allem auf Deutsch. Solange für die schnellen STQ-Pakete keine KLD-Werte veröffentlicht sind, mit eigenen Prompts gegen die DeepSeek-API vergleichen.
3. Den zweiten 256er erst kaufen, wenn zwei Bedingungen erfüllt sind: Ein Modell, das du brauchst, passt nicht mehr auf einen Rechner, und deine Engine beherrscht dafür nachweislich Tensor-Parallelisierung über RDMA.
4. Den 512er nur als Versicherung wählen: wenn du keinerlei Abhängigkeit von Cluster-Support willst oder von vornherein zwei 512er für 1 TB planst.
5. Den Betrieb sauber aufsetzen: ohne Monitor betreiben, GPU-Limit anheben, Thunderbolt-Bridge deaktivieren, feste IP-Adressen auf dem Thunderbolt-Port vergeben und Swap beobachten.

Häufige Fragen

Kann man zwei Mac Studios mit 256 GB zu einem 512-GB-Rechner zusammenschalten? Nicht im Sinne eines gemeinsamen Arbeitsspeichers für beliebige Programme. Inferenz-Engines wie MLX, mlx-serve oder oMLX können ein Modell aber auf beide Rechner verteilen, über Thunderbolt 5 mit RDMA ab macOS 26.2. Nutzbar sind real rund 2 × 250 GB. Ob das funktioniert, hängt davon ab, ob die Engine das jeweilige Modell im Cluster unterstützt.

Ist ein Cluster aus zwei Macs schneller als ein einzelner Mac? Nur mit Tensor-Parallelisierung über echtes RDMA. Dann misst Apple beim M5 Ultra etwa den Faktor 1,6 bis 1,8. Mit Pipeline-Parallelisierung bleibt das Tempo beim Generieren praktisch gleich. Bei DeepSeek V4.1 zeigen die bisher veröffentlichten Cluster-Messungen noch keinen Vorteil gegenüber einem einzelnen Rechner. Ein einzelner M5 Ultra schafft das Modell mit rund 90 bis 100 tok/s.

Läuft DeepSeek V4.1 Flash 1017 auf einem einzelnen Mac Studio mit 256 GB? Ja. Mit einem 3-Bit-Paket messen die mlx-serve-Entwickler auf einem M5 Ultra mit 256 GB 92 tok/s beim Generieren und knapp 3.900 tok/s beim Einlesen. Das Sushi-STQ-Paket mit 1,75 bpw kommt auf rund 100 tok/s. Die Engram-Tabellen bleiben dabei auf der SSD. Für die Sushi-STQ-Pakete sind allerdings noch keine Qualitätswerte veröffentlicht.

Lohnt sich der Aufpreis für 512 GB? Für die meisten nicht. Der Aufpreis entspricht etwa einem zweiten 256er, und der 512er macht dasselbe Modell nicht schneller. Er lohnt sich, wenn du Modelle der 750B-Klasse ohne jede Abhängigkeit von Cluster-Support in höherer Präzision betreiben willst oder einen Ausbau auf 1 TB mit zwei 512ern planst.

Geht die SSD durch Streaming kaputt? Nein. Streaming liest nur, und Lesen verschleißt Flash-Speicher praktisch nicht. Kritisch ist dauerhaftes Swapping durch ein zu knappes Speicherbudget. Mit smartctl und sysctl vm.swapusage lässt sich das einfach überwachen.

Wie stark leidet die Qualität durch Quantisierung? Das hängt vor allem vom Format ab. EXL3-Builds um 2,8 bpw stimmen bei DeepSeek V4.1 Flash 1017 zu rund 96 % mit dem Original überein, einfache MLX-2-Bit-Quants nur zu rund 80 %. Nicht-englische Sprachen, also auch Deutsch, verlieren zuerst an Qualität.

Quellen

• Apple Machine Learning Research: Local and Distributed Large LLM Inference with MLX and RDMA on Mac Studio (15.10.2026) – https://machinelearning.apple.com/research/mlx-distributed-inference
• computingforgeeks: Cluster Local LLMs – Mac Studio vs Strix Halo vs Two DGX Sparks – https://computingforgeeks.com/?p=178136
• mlx-serve Release v26.10.3 (22.10.2026) – https://github.com/ddalcu/mlx-serve/releases/tag/v26.10.3
• mlx-serve PR #895: DeepSeek-V4.1 über ein Thunderbolt-Paar – https://github.com/ddalcu/mlx-serve/pull/895
• mlx-serve PR #911: DeepSeek-V4.1-Decode auf M5 Ultra – https://github.com/ddalcu/mlx-serve/pull/911
• mlx-serve PR #1002: Outside model plugins (28.10.2026) – https://github.com/ddalcu/mlx-serve/pull/1002
• CommunityServe/plugins (sushi_ds41) – https://github.com/CommunityServe/plugins
• CommunityServe/plugins PR #10 und #11: Prefill- und Decode-Messungen M5 Ultra 256 GB – https://github.com/CommunityServe/plugins/pull/10 und https://github.com/CommunityServe/plugins/pull/11
• Sushi v1.4.0 – https://newreleases.io/project/github/beamivalice/sushi/release/v1.4.0
• oMLX Issue #4720: Clustering DeepSeek V4.1-1017 auf 2× M5 Ultra 256 GB – https://github.com/jundot/omlx/issues/4720
• oMLX Releases (0.7.3rc1, Cluster-Messungen 2× M3 Ultra) – https://github.com/jundot/omlx/releases
• MLX Discussion #4491: DeepSeek V4.1 Flash auf drei M5-Max-Macs – https://github.com/ml-explore/mlx/discussions/4491
• BobClawblaw/deepseek-v41-flash-mlx-m5-ultra (TensorFold-Build für einen M5 Ultra) – https://github.com/BobClawblaw/deepseek-v41-flash-mlx-m5-ultra
• sudoingX/dgx-spark-deepseek-v41 Releases (EXL3-Qualität und DGX-Spark-Tempo) – https://github.com/sudoingX/dgx-spark-deepseek-v41/releases
• rapid-mlx/DeepSeek-V4.1-Flash-1017-MLX (Qualitätsmessung) – https://huggingface.co/rapid-mlx/DeepSeek-V4.1-Flash-1017-MLX
• patrickbdevaney/DeepSeek-V4.1-Flash-1017-REAP192-MXFP4 – https://huggingface.co/patrickbdevaney/DeepSeek-V4.1-Flash-1017-REAP192-MXFP4
• LibertAIDAI/DeepSeek-V4.1-Flash-NVFP4 (native FP4-Experten) – https://huggingface.co/LibertAIDAI/DeepSeek-V4.1-Flash-NVFP4
• aiweekly: DeepSeek posts V4.1-Flash: 552B MoE, 8B active, 1M context – https://aiweekly.co/alerts/deepseek-posts-v41-flash-552b-moe-8b-active-1m-context
• TensorFold – https://github.com/ashhart/TensorFold und Fork mit DGX-Spark-Branch https://github.com/Elevatormusic/TensorFold
• Macworld: The Mac Studio with 512GB of RAM is shipping – https://macworld.com/article/3271691/the-mac-studio-with-512gb-of-ram-is-shipping-and-it-costs-new-car-money.html
• Appleosophy: Lieferzeit 512-GB-Mac-Studio – https://appleosophy.com/2026/10/28/mac-studio-with-512gb-of-ram-now-available-starts-at-22299/
• Macwelt: Mac Studio M5 Max und M5 Ultra, Preise in Deutschland – https://www.macwelt.de/article/3220005/mac-studio-m5-max-m5-ultra.html
• iThinkDiff: 512GB Mac Studio und Muse Spark Open – https://www.ithinkdiff.com/512gb-mac-studio-m5-ultra-price-22299/
• mlx-serve-Entwickler: Benchmark-Screenshot DeepSeek-V4.1-Flash-1017-iQ-MLX-3.0bpw auf M5 Ultra 256 GB, veröffentlicht auf X (Oktober 2026)
• Vergleichsgrafik „Two 256GB M5 Ultras beat one 512GB“, auf X verbreitet (Oktober 2026, Urheber unbekannt)