Qu'est-ce que l'interconnexion Thunderbolt 5 ?
Sur la page de configuration ZilCloud, une option s'appelle « service cluster Thunderbolt 5 » : +1,4 $/jour ou +8,9 $/mois. Ma première réaction en la découvrant : à quoi ça sert concrètement ?
En bref : Thunderbolt 5 (TB5) est le standard d'interface qu'Apple a introduit sur le Mac mini M4. La bande passante théorique atteint 120 Gbps sur les voies PCIe ; en interconnexion directe entre machines, on obtient 80 Gbps bidirectionnels, soit environ 10 Go/s de débit — le double du TB4 (40 Gbps). Le service TB5 de ZilCloud relie physiquement deux Mac mini M4 cloud (ou plus) par câble TB5, formant un réseau local ultra-rapide transparent pour macOS.
Côté ingénierie, ce n'est pas simplement « deux machines branchées en Ethernet ». TB5 passe par PCIe : la latence est bien inférieure à celle d'un réseau IP classique, et l'on peut théoriquement approcher des vitesses proches du NVMe local pour du partage mémoire inter-machine (via des mécanismes de type RDMA). Pour une ferme de compilation, un cluster d'inférence IA ou un pool de rendu vidéo, la différence est tangible.
Nous avons loué 2 Mac mini M4 sur le nœud Singapour de ZilCloud (16 Go de mémoire unifiée + SSD 256 Go chacun, 1 Gbps dédié en public), avec le service Thunderbolt 5 activé. ZilCloud a réalisé le câblage physique et confirmé la reconnaissance système avant livraison.
Mise en place : activation et reconnaissance TB5
Dans la console ZilCloud, après sélection de 2 nœuds et activation de l'option TB5, les machines passent à l'état « prêt » en environ 3 minutes. En SSH sur le premier nœud, vérifiez la reconnaissance des ports :
system_profiler SPThunderboltDataTypeLa sortie montre les deux ports TB5 reconnus, avec l'équipement distant (le second Mac mini) en état « Connected ». macOS expose automatiquement un interface « Thunderbolt Bridge » dans les préférences réseau, avec une adresse link-local 169.254.x.x — aucune configuration manuelle requise pour démarrer.
IP statique (recommandé)
L'adresse APIPA fonctionne, mais pour la stabilité des scripts et des tâches de compilation, nous recommandons des IP statiques sur l'interface Thunderbolt Bridge :
# Nœud A
sudo networksetup -setmanual "Thunderbolt Bridge" 192.168.100.1 255.255.255.0
# Nœud B
sudo networksetup -setmanual "Thunderbolt Bridge" 192.168.100.2 255.255.255.0Après configuration, ping -c 4 192.168.100.2 renvoie un RTT moyen d'environ 0,08 ms — inférieur à ce qu'on observe sur du 10 GbE dans le même datacenter.
Mesures de bande passante : iperf3 et transferts fichiers
Réseau en place, première étape logique : iperf3.
Test TCP iperf3
# Nœud B en serveur
iperf3 -s
# Nœud A en client, 8 flux parallèles
iperf3 -c 192.168.100.2 -P 8 -t 30Résultats obtenus :
| Scénario | Protocole | Flux | Débit mesuré | % du plafond théorique |
|---|---|---|---|---|
| TCP unidirectionnel | TCP | 1 flux | 38,2 Gbps | 48 % |
| TCP multi-flux | TCP | 8 flux | 72,4 Gbps | 90 % |
| UDP unidirectionnel | UDP | 1 flux | 79,1 Gbps | 99 % |
| Bidirectionnel simultané | TCP | 4+4 flux | 61,8 + 59,3 Gbps | ~76 % |
En UDP mono-flux, nous atteignons 79,1 Gbps, très proche des 80 Gbps annoncés. En TCP à 8 flux concurrents : 72,4 Gbps — largement suffisant pour les charges réelles. En bidirectionnel, chaque direction reste au-dessus de 60 Gbps, soit plus de 120 Gbps cumulés, cohérent avec la spec PCIe de TB5.
Transferts fichiers inter-machines
iperf3 ne mesure que la couche réseau ; en usage réel, on veut connaître les vitesses au niveau système de fichiers. Tests via partage SMB natif macOS et montage NFS :
| Protocole | Lecture | Écriture | IOPS petits fichiers (4K) |
|---|---|---|---|
| SMB (défaut macOS) | 4,8 Go/s | 3,9 Go/s | 42 000 |
| NFS v4.2 | 6,2 Go/s | 5,7 Go/s | 67 000 |
| rsync (sans compression) | 5,1 Go/s | — | — |
En lecture séquentielle, NFS v4.2 atteint 6,2 Go/s — au-delà de la vitesse de lecture locale d'un SSD NVMe unique. Lire des données sur la machine distante via TB5 peut être plus rapide que depuis le SSD local, car la bande passante mémoire du M4 et le chemin TB5 direct surpassent le disque interne dans certains scénarios.
Préférez NFS v4.2 à SMB pour le partage de gros fichiers ou de nombreux petits fichiers : +59 % d'IOPS et latence plus basse. Pour des cas ultra sensibles à la latence (synchronisation d'état de simulateur Xcode), SSH + montage FUSE reste une alternative viable.
Compilation Xcode distribuée : mesures concrètes
Pour un développeur iOS / macOS, la question directe est : combien TB5 accélère-t-il Xcode ?
Nous avons utilisé une application SwiftUI réelle (~180 modules, compilation à froid ~14 minutes). Avec distcc en mode pump, les tâches sont réparties sur les deux machines :
# Installer distcc
brew install distcc
# Nœud B : daemon de compilation
distccd --allow 192.168.100.0/24 --log-stderr --verbose
# Nœud A : liste des hôtes distcc
export DISTCC_HOSTS="192.168.100.2/8 localhost/4"
# Compilation en mode pump
pump xcodebuild -project MyApp.xcodeproj -scheme MyApp -configuration Release build| Mode de compilation | Durée totale | Pic CPU | Accélération |
|---|---|---|---|
| Mono-nœud (A local) | 14 min 12 s | 87 % | Référence |
| Mono-nœud (B local) | 14 min 08 s | 89 % | Référence |
| 2 nœuds TB5 (distcc) | 8 min 47 s | 91 % × 2 | ×1,62 |
| 2 nœuds TB5 (incrémental) | 1 min 38 s | 76 % × 2 | ×2,3+ |
La compilation à froid passe de 14 minutes à 8 min 47 s, soit environ ×1,62. L'accélération n'atteint pas ×2 car la phase frontend Swift (analyse sémantique) n'est pas distribuable — elle reste locale et représente ~35 % du temps total. Sur du C/C++/Objective-C pur, nous avons mesuré jusqu'à ×1,9.
L'incrémental est encore plus impressionnant : le partage des artefacts inter-machines via TB5 élimine le goulot réseau. Une compilation incrémentale typique (~3 min 46 s en solo) tombe à 1 min 38 s — un gain perceptible à chaque cycle de développement.
Inférence de grands modèles : llama.cpp multi-nœuds
Au-delà de la compilation, TB5 apporte une valeur réelle pour l'inférence IA. L'Apple Neural Engine du M4 offre 38 TOPS ; pour un service recevant plusieurs requêtes concurrentes, deux machines en parallèle augmentent nettement le débit.
Nous avons testé le backend RPC de llama.cpp (support multi-machine depuis la branche 0.1.x) avec Llama 3.1 8B (quantification Q4_K_M) :
# Nœud B : serveur RPC
./llama-rpc-server --host 192.168.100.2 --port 50052 -ngl 99
# Nœud A : client principal, deux machines
./llama-cli \
--rpc 192.168.100.2:50052 \
-m ./Llama-3.1-8B-Q4_K_M.gguf \
-ngl 99 --parallel 8 -p "Write a detailed technical analysis of..."| Scénario | tokens/s (génération) | Requêtes concurrentes | Mémoire utilisée |
|---|---|---|---|
| Mono-nœud (A) | 48,2 tok/s | 4 concurrentes | 12,3 Go |
| 2 nœuds TB5 RPC | 89,7 tok/s | 8 concurrentes | 11,8 Go × 2 |
| 2 nœuds TB5 (Llama 3.1 70B Q4) | 22,4 tok/s | 2 concurrentes | ~30 Go répartis |
Le modèle 8B passe de 48,2 tok/s à 89,7 tok/s — une montée quasi linéaire. La latence TB5 rend négligeable le coût de synchronisation du KV-Cache entre nœuds, ce qu'un réseau Ethernet classique ne permet pas.
Deux machines débloquent aussi une tâche impossible en solo : Llama 3.1 70B en Q4 (~40 Go requis). Avec 16 Go par machine, le chargement local seul échoue ; via RPC TB5, les couches se répartissent sur les deux nœuds pour ~22 tok/s — utilisable sans GPU dédié.
Le backend RPC de llama.cpp, avec accélération Metal (Neural Engine), peut parfois bloquer sur un problème d'alignement mémoire lors du sharding inter-machine (~2 % des runs). Contournement temporaire : baisser -ngl à 80 pour laisser quelques couches sur CPU. Un correctif est en cours de merge côté projet.
Latence et stabilité : 72 heures de charge continue
Des chiffres de burst ne suffisent pas : pour la production, la stabilité prime. Nous avons maintenu une charge continue pendant 72 heures : boucle de compilation Xcode incrémentale (toutes les 5 minutes) + inférence llama.cpp concurrente + transferts de gros fichiers en boucle.
| Indicateur | Moyenne 72 h | Pire cas | Remarque |
|---|---|---|---|
| Latence lien TB5 (RTT) | 0,09 ms | 0,21 ms | Pic lors des bascules de charge |
| Bande passante TB5 (soutenue) | 69,8 Gbps | 61,2 Gbps | Baisse lors du throttling thermique |
| Interruptions de lien | 0 | — | Zéro coupure sur 72 h |
| Disponibilité SSH | 100 % | — | Aucune intervention manuelle |
| Température (dessus du boîtier) | 38,2 °C | 41,7 °C | Refroidissement passif M4 stable |
Sur 72 heures, le lien TB5 n'a connu aucune interruption. La bande passante moyenne reste à 69,8 Gbps malgré de légers creux lors du throttling thermique du M4. Ce niveau de stabilité convient à un nœud CI/CD ou à un service IA permanent.
Cas d'usage recommandés
D'après ces mesures, un cluster TB5 est particulièrement pertinent pour :
1. Compilation iOS / macOS distribuée (Xcode + distcc) : ×1,6 en compilation à froid, plus de ×2 en incrémental — les pipelines CI gagnent des minutes à chaque build.
2. Inférence locale de grands modèles (llama.cpp RPC) : dépassement de la limite mémoire mono-machine (70B en Q4 sur 32 Go combinés) ; débit concurrent quasi linéaire.
3. Rendu vidéo / traitement média à grande échelle : lecture inter-machines NFS over TB5 jusqu'à 6,2 Go/s ; avec les protocoles de rendu distribué de Final Cut Pro, le temps de rendu peut théoriquement être divisé par deux.
4. Pipelines de données temps réel : 80 Gbps + 0,08 ms de latence ouvrent des scénarios de communication inter-nœuds à faible latence (backtesting quantitatif, agrégation de flux en temps réel, etc.).
Pourquoi ne pas monter le même cluster sur un cloud classique ?
À ce stade, une question légitime : pourquoi ne pas utiliser des instances GPU AWS ou Alibaba Cloud ? Leurs offres HPC annoncent souvent 100 Gbps Ethernet — les chiffres semblent comparables.
La réponse repose sur des différences structurelles souvent négligées.
L'environnement macOS est irremplaçable. Compilation Xcode, signature iOS, distribution TestFlight, inférence via Apple Neural Engine — aucune de ces charges ne tourne légalement ou techniquement sur Linux ou Windows. Les instances Graviton d'AWS sont ARM, mais pas macOS ; les instances Mac EC2 sont bien du matériel Apple, mais à partir d'environ 1,08 $/heure avec un minimum de 24 h (~25,9 $/jour), plus cher que les 20,9 $/jour de ZilCloud — et sans interconnexion TB5 possible.
Le surbooking des clouds virtualisés. Derrière des centaines de vCPU « garantis », il n'y a souvent que 60 cœurs physiques partagés. Un « 10 Gbps » peut être du burst, pas du débit garanti ; le voisin bruyant dégrade vos compilations aux heures de pointe. ZilCloud fournit une machine physique dédiée : pas de couche de virtualisation, pas de surbooking — 10 cœurs M4 signifient 10 cœurs réels.
La qualité de l'interconnexion. Un Cluster Placement Group AWS réduit la latence, mais le RTT inter-nœuds reste typiquement entre 0,5 et 2 ms ; même l'EFA HPC se situe autour de la microseconde — loin des 0,08 ms d'un lien TB5 physique direct, sans pile réseau intermédiaire. Pour des workloads partageant beaucoup d'état (sharding KV-Cache en inférence), l'écart est décisif.
Les clouds généralistes restent pertinents pour l'entraînement GPU Linux pur, la facturation à la seconde ou l'auto-scaling massif. Mais si vous cherchez macOS natif + interconnexion cluster haute performance + location flexible à la journée, la combinaison TB5 de ZilCloud est aujourd'hui difficile à reproduire ailleurs. À partir de 20,9 $/jour + 1,4 $/jour pour TB5, soit 22,3 $/jour au total, vous entrez dans un cluster 80 Gbps sur Mac mini M4 physique. Pour un projet de deux semaines, louez deux machines, exécutez vos builds, résiliez — sans payer pour des ressources inactives.
Montez votre propre cluster Mac mini TB5
Louez un Mac mini M4 à la journée, ajoutez une seconde machine et activez Thunderbolt 5 : vous obtenez le cluster 80 Gbps testé dans cet article — sans engagement, arrêt à la demande, machine physique dédiée sans voisin bruyant.