Parallax : servir un LLM sur plusieurs machines hétérogènes

Le problème posé : un modèle trop gros pour une seule machine

Un modèle de plusieurs centaines de milliards de paramètres ne tient pas sur un seul accélérateur grand public. La réponse habituelle consiste à louer un nœud multi-GPU dans un centre de données, ce qui suppose un budget récurrent et une connexion réseau stable vers un fournisseur unique. Parallax prend le chemin inverse : réunir des machines que vous possédez déjà, quelles que soient leur marque et leur localisation, pour former un cluster d'inférence. Le README formule l'objectif ainsi : construire son propre cluster d'IA pour l'inférence de modèles sur un ensemble de nœuds distribués, « malgré leurs configurations et leur emplacement physique variés ». Le public visé est donc celui qui a du matériel dispersé (un serveur GPU au bureau, quelques Mac Studio à la maison, une machine chez un partenaire) et qui veut servir un modèle ouvert sans passer par une API tierce. C'est un choix de souveraineté plus qu'un choix de performance brute, et le projet l'assume jusque dans le titre de son billet de blog, qui parle de « sovereign AI OS ».

Comment les couches s'empilent réellement

L'architecture décrite dans le README sépare trois responsabilités. La communication entre nœuds passe par Lattica, une bibliothèque pair-à-pair développée par le même éditeur. Le calcul sur GPU s'appuie sur SGLang et vLLM, deux moteurs d'inférence déjà largement utilisés seuls. Le calcul sur Mac passe par MLX LM, la bibliothèque d'Apple. Parallax ne réimplémente donc pas de noyaux d'attention ni de gestionnaire de mémoire KV : il ajoute une couche de coordination au-dessus de moteurs existants. Le découpage du modèle entre machines se fait en pipeline parallèle, ce qui signifie que chaque nœud détient une tranche de couches et transmet les activations intermédiaires au suivant. Ce choix a une conséquence directe : le débit global est borné par le nœud le plus lent de la chaîne, puisque chaque token traverse toutes les tranches l'une après l'autre. Le README mentionne aussi une gestion de cache KV paginée et du continuous batching, mais en les rattachant explicitement au backend Mac. Rien dans le matériel fourni ne permet d'affirmer que ces deux mécanismes s'appliquent de la même façon aux backends GPU, et il faut lire cette ligne comme une description du chemin MLX LM plutôt que comme une propriété générale du système.

Installation : ce que les commandes disent et ne disent pas

Le README donne une séquence en quatre temps. On clone le dépôt, on lance le script d'installation, on active l'environnement virtuel, puis on démarre le service :

git clone https://github.com/GradientHQ/parallax.git cd parallax ./install.sh source .venv/bin/activate parallax serve -m Qwen/Qwen3.5-0.8B

Le script install.sh crée un environnement virtuel Python à la racine du dépôt, comme l'indique le chemin .venv/bin/activate juste après. La commande parallax serve prend un argument -m suivi d'un identifiant de modèle au format HuggingFace. Le README ne détaille pas les autres options de cette commande, ni comment un second nœud rejoint le premier, ni quels ports doivent être ouverts entre les machines. Ces informations sont renvoyées vers docs/user_guide/install.md et docs/user_guide/quick_start.md, deux fichiers que le matériel fourni ne contient pas. Autrement dit, l'exemple ci-dessus suffit à lancer un modèle sur une machine, mais pas à constituer un cluster, et c'est précisément la partie qui demanderait le plus de documentation. Prévoir de lire ces deux fichiers avant de planifier un déploiement.

Modèles pris en charge et ce que la liste implique

Le tableau des modèles compatibles couvre DeepSeek (V3.2, R1), MiniMax (M3, M2.7), GLM (5.2, 5.1, 4.7), Kimi-K2 (Thinking, Instruct-0905), Qwen (3.6-35B-A3B), gpt-oss (120b et safeguard-120b) et Step-3.5-Flash. Plusieurs de ces modèles sont des MoE à attention creuse, comme MiniMax-M3 ou Step-3.5-Flash, ce qui est cohérent avec un découpage en pipeline : un modèle qui n'active qu'une fraction de ses paramètres par token laisse espérer qu'une partie du calcul reste locale à chaque tranche. Le tableau liste aussi des modèles de très grande taille, et c'est là que la contrainte matérielle redevient centrale. Répartir DeepSeek-V3.2 sur des machines distantes suppose que la somme de leur mémoire d'accélérateur couvre le modèle, et que la latence entre nœuds reste supportable pour un pipeline séquentiel. Le README ne donne aucune mesure de débit ni de latence réseau, et il n'y a pas de tableau comparatif entre les backends. Toute estimation de performance devra donc venir de vos propres essais, pas de la page du projet.

La limite qui compte : le nœud le plus lent impose son rythme

En pipeline parallèle, un token traverse les nœuds dans l'ordre. Si un Mac portable participe au cluster aux côtés de serveurs GPU, c'est lui qui fixe le débit de l'ensemble, et les GPU passeront une partie de leur temps à attendre. Parallax revendique le support de configurations variées, mais cette hétérogénéité n'est pas gratuite : elle se paie en efficacité. Le README mentionne un « ordonnancement et routage dynamiques des requêtes » sans décrire l'algorithme, et il est impossible de savoir depuis ce matériel si le système rééquilibre les tranches en fonction de la puissance réelle de chaque nœud ou s'il se contente de répartir les couches à parts égales. Autre point à surveiller : la communication passe par Lattica, une bibliothèque du même éditeur, ce qui ajoute une dépendance à un composant distinct du dépôt Parallax lui-même. Enfin, un cluster réparti sur plusieurs sites introduit un problème de confidentialité que le mot « souverain » ne règle pas : si vos nœuds sont chez des tiers, les activations intermédiaires circulent chez eux. Pour un usage mono-site, ce point disparaît.

Face à SGLang ou vLLM utilisés seuls

L'alternative la plus directe est d'utiliser SGLang ou vLLM sans Parallax. Ces moteurs savent déjà répartir un modèle sur plusieurs GPU d'une même machine, et vLLM propose du tensor parallèle sur un nœud unique. La différence d'approche est nette : vLLM et SGLang supposent un interconnect rapide (NVLink, ou au minimum un réseau local à faible latence) et un parc matériel homogène. Parallax ajoute une couche P2P par-dessus et accepte des nœuds distants et dissemblables, en échange d'un pipeline séquentiel qui tolère moins bien l'hétérogénéité que le tensor parallèle. Le choix se résume donc à une question de topologie : si toutes vos cartes sont dans la même machine, la couche Parallax n'apporte rien et ajoute un composant à maintenir. Si vos machines sont séparées physiquement, aucun des deux moteurs seuls ne résout le problème, et c'est là que Parallax a un argument. Le README indique d'ailleurs que les deux moteurs servent de backend au projet, ce qui suggère qu'on peut les considérer comme complémentaires plutôt que concurrents.

Version 0.1.x, licence Apache-2.0 et coût de suivi

Le projet est passé de v0.1.0 en novembre 2025 à v0.1.2 en décembre 2025, soit trois versions en trois semaines. Le rythme est soutenu, ce qui est normal à ce stade, mais il implique que les interfaces de configuration peuvent bouger entre deux versions mineures. Un déploiement en production devra donc épingler une version précise et lire les notes de version avant chaque mise à jour, d'autant que la documentation publique ne couvre pas encore tous les cas d'usage. La licence Apache-2.0 est permissive : usage commercial, modification et redistribution sont autorisés, avec conservation du fichier de licence et des mentions de copyright, et une clause de brevets explicite. Elle n'impose aucune obligation de publier vos modifications. Cette description ne constitue pas un avis juridique, et les dépendances (SGLang, vLLM, MLX LM, Lattica) ont leurs propres licences, à vérifier séparément si votre contexte l'exige. Le coût de maintenance réel ne vient pas de Parallax lui-même mais de la chaîne de moteurs qu'il orchestre : suivre trois backends aux cycles de publication indépendants demande plus de veille que de suivre un seul.

Conclusion éditoriale

Parallax s'adresse aux équipes qui possèdent déjà plusieurs machines, idéalement un mélange de GPU et de Mac, et qui acceptent de faire tourner un logiciel en version 0.1.x dont la documentation publique reste mince. Si votre besoin se limite à servir un modèle sur un seul serveur GPU, SGLang ou vLLM seuls font le travail sans ajouter de couche réseau. Avant de vous engager, vérifiez trois choses dans le dépôt : le contenu réel de install.sh, la manière dont parallax serve découvre les autres nœuds, et si le backend MLX LM est compilé par défaut ou seulement sur les machines Apple Silicon.

Sources officielles

1. GradientHQ/parallax on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases