Cloud-Mac-mini-Cluster im Praxistest: Was bedeuten Thunderbolt 5 mit 80 Gbps?

Was ist Thunderbolt-5-Parallelbetrieb überhaupt?

Auf der ZilCloud-Konfigurationsseite gibt es ein Add-on namens „Thunderbolt-5-Cluster-Service“. Pro Tag kostet es $1.4, pro Monat $8.9. Meine erste Reaktion: Wofür braucht man das?

Kurz gesagt: Thunderbolt 5 (im Folgenden TB5) ist der neue Anschlussstandard am Mac mini M4. Die theoretische Bandbreite beträgt 120 Gbps über PCIe; für Geräte-zu-Gerät-Verbindungen sind 80 Gbps bidirektional möglich – das entspricht etwa 10 GB/s und verdoppelt Thunderbolt 4 (40 Gbps). Der ZilCloud-TB5-Service verbindet zwei oder mehr Cloud-Mac-mini-M4-Knoten per physischem TB5-Kabel direkt miteinander und bildet ein für macOS transparentes Hochgeschwindigkeits-LAN.

Technisch ist das mehr als „zwei Rechner per Netzwerkkabel verbinden“. TB5 nutzt PCIe-Kanäle mit deutlich geringerer Latenz als Ethernet. Theoretisch sind nahezu NVMe-ähnliche Geschwindigkeiten für speicherübergreifenden Zugriff denkbar – etwa über Remote Direct Memory Access (RDMA). Für Build-Cluster, KI-Inferenz-Pools oder Render-Farmen ist das ein echter Unterschied, nicht nur Marketing.

Setup: Bereitstellung und TB5-Erkennung

Nach Auswahl von zwei Knoten und Aktivierung des TB5-Add-ons im ZilCloud-Dashboard waren beide Maschinen in etwa drei Minuten im Status „Bereit“. Per SSH auf dem ersten Knoten bestätigen wir die TB5-Schnittstellen mit:

system_profiler SPThunderboltDataType

Die Ausgabe zeigt beide TB5-Ports als erkannt; im Status „Connected“ erscheint das Gegenstück – der zweite Mac mini. In den macOS-Netzwerkeinstellungen legt das System automatisch eine „Thunderbolt Bridge“-Schnittstelle mit einer 169.254.x.x-Link-Local-Adresse an. Für erste Tests reicht das ohne manuelle Konfiguration.

Statische IP manuell setzen (empfohlen)

APIPA funktioniert, aber für Build-Skripte und reproduzierbare Jobs empfehlen wir feste Adressen auf der Thunderbolt Bridge:

# Knoten A
sudo networksetup -setmanual "Thunderbolt Bridge" 192.168.100.1 255.255.255.0

# Knoten B
sudo networksetup -setmanual "Thunderbolt Bridge" 192.168.100.2 255.255.255.0

Mit ping -c 4 192.168.100.2 messen wir eine durchschnittliche RTT von etwa 0,08 ms – niedriger als viele 10-Gbit-Ethernet-Setups im selben Rack.

Bandbreite im Praxistest: iperf3 und Dateisystem

Nach dem Netzwerk-Setup folgt logischerweise iperf3.

iperf3 TCP-Test

# Knoten B als Server
iperf3 -s

# Knoten A als Client, 8 parallele Streams
iperf3 -c 192.168.100.2 -P 8 -t 30

Die Ergebnisse:

UDP mit einem Stream erreicht 79,1 Gbps – sehr nah an den angegebenen 80 Gbps. TCP mit acht parallelen Streams kommt auf 72,4 Gbps, für reale Workloads mehr als ausreichend. Bidirektional stabilisieren sich beide Richtungen jeweils bei über 60 Gbps, zusammen über 120 Gbps – passend zur PCIe-Theorie von TB5.

Dateiübertragung über SMB und NFS

iperf3 misst nur die Netzwerkschicht. Im Alltag zählt die Geschwindigkeit auf Dateisystemebene. Wir haben macOS-SMB-Freigaben und NFS-Mounts getestet:

NFS v4.2 erreicht beim sequentiellen Lesen 6,2 GB/s – schneller als der lokale NVMe-SSD-Durchsatz auf einem einzelnen Knoten. Daten vom Partnerrechner über TB5 zu lesen kann damit sogar flotter sein als vom lokalen Laufwerk, weil der M4 hohe Speicherbandbreite nutzt und über TB5 direkt auf den Unified-Memory-Puffer des Partners zugreift.

Verteilte Xcode-Kompilierung im Test

Für iOS- und macOS-Entwickler ist die zentrale Frage: Wie viel schneller wird der Build mit einem TB5-Cluster?

Als Testobjekt diente eine reale iOS-App mit rund 180 Modulen (große SwiftUI-Anwendung, Cold Build lokal etwa 14 Minuten). Mit distcc und pump mode verteilen wir Compile-Jobs auf beide Maschinen:

# distcc installieren
brew install distcc

# Knoten B als Compile-Daemon
distccd --allow 192.168.100.0/24 --log-stderr --verbose

# Knoten A: distcc-Hostliste
export DISTCC_HOSTS="192.168.100.2/8 localhost/4"

# Build im Pump-Modus
pump xcodebuild -project MyApp.xcodeproj -scheme MyApp -configuration Release build

Der Cold Build sinkt von 14 Minuten auf 8 Minuten 47 Sekunden – etwa 1,62× schneller. Die volle Verdopplung bleibt aus, weil die Swift-Frontend-Phase (Semantikanalyse) noch nicht verteilt werden kann und rund 35 % der Gesamtzeit ausmacht. Reiner C/C++/Objective-C-Code profitiert stärker; dort messen wir bis zu 1,9×.

Bei inkrementellen Builds fällt der Gewinn noch deutlicher aus: Zwischenergebnisse tauschen über TB5 so schnell aus, dass Wartezeiten auf Netzwerk-I/O praktisch wegfallen. Aus etwa 3 Minuten 46 Sekunden werden 1 Minute 38 Sekunden – im Tagesgeschäft spürbar.

KI-Inferenz: llama.cpp über mehrere Knoten

Neben Builds lohnt sich TB5 auch für KI-Inferenz. Der Apple Neural Engine im M4 liefert 38 TOPS – für Einzelanfragen reicht ein Knoten. Wer mehrere parallele Requests bedient, skaliert mit zwei vernetzten Maschinen den Durchsatz spürbar.

Wir testen llama.cpp mit RPC-Backend (ab Build 0.1.x für Multi-Node-Lastverteilung) mit Llama 3.1 8B (Q4_K_M):

# Knoten B: llama-rpc-server
./llama-rpc-server --host 192.168.100.2 --port 50052 -ngl 99

# Knoten A als Steuerknoten
./llama-cli \
  --rpc 192.168.100.2:50052 \
  -m ./Llama-3.1-8B-Q4_K_M.gguf \
  -ngl 99 --parallel 8 -p "Write a detailed technical analysis of..."

Beim 8B-Modell steigt der Durchsatz von 48,2 tok/s auf 89,7 tok/s – nahezu linear. Die extrem niedrige TB5-Latenz hält den Overhead für KV-Cache-Sync zwischen den Knoten vernachlässigbar; klassisches Ethernet schafft das nicht in vergleichbarer Form.

Zwei Knoten eröffnen außerdem etwas, was ein einzelner 16-GB-Rechner nicht kann: Llama 3.1 70B in Q4-Quantisierung. Das Modell braucht rund 40 GB RAM; per TB5-RPC verteilen wir die Layer auf beide Maschinen und erreichen etwa 22 tok/s – ohne dedizierte GPU ein brauchbarer Wert für lokale Inferenz.

Latenz und Stabilität: 72-Stunden-Dauerlast

Gute Peak-Werte reichen nicht – für Produktion zählt Dauerstabilität. Wir liefen 72 Stunden Dauerlast: Xcode-Inkremental-Builds alle fünf Minuten, parallele llama.cpp-Inferenz und zyklisches Lesen/Schreiben großer Dateien über TB5.

In 72 Stunden fiel die TB5-Verbindung nicht ein einziges Mal aus; beide Knoten blieben per SSH erreichbar. Unter Spitzenlast drosselte der M4 thermisch leicht – der Mittelwert lag dennoch bei 69,8 Gbps, für CI/CD und dauerhafte KI-Dienste akzeptabel.

Für wen lohnt sich ein TB5-Cluster?

Aus den Messungen ergeben sich vier Hauptanwendungsfelder:

1. Verteilte iOS-/macOS-Builds (Xcode + distcc): Cold Build etwa 1,6× schneller, inkrementell über 2× – CI-Pipelines verkürzen sich spürbar.

2. Große Modelle lokal inferieren (llama.cpp RPC): Zwei Knoten mit je 16 GB Unified Memory ergeben zusammen 32 GB – genug für 70B-Quantisierungen; paralleler Durchsatz skaliert nahezu linear.

3. Video-Rendering und Medienproduktion: NFS über TB5 liest mit bis zu 6,2 GB/s – weit über normalem LAN; mit Final-Cut-Pro-Cluster-Protokollen theoretisch halbierte Renderzeiten.

4. Echtzeit-Datenpipelines: 80 Gbps plus 0,08 ms Latenz ermöglichen speicherübergreifende Muster mit niedriger Knoten-zu-Knoten-Latenz – z. B. Backtesting oder Stream-Aggregation.

Warum nicht einfach einen klassischen Cloud-Cluster nehmen?

Vielleicht fragen Sie sich: Brauche ich ZilCloud, wenn AWS oder andere Anbieter HPC-Instanzen mit 100-Gbit-Ethernet anbieten?

Die Antwort hängt von drei oft übersehenen Unterschieden ab.

macOS ist nicht ersetzbar. Xcode-Builds, iOS-Signing, TestFlight und Inferenz über die Apple Neural Engine laufen auf Linux oder Windows nicht – rechtlich und technisch. AWS Graviton ist ARM, aber ohne macOS. AWS Mac-Instanzen sind Apple-Hardware, kosten aber ab etwa $1,08/Stunde mit Mindestlaufzeit 24 Stunden (rund $25,9/Tag) – teurer als ZilClouds $20,9/Tag – und bieten kein TB5-Clustering.

Kein Oversubscribing. Viele Clouds virtualisieren und überbuchen Kapazität: hinter „10 Gbps“ steckt oft Burst-Bandbreite, und Nachbar-Last kann Ihre Builds bremsen. Bei ZilCloud erhalten Sie eine physische Mac mini M4 – 10 CPU-Kerne sind 10 echte Kerne, ohne Hypervisor und ohne Nachbarn auf derselben Hardware.

Interconnect-Qualität. Selbst AWS Cluster Placement Groups liegen bei 0,5–2 ms RTT; EFA-HPC-Netze sind schnell, aber nicht vergleichbar mit TB5-Direktverbindung bei 0,08 ms RTT ohne Routing durch den Netzwerk-Stack – entscheidend für Workloads mit großem gemeinsamem Zustand (z. B. KV-Cache-Sharding).

Klassische Clouds punkten bei sekundengenauer Abrechnung, breiter GPU-Auswahl und ausgereifter Autoscaling-Logik – für reines Linux-GPU-Training bleiben sie die richtige Wahl. Wer aber native macOS-Umgebung, Hochgeschwindigkeits-Cluster und flexible Tagesmiete kombinieren will, findet das TB5-Angebot bei ZilCloud derzeit kaum woanders. Ab $20,9/Tag plus $1,4/Tag für TB5 (= $22,3/Tag) sitzen Sie an einem 80-Gbps-Cluster-Knoten. Zwei Wochen Projekt, zwei Maschinen, danach abschalten – keine Bindung an ungenutzte Ressourcen.