Mesh LLM — Calcul IA distribué basé sur iroh

• Regroupe les GPU et la mémoire dispersés sur plusieurs machines en une seule ressource de calcul, et fournit l’exécution locale, le transfert vers des pairs et l’exécution fractionnée via une API unique compatible OpenAI
• Les requêtes sont traitées sur un GPU local ou par un pair ayant chargé le modèle ; les modèles qui ne tiennent pas sur une seule machine peuvent être exécutés sur plusieurs nœuds, répartis en étapes de pipeline
• Le catalogue basé sur des plugins inclut plus de 40 modèles, depuis des modèles de 500 millions de paramètres pour ordinateur portable jusqu’à des modèles MoE 235B ; le client appelle uniquement localhost:9337/v1, indépendamment du découpage interne
• Chaque nœud exécute un endpoint iroh qui utilise une clé publique comme ID et comme unique surface réseau, et établit des connexions QUIC authentifiées sans serveur central, via traversée NAT, hole punching et chemins de repli par relais
• Avec un logiciel d’environ 18 Mo, il est possible de constituer un mesh public ou un déploiement privé ; le projet prévoit de réduire la dépendance aux serveurs fermés via de futures apps mobiles prenant en charge l’iroh Swift SDK et ACP

---

Utiliser le matériel existant plutôt que des datacenters externes

• L’usage classique des LLM dépend des datacenters GPU d’opérateurs externes et d’API facturées à l’usage ; les coûts augmentent donc avec le volume d’utilisation
• Envoyer des prompts à un service externe rend difficile, pour l’utilisateur, de contrôler directement les éléments suivants
  • Le moment des mises à jour du modèle
  • L’endroit où les données sont transmises
  • La mémoire utilisée par le modèle et le matériel sous-jacent
  • Les changements de tarification et de politique de traitement des données personnelles
• Les entreprises et services qui possèdent déjà des GPU au bureau, dans un entrepôt ou sous un bureau ont besoin d’un moyen d’utiliser plusieurs machines comme une seule ressource de calcul
• Mesh LLM est conçu pour agréger les GPU et la mémoire détenus par l’utilisateur sur autant de machines que nécessaire, exécuter des modèles plus grands, et partager les ressources de calcul en privé au sein d’une équipe ou publiquement avec l’extérieur

Trois chemins pour traiter une requête

• Lorsqu’un client OpenAI standard appelle http://localhost:9337/v1, le mesh décide de l’emplacement réel d’exécution de la requête
• La requête est traitée par l’un des trois chemins suivants
  • Exécution du modèle sur le GPU local de la machine actuelle
  • Transfert de la requête vers un pair qui a déjà chargé le modèle requis
  • Fractionnement, en pipeline, d’un modèle qui ne tient pas sur une seule machine, sur plusieurs machines
• L’utilisateur peut commencer avec un seul nœud puis en ajouter selon les besoins ; le client OpenAI n’a pas besoin de connaître le routage interne ni le mode d’exécution fractionnée

Structure en plugins et catalogue de modèles

• Les plugins déclarent leurs capacités dans un manifeste, et le runtime les démarre puis route les appels
• Les capacités de chaque plugin sont exposées via MCP, HTTP, inférence et événements du mesh
• Le catalogue par défaut inclut plus de 40 modèles
  • Des modèles d’environ 500 millions de paramètres exécutables sur un ordinateur portable
  • Des modèles Mixture-of-Experts allant jusqu’à 235B

Exécution fractionnée Skippy

• Le mode de fractionnement pour les grands modèles est appelé en interne Skippy
• Les plages de couches du modèle sont découpées par étapes et placées sur chaque nœud
  • Un nœud prend en charge les couches 0 à 15
  • Le nœud suivant prend en charge les couches 16 à 31
  • Les couches suivantes sont distribuées de la même manière jusqu’à la fin du pipeline
• Les activations générées à une étape sont transmises à l’étape suivante, ce qui permet d’exécuter, en combinant plusieurs machines de milieu de gamme, des modèles qui ne tiendraient pas sur une machine individuelle
• Le processus de fractionnement n’est pas visible par le client OpenAI, qui continue simplement d’appeler l’endpoint local

Réseau P2P basé sur iroh

• Les nœuds qui fournissent des modèles comme ceux qui ne font qu’envoyer des requêtes démarrent tous un endpoint iroh
• L’endpoint remplit trois rôles
  • ID du nœud
  • Clé publique
  • Unique surface réseau exposée à l’extérieur par le nœud
• iroh gère le hole punching, la traversée NAT et les chemins de repli par relais sans serveur central, afin d’établir des connexions QUIC directes et authentifiées entre des nœuds situés à différents endroits
• Pour les nœuds qui ne peuvent pas se connecter directement, deux relais iroh sont exploités dans différentes régions afin de fournir un chemin de repli proche
• Comme il est possible de désigner une machine par sa clé publique et d’utiliser QUIC authentifié avec traversée NAT, le transfert d’une requête vers un pair ou l’envoi d’activations à l’étape suivante du pipeline reposent sur les mêmes primitives de communication, seul l’ID d’endpoint changeant

Distinction des protocoles avec QUIC ALPN

• L’ensemble du protocole utilise la négociation ALPN de QUIC et se divise en trois usages
  • mesh-llm/1 : mesh principal, incluant gossip, routage, tunnel HTTP et canaux de plugins
  • mesh-llm-control/1 : plan de contrôle propriétaire chargé de la synchronisation de configuration et de la preuve de propriété
  • skippy-stage/2 : transfert d’activations sensible à la latence pour les modèles fractionnés
• Sur une connexion mesh-llm/1, toutes les opérations sont transmises via des flux QUIC bidirectionnels, dont le premier octet identifie le type
  • 0x01 GOSSIP : annonces de pairs incluant modèles, GPU, RTT et capacités
  • 0x04 TUNNEL_HTTP : requêtes d’inférence proxifiées vers un pair
  • 0x05 ROUTE_REQUEST : recherche d’un modèle hébergé par un pair
  • 0x06 PEER_DOWN : notification d’un pair déconnecté
  • 0x07 PEER_LEAVING : notification de fermeture propre
  • 0x08 PLUGIN_CHANNEL : RPC de plugin
  • 0x0e DIRECT_PATH_REQUEST : partage d’adresses directes pour la traversée NAT
• Une seule connexion traite le gossip, l’inférence, la recherche de routes et les événements de cycle de vie des pairs, et démultiplexe chaque flux au moyen d’un octet de préfixe

Séparation entre transport sécurisé et contrôle du mesh

• iroh fournit la couche de transport sécurisée entre machines
• Mesh LLM construit par-dessus sa propre couche de gossip afin de contrôler directement les politiques suivantes
  • Les entités autorisées à rejoindre le mesh
  • Les versions compatibles
  • Les pairs de confiance

Installation et prises en charge à venir

• Un logiciel léger d’environ 18 Mo permet de rejoindre un mesh public ou de configurer un déploiement privé
• Pour les clients OpenAI standard, il est exposé sous forme d’endpoint localhost:9337/v1
• Le projet prévoit de développer des apps mobiles avec l’iroh Swift SDK et prépare la prise en charge d’ACP, un nouveau standard d’agents, afin que d’autres clients puissent rejoindre le mesh
• Le projet vise à accroître l’usage du P2P et à réduire les dépendances aux serveurs fermés
• Le projet est disponible via le code source et le site web Mesh LLM

Bibliothèque réseau iroh

• iroh est une bibliothèque réseau open source qui fournit des connexions entre appareils ; elle permet de combiner des protocoles prêts à l’emploi ou de construire des protocoles personnalisés au-dessus d’une abstraction de communication simple
• Elle fonctionne déjà en production sur des centaines de milliers d’appareils
• Une documentation, un code source et un canal Discord sont disponibles

[GN⁺]

Avis Hacker News

• En voyant le GPU, l’ordinateur portable, le serveur, les nœuds cloud, etc. sur la première image, j’ai pris conscience de à quel point mes ressources de calcul sont limitées. Je n’ai ni portable avec 24 Go de VRAM ni station de travail avec 96 Go, et même en mobilisant tous les PC gaming de mes amis pour faire tourner un LLM, je doute d’atteindre la VRAM totale de la photo
  L’article présentait aussi un réseau mesh public, mais je n’ai pas trouvé d’informations détaillées à son sujet

  • L’adresse du mesh public est https://public.meshllm.cloud/

• Le manque d’informations sur les performances saute aux yeux. Je m’attendais à ce que ce soit bien plus lent que toute autre façon d’exécuter de très grands modèles, y compris avec streaming via la RAM système ou le disque. Même un réseau grand public en Ethernet 10 Gbit/s reste très lent par rapport à la RAM locale ou au disque, donc je me demandais si un modèle partitionné tournait à 1 token/s ou moins
  En regardant la liste des modèles, j’ai vu que Qwen 235B A22B était indiqué comme « MoE 235B/22B validé à 16 tok/s sur 2 nœuds ». Les spécifications des nœuds et de la connexion réseau ne sont pas publiées, mais c’est une vitesse tout à fait correcte, et même si on reste un peu en dessous du confort idéal pour un usage interactif, on en est assez proche

  • Ce n’est pas forcément plus lent, et il y a probablement beaucoup de configurations où c’est même l’inverse. Si l’on déporte les poids vers la RAM ou le NVMe, il faut à chaque token transférer d’énormes poids du stockage lent vers le GPU à mesure que chaque couche est traitée, ce qui crée un goulet d’étranglement au niveau de la bande passante DRAM ou de la vitesse de lecture disque
    Dans une configuration distribuée, les poids restent dans la VRAM de chaque machine, ce qui permet d’exploiter une bande passante mémoire GPU bien plus rapide. Les sorties de couche échangées entre machines sont de l’ordre du kilooctet et non des poids de plusieurs gigaoctets, donc le débit réseau ne devient pas le facteur limitant
    La vraie contrainte, c’est la latence réseau. Si l’on répartit le modèle sur 4 appareils, on subit la latence réseau trois fois par token ; avec 1 ms de latence, cela ajoute 3 ms par token. En supposant un temps de calcul nul, la vitesse maximale théorique sans speculative decoding est donc d’environ 30 tok/s
    Sur Internet, la latence est probablement trop élevée pour que ce soit pratique, mais sur un réseau local ou d’entreprise, avec speculative decoding, cela semble tout à fait faisable. Pour le préremplissage ou le traitement du prompt, la latence ne s’accumule pas, donc la configuration distribuée sera presque certainement plus rapide
  • J’ai fait des mesures dans mon home lab en simulant une latence et une gigue de 5 ms entre les machines. L’exécution partitionnée fonctionne plutôt bien avec une latence WAN de niveau métropolitain, mais ce n’est pas très rapide à l’échelle d’un WAN mondial
    L’objectif est de relier plusieurs machines sans fabric RDMA ou NVLink dédiée pour servir de grands modèles avec du matériel possédé en propre et le partager avec d’autres. Je travaille actuellement à faire tourner GLM 5.2 à environ 10 tok/s avec ce type de partitionnement
  • Les performances peuvent s’estimer assez simplement. En décodage auto-régressif, il faut transmettre sur le réseau environ 2 × hidden_size × num_shards octets par token, et pour le préremplissage, il suffit de diviser cette valeur par la taille des chunks
  • C’est comparable à la vitesse que j’obtiens en exécutant Qwen3.6-35B-A3B sur un Framework 13 équipé d’un AMD Ryzen AI 9 HX 370. Si l’on obtient la même vitesse avec des modèles bien plus gros, c’est impressionnant

• Je suis plus intéressé par l’inférence distribuée de petits modèles de langage conçus pour un usage précis que par les LLM pour le code. Pour le traitement d’images, la radio logicielle (SDR), l’observation météo locale, etc., on pourrait obtenir des sorties fiables tout en restant exécutable sur du matériel ordinaire

  • Au lieu d’un seul modèle avec X experts actifs, une configuration avec 10 modèles différents, petits et denses, entraînés sur des informations spécifiques, chacun déployé sur l’un des 10 serveurs et relié via un routeur, me semble adaptée

• Je contribue à Mesh LLM et j’ai créé le moteur skippy qui permet de répartir de grands modèles sur plusieurs nœuds. Je répondrai volontiers aux questions

  • Ravi de voir des technologies liées à IPFS refaire surface. J’ai deux questions
    Premièrement, si l’on distribue le calcul de cette manière, tous les participants du graphe de calcul connaissent la séquence en cours de traitement ; comment gérez-vous la protection de la vie privée ? Deuxièmement, existe-t-il des garde-fous pour empêcher un participant malveillant de corrompre les activations du modèle ?
  • Je me demande quelle est l’incitation à participer au mesh public. Si quelqu’un fournit 1/8 de la VRAM nécessaire pour exécuter un modèle donné, y a-t-il au moins une garantie d’équité du type recevoir 1/16 de l’usage d’inférence ?
  • Y aurait-il un avantage à l’intégrer avec le projet Colibri publié il y a quelques jours ?
  • Je n’ai jamais vraiment examiné en profondeur l’implémentation du cache KV, mais je me demande si l’on exploite en pratique un cache indépendant par couche
    Si c’est le cas, cela semble se partitionner proprement en termes de calcul et de volume de données, et chaque couche ne ferait que ralentir en attendant son tour. Avec un pipeline, on pourrait aussi exécuter plusieurs requêtes en parallèle
    Existe-t-il des cas où un pipeline à N étapes, avec des requêtes injectées en décalé d’une étape, a été utilisé pour implémenter du best-of-N ?
  • Je dirige un labo avec de nombreux processeurs EPYC et de nombreux modèles différents, et je trouve impressionnant qu’on puisse les regrouper de cette manière

• En cherchant des LLM fonctionnant avec une approche de calcul distribué similaire, je suis tombé sur AI Horde, quelques essais modestes du côté d’Aphrodite, et l’apprentissage distribué de Nous Research
  Parmi eux, AI Horde semble être le plus important. Son API utilise le format de complétion texte de KoboldCPP plutôt qu’une complétion de chat. Cela expose davantage de variables de réglage et donne de meilleurs résultats en jeu de rôle, ce qui semble fortement plaire aux membres actifs de cette communauté. Pour les autres usages, il faudra sans doute surtout des appels d’outils, donc je ne vois pas très bien à quoi cela peut servir hors du jeu de rôle
  Cette semaine, j’ai commencé à améliorer le bridge OpenAI pour prendre en charge les chat templates et le parsing des réponses. Si j’arrive à le faire intégrer dans la distribution officielle, on pourra peut-être l’utiliser pour le code même en devant passer par des modèles orientés jeu de rôle
  Les dispositifs anti-abus sont également plus aboutis. Pour éviter les attaques coordonnées, un worker doit cumuler une semaine de temps de fonctionnement avant d’être reconnu comme fiable, et les utilisateurs peuvent choisir uniquement des workers de confiance. En faisant tourner un worker, on gagne des kudos, utilisables pour des générations de plus de 512 tokens, et les requêtes gratuites sont reléguées tout au bout de la file d’attente

• Je me suis demandé ce que pourrait faire un botnet polymorphe exécutant un ou plusieurs LLM distribués. L’idée serait d’utiliser tous les hôtes du botnet comme ressources de calcul en cluster pour faire tourner des LLM, tout en faisant évoluer les modes de propagation et les charges utiles de chaque cluster du botnet
  Les variantes nuisibles seraient détectées puis supprimées, les modes de propagation inefficaces ne se diffuseraient pas, mais les meilleures versions survivraient et continueraient à croître. C’est assez proche de l’architecture présentée ici, et QUIC fonctionne de manière très dynamique, ce qui pourrait rendre la détection plus difficile qu’on ne le pense

• Le projet https://query.mt/ utilise depuis un moment déjà un mesh basé sur iroh. Si vous voulez essayer des modèles mesh sur téléphone, cela peut valoir le coup d’œil

• J’ai passé pas mal de temps à essayer de faire tourner mesh-llm, mais parmi les builds installables de llama.cpp, aucun ne fonctionnait avec mon vieux GPU. Il semblait possible de passer par proxy vers un service llama.cpp externe, mais je n’ai pas non plus réussi cette configuration
  Le projet est très intéressant, mais il reste encore pas mal d’aspects peu aboutis

  • Si vous m’envoyez un rapport de bug, j’aimerais essayer de résoudre ça avec vous pour le faire fonctionner

• J’avais pensé que cette approche pouvait être possible et j’avais posé la question à ChatGPT il y a environ un an, mais on m’avait répondu que c’était impossible à cause d’une latence trop élevée. À l’époque, j’étudiais libp2p depuis presque un an en cherchant un projet où l’utiliser