Test de cluster Thunderbolt 5 : jusqu'où peut-on accélérer plusieurs Mac mini en réseau ?

Quand un Mac mini suffit — et quand ce n'est plus le cas

Un Mac mini M4 (CPU 10 cœurs, 16 Go de mémoire unifiée) archive un projet SwiftUI de taille moyenne en environ quatre minutes — largement suffisant pour un développeur indé ou une petite équipe avec quelques builds par jour. La douleur apparaît dans trois scénarios récurrents :

D'abord, les matrices multi-scheme / multi-apps : un monorepo doit compiler l'app principale, la Watch, le Widget et les variantes Debug/Release. Une seule machine les enchaîne en série, et le temps réel croît linéairement avec le nombre de cibles. Ensuite, les caches de compilation partagés : pousser DerivedData ou les caches SPM d'un runner vers les autres via le port public à 1 Gbps transforme une sync de plusieurs gigaoctets en pénalité d'une minute ou plus. Enfin, les shards d'inférence ou de rendu distribués : les machines échangent souvent des artefacts intermédiaires, et la latence Ethernet plus les plafonds de bande passante frappent avant le CPU.

Cet article ne discute pas de savoir s'il faut louer un Mac cloud (les pages tarifaires couvrent ce sujet). Il répond à une question précise : après liaison Thunderbolt 5 au même nœud de datacenter, à quelle vitesse peuvent aller les chemins de données entre machines — et qu'est-ce que cela implique pour le temps réel des builds parallèles ?

Ce que relie réellement la liaison Thunderbolt 5

Clarifions une idée reçue : la liaison TB5 ne fusionne pas trois CPU en un « super Mac », et ne lance pas de compilateur distribué transparent. Elle fournit une interconnexion physique haut débit entre machines de la même région — nominellement 80 Gbps, bien au-dessus du lien public 1 Gbps de chaque hôte.

Chez ZovCloud, la liaison ne fonctionne qu'entre instances au même nœud de datacenter : impossible de relier Singapour et Tokyo en TB5. Après provisionnement, le datacenter câble Thunderbolt et configure le pont ; macOS affiche une interface Thunderbolt Bridge / pont haut débit pour TCP, montage SMB/NFS ou caches d'objets.

Le modèle de valeur est simple : les CPU restent planifiés indépendamment ; le coût de déplacement des données entre hôtes chute fortement. Si votre pipeline ne synchronise jamais de gros artefacts entre machines — chaque runner clone, compile et envoie seul vers l'object storage — le gain sera faible et l'option liaison n'en vaut pas la peine.

Topologie et préparation : le lien est-il réel ?

Nous avons utilisé un triangle contrôleur + deux workers : node-a pour le scheduling et la collecte d'artefacts, node-b / node-c comme workers de build parallèle. Après paiement de l'option TB5 (ou activation depuis la console sur des instances en cours), les interfaces pont Thunderbolt sont apparues en quelques minutes. Avant tout benchmark, ces trois vérifications — sinon vous mesurez peut-être du simple Ethernet.

1. 01
   Vérifier les interfaces pont

   Sur chaque hôte : ifconfig ou Réglages système → Réseau. Thunderbolt Bridge (ou pont nommé par le DC) avec IP privée sur le même sous-réseau.

2. 02
   Ping bidirectionnel et contrôle MTU

   ping -c 20 entre toutes les paires. RTT sous la milliseconde à ~1 ms. Jitter de plusieurs ms : trafic peut-être encore sur le chemin public — inspecter les tables de routage.

3. 03
   Épingler le trafic de sync sur les IP TB

   Pointer les scripts de build vers les adresses du sous-réseau pont, pas l'IPv4 publique, pour que rsync / SMB ne retombe pas silencieusement sur le lien 1 Gbps.

Débit : TB5 vs chemins publics à 1 Gbps

Premier tour : iperf3 en débit TCP unidirectionnel. Référence : IPv4 publique de chaque machine vers les autres (switch en baie, plafond 1 Gbps par port dédié). Chemin test : sous-réseau privé Thunderbolt Bridge. 60 secondes par run, trois répétitions, médiane rapportée.

Le TCP en espace utilisateur atteint rarement les 80 Gbps théoriques — overhead protocole et planification mono-flux ; notre test était mémoire à mémoire, pas limité par le disque. En pratique, « une à deux ordres de grandeur plus rapide que 1 Gbps » suffit à changer la stratégie de sync : des caches multi-gigaoctets autrefois delta-compressés peuvent être poussés en entier, avec des scripts plus simples.

Gros fichiers et caches partagés : où le temps réel gagne

De beaux chiffres de débit ne garantissent pas des pipelines plus rapides si vous ne déplacez pas de gros blobs. Nous avons synchronisé un snapshot DerivedData de 8,4 Go (Module Cache + intermédiaires) via SMB, et récupéré un .xcarchive de 2,1 Go vers le contrôleur.

Conclusion : toute étape qui déplace des artefacts de l'ordre du gigaoctet entre hôtes voit le temps de sync s'effondrer avec TB5. Si chaque machine fait son git clone, récupère les dépendances et envoie vers l'object storage sans trafic pair à pair, l'accélération tend vers zéro — l'option liaison est gaspillée.

Archive parallèle : jusqu'où peut descendre le temps réel ?

Deuxième tour, proche du CI : même commit, trois schemes (app principale Release, Widget Release, Watch Release) chacun avec xcodebuild archive sur un worker distinct ; référence : trois Archives en série sur une machine. Le contrôleur a distribué les snapshots sources via TB5, collecté les artefacts et fait une validation légère. Trois runs par config, médiane retenue.

Temps réel parallèle : 4:18 — proche du scheme le plus lent seul (Archive app principale ~4:05) plus ~9 secondes de push source/cache et pull d'artefacts. En 1 Gbps, la sync seule ajoute plus d'une minute, absorbant l'essentiel du gain parallèle.

L'accélération n'est pas linéaire « trois machines = 3× ». Durées de scheme inégales, déverrouillage de certificats et courses SPM laissent le temps réel au maillon le plus lent. Le rôle de TB5 est de réduire dispatch et collecte de minutes à secondes pour que le parallélisme paie ; le gain CPU vient de plusieurs hôtes physiques qui calculent en même temps — pas de câbles qui accélèrent magiquement une compile Swift mono-cœur.

Pièges que nous avons vraiment rencontrés

1. Scripts de sync sur la mauvaise interface. Premier iperf à « seulement 900 Mbps » : les scripts utilisaient les IP publiques. Passage au sous-réseau pont : immédiatement au-delà de 50 Gbps. Définir explicitement CLUSTER_IFACE et PEER_TB_IP dans les variables CI.

2. La signature SMB plafonne le débit. Le SMB macOS par défaut peut saturer le CPU avant la bande passante sur des liens rapides. Ajuster la signature pour de courts benchmarks ; en production, arbitrer sécurité vs vitesse, ou rsync via SSH lié aux IP TB pour les répertoires de cache.

3. Keychain et signature par hôte. La liaison ne résout pas les certificats. Chaque worker a besoin des certificats Distribution et du déverrouillage configurés. Nous avons réutilisé l'automatisation mais gardé les clés par machine — pas de répertoire keychain partagé pour éviter la corruption concurrente.

4. Le disque avant le réseau. Des volumes système 256 Go sous écritures DerivedData simultanées ont parfois augmenté l'I/O wait. Les gros monorepos avec batches nocturnes lourds devraient ajouter l'extension SSD +1 To / +2 To avant plus de nœuds liés — TB5 n'aide pas si les disques locaux ne suivent pas.

Quand TB5 vaut le coup — et quand s'en passer

Condenser les benchmarks en tableau de décision avant d'acheter sur « 80 Gbps » seul :

Tarifs : nœuds de base ZovCloud à partir de 19,8 $/jour, 53,5 $/semaine, 99,1 $/mois, 269,6 $/trimestre ; option liaison Thunderbolt 5 à partir de 1,8 $/jour, 4,9 $/semaine, 9,1 $/mois, 24,8 $/trimestre. Trois hôtes mensuels plus liaison conviennent aux équipes dont les files sont clairement bloquées par sync et builds sériels ; les pics de release peuvent activer la liaison à la journée et la couper après les tests — sans acheter cuivre et switches en datacenter.

Du benchmark à la production : clusters cloud dédiés

Auto-héberger trois Mac mini liés au bureau peut donner un débit similaire, mais rack, câblage, coupures de courant, IP publiques fixes, rotation de certificats et astreinte nocturne restent à votre charge. Pour beaucoup d'équipes mobile, cette charge ops est le vrai frein — pas la capacité à lancer iperf3.

Les maillages de VM Linux rapides échouent au portillon toolchain Apple : sans macOS complet, pas de chemin légitime xcodebuild / codesign / TestFlight. Les hôtes macOS partagés sursouscrits font jitter mémoire et disque sous builds parallèles, effondrant la « parallélisation théorique ».

ZovCloud maintient chaque hôte comme un Mac mini M4 physique dédié (10 cœurs, 16 Go, bande passante dédiée 1 Gbps, droits admin complets). Quand il faut de la vitesse inter-hôtes, activez la liaison Thunderbolt 5 dans la même région pour un chemin physique 80 Gbps ; provisionnement en 1–5 minutes après paiement, régions Singapour, Japon (Tokyo), Corée (Séoul), Hong Kong et USA Est. VNC navigateur, SSH et clients VNC tiers fonctionnent ; le montage runner est identique à l'hôte unique — ajoutez seulement les IP pont pour la sync.

1. 01
   Définir d'abord le découpage parallèle

   Par app / scheme / plateforme ; confirmer que chaque machine a une cible Archive indépendante avant de dimensionner le cluster.

2. 02
   Commander des hôtes même région avec TB5

   Sur la page de commande, choisir plusieurs instances dans une région et cocher Thunderbolt 5 ; détails sous options tarifaires.

3. 03
   Lier les IP pont, puis attacher les runners

   Après vérification de préparation, router sync cache et collecte d'artefacts sur le sous-réseau TB ; réserver le port public pour git, object storage et releases.

La liaison Thunderbolt 5 résout comment déplacer vite les données entre de vrais Mac — pas comment faire passer une machine pour trois. Quand les builds matriciels et la sync de cache dominent déjà le temps réel, des clusters dédiés même région à 80 Gbps battent souvent des files mono-hôte plus longues ; si vous êtes encore sur une app unique avec releases peu fréquentes, un nœud M4 dédié stable est en général le meilleur investissement.