Thunderbolt 5 Cluster Benchmark: How Much Faster Is a Multi-Mac mini Network?

When one machine is enough—and when TB5 clustering matters

Many teams' first cloud Mac already covers daily iOS builds: one M4, 16 GB RAM, full Archive in three or four minutes. The bottleneck is usually parallelism, not single-core speed— you have 6 app targets, 3 extensions, and 2 widgets, but CI scripts queue on one runner; or your monorepo's Swift Package graph is huge, a clean build exceeds 15 minutes, and every runner needs tens of GB of DerivedData and source snapshots synced.

The obvious fix is "spin up more cloud Macs, each running its own job." That works in theory, but if machines only talk over separate 1 Gbps public ports, syncing a 40 GB workspace can take 6–8 minutes— eating the gains from parallel runs. Thunderbolt 5 clustering addresses the data plane between machines in the same rack: PixVPS physically links Mac minis at the same node with TB5 cables, rated at 80 Gbps, so build-farm nodes can sync artifacts and dispatch work without saturating public egress.

One clarification up front: TB5 does not add CPU cores to a single box, and it does not "merge three M4s into a 30-core machine." It speeds up data transfer and job orchestration when machines cooperate. If your pain is "one machine compiles too slowly," TB5 will not help much; if your pain is "copying caches between machines is slow" or "overnight batch builds never finish," TB5 is the right lever.

80 Gbps physical link vs 1 Gbps public: what actually changes

Every PixVPS Mac mini has its own public IPv4 and 1 Gbps port—fine for SSH, VNC, and TestFlight uploads. When machine A pushes a 30 GB DerivedData folder to machine B for an incremental build, routing over the public internet means data leaves the rack and comes back. Theoretical cap is ~125 MB/s; in practice, TCP window and disk write limits held us at 108–112 MB/s—about 4 minutes 30 seconds for 30 GB.

TB5 clustering creates a dedicated in-rack data path. In System Information, the interconnect shows as a Thunderbolt 5 bridge (bridge0 or a dedicated en* interface), separate from public en0. We ran 60-second iperf3 TCP tests between nodes 1 and 2: one-way mean 58.4 Gbps (~7.3 GB/s), bidirectional total ~94 Gbps; rsync of 30 GB mixed-size files (DerivedData-like layout) took 42 seconds— roughly 6.4× faster than the public path.

58 Gbps below the 80 Gbps headline is normal: protocol overhead, CPU soft interrupts, and NVMe sustained write (~2.8 GB/s sequential per drive) all cap real throughput. In build-farm workloads, the bottleneck often shifts from "network" to "disk I/O" or "single-threaded linker"— which is why Xcode parallel tests below did not scale linearly to 3×.

Post-provisioning checklist: what you should see in macOS

On the order page, check "Thunderbolt 5 multi-machine clustering" ($1.9/day, $9.5/month) and ensure every instance in the same node and order batch has the option enabled. PixVPS completes physical wiring in-rack; after SSH login, verify interconnect with these steps.

1. 01
   Confirm the TB5 bridge interface exists

   On each machine run networksetup -listallhardwareports—you should see Thunderbolt Bridge or a dedicated TB port. Run ifconfig to find the interconnect subnet IP (often 169.254.x.x or an internal range; use what the console assigns).

2. 02
   Ping peers and quick bandwidth test

   From node A: ping -c 10 <node B TB IP>—latency should be < 1 ms. After brew install iperf3, run iperf3 -s on B and iperf3 -c <B TB IP> -t 30 on A; throughput should be tens of Gbps.

3. 03
   Set up SSH over TB only

   In ~/.ssh/config, add Host aliases with Hostname set to TB internal IPs so large syncs never touch public routes. Example: Host m4-node2 → Hostname 10.20.0.12 (use IPs from console "Cluster interconnect info").

4. 04
   Mount shared artifact dirs (optional)

   Simplest path: scheduled rsync --delete for DerivedData; advanced options include NFS over TB or read-only sshfs. We used "primary node builds + rsync push increments"—lowest scripting cost.

Test 1: overnight multi-app matrix parallel Archive

Scenario: a team with 4 independent apps wants all Release Archives done within 30 minutes. Single-machine serial: 4 schemes run xcodebuild archive one after another, ~3m48s clean build each, total 15m12s—before Export and upload.

Three-node strategy: GitHub Actions matrix splits 4 schemes across 3 runners (2+1+1), each checking out code and signing independently—no shared DerivedData. Wall-clock follows the slowest runner: 4m05s (one scheme spent 17 extra seconds on Swift Package resolution). Roughly 73% less wait vs serial.

This scenario barely uses TB5 bandwidth—builds do not exchange large files; value is "same order batch, same rack, low-latency scheduling," not data movement. If you have 2 apps and ship monthly, 3 machines + TB5 is overkill; with 5+ targets and nightly batch builds, matrix parallelism pays off.

Test 2: monorepo DerivedData incremental sync

This scenario highlights TB5 bandwidth: after the primary node completes a full build, sync 28 GB DerivedData to two secondary nodes that run incremental compiles for their framework targets only.

Flow: node 1 clean archive (3m52s) → rsync -avz --progress -e ssh ~/Library/Developer/Xcode/DerivedData/MyMonorepo-* m4-node2:~/cache/ → nodes 2 and 3 parallel incremental archive for assigned framework targets.

TB5 saves ~3m40s on sync alone; end-to-end is nearly 5 minutes faster than single-machine serial. With larger DerivedData (50 GB+) or more frequent sync (every PR pushing cache), the gap widens. This is why we recommend TB5 for teams that share build caches across cooperating machines.

Test 3: distcc trial vs reality

We tried distcc across three M4s: primary dispatches preprocessed compile units, secondaries return .o files. Theory says ~3× speedup; clean build only dropped from 3m52s to 2m34s (~1.5×)—far from linear.

Reasons are straightforward: Xcode's modern build system enables Swift explicit modules and heavy parallelism; a single M4 already saturates 10 cores. distcc adds remote scheduling, header sync, and link steps back on the primary— eating gains. Swift compile units also respect module dependency order; unlike pure C projects, you cannot slice freely.

Takeaway: for typical iOS/Swift work, "each machine runs independent jobs" beats "distcc splitting one xcodebuild." TB5's value is getting consistent source and cache to each node fast—not forcing one build across multiple CPUs. If your stack is mature C/C++ with Makefiles, distcc may still help; do not expect 3× on large SwiftUI repos.

Pitfalls: wired correctly but still slow?

During testing we hit cases that "looked clustered" but performed like public internet. Checklist:

rsync used a public IP. If SSH config Host aliases still point at public addresses, 30 GB syncs return to ~4-minute territory. Run ssh -v m4-node2 and confirm the target IP is on the TB subnet.

Disk write became the bottleneck. Three machines writing NVMe simultaneously can drop sustained write to ~1.5 GB/s; iperf3 still shows high bandwidth but rsync end-to-end slows. Stagger syncs or use incremental dirs (--link-dest).

Firewall or Little Snitch blocked the TB interface. Some security tools block bridge traffic by default— temporarily allow Thunderbolt Bridge and retest iperf3.

Nodes were not in the same order batch. TB5 clustering only applies to instances at the same node with clustering enabled in the same batch; cross-region pairs (e.g. Singapore + Tokyo) cannot TB-link—public internet only, so skip the TB5 add-on.

When TB5 clustering is worth the add-on

Back to the headline: how much faster is a multi-Mac mini network? Across our three tests, the answer depends on workflow shape— pure matrix parallelism (separate apps) can shrink wall-clock close to machine count; monorepos sharing caches gain most when TB5 cuts sync from minutes to seconds; distcc on Swift projects delivers modest returns.

If one cloud Mac handles daily CI, the standard M4 ($21.1/day, 16 GB RAM, 1 Gbps dedicated) is enough—no TB5 fee. Add TB5 ($1.9/day / $9.5/month) when you run at least 2 instances at the same node, overnight batch builds exceed 30 minutes total, or nodes frequently sync 10 GB+ DerivedData / SPM caches.

PixVPS offers the same hardware and clustering at five regions—Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, China, and US East—delivered in 1–5 minutes per machine; cluster batches get TB wiring in-rack. Check TB5 clustering on the order page to place machines in the same interconnect domain; you can also add the service later from the console for existing instances (see Help Center). 24/7 human support with ticket replies within one hour; cluster topology and internal IPs appear under "Cluster interconnect info."

Build-farm economics are simple: parallelism × single-machine speed − coordination overhead = real gain. Thunderbolt 5 clustering cuts the biggest chunk of overhead—waiting on large-file sync. Split work into parallel independent jobs first, then use TB5 to accelerate cache distribution—that beats blindly adding machines.