6 Punkte von GN⁺ 2025-12-19 | 2 Kommentare | Auf WhatsApp teilen
  • Experiment, bei dem die in macOS 26.2 neu hinzugefügte Funktion RDMA (Remote Direct Memory Access) über Thunderbolt 5 genutzt wird, um mehrere Mac Studio wie einen einzigen riesigen Speicherpool arbeiten zu lassen
  • Mit dem Open-Source-Clustering-Tool Exo 1.0 wurde ein gemeinsamer Speicher von 1,5 TB aufgebaut, um die Ausführung großer AI-Modelle zu beschleunigen
  • Das M3 Ultra Mac Studio zeigt bereits als einzelner Knoten hohe Rechenleistung und Effizienz; mit RDMA sinkt die Speicherzugriffs-Latenz von 300 μs auf unter 50 μs
  • Es gibt jedoch auch betriebliche Grenzen beim Cluster-Betrieb, etwa die Kabelkomplexität von Thunderbolt 5, das Fehlen von Switches und Einschränkungen bei der macOS-Verwaltung
  • Die Kombination aus RDMA und Exo zeigt das Erweiterungspotenzial für Mac-basierte AI- und HPC-Umgebungen, doch Stabilität und Skalierbarkeit müssen noch verbessert werden

Überblick über das Experiment mit RDMA über Thunderbolt 5

  • Mit einem von Apple bereitgestellten Mac-Studio-Cluster wurde die RDMA-over-Thunderbolt-Funktion von macOS 26.2 getestet
    • RDMA lässt mehrere Macs wie einen großen RAM-Verbund arbeiten und beschleunigt so die Verarbeitung großer AI-Modelle
  • Für den Test wurde das Open-Source-AI-Clustering-Tool Exo 1.0 verwendet
  • Vier Mac Studio mit insgesamt 1,5 TB Unified Memory kosten rund 40.000 US-Dollar

Apples HPC-Geschichte und die Rolle des M3 Ultra

  • Apple hat seit den Zeiten von Xserve und Xgrid kaum noch HPC-bezogene Versuche unternommen
  • Das M3 Ultra Mac Studio bietet eine für lokale AI-Modelle geeignete Leistung; mit RDMA sinkt die Latenz beim Clustering von 300 μs auf unter 50 μs
  • Es arbeitet leise mit weniger als 250 W Leistungsaufnahme und eignet sich auch für kleinere wissenschaftliche Berechnungen und kreative Workloads

Hardware-Aufbau und Networking

  • Die unteren zwei Geräte sind mit 512 GB RAM / 32-Core-CPU ausgestattet, die oberen zwei mit 256 GB RAM
  • Über Thunderbolt 5 werden 50–60 Gbit/s effektive Bandbreite erreicht, wegen des fehlenden Thunderbolt-Switches müssen die Macs jedoch direkt miteinander verbunden werden
  • Im Vergleich zur Nvidia DGX Spark mit QSFP-Ports ist die Netzwerkstabilität geringer
  • Es gibt mit ThunderLok-A zwar eine Fixierung für Thunderbolt-Kabel, sie wurde aber nicht eingesetzt, weil dafür Modifikationen am Mac-Studio-Gehäuse nötig wären

Leistungs-Benchmarks des M3 Ultra Mac Studio

  • In Geekbench liegt es bei Single- und Multi-Core vor dem Dell Pro Max (GB10) und dem AMD AI Max+ 395
  • Im FP64-HPL-Benchmark überschreitet es 1 Tflop und erreicht damit etwa die doppelte Leistung des Nvidia GB10
  • Auch bei der Inferenz großer AI-Modelle ist es stark und bietet eine hohe Effizienz pro Watt
  • Ein einzelner M3 Ultra liegt bei Leistung und Effizienz vor einem 2-Knoten-Cluster aus Dell Pro Max

Cluster-Verwaltung und macOS-Einschränkungen

  • macOS erlaubt keine System-Upgrades per SSH, stattdessen ist GUI-Bedienung nötig
  • Die Fernverwaltung erfolgt über Screen Sharing
  • Im Vergleich zu Linux ist die Automatisierung der Cluster-Verwaltung schwieriger, und das Fehlen von MDM-Tools ist unpraktisch

Tests mit HPL und Llama.cpp

  • HPL erreicht auf einem einzelnen Knoten 1,3 Tflops, mit 4 Knoten 3,7 Tflops, also etwa die dreifache Leistung
  • Bei TCP-Verbindungen über Thunderbolt kam es zu Systemabstürzen; ohne RDMA war der Betrieb instabil
  • In Llama.cpp-Tests zeigte Thunderbolt 5 eine geringere Latenz als 2,5-Gbit/s-Ethernet

Aktivierung von RDMA und Tests mit Exo 1.0

  • Vorgehen zum Aktivieren von RDMA: In den Wiederherstellungsmodus wechseln → Befehl rdma_ctl enable ausführen → neu starten
  • Exo 1.0 ist das einzige Tool mit RDMA-Unterstützung und kann Modelle mit mehr als 600 GB (wie Kimi K2 Thinking) verteilt über mehrere Macs ausführen
  • Llama.cpp verteilt Modell-Layer per RPC, was jedoch ineffizient ist
  • Mit zunehmender Knotenzahl steigt bei Exo die Leistung; beim Qwen3-235B-Modell wurden 32 Token pro Sekunde erreicht
  • Auch DeepSeek V3.1 und Kimi K2 Thinking (1 Billion Parameter) konnten erfolgreich ausgeführt werden

Stabilitätsprobleme und Open-Source-Themen

  • Die Tests basierten auf Pre-Release-Software und waren daher instabil
  • Wenn RDMA funktionierte, war die Leistung stark, bei Fehlern musste jedoch der gesamte Cluster neu gestartet werden
  • Das Exo-Entwicklungsteam kehrte nach einer längeren Pause zurück; die Software steht unter der Apache-2.0-Lizenz
  • Erwähnt werden auch Bedenken bezüglich eines nicht öffentlichen Entwicklungsprozesses durch die Zusammenarbeit mit Apple

Künftige Aufgaben und offene Fragen

  • Ob ein M5 Ultra erscheint und ob sich die Machine-Learning-Leistung weiter steigern lässt
  • Der Bedarf an besseren Clustering-Möglichkeiten durch eine Rückkehr der PCIe-Erweiterbarkeit beim Mac Pro
  • Die Möglichkeit schneller Dateifreigaben bei Unterstützung von SMB Direct
  • Die Hoffnung auf breitere RDMA-Unterstützung in anderer Software wie Llama.cpp

Fazit

  • Die Kombination aus RDMA und Exo erweitert die Einsatzmöglichkeiten des Mac Studio für AI und HPC erheblich
  • Dennoch bleiben die strukturellen Grenzen von Thunderbolt 5 und die Verwaltungsbeschränkungen von macOS ein Flaschenhals
  • Für bessere Netzwerk-Skalierbarkeit wären Verbesserungen wie die Einführung von QSFP-Ports nötig
  • Auch wenn der AI-Boom abflaut, bleibt das Mac Studio als leise und leistungsstarke Workstation wertvoll

2 Kommentare

 
kaydash 2025-12-21

Das erinnert mich an impala.

 
GN⁺ 2025-12-19
Hacker-News-Kommentare
  • Eine Zusammenfassung der Erwartungen an den M5 Max/Ultra
    Statt Thunderbolt sollte er Links auf QSFP-Niveau (200Gb/s oder mehr) wie bei einer DGX unterstützen. Die RDMA-Architektur ist zwar cool, aber bei geringerer Geschwindigkeit ist das wirtschaftlich wenig attraktiv.
    Mit einem Neural Accelerator würde ich gern die Prompt-Prefill-Zeit verkürzen. Es muss nicht auf RTX-6000-Niveau sein; 3090/4090 wäre schon ausreichend.
    Für die Top-Konfiguration des Mac Studio hoffe ich auf 1 TB Unified Memory. Mehr Speicher ist aus meiner Sicht effizienter als mehrere Geräte.
    Auch die Bandbreite sollte auf +1 TB/s erhöht werden. In den letzten drei Generationen ist sie bei 800 GB/s stehen geblieben.
    Außerdem wäre Overclocking wünschenswert. Der Mac Studio ist kein Laptop, also wären auch über 600 W Leistungsaufnahme in Ordnung. Derzeit ist er auf etwa 250 W begrenzt.
    Diese RDMA-Konfiguration kann außerdem nur bis zu vier Macs verbinden, weil alle Macs direkt miteinander verbunden sein müssen. Deshalb sollte Apple meiner Meinung nach in Hochgeschwindigkeits-Links wie QSFP investieren.

    • 1 TB Speicher? Ihr solltet uns normalen Nutzern noch etwas RAM übrig lassen. Das klingt wie: „KI, mach die Menschheit glücklich!“
    • Der M4 erreicht bereits die nötige Geschwindigkeit pro Kanal, und der M5 liegt darüber. Falls eine Ultra-Version kommt, sind 1 TB/s Bandbreite sicher machbar. Der Max ist nur die Hälfte eines Ultra, daher wohl eher nicht.
    • Der Mac Studio hat keine thermische Auslegung, um dauerhaft 650 W Abwärme zu bewältigen. So etwas wäre eher in einem Mac-Pro-Design möglich.
    • Auch die vorderen USB-C-Ports des M3 Ultra Mac Studio sind Thunderbolt 5, also gibt es insgesamt sechs Ports. Wenn man die offiziellen Spezifikationen ansieht, frage ich mich, warum diese Begrenzung auf vier Geräte nötig ist.
    • Die Apple Neural Engine unterstützt bereits INT8- und FP16-Berechnungen. Allerdings nutzen die KI-Frameworks das noch nicht richtig aus.
      Und ich frage mich auch, ob wirklich alle Macs vollständig vermascht sein müssen. Thunderbolt läuft doch gewissermaßen wie eine Netzwerkschnittstelle über RDMA, oder nicht?
  • Ich frage mich, warum Apple Funktionen wie RDMA für Server-Cluster einführt, grundlegende Verbesserungen wie Remote-Management oder Rackmount aber ignoriert.
    Vielleicht nutzt Apple intern M-Serie-Serverprodukte, und solche Funktionen sind nur ein Nebenprodukt davon.

    • Vielleicht bereitet Apple tatsächlich ein echtes Server-Produkt vor und hat RDMA vorab veröffentlicht, damit Drittanbieter-Software schon darauf reagieren kann.
    • Der Mac Studio hat eine eigene Nische für LLM-Inferenz. RDMA ist wohl nicht für allgemeine Server gedacht, sondern dafür, vier Studios zu einem LLM-Inferenz-Cluster zusammenzufassen.
    • Ich habe einmal gehört, dass Apple für die Private-Compute-Funktion M2 Mac Pros in Racks gestapelt eingesetzt hat.
    • Ich frage mich, ob Apple eigene Rechenzentren betreibt. Ich dachte, das meiste wäre an GCP outgesourct.
    • Das frage ich mich schon lange: Warum ist das Tooling für die Entwicklung so schwach, und welche Umgebung nutzt Apple intern eigentlich? Mac Minis per Thunderbolt-Kabel zu verketten wirkt etwas unerquicklich.
  • Jeffs Arbeit ist wirklich großartig. Die Neuigkeiten zu Thunderbolt-basiertem RDMA waren ebenfalls spannend.
    Vor allem danke ich Jeff für seine positive Energie und seine kontinuierlichen Beiträge.

  • Linux unterstützt RDMA, aber über Thunderbolt geht das bislang noch nicht. Um das zu implementieren, wäre wohl ziemlich viel Arbeit nötig.
    Es wäre schön, wenn man mit günstigen Strix-Halo-Boxen (128 GB DDR5-8000, 2× USB4) zwei oder drei Geräte bündeln und damit große Modelle ausführen könnte.

  • Thunderbolt hat derzeit keine Switches, deshalb ist die Cluster-Größe begrenzt.
    Stattdessen könnte man vielleicht RoCE (RDMA over Converged Ethernet) verwenden. Ich habe gehört, dass RDMA 7- bis 10-mal schneller als TCP ist.
    Es gibt zwar 10G- bis 80G-Thunderbolt-Ethernet-Adapter, aber Latenz könnte das Problem sein.
    Mit einem PCIe-Slot müsste man nur eine Infiniband-Karte einstecken, aber letztlich hängt alles am Treiber.

    • Man könnte Thunderbolt auch auf PCIe umsetzen und normale NICs verwenden. Atto Thunderlink ist im Grunde nur ein Gehäuse um eine Broadcom-NIC.
      Dass Apple den MLX5-Treiber sogar in iPadOS aufgenommen hat, ist überraschend. Siehe diesen Blog.
    • macOS enthält Treiber für Mellanox-ConnectX-Karten, aber ich weiß nicht, ob sie in ibv_devices tatsächlich erscheinen.
  • Mich würden Daten interessieren, die Prefill- und Decode-Geschwindigkeit getrennt messen.
    Im Beitrag von Exo stand, dass sich diese beiden Geschwindigkeiten auf Mac-Hardware ziemlich stark unterscheiden.

    • Einige zugehörige Daten gibt es in diesem GitHub-Issue.
      Ich überlege, dem Exo-Team vorzuschlagen, eine Benchmark-Funktion hinzuzufügen.
  • Ich fand interessant, dass Thunderbolt 5 doch nicht so überwältigend ist wie gedacht.
    Gegenüber 2,5-Gbps-Ethernet war TB5 nur etwa 10 % schneller. Das M3 Studio unterstützt 10-Gbps-Ethernet, wurde aber nicht getestet.
    TB5 ist auf vier Geräte begrenzt, weil alle CPUs direkt miteinander verbunden sein müssen. Mit einem Ethernet-Switch könnte man dagegen mehr Knoten anbinden.

    • In diesem Video wird mit 10-Gbps-Ethernet getestet.
    • Nach meinen früheren Erfahrungen mit llama RPC bringt 10G-Ethernet nur geringe Geschwindigkeitsvorteile. Latenz ist wichtiger, aber auch da gibt es Grenzen.
    • llama ist noch nicht ausreichend optimiert und skaliert deshalb schlecht. RDMA hat weniger Overhead als Ethernet.
  • Jeder Knoten im Cluster hat 512 GB RAM. Das Modell DeepSeek V3.1 benötigt 700 GB RAM.
    Es ist merkwürdig, dass sich die Inferenzgeschwindigkeit beim Wechsel von einem auf zwei Knoten nur um 32 % verbessert. Selbst bei vier Knoten liegt die Steigerung unter 50 %.
    Es scheint also irgendeinen Flaschenhals zu geben.

    • Die Netzwerkbandbreite von 80 Gbps ist der Flaschenhals. Infiniband ist etwa zehnmal schneller.
    • Die Weights des Modells sind schreibgeschützt, daher könnte man sie auch per Memory-Mapping von einer SSD laden. Die eigentliche Einschränkung ist der Activation-Speicher. Eine MoE-Architektur könnte helfen.
    • TB5-RDMA ist viel langsamer als direkter Zugriff auf den Systemspeicher.
  • Die Struktur, bei der alle Knoten miteinander verbunden sind, erinnert mich an SGIs NUMALink.
    In SGI-Supercomputern war jeder Knoten mit zwei Links zu allen anderen Knoten verbunden. Das bedeutete viele Kabel, aber man musste sich nicht mit Framing oder Staukontrolle befassen.

    • SGI-Hardware implementierte ccNUMA (cache-coherent NUMA). Das Betriebssystem IRIX verschob Aufgaben und Speicher physisch näher zusammen, um die Latenz zu senken.
      Dass heutige Hochfrequenzhandelssysteme Prozesse unter Berücksichtigung von CPU-Kernen und DIMM-Positionen platzieren, folgt demselben Gedanken.
    • Das NVL72-Rack hat ebenfalls eine ähnliche Struktur, da es dutzende Links zwischen den GPUs verbindet.
  • Mir gefielen einige interessante Details aus dem Beitrag.
    Exos mysteriöses Verschwinden, Jeffs Wunsch nach SMB Direct für den Mac, die Inferenzgeschwindigkeit des M3 Ultra und der 2100-Dollar-Framework-AI-Desktop.
    Dadurch hatte ich das Gefühl, ein neues Rabbit Hole entdeckt zu haben.