Test réel d'un cluster Mac mini cloud : que vaut le 80 Gbps en parallèle Thunderbolt 5 ?

Quand une machine suffit — et quand le TB5 change la donne

Le clustering Thunderbolt 5 n'est pas un interrupteur qui accélère xcodebuild sur une cible isolée. Un M4 dédié avec 16 GB de mémoire unifiée fixe toujours le plafond d'un build complet seul. Le TB5 règle le plan de données entre machines : quand le CPU n'est plus le goulot, copier DerivedData, des .xcarchive ou des poids de modèle sur un WAN gigabit devient une taxe visible.

Trois scénarios revenaient sans cesse avant les tests — et c'est là que le TB5 paie :

• Ferme de build : même dépôt, plusieurs schemes (Debug interne, Release store, Archive Extension) en parallèle ;
• Sync d'artefacts volumineux : cache et sorties copiés entre workers, souvent des dizaines de Go par passage ;
• Inférence ou rendu distribué : shards de modèle exigeant une interconnexion proche de la bande passante mémoire, pas un uplink 1 Gbps partagé.

Trois hôtes parlant uniquement via IPv4 publique plafonnent autour de 125 Mo/s — 50 Go prennent six à sept minutes et rivalisent avec le reste du trafic. L'intérêt du TB5 : regrouper plusieurs Mac mini dans le même nœud SpinMac par un lien physique à 80 Gbps en LAN logique haut débit, et ramener l'attente collaborative de minutes à secondes.

Banc d'essai : trois boîtiers, une dorsale TB5

Toutes les mesures ont été faites sur SpinMac Singapour. Les équipes en Europe y accèdent avec une latence SSH raisonnable ; contrainte clé : le TB5 exige des machines sur le même nœud — Singapour plus Tokyo ne se maillent pas.

De la commande au lien actif : checklist de mise en service

Le TB5 est une option pour plusieurs instances du même groupe de commande sur un nœud. Pas de câbles ni de switch à acheter — SpinMac câble en baie.

1. 01
   Louer plusieurs hôtes et activer le TB5

   Sur la page de commande, nœud « Singapour », quantité 3, période au choix (nous avons pris $57,3/semaine/hôte). Cocher « Clustering multi-machines Thunderbolt 5 » — TB5 à +$4,1/semaine par machine. Après paiement, les trois hôtes sont prêts en 1 à 5 minutes ; la console affiche « cluster TB5 ».

2. 02
   Vérifier Thunderbolt Bridge dans macOS

   Après SSH, « Réglages système → Réseau » doit montrer un pont Thunderbolt avec adresse link-local 169.254.x.x. ifconfig bridge0 doit être active. Pont absent sur un hôte : provisioning en cours — ticket support (nous avons attendu ~8 min).

3. 03
   Fixer les noms d'hôte et la confiance SSH

   IPs côté TB5 et alias (mac-a, etc.) dans /etc/hosts, SSH par clé. iperf3 et rsync exclusivement sur le segment bridge — jamais les IP publiques.

4. 04
   Test de fumée

   Depuis mac-a : ping -c 5 169.254.x.x (adresse bridge de mac-b) — attendez 0,3–0,8 ms. Court iperf3, puis jobs de production.

Benchmark bande passante : à quelle distance de 80 Gbps ?

80 Gbps est une valeur nominale physique. Le débit réel dépend de l'overhead, des softirq, des réglages d'outils et de la topologie. iperf3 en flux unique et 8 flux parallèles, cinq passages chacun — médianes ci-dessous.

En clair : un snapshot DerivedData de 42 Go en scp public prend plus de six minutes ; en rsync sur TB5, la première copie complète tient sous vingt secondes, l'incrémental sous trois secondes. Dans une ferme de build, l'attente de cache passe du niveau « pause café » à « remplir un verre ».

À noter : le TB5 optimise le transport inter-nœuds, pas la durée d'un clean build isolé. Cible lente ? Vérifiez d'abord dépendances et modularisation. Douleur sur machines parallèles + gros cache partagé ? Le gain TB5 est net.

Workflows réels : builds Xcode et répartition CI

Les benchmarks doivent coller à votre flux de release. Deux scénarios contrôlés :

Expérience A : trois Archives parallèles, une source DerivedData

mac-a fait un build complet et produit DerivedData, pousse le cache vers mac-b et mac-c via TB5 ; les trois archivent des schemes différents (Debug interne, Release store, Notification Service Extension seul).

Sans TB5 (chaque hôte rebuild) : ~47 min horloge totales (14–16 min de build complet chacun).
Avec TB5 (un build + fan-out cache) : premier build 15 min 20 s, push cache 22 s, Archives parallèles 8 min 40 s, total 24 min 22 s — environ 48 % gagnés. Trois tours de release par jour, c'est des dizaines d'heures par semaine.

Expérience B : pool de runners self-hosted GitHub Actions

Trois enregistrements self-hosted (macos-m4-a/b/c). Matrix sépare tests unitaires et UI ; agréger 6,2 Go de .xcresult sur mac-a : 4 min 50 s en public, 41 s via TB5.

Installation runner, signature et TestFlight : voir notre guide CI/CD Xcode sur Mac cloud — pipeline mono-nœud ; cet article complète la couche d'interconnexion multi-machines.

Pièges rencontrés en conditions réelles

SpinMac fournit la physique et le réseau bridge — l'architecture applicative reste à vous.

• Topologie en chaîne : A–B–C donne A→C plus lent que A→B. Source de cache au centre (ici mac-b) pour syncs complètes sensibles à la latence.
• Le disque limite encore : trois arbres DerivedData sur 256 Go système, c'est serré. Extension SSD +1 To sur au moins un worker (+$12,5/mois), séparer cache et Archives.
• Stratégie de signature : Archives parallèles partout = certificats Distribution sur chaque trousseau — ou primary seul signe, workers en test seulement.
• Le TB5 ne remplace pas l'accès public : votre portable reste en SSH/VNC via IP publiques ; le segment TB5 est interne et non exposé Internet par conception.

Calcul des coûts : quand l'option TB5 vaut le coup

Tarif de base SpinMac identique sur les cinq régions (Singapour, Japon (Tokyo), Corée (Séoul), Hong Kong, US Est) : $21,2/jour, $57,3/semaine, $106,1/mois, $288,6/trimestre par machine. Clustering TB5 par hôte : +$1,5/jour, +$4,1/semaine, +$7,5/mois, +$20,4/trimestre. Exemple trois machines à la semaine :

Compute : 3 × $57,3 = $171,9/semaine
Option TB5 : 3 × $4,1 = $12,3/semaine (~7 % du compute)
Total $184,2/semaine — environ $26,3/jour pour trois nœuds M4 interconnectés.

Face à l'achat matériel : trois Mac mini M4 à partir de ~$1 800 plus câbles, baie, électricité — sans réduire à la demande. Face à « trois cloud sur WAN seul » : même coût machines, mais dès dix syncs de 40 Go par semaine, le temps d'attente dépasse souvent les $12,3 d'écart TB5.

Prendre le TB5 si : au moins deux hôtes sur le même nœud avec sync quotidienne d'artefacts ou cache volumineux ; ou matrices CI avec routinemment trois jobs macOS parallèles ou plus. Passer son tour si un seul hôte à long terme, ou DR multi-région — pas de TB5 inter-nœuds ; stockage objet compatible S3 pour caches de build.

Nouveau client : plusieurs hôtes et TB5 sur la page de commande. Instance unique existante : ajout du parallélisme depuis la console, sans migration de données.

Conclusion : 80 Gbps réduit la friction collaborative, pas le pic mono-machine

La question du titre — que vaut le 80 Gbps en parallèle Thunderbolt 5 ? En une phrase : plusieurs Mac mini communiquent sur le plan données comme des serveurs dans le même rack — iperf3 autour de 60–68 Gbps, gros fichiers de minutes à secondes ; un build Xcode complet isolé dure toujours pareil. La valeur du cluster est parallélisme et réutilisation de cache, pas un chip plus rapide.

Pour les clients SpinMac, l'option TB5 signifie : vous avez déjà choisi des Mac cloud physiques et voulez abaisser la friction du multi-machines — sans acheter de câbles, sans négocier avec la colo, une case sur le même nœud. Si votre équipe bloque sur « ferme de build oui, transferts inter-machines trop lents », utilisez chiffres et étapes ici comme checklist PoC.