Mesh LLM : agréger des GPU hétérogènes derrière une seule API compatible OpenAI

Le problème : faire cohabiter des machines qui ne peuvent pas héberger le même modèle

Un modèle dense de grande taille ne tient pas sur une seule machine, mais un parc de machines modestes peut souvent cumuler assez de mémoire. La difficulté n'est pas le calcul, c'est la coordination : savoir quel pair peut servir quel modèle, router la requête vers lui, et découper le modèle quand aucun pair n'y arrive seul. Mesh LLM prend cette coordination à sa charge et la cache derrière une API compatible OpenAI exposée sur http://localhost:9337/v1. Le public visé est double. D'un côté des opérateurs qui possèdent déjà plusieurs machines et veulent les traiter comme une seule ressource. De l'autre des développeurs qui écrivent des agents et veulent un endpoint stable, sans se soucier de la topologie sous-jacente. Le README résume l'intention en une phrase : « Start one node, add more nodes later, and let the mesh decide whether a model runs locally, routes to a peer, or uses Skippy stage splits for models that are too large for one box. »

Le routage par champ model et le premier critère : tenir sur une seule machine

Le mécanisme central est simple à énoncer. Chaque nœud expose la même API /v1, et la requête est dirigée vers le pair capable de servir le modèle demandé, en lisant le champ model du corps JSON. Le README formule la règle ainsi : « Requests are routed by the model field to the peer that can serve that model. » Avant de router, le système tente de faire tenir le modèle sur un seul nœud. Si c'est possible, le modèle est servi localement et aucun trafic d'étages n'est généré. C'est une décision de conception qui a un coût et un bénéfice. Le bénéfice est évident : pas de latence réseau ajoutée, pas de coordination inutile. Le coût l'est moins : le comportement du maillage dépend de la capacité de chaque machine, donc deux déploiements avec le même modèle peuvent produire des topologies de routage différentes. La documentation ne décrit pas de mécanisme de forçage explicite pour empêcher un nœud de servir localement un modèle qu'il pourrait héberger, en dehors du mode --local-model-only qui va dans la direction inverse.

QUIC, relais Iroh et la séparation entre plan public et plan de contrôle

Le transport entre nœuds passe par QUIC, avec chiffrement de bout en bout. Le README précise que cela couvre « inference requests, responses, and split-model activations », donc y compris les activations échangées lors d'un découpage de modèle. Les relais Iroh acheminent des paquets chiffrés sans lire leur contenu. Un point mérite l'attention : la documentation distingue deux plans. Les actions d'inventaire et de configuration opérateur passent par une voie additive nommée mesh-llm-control/1, avec un bootstrap d'endpoint explicite. La jonction au maillage public, le gossip, le routage et l'inférence restent sur le plan public, ce qui est présenté comme une condition de compatibilité entre versions mélangées. Cette séparation est un choix défendable, mais elle signifie que toute évolution du format de contrôle peut nécessiter un bootstrap explicite côté opérateur. Le README ne détaille pas la procédure de bascule entre versions de ce plan.

Skippy : découper un modèle dense en étages ordonnés

Quand aucun nœud ne peut héberger le modèle entier, l'option --split entre en jeu. Le modèle est chargé sous forme d'étages de couches contigus, décrits comme « package-backed layer stages ». Le coordinateur planifie ces plages, démarre les étages en aval d'abord, attend qu'ils soient prêts, puis publie la route vers l'étage 0. L'ordre compte : publier la route avant que les étages aval soient prêts exposerait les requêtes à un échec. Les dépôts de paquets contiennent un fichier model-package.json accompagné de fragments GGUF, ce qui permet à chaque pair de ne récupérer que les morceaux correspondant à son étage assigné. C'est le point le plus intéressant du projet sur le plan architectural, et aussi le plus difficile à évaluer depuis le seul README : la documentation renvoie à docs/SKIPPY_SPLITS.md sans en résumer les contraintes de mémoire par étage ni le comportement en cas de perte d'un pair en cours d'inférence.

Mise en route : les commandes réellement documentées

L'installation se fait par script, avec une variante PowerShell pour Windows et une formule Homebrew pour Apple Silicon. Les commandes données sont curl -fsSL https://raw.githubusercontent.com/Mesh-LLM/mesh-llm/main/install.sh | bash, irm https://raw.githubusercontent.com/Mesh-LLM/mesh-llm/main/install.ps1 | iex, et brew install Mesh-LLM/tap/mesh-llm. La configuration se termine par mesh-llm setup, ou mesh-llm.exe setup sous PowerShell. Pour rejoindre le maillage public et servir, la commande est mesh-llm serve --auto : elle choisit une variante de backend, télécharge un modèle adapté si nécessaire, rejoint le meilleur maillage public découvert, démarre l'API locale sur 9337 et la console web sur 3131. La vérification des modèles disponibles se fait avec curl -s http://localhost:9337/v1/models | jq '.data[].id', et l'envoi d'une requête avec un POST sur /v1/chat/completions incluant Content-Type: application/json. Pour un déploiement serveur, --headless masque l'interface web tout en conservant l'API de gestion sur le port indiqué par --console. La désinstallation se prévisualise avec mesh-llm uninstall --dry-run avant mesh-llm uninstall --yes, et le README précise que ~/.mesh-llm n'est supprimé que si --purge-config est passé explicitement.

Le mode local-only : un choix de refus assumé

Le mode --local-model-only expose un modèle complet via l'API OpenAI sans devenir un nœud du maillage. Il démarre le frontend OpenAI et un seul runtime Skippy local, et n'active ni QUIC, ni découverte, ni maintenance de pairs, ni planification de découpage, ni plugins, ni recherche de release, ni console web, ni API de gestion. Deux contraintes sont explicites dans le README. D'abord, le démarrage échoue si le modèle complet ne tient pas dans la capacité locale détectée ou dans --max-vram : il n'y a jamais de repli vers le service distribué. Ensuite, pour ce mode ainsi que pour --model, --gguf et --mmproj, les valeurs doivent être des chemins absolus et ne doivent pas être des liens symboliques. Cette dernière règle est une vraie contrainte opérationnelle pour les déploiements qui utilisent des liens vers des volumes montés. Le refus de basculer automatiquement vers le distribué est cohérent avec l'objectif du mode, mais il transforme une erreur de dimensionnement en échec de démarrage plutôt qu'en dégradation progressive.

Mixture-of-Agents et l'alternative : ce que change le champ model

En envoyant model: "mesh", la requête est diffusée en parallèle vers tous les modèles disponibles dans le maillage, puis arbitrée par une logique déterministe codée, qui ne fait appel à un LLM réducteur qu'en cas de conflit réel. Le README encadre cette fonctionnalité d'un avertissement explicite : elle est nouvelle dans cette release, et « Behavior, routing heuristics, error shapes, and tuning knobs may change between versions ». Il demande de traiter model: "mesh" comme un aperçu plutôt qu'un chemin de production stable, et de citer un identifiant de modèle précis quand une sémantique stable est nécessaire. C'est ici que se situe la vraie alternative au sein du projet : un identifiant de modèle nommé donne un routage déterministe vers un pair identifié, tandis que model: "mesh" échange cette prévisibilité contre une agrégation de réponses dont les règles peuvent évoluer. Le README indique aussi que les appels d'outils traversent l'ensemble du pipeline, mais la section fournie est tronquée et ne permet pas de confirmer les conditions d'activation exactes.

Coût de maintenance, licence et ce que la documentation ne dit pas

Le dépôt est actif, la dernière poussée datant du 9 septembre 2026, et les trois dernières publications sont des release candidates de la série 0.76.0, la plus récente étant v0.76.0-rc9. Suivre une série de RC implique de relire les notes de version avant chaque mise à jour, en particulier pour les fonctionnalités marquées expérimentales comme le gateway MoA. La licence est Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et d'état des modifications ; ce paragraphe n'est pas un avis juridique et une revue par un professionnel reste nécessaire avant toute redistribution. Le projet s'appuie par ailleurs sur un dépôt séparé, Mesh-LLM/mesh-packaging, pour les formules versionnées, les paquets Ubuntu et Arch, les sommes de contrôle, les SBOM et les images OCI : la chaîne de publication est donc répartie sur deux dépôts, ce qui ajoute un point de synchronisation à surveiller. Enfin, plusieurs points restent non documentés dans le matériel fourni : le comportement du maillage lorsqu'un pair disparaît pendant une inférence découpée, la consommation mémoire par étage Skippy, et les conditions exactes d'activation du gateway MoA, la section du README étant tronquée.

Conclusion éditoriale

Adoptez Mesh LLM si vous voulez exposer un parc de machines hétérogènes derrière une API compatible OpenAI sans écrire vous-même la couche de routage, et si vous acceptez de suivre une série 0.76.0 en release candidates. Évitez-le si votre charge exige une sémantique de routage figée : la fonctionnalité Mixture-of-Agents est explicitement marquée expérimentale dans le README, et le mode --local-model-only échoue volontairement plutôt que de basculer en distribué. Avant tout déploiement, vérifiez trois choses concrètes : que le modèle complet tient dans la capacité locale détectée ou dans --max-vram, que vos chemins --model, --gguf et --mmproj sont absolus et ne sont pas des liens symboliques, et que le port 9337 est bien celui que vous voulez exposer si vous ajoutez --listen-all.

Sources officielles

1. License: Apache-2.0
2. Mesh-LLM/mesh-llm on GitHub
3. Project website
4. README
5. Releases