Test de cluster Thunderbolt 5 : à quelle vitesse un réseau de plusieurs Mac mini peut-il aller ?

Quand une machine suffit — et quand le clustering TB5 compte

Le premier Mac cloud de beaucoup d'équipes couvre déjà les builds iOS quotidiens : un M4, 16 Go de RAM, un Archive complet en trois ou quatre minutes. Le goulot d'étranglement est souvent le parallélisme, pas la vitesse d'un seul cœur — vous avez 6 cibles app, 3 extensions et 2 widgets, mais les scripts CI s'alignent sur un seul runner ; ou le graphe Swift Package de votre monorepo est énorme, un build propre dépasse 15 minutes, et chaque runner doit synchroniser des dizaines de Go de DerivedData et d'instantanés de sources.

La solution évidente : « louer plus de Mac cloud, chacun exécutant son propre job ». En théorie, ça marche ; mais si les machines ne communiquent que via des ports publics 1 Gbps séparés, synchroniser un workspace de 40 Go peut prendre 6 à 8 minutes — annulant les gains du parallélisme. Le clustering Thunderbolt 5 cible le plan de données entre machines dans le même rack : PixVPS relie physiquement les Mac mini du même nœud par câbles TB5, annoncés à 80 Gbps, pour que les nœuds d'une ferme de compilation synchronisent artefacts et dispatch de jobs sans saturer la sortie publique.

Une précision d'emblée : le TB5 n'ajoute pas de cœurs CPU à une seule boîte, et ne « fusionne » pas trois M4 en une machine 30 cœurs. Il accélère le transfert de données et l'orchestration lorsque les machines coopèrent. Si votre problème est « une machine compile trop lentement », le TB5 n'aidera guère ; si c'est « copier les caches entre machines est lent » ou « les builds batch nocturnes ne finissent jamais », le TB5 est le bon levier.

Liaison physique 80 Gbps vs public 1 Gbps : ce qui change vraiment

Chaque Mac mini PixVPS a sa propre IPv4 publique et son port 1 Gbps — suffisant pour SSH, VNC et les uploads TestFlight. Quand la machine A pousse un dossier DerivedData de 30 Go vers la machine B pour un build incrémental, router via Internet public signifie que les données sortent du rack et reviennent. Plafond théorique ~125 Mo/s ; en pratique, fenêtre TCP et limites d'écriture disque nous ont maintenus à 108–112 Mo/s — environ 4 minutes 30 pour 30 Go.

Le clustering TB5 crée un chemin de données dédié en rack. Dans Informations système, l'interconnexion apparaît comme un pont Thunderbolt 5 (bridge0 ou une interface en* dédiée), distincte du en0 public. Nous avons exécuté des tests TCP iperf3 de 60 secondes entre les nœuds 1 et 2 : moyenne unidirectionnelle 58,4 Gbps (~7,3 Go/s), total bidirectionnel ~94 Gbps ; rsync de 30 Go de fichiers de tailles mixtes (structure type DerivedData) a pris 42 secondes — environ 6,4× plus rapide que le chemin public.

58 Gbps sous les 80 Gbps annoncés est normal : overhead protocole, interruptions logicielles CPU, et écriture NVMe soutenue (~2,8 Go/s séquentiel par disque) plafonnent le débit réel. En charge ferme de compilation, le goulot passe souvent du « réseau » vers « I/O disque » ou « éditeur de liens mono-thread » — d'où les tests Xcode parallèles ci-dessous n'ont pas mis à l'échelle linéairement en 3×.

Checklist post-livraison : ce que vous devez voir dans macOS

Sur la page de commande, cochez « Clustering multi-machines Thunderbolt 5 » ($1,9/jour, $9,5/mois) et assurez-vous que chaque instance du même nœud et du même lot de commande a l'option activée. PixVPS termine le câblage physique en rack ; après connexion SSH, vérifiez l'interconnexion avec ces étapes.

1. 01
   Confirmer l'interface pont TB5

   Sur chaque machine, exécutez networksetup -listallhardwareports — vous devez voir Thunderbolt Bridge ou un port TB dédié. Lancez ifconfig pour trouver l'IP du sous-réseau d'interconnexion (souvent 169.254.x.x ou une plage interne ; utilisez ce que la console assigne).

2. 02
   Ping des pairs et test de bande passante rapide

   Depuis le nœud A : ping -c 10 <IP TB nœud B> — latence < 1 ms. Après brew install iperf3, lancez iperf3 -s sur B et iperf3 -c <IP TB B> -t 30 sur A ; le débit doit atteindre des dizaines de Gbps.

3. 03
   Configurer SSH uniquement via TB

   Dans ~/.ssh/config, ajoutez des alias Host avec Hostname sur les IP internes TB pour que les grosses syncs ne passent jamais par les routes publiques. Exemple : Host m4-node2 → Hostname 10.20.0.12 (utilisez les IP de la console « Infos interconnexion cluster »).

4. 04
   Monter des répertoires d'artefacts partagés (optionnel)

   Chemin le plus simple : rsync --delete planifié pour DerivedData ; options avancées : NFS sur TB ou sshfs en lecture seule. Nous avons utilisé « nœud primaire build + push incréments rsync » — coût de script minimal.

Test 1 : matrice multi-apps Archive parallèle nocturne

Scénario : une équipe avec 4 apps indépendantes veut tous les Archives Release en moins de 30 minutes. Série sur une machine : 4 schémas exécutent xcodebuild archive l'un après l'autre, ~3m48s de build propre chacun, total 15m12s — avant Export et upload.

Stratégie trois nœuds : la matrice GitHub Actions répartit 4 schémas sur 3 runners (2+1+1), chacun checkout et signature indépendants — pas de DerivedData partagé. Le temps mur suit le runner le plus lent : 4m05s (un schéma a passé 17 secondes de plus en résolution Swift Package). Environ 73 % d'attente en moins vs série.

Ce scénario utilise à peine la bande passante TB5 — les builds n'échangent pas de gros fichiers ; la valeur est « même lot de commande, même rack, planification à faible latence », pas le mouvement de données. Si vous avez 2 apps et livrez mensuellement, 3 machines + TB5 est excessif ; avec 5+ cibles et builds batch nocturnes, le parallélisme matriciel paie.

Test 2 : synchronisation incrémentale DerivedData monorepo

Ce scénario met en avant la bande passante TB5 : après le build complet sur le nœud primaire, synchroniser 28 Go de DerivedData vers deux nœuds secondaires qui exécutent des compiles incrémentaux pour leurs cibles framework uniquement.

Flux : nœud 1 archive propre (3m52s) → rsync -avz --progress -e ssh ~/Library/Developer/Xcode/DerivedData/MyMonorepo-* m4-node2:~/cache/ → nœuds 2 et 3 archive incrémental parallèle pour les cibles framework assignées.

Le TB5 économise ~3m40s sur la sync seule ; bout en bout, près de 5 minutes de plus rapide que la série mono-machine. Avec un DerivedData plus volumineux (50 Go+) ou des sync plus fréquentes (chaque PR poussant le cache), l'écart s'élargit. C'est pourquoi nous recommandons le TB5 aux équipes qui partagent des caches de build entre machines coopérantes.

Test 3 : essai distcc vs réalité

Nous avons testé distcc sur trois M4 : le primaire dispatch les unités de compilation prétraitées, les secondaires renvoient les fichiers .o. La théorie promet ~3× d'accélération ; le build propre n'est passé que de 3m52s à 2m34s (~1,5×) — loin du linéaire.

Les raisons sont simples : le système de build moderne de Xcode active les modules Swift explicites et un fort parallélisme ; un seul M4 sature déjà les 10 cœurs. distcc ajoute planification distante, sync d'en-têtes et étapes de lien sur le primaire — grignotant les gains. Les unités Swift respectent aussi l'ordre des dépendances de modules ; contrairement aux projets C purs, on ne peut pas découper librement.

Conclusion : pour le travail iOS/Swift typique, « chaque machine exécute des jobs indépendants » bat « distcc découpant un seul xcodebuild ». La valeur du TB5 est d'amener source et cache à chaque nœud rapidement — pas de forcer un build sur plusieurs CPU. Si votre stack est du C/C++ mature avec Makefiles, distcc peut encore aider ; n'attendez pas 3× sur de gros repos SwiftUI.

Pièges : câblé correctement mais toujours lent ?

Pendant les tests, nous avons rencontré des cas qui « semblaient clusterisés » mais performaient comme Internet public. Checklist :

rsync a utilisé une IP publique. Si les alias Host SSH pointent encore vers des adresses publiques, les sync de 30 Go reviennent vers ~4 minutes. Lancez ssh -v m4-node2 et confirmez que l'IP cible est sur le sous-réseau TB.

Le disque est devenu le goulot. Trois machines écrivant sur NVMe simultanément peuvent faire chuter l'écriture soutenue à ~1,5 Go/s ; iperf3 affiche encore une haute bande passante mais rsync bout en bout ralentit. Décalez les syncs ou utilisez des répertoires incrémentaux (--link-dest).

Pare-feu ou Little Snitch a bloqué l'interface TB. Certains outils de sécurité bloquent le trafic pont par défaut — autorisez temporairement Thunderbolt Bridge et retestez iperf3.

Les nœuds n'étaient pas dans le même lot de commande. Le clustering TB5 ne s'applique qu'aux instances du même nœud avec clustering activé dans le même lot ; les paires inter-régions (ex. Singapour + Tokyo) ne peuvent pas être reliées en TB — Internet public uniquement, donc passez l'option TB5.

Quand le clustering TB5 vaut l'option

Retour au titre : à quelle vitesse un réseau de plusieurs Mac mini peut-il aller ? Sur nos trois tests, la réponse dépend de la forme du workflow — le parallélisme matriciel pur (apps séparées) peut réduire le temps mur proche du nombre de machines ; les monorepos partageant des caches gagnent le plus quand le TB5 ramène la sync de minutes à secondes ; distcc sur projets Swift offre des retours modestes.

Si un Mac cloud gère votre CI quotidienne, le M4 standard ($21,1/jour, 16 Go RAM, 1 Gbps dédié) suffit — pas de frais TB5. Ajoutez le TB5 ($1,9/jour / $9,5/mois) lorsque vous exécutez au moins 2 instances sur le même nœud, que les builds batch nocturnes dépassent 30 minutes au total, ou que les nœuds synchronisent fréquemment 10 Go+ de DerivedData / caches SPM.

PixVPS propose le même matériel et clustering dans cinq régions — Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et États-Unis (Est) — livré en 1 à 5 minutes par machine ; les lots cluster reçoivent le câblage TB en rack. Cochez le clustering TB5 sur la page de commande pour placer les machines dans le même domaine d'interconnexion ; vous pouvez aussi ajouter le service plus tard depuis la console pour des instances existantes (voir le Centre d'aide). Support humain 7×24 avec réponse ticket sous une heure ; topologie cluster et IP internes sous « Infos interconnexion cluster ».

L'économie d'une ferme de compilation est simple : parallélisme × vitesse mono-machine − overhead de coordination = gain réel. Le clustering Thunderbolt 5 réduit la plus grosse part d'overhead — attendre la synchronisation de gros fichiers. Découpez d'abord le travail en jobs parallèles indépendants, puis utilisez le TB5 pour accélérer la distribution des caches — mieux que d'ajouter des machines à l'aveugle.