Vier Macs als Cluster: verteilte Inferenz und Training mit MLX

Lokale Sprachmodelle werden größer, und irgendwann reicht der Speicher einer einzelnen Maschine nicht mehr. Auf der WWDC26 hat das MLX-Team von Apple gezeigt, wie sich diese Grenze verschieben lässt: indem man mehrere Macs zu einem Cluster verbindet und ein Modell über sie verteilt. Die Demo läuft mit vier M3 Ultra, führt ein Modell mit einer Billion Parametern lokal aus und beschleunigt die Inferenz auf nahezu das Dreifache eines einzelnen Geräts. Das Bemerkenswerte daran ist nicht die rohe Leistung, sondern wie wenig sich am Code ändert.

Der Stack: von RDMA bis MLX

Verteilte Workloads auf Apple Silicon stehen auf drei Schichten. Ganz unten liegt die physische Verbindung. Damit zwei Maschinen schnell Daten austauschen, brauchen sie einen Interconnect und ein Transportprotokoll, das Bytes aus dem Speicher der einen Maschine in den der anderen schiebt. Ab macOS 26.2 unterstützt Apple Remote Direct Memory Access, kurz RDMA, über Thunderbolt 5. RDMA verschiebt Daten direkt zwischen den Speichern zweier Maschinen und umgeht dabei den größten Teil des Overheads von CPU und Betriebssystem. Das ergibt genau die Kombination, die verteilte Workloads verlangen: hohe Bandbreite bei niedriger Latenz.

RDMA allein liefert aber nur rohen Datentransfer zwischen zwei Maschinen. Ein verteiltes Programm braucht etwas Höheres, ein Communication Backend mit Primitiven zum Senden von Daten zwischen einzelnen Maschinen und zum Zusammenführen von Ergebnissen über die ganze Gruppe. Diese beiden Operationen sind die Bausteine von verteiltem Training und verteilter Inferenz.

Hier kommt JACCL ins Spiel. JACCL ist eine quelloffene Collective Communication Library von Apple. Der Name steht für »Jack and Angelos’ Collective Communication Library« und ist ein Wortspiel auf NVIDIAs NCCL. Die Bibliothek nutzt RDMA über Thunderbolt und stellt Primitiven für kollektive Kommunikation bereit, ohne dass man sich um den Low-Level-Transport kümmern muss. JACCL ist nicht auf maschinelles Lernen beschränkt. Jeder verteilte Workload auf Apple Silicon kann darauf aufbauen, auch außerhalb von ML.

Die oberste Schicht ist das ML-Framework, das dieses Backend für verteilte Inferenz und Training verwendet, und das ist MLX. MLX ist Apples quelloffene ML-Bibliothek für Apple Silicon. Sie nutzt JACCL für die latenzarme Kommunikation und liefert die Werkzeuge, um verteilte Jobs über den Cluster zu orchestrieren. Wer MLX noch nicht kennt, findet in der WWDC25-Session »Get started with MLX for Apple silicon« den Einstieg.

Das Cluster: vier M3 Ultra verkabeln

Aus den drei Schichten wird ein Cluster, also eine Gruppe von Maschinen, die gemeinsam an derselben Aufgabe arbeiten. In der Demo sind das vier M3 Ultra, verbunden mit Thunderbolt-5-Kabeln. Es gibt verschiedene Wege, sie zu verkabeln, und die Topologie wirkt sich direkt auf die Kommunikationszeit aus.

Diese Zeit besteht aus zwei Komponenten. Die Latenz ist der feste Preis pro Kommunikationsoperation, unabhängig von der Datenmenge. Die Transferzeit ist der Preis für das Bewegen der Daten durch die Verbindung; sie wächst mit der Nachrichtengröße und hängt von der Bandbreite ab. Bei kleinen Nachrichten dominiert die Latenz, bei großen die Transferzeit. Je nachdem, ob die Kommunikation latenz- oder bandbreitengebunden ist, passt eine andere Topologie besser.

JACCL unterstützt zwei davon. Im vollen Mesh ist jede Maschine direkt mit jeder anderen verbunden, womit jede Gruppenkommunikation die niedrigstmögliche Latenz hat. Im Ring ist jeder Knoten nur mit seinen beiden Nachbarn verbunden. Kommunikation zwischen nicht benachbarten Knoten muss über Zwischenmaschinen laufen, was die Latenz erhöht. Dafür braucht der Ring weniger Kabel und Ports pro Maschine und skaliert leichter auf mehr Knoten. Weil jeder Knoten nur zwei Verbindungen hat, lassen sich die übrigen Thunderbolt-Ports nutzen, um zwei oder drei Kabel pro Nachbar zu legen. Das erhöht die Bandbreite pro Verbindung und senkt die Transferzeit.

Der praktische Trick: Wenn die Maschinen physisch als Mesh verkabelt sind, kann JACCL jede Kommunikation entweder über die Mesh- oder über die Ring-Route schicken. Die Bibliothek wählt automatisch die beste Variante je nach Nachrichtengröße und Operation, Mesh wenn die Latenz zählt, Ring wenn die Bandbreite zählt. Genau deshalb werden in der Demo alle vier M3 Ultra zu einem vollen Mesh verbunden.

Danach muss auf jeder Maschine RDMA aktiviert werden. Das passiert in den Systemeinstellungen: nach »RDMA« suchen, »Enable RDMA over Thunderbolt« anklicken, aktivieren und neu starten.

Jobs starten mit mlx.launch

Verteilte Programme müssen auf allen Knoten gestartet werden. Von einer Maschine mit SSH-Zugriff auf das Cluster, etwa einem MacBook, verbindet man sich mit jedem Mac, startet das Programm, und ab da kommunizieren alle Maschinen direkt über die Thunderbolt-Links. MLX liefert dafür einen Launch-Helfer, der genau das übernimmt.

mlx.launch --hostfile "m3-ultra-jaccl.json" -- \
    /remote/path/to/mlx_lm.chat --model "Qwen/Qwen3.6-27B" --max-tokens 2048

mlx.launch bekommt das auszuführende Programm und ein JSON-Hostfile, das das Cluster beschreibt. Von dort aus verbindet sich der Helfer per SSH mit jedem Knoten und startet die ausführbare Datei auf jeder Maschine. Das Hostfile ist ein JSON-Array mit einem Eintrag pro Knoten. Pro Eintrag stehen drei Felder: ssh ist der Hostname, über den mlx.launch die Maschine erreicht, ips ist die IP im lokalen Netz, die JACCL für die anfängliche Koordination nutzt, und rdma ist die Liste der RDMA-Gerätenamen für jede Thunderbolt-Verbindung.

Man kann das Hostfile von Hand schreiben, aber MLX bringt mit mlx.distributed_config ein Hilfsskript mit, das es erzeugt:

mlx.distributed_config \
    --hosts m3-ultra-0,m3-ultra-1,m3-ultra-2,m3-ultra-3 \
    --output "m3-ultra-jaccl.json" \
    --env MLX_METAL_FAST_SYNCH=1 \
    --auto-setup \
    --backend jaccl

Über --env lassen sich Umgebungsvariablen einbetten, die beim Start auf jedem Knoten gesetzt werden. MLX_METAL_FAST_SYNCH=1 aktiviert eine schnellere GPU-zu-CPU-Synchronisation und ist für verteilte Aufgaben wichtig, weil die Berechnung auf der GPU läuft, die Kommunikation aber auf der CPU. Das --backend-Argument legt fest, ob Mesh oder Ring genutzt wird: jaccl für das Mesh, jaccl-ring für den Ring. Mit --auto-setup konfiguriert das Skript das Thunderbolt-Netz selbst. Es prüft zuerst, ob alle Hosts per SSH erreichbar sind, sondiert dann die Thunderbolt-Ports, um die physische Topologie zu kartieren, deaktiviert die Thunderbolt Bridge auf allen Maschinen, richtet jeden Link für RDMA ein und schreibt am Ende das Hostfile. Ohne --auto-setup gibt das Skript nur die Konfigurationsbefehle aus, damit man sie selbst prüfen und ausführen kann.

Verteilte Inferenz: Qwen3.6 dreimal schneller, Kimi K2.6 überhaupt

Mit fertigem Cluster beginnt der interessante Teil. Der einfachste Einstieg läuft über die Kommandozeile und MLX LM, ein quelloffenes Python-Paket auf Basis von MLX mit CLI-Werkzeugen und Python-API für lokale Sprachmodelle.

Auf einer einzelnen Maschine chattet man mit einem Modell über mlx_lm.chat, indem man Modell und maximale Token-Zahl angibt. Für das Cluster wird derselbe Befehl in mlx.launch gewickelt, mit --hostfile auf die Cluster-Konfiguration und dem identischen mlx_lm.chat-Aufruf nach dem doppelten Bindestrich, allerdings mit dem Remote-Pfad zur ausführbaren Datei auf jedem Knoten. MLX LM zerteilt das Modell und koordiniert die verteilte Inferenz selbst. Voraussetzung ist, dass alle nötigen Bibliotheken auf jedem Mac installiert und die ausführbaren Dateien auf allen Maschinen erreichbar sind.

Im direkten Vergleich läuft Qwen/Qwen3.6-27B, ein Modell mit 27 Milliarden Parametern, links auf einem einzelnen M3 Ultra und rechts über vier Maschinen verteilt. Beide bekommen denselben Prompt. Laut Apple erzeugt das Cluster Tokens mit nahezu der dreifachen Rate des einzelnen Geräts. Der genaue Speedup hängt von Größe und Architektur des Modells ab.

Geschwindigkeit ist aber nicht der einzige Grund, verteilt zu rechnen. Manchmal ist ein Modell schlicht zu groß für eine Maschine. Kimi-K2.6 hat eine Billion Parameter. Selbst mit 8-Bit-Quantisierung belegen allein die Gewichte rund ein Terabyte Speicher. Das passt nicht auf einen einzelnen M3 Ultra, aber über vier verteilt. Mit einem einzigen Befehl läuft ein solches Modell lokal über die Macs hinweg und beantwortet Anfragen.

Pipeline- und Tensor-Parallelität

Wie werden Gewichte und Berechnung auf die Maschinen aufgeteilt? MLX und MLX LM kennen zwei Ansätze.

Pipeline-Parallelität teilt das Modell nach Tiefe. Jede Maschine hält eine Gruppe von Layern, die Daten wandern sequentiell durch die Maschinen. Das beschleunigt die Inferenz nicht, weil jedes Token weiterhin eine Layer-Gruppe nach der anderen durchläuft. Der Vorteil ist die einfache Kommunikation: Maschinen tauschen nur an den Grenzen zwischen den Layer-Gruppen Aktivierungen aus.

Tensor-Parallelität teilt das Modell nach Breite. Jede Maschine hält einen Teil jedes Layers, alle Maschinen verarbeiten dasselbe Token gleichzeitig. Das beschleunigt die Inferenz durch parallelisierte Berechnung pro Layer. Der Preis ist deutlich häufigere Kommunikation, bei jedem Layer und für jedes Token. Niedrige Latenz wird dadurch entscheidend, und genau deshalb ist die Mesh-Topologie hier wichtig, weil jede Maschine jede andere in einem einzigen Hop erreicht.

Tensor-Parallelität ist die Standardstrategie in MLX LM. Pipeline-Parallelität aktiviert man, indem man dem Befehl ein --pipeline anhängt, wobei nicht jedes Modell sie unterstützt. Beim Chat mit dem Billion-Parameter-Kimi wird kein --pipeline übergeben, es läuft also Tensor-Parallelität.

Verteiltes Fine-Tuning per Datenparallelität

Mit MLX und MLX LM lässt sich nicht nur Inferenz verteilen, sondern auch Fine-Tuning, schnell, effizient und vollständig privat, weil die Daten die eigenen Maschinen nie verlassen.

Beim Training auf einer einzelnen Maschine werden die Trainingsdaten in Batches aufgeteilt. Für jeden Batch berechnet der Mac Gradienten und aktualisiert die Gewichte, und dieser Vorgang wiederholt sich über einen oder mehrere Durchläufe durch den Datensatz, bis das Modell die gewünschte Qualität erreicht. Je schneller die Daten verarbeitet werden, desto früher ist das Fine-Tuning fertig.

Mehrere Maschinen beschleunigen das nach einem einfachen Prinzip. Das Modell wird auf jedem Mac repliziert. Jede Maschine bekommt einen anderen Batch und berechnet ihre Gradienten lokal. Danach werden die Gradienten gemittelt, sodass die Aktualisierung Information aus allen Batches nutzt. Das nennt sich datenparalleles Training, weil das Modell repliziert wird, während die Daten parallel über die Maschinen verarbeitet werden. Mit N Maschinen lassen sich die Daten bis zu N-mal schneller verarbeiten.

Der einzige Unterschied zum Einzelgerät ist wieder der Start über mlx.launch, diesmal mit dem Pfad zu mlx_lm.lora auf den Remote-Maschinen. Das Daten-Sharding übernimmt MLX LM, der Befehl ist nahezu identisch. Lediglich --batch-size wird mit der Zahl der Geräte multipliziert, damit jede Maschine pro Schritt weiterhin gleich viele Samples verarbeitet.

In der Demo wird Qwen/Qwen3.5-9B, ein Modell mit 9 Milliarden Parametern, einmal auf einem einzelnen Gerät und einmal auf dem Cluster feingetunt. Laut Apple verarbeitet der einzelne M3 Ultra rund 180 Tokens pro Sekunde, das Cluster rund 600, was einem mehr als dreifachen Speedup für das Fine-Tuning entspricht.

Vier Wege in den Code: CLI, Python, Swift, C++

Alle Beispiele bisher liefen über die Kommandozeile innerhalb von MLX LM. Darunter liegt eine feingranulare Kontrolle über Sharding und verteilte Operationen, erreichbar über flexible APIs in Python, Swift und C++. So kann man in Python und C++ mit Modellen experimentieren oder sie mit Swift direkt in eine App einbetten.

Verteilte Inferenz mit der Python-API und MLX LM braucht drei Schritte: zuerst die verteilte Gruppe für die Kommunikation initialisieren, dann die Art der Parallelität festlegen, etwa Tensor-Parallelität, und schließlich das Modell mit sharded_load aufteilen. Danach nutzt man das Modell genau wie auf einem Einzelgerät, MLX LM kümmert sich um die verteilte Kommunikation.

Wer mehr Kontrolle will, greift zu den Low-Level-Primitiven von MLX selbst. Ein einfacher Linear-Layer lässt sich mit shard_linear per Tensor-Parallelität aufteilen, und grundlegende verteilte Operationen wie all reduce stehen direkt zur Verfügung. In Python, Swift oder C++ initialisiert man dafür die verteilte Gruppe über JACCL und führt dann mit den passenden MLX-Primitiven eine kollektive Summe über alle Macs aus.

Weil JACCL eigenständig verfügbar ist, lässt es sich auch für nicht-ML-Workloads nutzen. Es kann ohne MLX gebaut werden und bietet eine C++-API mit Kommunikationsprimitiven, mit denen man dieselbe kollektive Summe direkt über JACCL ausführt, statt über MLX.

Einordnung

Die Session führt den ganzen Stack vor, der verteiltes Training und Inferenz auf Apple Silicon möglich macht, von RDMA über Thunderbolt bis hinauf zu MLX und MLX LM. Der durchgängige Befund: Der Schritt vom einzelnen Gerät zum Cluster verlangt minimale Änderungen am Code, der für ein Einzelgerät geschrieben wurde. Derselbe mlx_lm.chat-Aufruf, nur in mlx.launch gewickelt, verteilt ein 27-Milliarden-Modell über vier Maschinen. Derselbe mlx_lm.lora-Aufruf skaliert das Fine-Tuning.

Praktisch heißt das zweierlei. Erstens lassen sich Modelle lokal ausführen, die auf keine einzelne Maschine passen, bis hin zu einer Billion Parametern. Zweitens beschleunigt sich vorhandene Arbeit, Inferenz wie Fine-Tuning, um etwa das Dreifache bei vier Geräten. Beides geschieht auf Hardware, die auf dem eigenen Schreibtisch steht, ohne dass Daten die eigenen Maschinen verlassen.

Zur WWDC-Demo im Juni 2026 sah die Kostenrechnung verlockend aus. Ein Mac Studio mit M3 Ultra startet in Deutschland bei rund 4.800 Euro in der Basis mit 96 GB Unified Memory und 1 TB SSD (Apple DE, Juni 2026). Vier davon liegen schon in der Basis bei etwa 19.000 Euro, mit dem für große Modelle nötigen Speicherausbau eher im mittleren fünfstelligen Bereich. Dem gegenüber steht ein NVIDIA-System mit vergleichbarer Speichermenge: Ein DGX H200 mit acht H200-Karten bietet zusammen rund 1,1 TB HBM3e und kostet bei einem deutschen Händler rund 393.000 Euro inklusive dreijährigem Support (smicro.eu, Juni 2026). Einzelne H200-Karten mit 141 GB liegen bei etwa 30.000 bis 40.000 US-Dollar (IntuitionLabs, 2026).

Der Vergleich ist dabei keiner der Leistung. NVIDIAs HBM3e liefert ein Vielfaches der Speicherbandbreite des Unified Memory, und ein DGX-System ist auf Durchsatz und Mehrnutzerbetrieb ausgelegt, nicht auf einen Schreibtisch. Er gilt allein der Fähigkeit, ein Modell dieser Größe überhaupt lokal vorzuhalten. Genau dort steht eine Anschaffung im niedrigen fünfstelligen Bereich gegen eine im niedrigen sechsstelligen, rund eine Größenordnung Unterschied.

Diese Rechnung ist allerdings schon zum Erscheinen dieses Artikels überholt, und zwar aus zwei Gründen. Erstens gibt es die in der Demo verwendete Konfiguration nicht mehr. Apple hat die hohen RAM-Stufen des M3 Ultra im Lauf des Jahres 2026 gestrichen, erst die 512-GB-Option im März, dann im Mai auch 128 GB und 256 GB. Seither ist der M3 Ultra nur noch mit 96 GB Unified Memory bestellbar (MacRumors, 9to5Mac, Mai 2026). Damit fehlt genau der Speicherausbau, den die vier Maschinen im Apple-Beispiel hatten, um ein Billion-Parameter-Modell aufzunehmen. Zweitens sind selbst die verbliebenen Konfigurationen kaum kurzfristig lieferbar. Apple nennt für die noch orderbaren High-RAM-Modelle Lieferzeiten von vielen Wochen bis Monaten, mit Abholung im Store teils erst ab September.

Ursache ist eine globale Knappheit an Speicherchips, ausgelöst durch dieselbe KI-Nachfrage, die Unternehmen RAM-schwere Server für genau solche Modelle bauen lässt. Apple rechnet mit einer Entspannung frühestens im dritten Quartal 2026 (Apple-Prognose, 2026). Die Hardware, mit der man sich die teuren GPU-Server sparen könnte, ist knapp geworden, weil dieselbe Nachfrage die Speicherchips bindet.

Der Mechanismus bleibt davon unberührt. RDMA über Thunderbolt, JACCL und MLX machen aus mehreren Macs ein Cluster mit minimalen Änderungen am Code, das ein Modell lokal hält, das auf keine einzelne Maschine passt, und Inferenz wie Fine-Tuning um etwa das Dreifache beschleunigt. Was 2026 fehlt, ist nicht die Technik, sondern der Arbeitsspeicher zum Kaufpreis von gestern.