distributed-llama : répartir l'inférence d'un LLM sur plusieurs machines du réseau local

Le problème que distributed-llama attaque vraiment

Un modèle de 70B paramètres en quantization q40 pèse environ 40 GB selon le tableau du README. Une seule machine domestique ne dispose pas toujours de cette mémoire, et même lorsqu'elle l'a, la vitesse de génération reste limitée par la bande passante mémoire d'un seul socket. Le projet part de ce constat et propose une réponse : découper le réseau de neurones en tranches, placer chaque tranche sur une machine distincte, et faire circuler les activations entre elles à chaque étape de calcul. Le README résume l'idée en une phrase : plus de machines signifie une inférence plus rapide. La cible est donc l'ingénieur ou le particulier qui possède déjà deux, quatre ou huit machines et cherche à les faire travailler ensemble sur un même modèle, plutôt que d'acheter une carte accélératrice unique. Le projet est distribué sous licence MIT, en C++, avec un support annoncé de Linux, macOS et Windows, et une optimisation pour les processeurs ARM et x86_64 AVX2.

Un nœud racine, des nœuds travailleurs, et une topologie en étoile

L'architecture décrite dans le README est volontairement simple. Toutes les machines sont branchées derrière un switch ou un routeur, et l'une d'elles joue le rôle de nœud racine. Le nœud racine charge le modèle et les poids, les transmet aux travailleurs, puis synchronise l'état du réseau de neurones à chaque cycle. Il traite aussi sa propre tranche : le README précise explicitement que le nœud racine est également un travailleur. Les nœuds travailleurs, eux, ne reçoivent aucune configuration liée au modèle. C'est un point de conception intéressant : la connaissance du modèle est centralisée, ce qui évite de dupliquer des fichiers de configuration sur chaque machine, mais cela signifie aussi que le démarrage passe entièrement par le nœud racine. La consommation de RAM est répartie sur l'ensemble des nœuds, avec une nuance signalée par le README : le nœud racine demande un peu plus de mémoire que les travailleurs. Le schéma donne des adresses concrètes, du type 10.0.0.1 pour la racine et 10.0.0.2:9999, 10.0.0.3:9999 pour les travailleurs, ce qui indique que le port 9999 est la valeur d'exemple utilisée pour l'écoute des travailleurs.

Les puissances de deux et le plafond des KV heads

Deux limitations du README méritent d'être lues avant toute installation. La première est arithmétique : le nombre de nœuds doit valoir 1, 2, 4, et ainsi de suite, soit 2^n. Trois machines ne forment pas une configuration valide. Cela découle du découpage en tranches du modèle, qui suppose une subdivision régulière. La seconde est plus subtile : le nombre maximal de nœuds est égal au nombre de KV heads du modèle, et le README renvoie à un ticket de suivi sur ce point. Concrètement, un modèle dont l'architecture comporte peu de KV heads plafonne rapidement, indépendamment du nombre de machines disponibles. Ces deux contraintes combinées limitent fortement les configurations possibles : on ne choisit pas librement le nombre de nœuds en fonction du matériel, on le choisit en fonction du modèle. Le README liste aussi les quantizations supportées, et la liste est courte : un modèle q40 avec un buffer-float-type q80, ou un modèle f32 avec un buffer-float-type f32. Aucune autre combinaison n'est annoncée comme fonctionnelle.

Mise en route : launch.py, puis les commandes dllama

Le chemin le plus court passe par le script Python fourni. Le README indique que Python 3 et un compilateur C++ sont nécessaires, et que la commande télécharge le modèle ainsi que le tokenizer. Pour un Llama 3.1 8B Instruct Q40, la commande est python launch.py llama3_1_8b_instruct_q40. Pour un Qwen 3 0.6B Q40, ce sera python launch.py qwen3_0.6b_q40. Le tableau couvre des tailles allant de 0.9 GB à 238 GB pour le Llama 3.1 405B Instruct Q40. Une fois le modèle en place, l'outil expose quatre sous-commandes : dllama inference pour lancer une inférence avec un benchmark simple, dllama chat pour une session en ligne de commande, dllama worker pour un nœud travailleur, et dllama-api pour le serveur d'API. Les arguments documentés incluent --model et --tokenizer pour les chemins, --buffer-float-type pour la précision de synchronisation, --workers pour la liste des adresses ip:port séparées par des espaces, et --max-seq-len pour plafonner la longueur de séquence et réduire l'usage de RAM. Les sous-commandes inference, chat, worker et api acceptent --nthreads, avec une recommandation explicite dans le README : ne pas dépasser le nombre de cœurs du processeur. Les sous-commandes worker et api prennent --host et --port, tandis que inference ajoute --prompt et --steps.

Ce que le réseau local impose comme coût caché

Le README vante une synchronisation haut débit sur Ethernet, et le choix du parallélisme tensoriel implique que les nœuds échangent des données à chaque étape de calcul, pas seulement en début et en fin de génération. C'est la différence structurelle avec un simple serveur qui enverrait des requêtes à des machines indépendantes. La conséquence pratique est qu'un lien lent ou un switch saturé se répercute directement sur la latence de génération, et le matériel fourni ne donne aucun chiffre de débit, aucune mesure de latence et aucune indication sur le volume échangé par token. Je ne peux donc pas affirmer ici quel débit réseau est nécessaire. Ce que le matériel permet de dire, c'est que la conception repose entièrement sur la qualité du réseau local, et que le projet est présenté comme destiné à des appareils domestiques connectés entre eux. Un lecteur qui envisage du Wi-Fi plutôt que de l'Ethernet filaire prend un risque que la documentation ne chiffre pas.

Un support GPU encore marqué expérimental

Le projet n'est pas uniquement CPU. Les notes de version mentionnent un support Vulkan introduit en version 0.13.0 et qualifié d'expérimental dans le lien fourni. Les actualités du README indiquent aussi que les modèles Qwen 3 MoE sont pris en charge sur Vulkan depuis le 16 septembre 2025, et sur CPU depuis le 5 septembre 2025. Le tableau des commandes de lancement, lui, ne contient que des modèles Q40 et ne distingue pas les variantes GPU. Il existe un document dédié, docs/HOW_TO_RUN_GPU.md, vers lequel le README renvoie, mais son contenu n'est pas fourni ici. La prudence s'impose donc : la voie CPU est celle qui est la mieux documentée dans le matériel disponible, et le support GPU doit être traité comme une fonctionnalité en cours de stabilisation, pas comme le mode par défaut.

Face à llama.cpp et à ses serveurs

L'alternative la plus évidente est llama.cpp et son serveur llama-server, qui exécutent un modèle sur une seule machine et exposent une API HTTP compatible avec le format OpenAI. La différence d'approche est nette : llama.cpp mise sur l'optimisation d'un seul hôte, avec une quantization très variée et un large catalogue de modèles, tandis que distributed-llama mise sur l'agrégation de plusieurs hôtes modestes avec un jeu de quantizations réduit à deux combinaisons annoncées. Si vous avez une seule machine avec assez de RAM, llama.cpp est le choix direct et distributed-llama n'apporte rien. Si vous avez quatre machines dont aucune ne peut charger le modèle seul, distributed-llama devient pertinent, à condition d'accepter la contrainte des puissances de deux. Une autre différence tient à l'API : le README mentionne dllama-api comme serveur d'API, mais ne documente ni les routes exposées ni un éventuel format compatible OpenAI, ce qui empêche de comparer les deux projets sur ce terrain.

Maintenance, licence et ce qu'il reste à vérifier

Le rythme de publication est irrégulier. La version 0.16.5 date du 2 février 2026, la 0.16.4 du 17 janvier 2026, et la 0.16.3 du 26 octobre 2025, avec un dernier push sur la branche main en juillet 2026. Les intervalles vont de quelques semaines à plus de trois mois, ce qui suggère un projet mené par une petite équipe plutôt qu'un cycle de publication prévisible. Le README signale d'ailleurs une refonte fondamentale du code en version 0.12.0, ce qui signifie que les versions antérieures à ce jalon ne sont pas représentatives de l'état actuel. La licence MIT est permissive : elle autorise la modification et la redistribution, y compris dans un contexte commercial, à condition de conserver l'avis de copyright et le texte de licence. Je ne donne pas d'avis juridique sur votre cas particulier. Le point à vérifier en premier reste le nombre de KV heads du modèle que vous visez, puisqu'il détermine le nombre maximal de nœuds que vous pourrez réellement utiliser.

Conclusion éditoriale

Adoptez distributed-llama si vous disposez déjà de plusieurs machines (Mac Mini, Raspberry Pi, PC sous Linux, macOS ou Windows) et que vous voulez faire tenir un modèle trop gros pour une seule d'entre elles, en acceptant la contrainte du nombre de nœuds en puissance de deux et un jeu de quantifications restreint. Passez votre chemin si votre matériel est hétérogène en performance ou si vous voulez servir plusieurs requêtes simultanées : rien dans le matériel fourni ne décrit une gestion de file d'attente ou d'ordonnancement multi-clients. Avant de vous engager, vérifiez le nombre de KV heads du modèle visé, puisque le README indique que le nombre maximal de nœuds est égal à ce nombre, et confirmez la compatibilité de la paire quantization / buffer-float-type sur votre modèle.

Sources officielles

1. b4rtaz/distributed-llama on GitHub
2. Issues
3. License: MIT
4. README
5. Releases