Thunderbolt-5-Cluster im Praxistest: Wie viel schneller ist ein Multi-Mac-mini-Netzwerk?

Eine Maschine reicht – warum überhaupt TB5 Parallel?

Viele Teams decken tägliche iOS-Builds mit dem ersten Cloud-Mac ab: M4, 16 GB RAM, vollständiges Archive in 3–4 Minuten. Der Engpass liegt oft bei der Parallelität, nicht bei der Einzel-CPU – 6 App-Targets, 3 Extensions, 2 Widgets, aber das CI-Skript serialisiert auf einer Maschine; oder ein Monorepo mit riesigem Swift-Package-Graphen braucht über 15 Minuten Clean Build, und jeder Runner muss Dutzende GB DerivedData und Quell-Snapshots synchronisieren.

Die naheliegende Antwort: mehrere Cloud-Macs mieten und Jobs aufteilen. Logisch korrekt – wenn die Maschinen aber nur über jeweils 1 Gbps öffentliches Netz Build-Caches austauschen, kostet das Sync eines 40-GB-Workspace 6–8 Minuten und frisst den Parallelitätsgewinn auf. Thunderbolt 5 Parallel adressiert die Datenebene zwischen Maschinen im selben Rack: PixVPS verbindet mehrere Mac mini im selben Node per TB5-Kabel, nominell 80 Gbps, damit Sync und Task-Verteilung in der Compile-Farm nicht den öffentlichen Uplink blockieren.

Wichtig vorab: TB5 erhöht nicht die Kernzahl einer Maschine und „verschmilzt“ drei M4 nicht zu einem 30-Kern-System. Es beschleunigt Datentransfer und Scheduling bei Multi-Maschinen-Kooperation. Schmerzpunkt „eine Maschine kompiliert zu langsam“ → TB5 hilft wenig. Schmerzpunkt „Cache-Kopien zwischen Maschinen dauern ewig, Nacht-Batch-Gesamtzeit sinkt nicht“ → TB5 trifft den Kern.

80 Gbps physisch vs. 1 Gbps öffentlich: der Unterschied

Jeder PixVPS Mac mini hat eigene öffentliche IPv4 und 1 Gbps – ideal für SSH, VNC, TestFlight-Upload. Wenn Maschine A 30 GB DerivedData an Maschine B für einen inkrementellen Build schickt, geht der Traffic über das öffentliche Netz erst aus dem Rack und zurück. Theoretisch ~125 MB/s, praktisch stabil 108–112 MB/s – 30 GB in etwa 4 Minuten 30 Sekunden.

TB5 Parallel schafft einen dedizierten Datenkanal im Rack. In den Systeminformationen erscheint der Interconnect als Thunderbolt-5-Bridge (bridge0 oder dediziertes en*), getrennt von en0. iperf3 60 Sekunden TCP zwischen Node 1 und 2: Einweg-Mittel 58,4 Gbps (~7,3 GB/s), beidseitig zusammen ~94 Gbps. rsync für 30 GB gemischte Dateigrößen (DerivedData-Struktur): 42 Sekunden – etwa 6,4× schneller als direkt über öffentliches Netz.

58 Gbps unter 80 Gbps nominal ist normal: Protokoll-Overhead, CPU-Soft-Interrupts und NVMe-Dauerwrite (~2,8 GB/s sequenziell) begrenzen gemeinsam. In Compile-Farm-Szenarien wandert der Engpass oft von „Netzwerk“ zu „Disk I/O“ oder „Linker Single-Thread“ – deshalb erreichen die Xcode-Paralleltests später kein lineares 3×.

Abnahme nach Aktivierung: was im System sichtbar sein muss

Auf der Konfigurationsseite „Thunderbolt 5 Multi-Maschinen-Parallel“ aktivieren (ab $1,9/Tag, $9,5/Monat) und sicherstellen, dass alle Instanzen im selben Node und derselben Bestellcharge die Option haben. PixVPS verkabelt physisch im Rack; nach Login die Schritte zur Abnahme:

1. 01
   TB5-Bridge-Interface prüfen

   Auf jeder Maschine networksetup -listallhardwareports – Thunderbolt Bridge oder dediziertes TB-Interface muss erscheinen. Mit ifconfig die Interconnect-IP finden (meist 169.254.x.x oder DC-Interna, je nach Zuweisung).

2. 02
   Ping und schneller Bandbreitentest

   Von Node A: ping -c 10 <TB-IP von Node B>, Latenz < 1 ms. Nach brew install iperf3: auf B iperf3 -s, auf A iperf3 -c <TB-IP von B> -t 30 – Durchsatz im Zehner-Gbps-Bereich.

3. 03
   SSH-Vertrauen (nur TB-Interna)

   In ~/.ssh/config Host-Aliase für Cluster-Nodes, Hostname = TB-Interna-IP, damit große Syncs nicht über öffentliches Netz laufen. Beispiel: Host m4-node2 → Hostname 10.20.0.12 (IP laut Konsole „Cluster-Interconnect-Info“).

4. 04
   Gemeinsames Artefakt-Verzeichnis (optional)

   Einfach: rsync --delete für periodisches DerivedData-Sync. Fortgeschritten: NFS over TB oder sshfs read-only. Unser Test: „Master baut + rsync pusht Inkremente“ – geringster Skript-Aufwand.

Test 1: nächtliche Multi-App-Matrix parallel archivieren

Szenario: Team mit 4 unabhängigen Apps will alle Release Archives in 30 Minuten. Serial auf einer Maschine: 4 Schemes nacheinander xcodebuild archive, je Clean Build ~3:48, gesamt 15:12 (ohne Export/Upload).

Drei-Maschinen-Strategie: GitHub Actions matrix verteilt 4 Schemes auf 3 Runner (2+1+1). Jede Maschine checkt Code und Signierung eigenständig aus, kein geteiltes DerivedData. Wanduhr-Zeit = langsamster Runner: 4:05 (langsamstes Scheme +17 s Swift-Package-Auflösung). Gegenüber Serial ~73 % weniger Wartezeit.

Hier verbraucht man kaum TB5-Bandbreite – keine großen Dateitransfers zwischen Builds. Der Wert liegt in „gleiche Bestellcharge, gleiches Rack, niedrige Scheduling-Latenz“. 2 Apps, monatlich ein Release → 3 Maschinen + TB5 ist Overkill; 5+ Targets mit täglichem Nacht-Batch → Matrix lohnt sich.

Test 2: Monorepo mit geteiltem DerivedData inkrementell syncen

Näher am TB5-Vorteil: Master macht ersten Full Build, synchronisiert 28 GB DerivedData auf zwei Slaves, die nur ihre Framework-Targets inkrementell bauen.

Ablauf: Node 1 Clean Archive (3:52) → rsync -avz --progress -e ssh ~/Library/Developer/Xcode/DerivedData/MyMonorepo-* m4-node2:~/cache/ → Node 2 und 3 parallel inkrementelles Archive je Framework-Target.

TB5 spart ~3:40 gegenüber öffentlichem Sync, Gesamtflow ~5 Minuten schneller als Serial. Bei 50+ GB DerivedData oder Sync pro PR wächst die Lücke weiter. Teams mit „Multi-Maschinen + geteiltem Build-Cache“ sollten TB5 priorisieren.

Test 3: distcc-Versuch und die Realität

Wir haben drei M4 per distcc für verteiltes C/Swift-Compile getestet: Master verteilt vorverarbeitete Units, Slaves liefern .o-Dateien. Theoretisch ~3×, praktisch Clean Build nur von 3:52 auf 2:34 (~1,5×).

Xcode’s neues Build-System nutzt Swift Explicit Modules und hohe Parallelität – ein M4 ist ohnehin voll ausgelastet. distcc bringt Remote-Scheduling, Header-Sync und Link zurück zum Master – das frisst Gewinn. Swift-Compile-Units haben Modul-Abhängigkeiten und lassen sich nicht frei wie reines C schneiden.

Fazit: Bei typischen iOS/Swift-Projekten ist „jede Maschine eigener Job“ pragmatischer als distcc auf einem Build. TB5 hilft, konsistente Quellen und Caches schnell zu verteilen – nicht, einen einzelnen xcodebuild künstlich auf mehrere CPUs zu zerreißen. Reines C/C++ mit ausgereiftem Makefile: distcc probieren; bei großen SwiftUI-Apps kein 3× erwarten.

Stolpersteine: verkabelt, aber Geschwindigkeit wie öffentliches Netz

Während der Tests: „sieht parallel aus, fühlt sich wie 1 Gbps an“. Kurz die häufigsten Ursachen:

rsync nutzt öffentliche IP. SSH-Host-Alias zeigt noch auf öffentliche Adresse → 30 GB wieder ~4 Minuten. Mit ssh -v m4-node2 prüfen, ob die Ziel-IP zur TB-Interna gehört.

Disk-Write wird Engpass. Drei gleichzeitige rsync-Writes auf NVMe können Dauerwrite auf ~1,5 GB/s fallen – iperf3 bleibt hoch, End-to-End-rsync nicht. Sync zeitversetzt oder nur Inkrement-Verzeichnisse (--link-dest).

Firewall oder Little Snitch blockiert TB-Interface. Selten blockieren Security-Tools Bridge-Traffic standardmäßig – temporär erlauben und iperf3 wiederholen.

Nodes nicht in derselben Bestellcharge. TB5 Parallel gilt nur für Instanzen im selben Node und Batch mit aktivierter Parallel-Option. Cross-Node (z. B. Singapur + Tokio) → kein TB, nur öffentliches Netz → TB5-Zusatz unnötig.

Wann lohnt sich TB5 Parallel?

Zurück zur Titelfrage: wie viel schneller wird ein Multi-Mac-mini-Netzwerk? In unseren drei Tests hängt die Antwort vom Workflow ab – reine Matrix-Parallelität (jede App separat) kann die Wanduhr-Zeit nahe an die Maschinenzahl annähern; Monorepos mit geteiltem Cache profitieren davon, dass TB5 Sync von Minuten auf Sekunden drückt; distcc auf einem Swift-Build bringt begrenzten Nutzen.

Reicht ein Cloud-Mac für tägliches CI, genügt Standard-M4 ($21,1/Tag, 16 GB, 1 Gbps dediziert) ohne TB5-Aufpreis. TB5 ($1,9/Tag / $9,5/Monat) lohnt bei: mindestens 2 Instanzen im selben Node, Nacht-Batch-Gesamtzeit über 30 Minuten, oder häufigem Sync von 10+ GB DerivedData/SPM-Cache zwischen Nodes.

PixVPS bietet identische Hardware und Parallel-Option in Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und USA Ost. Zahlung → Einzelinstanz in 1–5 Minuten; Cluster-Batch-TB-Verkabelung im Rechenzentrum. TB5 auf der Konfigurationsseite aktivieren – mehrere Maschinen landen in derselben Interconnect-Domain; nachträglich für laufende Instanzen möglich (siehe Hilfezentrum). 7×24 menschlicher Support, Tickets innerhalb einer Stunde. Topologie und Interna-IPs in der Konsole unter „Cluster-Interconnect-Info“.

Die Ökonomie einer Compile-Farm ist simpel: Parallelität × Einzelgeschwindigkeit − Kooperations-Overhead = realer Gewinn. Thunderbolt 5 Parallel schneidet den größten Kooperationskostenblock – Warten auf große Dateisyncs. Workflow zuerst in unabhängige Jobs zerlegen, dann TB5 für Cache-Verteilung – das verkürzt die Wanduhr-Zeit zuverlässiger als blind mehr Maschinen zu mieten.