Mac-Studio-KI-Cluster: 3x Tempo in 12 Schritten [2026]

Apple hat im August 2026 die neuen Mac-Studio-Modelle mit M5 Max und M5 Ultra vorgestellt, seit dem 22. September 2026 sind die Geräte in Österreich erhältlich. Neben mehr Kernen und bis zu 512 GB Arbeitsspeicher bringt die Reihe eine Funktion mit, die bisher vor allem Rechenzentren vorbehalten war: Mehrere Mac Studios lassen sich über Thunderbolt 5 zu einem Cluster verbinden und teilen sich dann die Arbeit bei der KI-Inferenz. Apple selbst spricht von bis zu dreifacher Geschwindigkeit gegenüber einem Einzelgerät, wie auch MacRumors nach der Ankündigung berichtete. Dieser Artikel zeigt in zwölf Schritten, wie man einen solchen Cluster tatsächlich aufbaut, welche Software dafür nötig ist und wo die Stolperfallen liegen.

Für Leserinnen und Leser in Österreich ist das kein reines Bastelprojekt. Wer Kundendaten, Verträge oder internen Programmcode durch ein Sprachmodell verarbeiten lassen will, muss abwägen, ob die Daten über eine amerikanische Cloud-API laufen oder auf einem Server im eigenen Büro bleiben. Ein Thunderbolt-5-Cluster aus mehreren Mac Studios ist eine der wenigen Möglichkeiten, große offene Modelle komplett lokal zu betreiben, ohne dafür ein Rack mit mehreren Grafikkarten und einer eigenen Stromversorgung einzurichten. Ein Mac Studio läuft im Alltag zudem deutlich leiser und braucht weniger Fläche als ein Server-Gehäuse mit mehreren Grafikkarten, was den Aufbau auch außerhalb eines klassischen Rechenzentrums praktikabel macht, etwa in einem kleinen Büro oder Homeoffice.

Im Zentrum steht MLX, Apples eigenes Machine-Learning-Framework für Apple Silicon, zusammen mit dem RDMA-Backend, das seit macOS 26.2 auch über Thunderbolt 5 läuft. Wer bereits einen einzelnen Mac Studio M5 Ultra für lokale KI eingerichtet hat, bekommt hier den nächsten Schritt: mehrere Geräte zu einem gemeinsamen Rechenknoten zu verschalten, um Modelle zu betreiben, die auf einer einzelnen Maschine gar nicht mehr in den Speicher passen.

Warum ein Mac-Studio-Cluster über Thunderbolt 5 überhaupt Sinn ergibt

Ein einzelner Mac Studio mit M5 Ultra bietet bis zu 512 GB einheitlichen Speicher. Das reicht für die meisten offenen Sprachmodelle locker aus, doch sobald man Modelle mit mehreren hundert Milliarden Parametern in hoher Präzision laden will, stößt selbst diese Ausstattung an Grenzen. Ein Cluster aus zwei oder vier Geräten addiert nicht nur den Speicher, sondern auch die Rechenleistung der GPU-Kerne. Apple beschreibt das in der offiziellen Produktankündigung so: “Thunderbolt 5 also enables multiple Mac Studio systems to be clustered, bringing up to 3x faster performance for distributed AI inference when compared to a single system.” Die Aussage stammt aus der offiziellen Apple-Newsroom-Meldung vom August 2026.

Der Faktor drei gilt allerdings nicht pauschal für jede Aufgabe. Er hängt von der Modellgröße, der gewählten Quantisierung und davon ab, ob die Software Pipeline- oder Tensor-Parallelität nutzt. Genau deshalb lohnt sich ein eigener Test mit dem tatsächlich benötigten Modell, bevor man Geld in zusätzliche Hardware steckt. Wer stattdessen bei Nvidia bleiben will, findet in unserem Vergleich zur Multi-GPU-Workstation für KI eine Alternative mit klassischen Grafikkarten, und wer nur ein einzelnes Notebook clustern will, kann auch mit dem MacBook Pro M5 und MLX einsteigen, bevor er auf mehrere Geräte skaliert.

Voraussetzungen: Hardware, macOS-Version und Software

Bevor es losgeht, braucht es eine klare Liste an Voraussetzungen. Fehlt auch nur eine davon, bricht die Cluster-Einrichtung später mit kryptischen Fehlermeldungen ab. Die gute Nachricht: Anders als bei einem klassischen Server-Rack mit Nvidia-Grafikkarten braucht ein Mac-Studio-Cluster keine zusätzliche Treiberinstallation und kein separates Betriebssystem. Die gesamte Grundausstattung ist bereits Teil von macOS, lediglich die Python-Umgebung und die beiden MLX-Pakete kommen von außen hinzu.

• Zwei bis vier Mac-Studio-Systeme mit M5 Max oder M5 Ultra (auch eine Mischung mit älteren M3-Ultra-Geräten ist möglich, sofern diese Thunderbolt 5 unterstützen)
• macOS 26.2 (Tahoe) oder neuer auf jedem Node, da RDMA über Thunderbolt 5 laut EXO Labs’ Dokumentation erst ab dieser Version aktiv ist
• Ein zertifiziertes Thunderbolt-5-Kabel pro Verbindung zwischen zwei Geräten
• Xcode Command Line Tools sowie Homebrew auf jedem Node
• Python 3.11 oder neuer in einer eigenen virtuellen Umgebung
• Die aktuellen Versionen von mlx und mlx-lm über pip
• Administratorrechte und aktivierte Fernanmeldung (SSH) auf allen Geräten
• Mindestens 200 GB freier SSD-Speicher pro Node für Modellgewichte, mehr bei größeren Modellen

Ein Hinweis zur Terminologie: MLX bezeichnet den Cluster-Modus intern als Jaccl-Backend. Es handelt sich um die Softwareschicht, die die Thunderbolt-Verbindungen erkennt, die Netzwerktopologie prüft und die eigentliche Kommunikation zwischen den Prozessen übernimmt. Die genaue technische Beschreibung findet sich in der offiziellen MLX-Dokumentation zu verteiltem Rechnen.

M5 Max vs. M5 Ultra: Die richtige Cluster-Basis wählen

Nicht jeder Node im Cluster muss das teuerste Modell sein. Für reine Kapazitätserweiterung reichen oft mehrere M5-Max-Geräte, während ein M5 Ultra als Master-Node mit mehr Speicher und Bandbreite sinnvoll ist. Die folgende Tabelle zeigt die aktuellen Einstiegspreise laut Apples österreichischem Online-Store, jeweils für die Basis- und die nächsthöhere Konfiguration ohne zusätzlichen Arbeitsspeicher oder Storage-Ausbau.

Konfiguration	CPU-Kerne	GPU-Kerne	Max. Unified Memory	Preis ab (AT)
M5 Max (Basis)	18	32	128 GB	2.999 €
M5 Max (erweitert)	18	40	128 GB	3.659 €
M5 Ultra (Basis)	30	64	512 GB	6.599 €
M5 Ultra (erweitert)	36	80	512 GB	8.029 €

Die Preise stammen direkt aus dem Apple-Konfigurator und steigen mit zusätzlichem Speicher und größerer SSD noch deutlich weiter. Der M5 Ultra basiert laut Apple auf einem Quad-Die-Design, bei dem zwei M5-Max-Chips über die UltraFusion-Technik verbunden werden. Das ergibt laut Herstellerangabe etwa 1,25-fache Singlethread- und 1,3-fache Multithread-Leistung gegenüber dem M3 Ultra, bei rund 1,2 TB/s Speicherbandbreite. Für den Cluster-Betrieb ist Letzteres wichtiger als die reine Rechenleistung, weil viele Sprachmodelle beim Generieren von Text speicherbandbreitenlimitiert und nicht rechenlimitiert sind.

Wer mit einem kleineren Budget startet, kann auch zwei gebrauchte M3-Ultra-Systeme kombinieren, da RDMA über Thunderbolt 5 laut EXO-Dokumentation auch auf M4 Pro Mac mini, M4 Max Mac Studio, M4 Max MacBook Pro und M3 Ultra Mac Studio läuft. Ein gemischter Cluster aus alten und neuen Geräten funktioniert technisch, bremst aber auf die Geschwindigkeit des langsamsten Nodes.

Für die Praxis hat sich eine einfache Faustregel bewährt: Wer hauptsächlich Kapazität für sehr große Modelle braucht, kombiniert mehrere M5-Max-Geräte, weil sich deren Speicher im Cluster addiert, ohne dass man gleich den deutlich höheren Einstiegspreis eines M5 Ultra zahlen muss. Wer dagegen auf niedrige Latenz bei kleineren, aber rechenintensiven Modellen Wert legt, etwa für Code-Vervollständigung in Echtzeit, profitiert stärker von der höheren Speicherbandbreite eines einzelnen M5 Ultra als von zusätzlichen M5-Max-Nodes. Die Entscheidung lässt sich nicht pauschal treffen, sie hängt vom tatsächlichen Modell und Einsatzzweck ab und sollte, wo möglich, vor dem Kauf mit einer Leihstellung oder einem kleinen Testaufbau überprüft werden.

Schritt 1: Cluster-Topologie und Node-Anzahl planen

Vor dem ersten Kabel steht eine Entscheidung: Wie viele Nodes, und in welcher Anordnung? Bei zwei Geräten reicht eine direkte Punkt-zu-Punkt-Verbindung über ein einziges Thunderbolt-5-Kabel. Ab drei Geräten braucht es entweder einen Thunderbolt-5-Hub oder eine Ringtopologie, bei der jeder Node mit seinen zwei Nachbarn verbunden ist. MLX bevorzugt eine vollständig vermaschte Topologie, bei der jeder Node direkt mit jedem anderen spricht, weil das bei Tensor-Parallelität die Latenz senkt. Bei vier Nodes bedeutet das sechs Kabelverbindungen statt nur drei bei einer einfachen Kette. Wer nur zwei Thunderbolt-Anschlüsse pro Gerät für den Cluster reservieren will, bleibt bei einer Ringtopologie und nimmt dafür bei größeren Modellen eine etwas höhere Kommunikationslatenz in Kauf.

Die Wahl der Topologie hängt auch davon ab, welche Art von Parallelität später zum Einsatz kommt. Pipeline-Parallelität, bei der jeder Node einen Abschnitt der Modellschichten übernimmt, kommt mit einer einfachen Kette meist gut zurecht, weil die Daten ohnehin nur in eine Richtung wandern. Tensor-Parallelität, bei der jede Schicht auf mehrere Nodes gleichzeitig aufgeteilt wird, verlangt dagegen nach häufigem Datenaustausch in alle Richtungen und profitiert deshalb deutlich stärker von einer vollständig vermaschten Verkabelung.

Für den Einstieg empfiehlt sich ein Zwei-Node-Cluster. Er lässt sich in unter einer Stunde aufbauen, deckt bereits die komplette Softwarekette ab und zeigt, ob sich die Investition überhaupt lohnt, bevor man in weitere Geräte investiert.

Schritt 2: Thunderbolt-5-Kabel korrekt verbinden

Jeder Mac Studio bringt mehrere Thunderbolt-5-Anschlüsse mit, die laut Apple bis zu 120 Gbit/s Bandbreite pro Verbindung liefern. Auf der Apple-Produktseite heißt es dazu: “At up to 120Gb/s, Thunderbolt 5 handles everything from high-bandwidth external storage and video synchronization with genlock to low-latency clustered compute and daisy-chaining multiple displays.” Die Formulierung stammt von der offiziellen Mac-Studio-Produktseite und zeigt, dass Clustering für Apple kein Nebeneffekt, sondern ein geplanter Anwendungsfall des Anschlusses ist. Für den Cluster wird ein Port pro Verbindung reserviert und nicht gleichzeitig für ein Display oder externen Speicher genutzt, da sich die Bandbreite sonst aufteilt. Nach dem Verbinden zeigt das Menü unter Systemeinstellungen → Netzwerk automatisch einen neuen Dienst mit der Bezeichnung Thunderbolt Bridge an. Bei mehr als zwei Geräten in Ringtopologie taucht dieser Dienst auf jedem Node zweimal auf, einmal pro Nachbarverbindung. Wichtig ist außerdem die Kabellänge: Je länger das Kabel, desto eher braucht es eine aktive statt einer passiven Verkabelung, damit die volle Bandbreite über die gesamte Strecke erhalten bleibt.

Schritt 3: Thunderbolt Bridge und statische IP-Adressen einrichten

Damit sich die Nodes zuverlässig finden, bekommt jeder eine feste IP-Adresse im selben privaten Subnetz. Router- und DNS-Felder bleiben leer, weil der Cluster isoliert läuft und kein Internet über diese Schnittstelle braucht. Ein bewährtes Schema:

• Node 1 (Master): 192.168.50.1/24
• Node 2: 192.168.50.2/24
• Node 3: 192.168.50.3/24
• Node 4: 192.168.50.4/24

Nach der Vergabe prüft ein einfacher Ping von jedem Node zu jedem anderen, ob die Verbindung tatsächlich steht. Schlägt der Ping fehl, liegt es fast immer an einem nicht aktivierten Netzwerkdienst oder an einem Kabel, das nicht den Thunderbolt-5-Standard erfüllt, sondern nur USB-C-Ladefunktion bietet. Eine feste statt einer per DHCP zugewiesenen Adresse ist hier kein Detail, sondern notwendig: Würde sich die Adresse eines Nodes nach einem Neustart ändern, müsste die gesamte Cluster-Konfiguration im späteren Schritt mit mlx.distributed_config neu erzeugt werden, weil die Hostdatei sonst auf eine nicht mehr existierende Adresse verweist.

Schritt 4: Passwortloses SSH zwischen allen Nodes einrichten

MLX startet die Prozesse auf den anderen Nodes über SSH, deshalb muss sich der Master-Node ohne Passwortabfrage bei allen anderen anmelden können. Zuerst wird auf dem Master ein Schlüsselpaar erzeugt und anschließend auf jeden weiteren Node kopiert.

ssh-keygen -t ed25519 -C "cluster-master"
ssh-copy-id [email protected]
ssh-copy-id [email protected]
ssh-copy-id [email protected]

Zusätzlich muss unter Systemeinstellungen → Allgemein → Freigabe die Fernanmeldung auf jedem Node aktiv sein, und die Firewall darf eingehende SSH-Verbindungen sowie den von MLX genutzten Port nicht blockieren. Ein Test mit ssh [email protected] hostname sollte ohne Passwortabfrage sofort den Hostnamen des Zielgeräts zurückgeben. Fragt SSH trotzdem nach einem Passwort, liegt es in den meisten Fällen an falschen Zugriffsrechten auf den Ordner .ssh im Benutzerverzeichnis. macOS verweigert die Anmeldung über einen Schlüssel, wenn dieser Ordner für andere Benutzer schreibbar ist, weshalb sich die Rechte mit chmod 700 ~/.ssh und chmod 600 ~/.ssh/authorized_keys auf jedem Node einmal kontrollieren lassen.

Schritt 5: Python, Homebrew und Xcode-Tools vorbereiten

Auf jedem einzelnen Node wird dieselbe Softwareumgebung installiert, damit die Prozesse später identische Bibliotheksversionen verwenden. Wer bereits Ollama auf Apple Silicon im Einsatz hat, kennt die grundlegenden Schritte, MLX ersetzt hier aber das Backend für verteiltes Rechnen.

xcode-select --install
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install [email protected]
python3.12 -m venv ~/mlx-cluster
source ~/mlx-cluster/bin/activate

Dieser Block läuft identisch auf jedem Node. Am schnellsten geht es, wenn man die Befehle einmal in ein kleines Shell-Skript packt und es per SSH auf allen Geräten ausführt, statt es viermal von Hand einzutippen.

Schritt 6: MLX und mlx-lm auf jedem Node installieren

Mit aktivierter virtueller Umgebung folgt die Installation der beiden zentralen Pakete. mlx stellt die Rechenkerne bereit, mlx-lm die fertigen Werkzeuge zum Laden und Ausführen von Sprachmodellen.

pip install --upgrade pip
pip install mlx mlx-lm

Ein kurzer Funktionstest mit python -c "import mlx.core as mx; print(mx.default_device())" sollte die GPU des jeweiligen Nodes als aktives Gerät ausgeben. Kommt stattdessen eine Fehlermeldung, fehlt meist die Command-Line-Tools-Installation aus Schritt 5 oder die Python-Version ist älter als 3.11.

Schritt 7: RDMA über Thunderbolt 5 aktivieren

RDMA, also der direkte Speicherzugriff zwischen den Nodes ohne Umweg über den klassischen Netzwerkstapel, ist der eigentliche Grund für den Geschwindigkeitsgewinn im Cluster. Normalerweise muss jedes Datenpaket, das ein Mac verlässt, durch mehrere Softwareschichten des Betriebssystems wandern, kopiert und neu verpackt werden, bevor es beim Zielgerät ankommt. RDMA überspringt diesen Umweg und schreibt Daten direkt in den Speicherbereich des anderen Nodes. Bei einem Sprachmodell, das bei jedem einzelnen Token Zwischenergebnisse zwischen den Nodes austauschen muss, macht dieser Unterschied den entscheidenden Ausschlag zwischen einem Cluster, der schneller wird, und einem, der durch die zusätzliche Kommunikation sogar langsamer wird als ein Einzelgerät.

Laut EXO Labs wurde die Unterstützung dafür über Thunderbolt 5 mit macOS 26.2 eingeführt. Ist diese Version auf allen Nodes installiert, aktiviert MLX das RDMA-Backend automatisch, sobald die Cluster-Konfiguration im nächsten Schritt erstellt wird. Eine manuelle Aktivierung ist nicht nötig, eine falsche oder ältere macOS-Version auf nur einem Node reicht aber aus, damit der gesamte Cluster stattdessen auf den langsameren Standardpfad zurückfällt.

Schritt 8: Cluster-Topologie mit mlx.distributed_config erkennen

Statt die Netzwerkkonfiguration von Hand zu schreiben, übernimmt das Werkzeug mlx.distributed_config die automatische Erkennung. Es prüft, ob alle Nodes vollständig vermascht sind, ob RDMA verfügbar ist, und erzeugt daraus eine fertige Hostdatei.

mlx.distributed_config --verbose \
  --backend jaccl \
  --hosts 192.168.50.1,192.168.50.2,192.168.50.3,192.168.50.4 \
  --over thunderbolt \
  --auto-setup \
  --output cluster-jaccl.json

Läuft alles wie erwartet, meldet das Tool für jeden Node den erkannten Verbindungsstatus und bestätigt, ob RDMA aktiv ist:

[1/4] 192.168.50.1: reachable, RDMA: enabled
[2/4] 192.168.50.2: reachable, RDMA: enabled
[3/4] 192.168.50.3: reachable, RDMA: enabled
[4/4] 192.168.50.4: reachable, RDMA: enabled
Topology: fully connected mesh (6 links)
Config written to cluster-jaccl.json

Taucht bei einem Node stattdessen RDMA: disabled auf, lohnt sich zuerst ein Blick auf die macOS-Version dieses Geräts, bevor man die Kabel oder das Netzwerk verdächtigt.

Schritt 9: Erstes verteiltes Modell mit Pipeline-Parallelität starten

Mit der fertigen Konfigurationsdatei lässt sich ein erstes Modell über alle Nodes verteilen. Bei Pipeline-Parallelität übernimmt jeder Node einen zusammenhängenden Block der Modellschichten, was weniger Kommunikation zwischen den Geräten braucht als Tensor-Parallelität und sich deshalb gut als Einstieg eignet.

mlx.launch --hostfile cluster-jaccl.json -- \
  mlx_lm.chat \
  --model "moonshotai/Kimi-K2.6" \
  --max-tokens 2048 \
  --pipeline

Das Flag --pipeline weist MLX an, das Modell schichtweise über die Nodes zu verteilen. Fehlt es, versucht MLX, das gesamte Modell auf dem Master-Node allein zu laden, was bei großen Modellen zu einem Speicherfehler führt, obwohl der Cluster rechnerisch genug Kapazität hätte.

Schritt 10: Inferenz-Server mit mlx_lm.server betreiben

Für den produktiven Einsatz läuft der Cluster besser als dauerhafter Server mit einer OpenAI-kompatiblen Programmierschnittstelle, statt für jede Anfrage ein neues Chat-Skript zu starten.

mlx.launch --hostfile cluster-jaccl.json \
  --backend jaccl \
  -- mlx_lm.server \
  --model mlx-community/Qwen-3.5-122B-A3B-8bit \
  --port 8080

Das Modell wird dabei automatisch über die verfügbaren Nodes geshardet. Ein einfacher Testaufruf von einem beliebigen Rechner im selben Netzwerk bestätigt, dass der Server antwortet:

curl http://192.168.50.1:8080/v1/completions \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Erkläre RDMA in einem Satz.", "max_tokens": 60}'

{"id":"cmpl-01","choices":[{"text":" RDMA erlaubt direkten Speicherzugriff zwischen Rechnern ohne Umweg über das Betriebssystem des Zielsystems."}],"usage":{"prompt_tokens":9,"completion_tokens":21}}

Schritt 11: Performance messen und Tokens pro Sekunde auswerten

Ob sich der Aufwand gelohnt hat, zeigt erst ein Vergleich der Tokens pro Sekunde zwischen einem einzelnen Node und dem vollen Cluster. EXO Labs, ein auf verteilte Apple-Silicon-Inferenz spezialisiertes Projekt, hat dazu eigene Benchmarks veröffentlicht. Die folgenden Zahlen stammen aus EXO Labs’ eigenen Tests und sind als deren Herstellerangaben zu verstehen, nicht als unabhängig reproduzierte Messung durch diese Redaktion.

Nodes	Llama (Standard-Backend)	EXO mit RDMA
1 Node	20,4 Tokens/Sek	19,5 Tokens/Sek
2 Nodes	17,2 Tokens/Sek	26,2 Tokens/Sek
4 Nodes	15,2 Tokens/Sek	31,9 Tokens/Sek

Auffällig ist, dass das Standard-Backend mit steigender Node-Zahl sogar langsamer wird, weil die Kommunikation ohne RDMA zum Flaschenhals wird. Erst das RDMA-Backend zeigt den erwarteten Skalierungseffekt. Bei einem größeren Modell wie DeepSeek V3.1 mit 671 Milliarden Parametern meldet EXO Labs für den RDMA-Pfad 21,1 Tokens/Sek bei einem Node, 27,8 bei zwei Nodes und 32,5 bei vier Nodes. Für GLM-4.7 in 8-Bit-Quantisierung auf zwei M3-Ultra-Systemen mit je 512 GB Speicher und Tensor-Parallelität nennt EXO Labs 19,8 Tokens/Sek. Die eigene Messung mit dem tatsächlich genutzten Modell bleibt trotzdem unverzichtbar, da Prompt-Länge, Kontext und Quantisierung die Werte stark verschieben.

Wichtig für die Einordnung dieser Zahlen: Es handelt sich um Herstellerangaben von EXO Labs selbst, ohne dass die verwendete Prompt-Länge, die Generierungslänge oder die genaue Testmethodik im Detail offengelegt wurden. Wer eigene Zahlen erheben will, misst am besten getrennt nach Zeit bis zum ersten Token (Latenz) und Tokens pro Sekunde während der laufenden Generierung (Durchsatz), weil beide Werte je nach Node-Zahl und Topologie unterschiedlich stark schwanken können. Ein Cluster mit vier Nodes bringt außerdem nicht zwangsläufig die doppelte Geschwindigkeit gegenüber zwei Nodes, da mit jedem zusätzlichen Node auch der Koordinationsaufwand steigt. Diese abnehmenden Grenzerträge sind normal und kein Zeichen für einen Konfigurationsfehler.

Schritt 12: Cluster automatisieren, überwachen und absichern

Ein Cluster, der nach jedem Neustart manuell wieder hochgefahren werden muss, wird in der Praxis schnell ignoriert. Ein einfacher launchd-Dienst auf dem Master-Node startet den Server automatisch beim Systemstart.

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>io.cluster.mlxserver</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/mlx.launch</string>
    <string>--hostfile</string>
    <string>/etc/cluster-jaccl.json</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
</dict>
</plist>

Für die Absicherung reicht es nicht, den Cluster nur im eigenen Heimnetz laufen zu lassen. Der SSH-Zugang sollte ausschließlich über Schlüssel funktionieren, Passwort-Login gehört deaktiviert, und der Server-Port 8080 sollte nicht direkt aus dem Internet erreichbar sein. Wer den Zugriff von außen braucht, legt dafür besser ein separates VPN an, statt den Port in der Firewall freizugeben.

Welche Modelle sich für einen Mac-Studio-Cluster eignen

Nicht jedes Sprachmodell profitiert gleich stark von einem Cluster. Kleine Modelle mit wenigen Milliarden Parametern laufen oft schon auf einem einzelnen M5 Max flüssig und gewinnen durch mehrere Nodes vor allem an Kontextlänge, nicht an Geschwindigkeit. Der eigentliche Mehrwert eines Clusters zeigt sich erst bei sehr großen offenen Modellen, die einzeln gar nicht mehr in den Speicher eines Geräts passen. Dazu zählen aktuell etwa Kimi K2.6 von Moonshot AI, DeepSeek V3.1 mit 671 Milliarden Parametern, Qwen 3.5 in der 122B-Variante sowie GLM-4.7, die alle in vorquantisierten Fassungen über die Community-Sammlung mlx-community verfügbar sind.

Modell	Größenordnung	Typische Quantisierung	Empfohlene Cluster-Größe
Qwen 3.5 122B-A3B	122 Mrd. Parameter	8-Bit	1 bis 2 Nodes
Kimi K2.6	über 200 Mrd. Parameter	4-Bit oder 8-Bit	2 Nodes
GLM-4.7	im dreistelligen Milliardenbereich	8-Bit	2 Nodes
DeepSeek V3.1	671 Mrd. Parameter	4-Bit	4 Nodes

Die Quantisierung entscheidet dabei oft mehr über den Speicherbedarf als die Node-Zahl. Ein Modell in 4-Bit-Präzision braucht nur rund ein Viertel des Speichers derselben Gewichte in 16-Bit, bei einem für die meisten Alltagsaufgaben kaum spürbaren Qualitätsverlust. Wer unsicher ist, wie viele Nodes ein bestimmtes Modell braucht, rechnet grob mit zwei Bytes pro Parameter bei 16-Bit, einem Byte bei 8-Bit und einem halben Byte bei 4-Bit, und vergleicht das Ergebnis mit dem verfügbaren Gesamtspeicher aller Nodes zusammen. Die konkreten Befehle zum Laden dieser Modelle über mlx_lm.server oder mlx_lm.chat entsprechen genau den in Schritt 9 und Schritt 10 gezeigten Beispielen, nur mit dem jeweils anderen Modellnamen.

Ein letzter Punkt zur Modellwahl: Die Community-Sammlung mlx-community aktualisiert ihre vorquantisierten Modelle laufend, oft schon wenige Tage nach dem Erscheinen eines neuen offenen Modells. Vor jedem größeren Cluster-Kauf lohnt sich deshalb ein kurzer Blick in diese Sammlung, um zu prüfen, ob das gewünschte Modell bereits in einer für MLX optimierten Fassung vorliegt, statt sich auf die theoretische Parameterzahl allein zu verlassen.

Die fünf häufigsten Fehler beim Cluster-Aufbau

Die meisten Probleme entstehen nicht bei MLX selbst, sondern in den Schritten davor. Diese fünf Fehler tauchen in der Praxis am häufigsten auf.

• Gemischte Kabeltypen: Ein USB-C-Ladekabel ohne Thunderbolt-5-Zertifizierung verbindet die Geräte zwar optisch, liefert aber nicht die nötige Bandbreite und wird von MLX oft gar nicht als Thunderbolt-Link erkannt.
• Unterschiedliche macOS-Versionen: Ein Node mit älterem macOS deaktiviert stillschweigend RDMA für den gesamten Cluster, ohne dass eine Fehlermeldung erscheint.
• Kettentopologie statt Vollvermaschung: Bei mehr als zwei Nodes in einer einfachen Kette ohne direkte Verbindung zwischen den äußeren Geräten sinkt die Leistung bei Tensor-Parallelität deutlich.
• Abweichende Paketversionen: Werden mlx oder mlx-lm nicht auf allen Nodes gleichzeitig aktualisiert, kann die Kommunikation zwischen den Prozessen fehlschlagen.
• Fehlender Speicherplatz: Große Modelle wie DeepSeek V3.1 belegen deutlich über 100 GB auf der SSD, und wenn nur ein Node zu wenig freien Platz hat, bricht das Laden auf allen Geräten ab.

Troubleshooting: Acht Probleme und ihre Lösungen

Auch nach einer sauberen Einrichtung tauchen im Alltag immer wieder dieselben Fehlermeldungen auf. Die folgende Tabelle fasst die häufigsten Fälle zusammen.

Problem	Wahrscheinliche Ursache	Lösung
“Connection refused” beim Start von mlx.launch	SSH bzw. Fernanmeldung auf dem Ziel-Node deaktiviert	Fernanmeldung in den Systemeinstellungen aktivieren, SSH-Verbindung manuell testen
RDMA wird als “disabled” gemeldet	macOS-Version unter 26.2 auf mindestens einem Node	macOS auf allen Nodes aktualisieren und Konfiguration neu erzeugen
Cluster hängt beim Start fest	IP-Adresse in der Hostdatei stimmt nicht mit der tatsächlichen Thunderbolt-Bridge-Adresse überein	IP-Konfiguration in den Netzwerkeinstellungen prüfen und Hostdatei neu generieren
Nur ein Node zeigt GPU-Auslastung	Flag –pipeline oder –backend jaccl fehlt im Startbefehl	Startbefehl aus Schritt 9 bzw. 10 exakt übernehmen
Tokens/Sek sinkt trotz mehr Nodes	Kettentopologie statt Vollvermaschung, siehe häufige Fehler oben	Zusätzliche Kabel für eine vollständig vermaschte Topologie verlegen
Modell lässt sich nicht laden, “out of memory”	Modellgröße übersteigt den Gesamtspeicher aller Nodes zusammen	Kleineres Modell oder stärker quantisierte Version wählen, etwa 4-Bit statt 8-Bit
SSH fragt trotz Schlüssel immer wieder nach dem Passwort	Öffentlicher Schlüssel wurde nicht korrekt auf den Ziel-Node kopiert	ssh-copy-id erneut ausführen und Berechtigungen des .ssh-Ordners prüfen (700)
Thunderbolt-Verbindung bricht unter Last ab	Nicht aktiv gekühltes oder zu langes Kabel, thermische Drosselung	Kürzeres, aktives Thunderbolt-5-Kabel verwenden und Gehäusebelüftung prüfen

Führt keiner dieser Schritte zum Ziel, lohnt sich ein Blick in die ausführlichen Protokolle. Sowohl mlx.distributed_config als auch mlx.launch akzeptieren das Flag --verbose, das jeden einzelnen Verbindungsversuch und jede Fehlermeldung des jeweiligen Nodes einzeln ausgibt, statt nur eine zusammenfassende Fehlermeldung zu zeigen. In den meisten Fällen steckt der eigentliche Fehler nicht in MLX selbst, sondern in einer der Grundvoraussetzungen aus Schritt 1 bis Schritt 7, etwa einer falschen IP-Adresse oder einem SSH-Schlüssel, der nur auf einem Teil der Nodes hinterlegt wurde.

Erweiterte Tipps: Skalierung auf mehr Nodes und Alternativen zu MLX

Wer über vier Nodes hinausgeht, sollte statt der manuellen mlx.launch-Befehle das Open-Source-Projekt EXO in Betracht ziehen. Es baut auf MLX auf, übernimmt aber automatisch die Lastverteilung zwischen heterogenen Geräten und eignet sich besonders, wenn ältere und neuere Mac-Modelle gemeinsam im selben Cluster laufen. Details zum Projekt gibt es auf der Projektseite von EXO Labs.

Steht kein freier Thunderbolt-Port mehr zur Verfügung, weil bereits ein Display oder externer Speicher angeschlossen ist, funktioniert MLX grundsätzlich auch über ein gewöhnliches Ethernet-Netzwerk. Die Geschwindigkeit fällt dabei allerdings deutlich niedriger aus als über Thunderbolt 5, da selbst ein 10-Gigabit-Ethernet-Anschluss nur einen Bruchteil der 120 Gbit/s erreicht, die Thunderbolt 5 pro Verbindung liefert. Ethernet eignet sich deshalb eher als Notlösung oder für sehr kleine Modelle, bei denen die Kommunikationslast zwischen den Nodes ohnehin gering bleibt.

Ein weiterer Tipp betrifft die Rollenverteilung: Der Master-Node sollte immer das Gerät mit dem meisten Speicher sein, weil er zusätzlich zur eigentlichen Berechnung auch die Koordination übernimmt. Bei einem gemischten Cluster aus M5 Ultra und M5 Max lohnt es sich außerdem, das Modell manuell so aufzuteilen, dass der M5 Ultra die größeren Schichtblöcke übernimmt. Wer eher mit klassischen Grafikkarten arbeitet, findet in unserem Artikel zum NVIDIA DGX Spark eine vergleichbare Einstiegslösung außerhalb des Apple-Ökosystems. Und wer nicht sicher ist, ob sich ein eigener Cluster überhaupt lohnt, sollte zuerst mit Quantisierung experimentieren: Ein 4-Bit-Modell braucht oft nur ein Viertel des Speichers eines 16-Bit-Modells bei überschaubarem Qualitätsverlust, was den Umstieg auf mehrere Nodes in vielen Fällen sogar unnötig macht.

Auch die Aufstellung im Büro oder Serverraum verdient Aufmerksamkeit. Mehrere Mac Studios, die über Stunden hinweg unter Volllast laufen, erzeugen spürbare Abwärme und Lüftergeräusche, auch wenn Apple bei diesen Geräten traditionell auf ein vergleichsweise leises Kühlkonzept setzt. Ein separater Raum oder zumindest ein gut belüfteter Schrank verhindert, dass der Cluster im offenen Büro zur Dauerbelastung für die Kolleginnen und Kollegen wird. Genaue Angaben zur Leistungsaufnahme eines M5-Ultra-Clusters unter Volllast hat Apple bislang nicht veröffentlicht, weshalb sich eine eigene Messung mit einer haushaltsüblichen Strommessdose empfiehlt, bevor größere Cluster mit vier oder mehr Geräten geplant werden.

Weitere Hintergründe zur allgemeinen Hardware-Entwicklung rund um KI-Workstations gibt es in der Hardware-Rubrik von shattered.io.

Wirtschaftlichkeit und Datenschutz: Zwei gute Gründe für den eigenen Cluster

Kostenvergleich mit Cloud-APIs

Ein Zwei-Node-Cluster mit M5 Max kostet ab rund 6.000 € in der Anschaffung, dazu kommen Kabel und Strom. Das wirkt zunächst nach viel Geld für ein Hobbyprojekt. Der Vergleich verschiebt sich aber, sobald ein Team täglich über mehrere Stunden hinweg ein großes Modell für Programmieraufgaben, interne Dokumentensuche oder Support-Automatisierung nutzt. Bei einer Cloud-API fallen die Kosten pro verarbeitetem Token laufend an und wachsen mit jedem zusätzlichen Nutzer und jeder zusätzlichen Anfrage. Ein eigener Cluster ist dagegen eine einmalige Investition, die anschließend nur noch Stromkosten verursacht, unabhängig davon, wie stark er ausgelastet wird. Wo genau der Break-even liegt, hängt stark vom gewählten Modell und Anbieter ab und sollte im Einzelfall mit den eigenen Nutzungszahlen durchgerechnet werden, statt sich auf eine pauschale Zahl zu verlassen.

Ein weiterer, oft übersehener Vorteil: Ein einmal eingerichteter Cluster lässt sich nicht nur für den ursprünglich geplanten Zweck nutzen. Dieselbe Infrastruktur kann tagsüber Programmieranfragen eines Entwicklerteams beantworten und nachts für Batch-Aufgaben wie das Zusammenfassen großer Dokumentenmengen oder das Testen neuer Prompt-Strategien genutzt werden, ohne dass dafür zusätzliche Kosten anfallen. Bei einer nutzungsbasierten Cloud-API wächst die Rechnung dagegen mit jeder zusätzlichen Anwendung mit.

DSGVO und Datenhoheit in Österreich

Der zweite Grund wiegt für viele österreichische Unternehmen schwerer als der reine Preis. Läuft ein Sprachmodell auf einem Server im eigenen Büro, verlassen Kundendaten, Verträge oder Quellcode das Firmengelände nicht. Das vereinfacht die Argumentation gegenüber der Datenschutzbehörde erheblich, weil sich die Frage nach einer Datenübermittlung in ein Drittland gar nicht erst stellt. Bei einer Cloud-API aus den USA braucht es dagegen in der Regel Standardvertragsklauseln und eine saubere Risikobewertung, bevor personenbezogene Daten überhaupt verarbeitet werden dürfen. Ein lokaler Mac-Studio-Cluster verschiebt diese Diskussion komplett: Die Daten bleiben im eigenen Netzwerk, und die einzige Verbindung nach außen ist der einmalige Download der Modellgewichte zu Beginn.

Für Kanzleien, Arztpraxen, Behörden und andere Stellen, die mit besonders sensiblen Daten arbeiten, kommt noch ein praktischer Aspekt hinzu: Der Cluster lässt sich vollständig vom Internet trennen, sobald die Modellgewichte einmal heruntergeladen sind. Ein air-gapped betriebener Mac-Studio-Cluster kann dann Anfragen verarbeiten, ohne dass überhaupt eine technische Möglichkeit zur Datenübertragung nach außen besteht, ein Sicherheitsniveau, das sich mit einer Cloud-API grundsätzlich nicht erreichen lässt.

Komplettes Projekt: Der Zwei-Node-Cluster von Anfang bis Ende

Zum Abschluss noch einmal der gesamte Ablauf im Überblick, als fertiges Projekt zum Nachbauen. Ausgangspunkt sind zwei Mac Studios mit M5 Max, jeweils mit macOS 26.2, die nebeneinander auf einem Schreibtisch stehen und über ein einziges Thunderbolt-5-Kabel verbunden sind.

• Beide Geräte erhalten unter Systemeinstellungen → Netzwerk die statischen Adressen 192.168.50.1 und 192.168.50.2 auf der neu erschienenen Thunderbolt-Bridge-Schnittstelle.
• Auf dem ersten Gerät (Master) wird ein SSH-Schlüssel erzeugt und per ssh-copy-id auf das zweite Gerät übertragen.
• Auf beiden Geräten laufen Xcode Command Line Tools, Homebrew, eine eigene virtuelle Python-3.12-Umgebung sowie die Pakete mlx und mlx-lm.
• Der Master-Node führt mlx.distributed_config mit beiden IP-Adressen aus und erhält eine cluster-jaccl.json, die RDMA als aktiv bestätigt.
• Mit mlx.launch und dem Flag –pipeline startet ein erster Testlauf mit mlx_lm.chat, um die grundsätzliche Funktion zu prüfen.
• Anschließend übernimmt mlx_lm.server den dauerhaften Betrieb auf Port 8080, abgesichert durch eine launchd-Konfiguration für den automatischen Start.
• Ein Benchmark mit dem tatsächlich genutzten Modell und realistischen Prompts liefert die eigene Tokens-pro-Sekunde-Zahl, mit der sich die Investition rechtfertigen oder verwerfen lässt.

Dieses Grundgerüst aus zwei Nodes lässt sich jederzeit um weitere Mac Studios erweitern, ohne dass die bisherige Konfiguration verworfen werden muss. Es reicht, die neuen Geräte per Thunderbolt-5-Kabel in eine vollständig vermaschte Topologie einzubinden, die IP-Adressen im selben Subnetz zu vergeben und die Hostdatei mit mlx.distributed_config neu zu erzeugen. Der Rest der Konfiguration, von den SSH-Schlüsseln bis zur Server-Definition, bleibt unverändert bestehen.

Am Ende dieses Projekts steht kein Prototyp, sondern ein produktiv nutzbarer Dienst: eine lokale, über die Netzwerkschnittstelle 192.168.50.1:8080 erreichbare Inferenz-API, die sich in eigene Anwendungen, interne Chatbots oder Entwicklungswerkzeuge einbinden lässt, ohne dass dafür ein einziges Datenpaket das eigene Netzwerk verlässt. Genau dieser Zustand, ein voll funktionsfähiger, selbst kontrollierter KI-Dienst auf eigener Hardware, ist der eigentliche Grund, warum sich der Aufwand für viele Teams in Österreich trotz der hohen Anfangsinvestition lohnt.

Häufig gestellte Fragen (FAQ)

Braucht jeder Node im Cluster dieselbe Mac-Studio-Variante?

Nein. Ein Cluster kann M5 Max, M5 Ultra und ältere M3-Ultra-Systeme mischen, solange alle Thunderbolt 5 unterstützen und dieselbe macOS-Version laufen lassen. Die Gesamtleistung richtet sich aber nach dem langsamsten Node.

Wie viele Mac Studios sind für einen sinnvollen Cluster nötig?

Schon zwei Geräte reichen für einen ersten funktionsfähigen Cluster und zeigen laut EXO Labs’ Benchmarks bereits einen spürbaren Geschwindigkeitsgewinn gegenüber einem Einzelgerät bei großen Modellen. Vier Nodes sind sinnvoll für Modelle jenseits von 500 Milliarden Parametern.

Funktioniert der Cluster auch ohne RDMA?

Technisch ja, MLX fällt dann auf einen langsameren Kommunikationspfad zurück. Laut EXO Labs’ eigenen Tests sinkt die Tokens-pro-Sekunde-Rate in diesem Fall mit steigender Node-Zahl sogar, statt zu steigen, weshalb RDMA für den praktischen Betrieb Voraussetzung ist.

Welche macOS-Version ist mindestens nötig?

macOS 26.2 (Tahoe) oder neuer auf jedem einzelnen Node, da RDMA über Thunderbolt 5 laut EXO Labs’ Dokumentation erst ab dieser Version unterstützt wird.

Kann man den Cluster auch für Gaming oder Videoschnitt statt für KI nutzen?

Die in diesem Artikel beschriebene Thunderbolt-5-Kopplung ist speziell für verteilte KI-Inferenz über MLX gedacht. Für Videoschnitt oder Speicherfreigabe lässt sich dieselbe Thunderbolt-Bridge-Verbindung nutzen, allerdings ohne die RDMA-Beschleunigung von MLX.

Was kostet ein Einstiegs-Cluster mit zwei Geräten?

Zwei Mac Studios mit M5 Max in der Basiskonfiguration kosten laut Apples österreichischem Store aktuell ab 2.999 € pro Gerät, also ab rund 6.000 € für zwei Nodes, zuzüglich Thunderbolt-5-Kabel. Für größere Modelle mit mehr Speicher steigt der Preis pro Gerät schnell in Richtung des M5-Ultra-Einstiegspreises von 6.599 €.

Lässt sich ein bestehender Einzel-Mac-Studio nachträglich in einen Cluster integrieren?

Ja, solange das Gerät Thunderbolt 5 besitzt und auf macOS 26.2 oder neuer aktualisiert ist. Wer bereits einen einzelnen Mac Studio für lokale KI eingerichtet hat, muss nur die in diesem Artikel beschriebenen Netzwerk- und Softwareschritte nachholen.

Ist EXO eine bessere Alternative zu den manuellen mlx.launch-Befehlen?

Für Cluster mit mehr als vier Nodes oder mit stark unterschiedlicher Hardware automatisiert EXO die Lastverteilung und nimmt einen Teil der manuellen Konfigurationsarbeit ab. Für einen einfachen Zwei- oder Vier-Node-Cluster reichen die in diesem Artikel gezeigten MLX-Befehle völlig aus.