Depuis des années, la RDMA (Remote Direct Memory Access) est synonyme de superinformatique et de centres de données : des réseaux capables de transférer des données directement entre mémoires, avec une surcharge minimale et des latences qui, dans le monde du HPC, font la différence entre un cluster efficace et un qui « s’étouffe » dans la pile réseau. Aujourd’hui, Apple franchit une étape audacieuse en activant la RDMA via Thunderbolt 5 dans macOS 26.2, une technologie que la société associe à des cas d’usage tels que l’inférence distribuée en intelligence artificielle.

Sur le papier, la promesse est puissante : connecter plusieurs Macs par Thunderbolt 5 et réduire considérablement la latence de communication par rapport aux approches classiques basées sur TCP/IP. En pratique, les premières expériences d’utilisateurs qui expérimentent cette fonction indiquent une conclusion claire : le potentiel est là, mais le chemin comporte encore quelques obstacles.

Qu’est-ce que la RDMA et pourquoi est-ce important (quand c’est réellement crucial)

La RDMA permet à deux machines d’échanger des données sans que le CPU ait besoin de copier constamment des buffers, et sans passer par une grande partie de la « machinerie » du système d’exploitation. Cela réduit la latence et libère du temps CPU pour des tâches utiles (par exemple, le calcul ou GPU).

Dans un centre de données, la RDMA est souvent associée à InfiniBand ou à des variantes Ethernet comme RoCE. Dans le cas d’Apple, la innovation réside dans le support physique : Thunderbolt 5, une interconnexion conçue pour des débits élevés via périphériques, stockage externe ou docks… qui est maintenant utilisée comme lien à faible latence entre hôtes.

Thunderbolt 5 double également la bande passante de base par rapport à Thunderbolt 4 (80 Gb/s en bidirectionnel) et prévoit des modes « boost » asymétriques dans certains scénarios.

L’enjeu principal : MLX et le backend « JACCL »

Ce qui a suscité l’attention (dans le bon sens) est que la documentation de MLX, le framework d’Apple pour le machine learning, inclut déjà un backend de communication appelé JACCL, conçu pour exploiter la RDMA via Thunderbolt. Selon leurs propres mots, ce backend permet des latences dix fois inférieures aux solutions alternatives comme le backend en anneau (« ring »).

En termes simples : Apple ne déploie pas la RDMA « pour le plaisir ». Elle crée une composante pour que le ML distribué localement — avec plusieurs Macs — ait un sens au-delà de simples démonstrations.

L’activation n’est pas une opération clic : il faut passer par la récupération

Voici le premier choc culturel pour ceux qui imaginent un « cluster » comme quelque chose d’automatisable : ce n’est pas activé à distance, même en sudo via SSH. Selon la documentation de MLX, le processus nécessite d’accéder à macOS Recovery, ouvrir le Terminal et exécuter :

rdma_ctl enable

Puis redémarrer.

Pour vérifier, la même documentation propose la commande ibv_devices, qui révèle une autre facette intéressante : Apple expose des interfaces compatibles avec l’écosystème « verbs » de la RDMA (couramment utilisé en HPC).

La topologie est essentielle : JACCL requiert un maillage complètement connecté

Un deuxième point critique — et qui influence fortement la « configuration maison » des Macs — : JACCL ne supporte que des topologies entièrement connectées (full mesh). Cela signifie, littéralement, un câble Thunderbolt entre chaque paire de nœuds.

Pour un cluster de 4 nœuds, c’est réalisable. Au-delà, le câblage devient rapidement complexe. De plus, à l’heure actuelle, il n’existe pas d’équivalent évident à un « switch Thunderbolt 5 » dédié à ce type de déploiements, compliquant la scalabilité sans transformer le rack en un nœud de câbles (et de points de défaillance potentiels).

Tableau synthétique : croissance du câblage en maillage complet

La limite physique : M4 Max vs M3 Ultra

La contrainte des ports n’est pas banale, car dans un maillage complet, chaque nœud doit posséder N−1 liens. Sur les Mac Studio modernes, Apple propose des configurations avec M4 Max et M3 Ultra, avec un nombre différent de ports Thunderbolt 5 selon le modèle.

Concrètement, cela se traduit souvent par une règle simple observée lors de tests :

• M4 Max (moins de ports Thunderbolt 5) : le plafond « naturel » en maillage complet tourne autour de 5 nœuds sans bricolage.
• M3 Ultra (plus de ports Thunderbolt 5) : permet d’atteindre 7 nœuds en maillage complet (chacun nécessitant 6 liens).

Pourquoi la CPU monte à 900 % : le cas du Thunderbolt Bridge

Une des anomalies fréquemment rapportées lors des premiers tests est la surcharge CPU et réseau lorsque le système entre dans des états inhabituels de routage ou de pontage. La documentation de MLX est là encore très claire : même si la RDMA Thunderbolt ne s’appuie pas sur TCP/IP pour communiquer, il est nécessaire de désactiver le Thunderbolt Bridge et d’isoler le réseau local par lien.

Cela s’inscrit dans un schéma classique en topologie maillée : si les interfaces pont activées persistent, cela peut créer des boucles, des tempêtes de trafic ou des routages inattendus. Résultat : pics CPU, trafic massif et, dans le pire des cas, la sensation que « le réseau plie » et qu’il faut revenir en mode local pour réparer.

« La documentation manque » (ou n’était pas là où on l’attendait)

Un autre point récurrent chez ceux qui expérimentent cette fonction est la frustration face à une documentation dispersée et des réponses contradictoires dans des ressources générales. La situation est compréhensible : il s’agit d’une capacité nouvelle, avec des exigences spécifiques (Recovery, maillage strict, bridge désactivé, réseaux isolés), et des outils qui ne font pas encore partie du « manuel mental » de la majorité.

En ce contexte, des projets communautaires comme Exo ont été utilisés pour expérimenter avec des clusters de Macs et la RDMA, et plusieurs tests publiés montrent des améliorations significatives de la latence dans l’accès à la mémoire distribuée, par rapport aux configurations antérieures.

Ce que les équipes techniques peuvent faire aujourd’hui (sans faire de promesses vaines)

Au-delà de la simple démonstration, un check-list réaliste pour les développeurs et administrateurs souhaitant évaluer la RDMA via Thunderbolt 5 sans y consacrer tout leur week-end :

1. Séparer « laboratoire » et « production » : considérer que cette technologie est en phase expérimentale.
2. Planifier la topologie : si l’on veut JACCL, penser dès le départ à un maillage complet.
3. S’assurer de l’accès local : l’activation nécessite Recovery ; en cas de problème, on doit pouvoir revenir à la console.
4. Configurer SSH et sudo sans mot de passe pour automatiser les déploiements (mlx.launch le suppose dans ses scripts).
5. Désactiver le Thunderbolt Bridge et isoler les liens en préalable, pas en tuning.
6. Surveiller les effets indésirables : des services comme Control Universal ou Screen Sharing peuvent augmenter l’usage CPU et réseau. Il faut isoler ces variables pour identifier les causes.

Une lecture stratégique : Apple esquisse le « cluster personnel » pour l’IA

Apple oriente ses efforts vers un scénario très précis : combiner la mémoire et la puissance de calcul de plusieurs Macs pour des tâches qui, jusqu’ici, nécessitaient un centre de données ou des stations équipées de GPU massifs. La connexion à MLX et à l’inférence distribuée n’est pas une coïncidence.

Ce qui est plus délicat, c’est que le saut vers cette configuration nécessite une mentalité orientée HPC : topologies strictes, configuration soignée et tolérance à la panne. Mais, malgré cette friction, le message est clair : la RDMA ne se limite plus au datacenter. Apple pousse cette voie vers le bureau… bien que, pour l’instant, cela reste un défi.