Exo : transformer plusieurs machines en cluster LLM maison

#Ce qu'Exo fait concrètement

Exo (dépôt exo-explore/exo, près de 48 000 étoiles sur GitHub au 28 septembre 2026) se présente par ses créateurs comme un outil pour « faire tourner l'IA de pointe en local ». Les appareils qui exécutent Exo se découvrent automatiquement sur le réseau, sans configuration manuelle, et exposent un tableau de bord et une API à l'adresse http://localhost:52415 sur chaque nœud.

Le projet met en avant un parallélisme tensoriel « topology-aware » : Exo évalue en temps réel la topologie réseau (latence, bande passante entre chaque paire de machines) et les ressources de chaque appareil pour décider comment répartir un modèle, plutôt que d'appliquer un découpage fixe identique quel que soit le matériel disponible.

#Mémoire cumulée : l'apport réel

Le bénéfice le plus tangible d'un cluster Exo est la somme des mémoires disponibles. Une configuration illustrée par le projet lui-même associe 4 Mac Studio M3 Ultra de 512 Go chacun pour charger DeepSeek v3.1 en 8-bit et Kimi-K2-Thinking en 4-bit simultanément — des modèles qu'aucune de ces machines ne pourrait charger seule, même à 512 Go.

Sur le plan du calcul, Exo revendique un gain avec le parallélisme tensoriel : jusqu'à 1,8x de vitesse sur 2 appareils et 3,2x sur 4 appareils. Ce sont des facteurs d'accélération du calcul réparti, pas des débits en tokens par seconde : le nombre réel de tokens générés par seconde dépend toujours du modèle, de la quantification et, on y revient plus bas, du réseau entre les machines.

#Le coût réseau : ce que le RDMA change

Relier des machines en réseau introduit une latence que n'a pas un GPU unique. Exo répond à ce problème avec un support RDMA (accès direct à la mémoire distante) sur Thunderbolt 5, annoncé dès la sortie de cette fonctionnalité, revendiquant une réduction de 99 % de la latence entre appareils par rapport à une liaison réseau classique.

Cette capacité RDMA n'est pas universelle : elle repose sur une fonctionnalité ajoutée à macOS 26.2 et ne fonctionne que sur des Mac équipés de Thunderbolt 5 — Mac mini M4 Pro, Mac Studio M4 Max ou M3 Ultra, MacBook Pro M4 Max selon la liste officielle. Le projet impose en outre que tous les appareils du cluster RDMA soient interconnectés entre eux, avec des câbles certifiés TB5, et que la version de macOS (bêta comprise) soit strictement identique sur chaque machine, faute de quoi les ports RDMA peuvent ne pas se découvrir mutuellement.

#Matrice de plateformes réellement supportées

Ce tableau contredit une hypothèse répandue : Exo n'est pas un outil qui fait tourner un cluster hétérogène Mac plus PC à pleine vitesse. Le backend d'inférence MLX est spécifique à Apple Silicon ; sur Linux, le README officiel indique noir sur blanc qu'Exo tourne aujourd'hui sur CPU, sans accélération GPU, avec un support GPU annoncé « en développement » sans date de livraison précisée.

#Installer un cluster en pratique

1. 01
   Préparer chaque machine macOS

   Installer Xcode (pour le toolchain Metal), Homebrew, uv et Node, prérequis documentés pour compiler et lancer Exo depuis les sources sur macOS.
2. 02
   Cloner et lancer Exo

   git clone du dépôt, construction du tableau de bord (npm install && npm run build), puis uv sync --extra mlx et uv run exo sur chaque machine.
3. 03
   Vérifier la découverte automatique

   Les appareils sur le même réseau se découvrent sans configuration ; le tableau de bord accessible sur http://localhost:52415 doit lister chaque nœud actif du cluster.
4. 04
   Activer le RDMA si le matériel le permet

   Sur des Mac Thunderbolt 5 sous macOS 26.2+, activer rdma_ctl enable depuis le mode Recovery sur chaque machine, puis relier tous les appareils entre eux avec des câbles certifiés TB5.
5. 05
   Charger un modèle réparti

   Depuis le tableau de bord ou l'API, choisir un modèle dont la taille dépasse la mémoire d'un seul appareil pour vérifier concrètement que la répartition fonctionne avant de viser des modèles encore plus gros.

#API compatibles et clients existants

Exo expose plusieurs API compatibles : OpenAI Chat Completions, OpenAI Responses, Claude Messages et Ollama — un client déjà écrit pour l'un de ces formats peut pointer vers le cluster Exo sans réécriture. C'est un choix pragmatique qui évite de devoir adopter un protocole propriétaire pour profiter du cluster.

Des variables d'environnement complètent la configuration pour un usage avancé : EXO_OFFLINE pour fonctionner sans connexion internet une fois les modèles déjà en cache, EXO_MODELS_READ_ONLY_DIRS pour partager un stockage de modèles en lecture seule entre machines (utile pour un montage NFS commun), et EXO_LIBP2P_NAMESPACE pour isoler plusieurs clusters Exo sur le même réseau physique.

#Modèles personnalisés depuis Hugging Face

Exo ne se limite pas à un catalogue fermé de modèles : le projet prend en charge des modèles personnalisés directement depuis le Hugging Face Hub, au-delà des déploiements de démonstration mis en avant par ses créateurs (DeepSeek v3.1 à 671 milliards de paramètres, Qwen3-235B, Kimi-K2-Thinking). C'est ce qui permet de tester un modèle récent dès sa publication sur le Hub, sans attendre qu'il soit ajouté à une liste officiellement supportée.

Cette ouverture a une contrepartie documentée : les modèles personnalisés qui exigent trust_remote_code dans leur configuration doivent être activés explicitement, ce réglage restant désactivé par défaut pour des raisons de sécurité. Exécuter du code arbitraire fourni par un dépôt Hugging Face tiers sur l'ensemble des machines du cluster n'est donc pas un comportement par défaut, mais un choix à faire consciemment pour les modèles qui l'exigent.

• Parcourir les modèles sur le Hugging Face Hub

#Sécurité : un cluster sans authentification documentée

Le README officiel et la documentation du tableau de bord ne mentionnent aucun mécanisme d'authentification, de clé d'API, de jeton ou de chiffrement TLS pour l'API et le tableau de bord d'Exo : dans l'état documenté au 28 septembre 2026, quiconque atteint le port 52415 d'un nœud peut interroger l'API ou consulter le tableau de bord, sans étape de connexion.

Ce point mérite d'autant plus d'attention que chaque machine du cluster expose sa propre API sur le réseau local : dans une configuration à plusieurs appareils, la surface exposée est celle de chaque nœud pris individuellement, pas seulement celle d'un point d'entrée unique qu'on pourrait protéger isolément.

#Dépannage : symptômes, cause, correction

#Limites et pièges à anticiper

Pas de Windows documenté

Le dépôt officiel ne mentionne aucun support Windows au 28 septembre 2026 ; les chemins d'installation couvrent macOS et Linux uniquement.

Linux limité au CPU

L'inférence accélérée par GPU sur Linux est en développement, sans date annoncée ; un cluster Linux seul sera nettement plus lent qu'un cluster Apple Silicon équivalent.

RDMA exigeant sur le matériel

Thunderbolt 5, macOS 26.2 ou plus récent, versions de système strictement identiques sur chaque machine : un seul appareil qui ne coche pas ces cases retombe sur un réseau classique, plus lent.

Débit non garanti

Les facteurs d'accélération (1,8x, 3,2x) mesurent l'apport du parallélisme tensoriel sur le calcul réparti, pas un débit en tokens par seconde transposable tel quel à votre propre modèle et votre propre réseau.

• LLM multi-GPU avec llama.cpp : tensor-split 2× RTX 3090
• llama.cpp vs vLLM vs Exllama
• Déployer un LLM en production avec Docker Compose
• Principes de sécurisation d'un serveur d'inférence exposé
• Source : dépôt GitHub officiel Exo
• Source : README officiel du dépôt Exo