Murmuration : un cluster LLM open-source à partir d'un parc de bureau

Projet open-source · github.com/Jaikin-SASU/murmuration · binaire murmur · version actuelle v0.2 (licence MIT).

Pourquoi ce projet : réutiliser plutôt qu'acheter

Le point de départ est une frustration concrète. Une PME veut faire de l'inférence LLM en interne — pour des raisons de coût, de confidentialité des données et de souveraineté — mais elle ne va pas câbler une salle serveur de GPU pour autant. Or elle possède déjà un parc d'une trentaine de postes de bureau, hétérogènes (NVIDIA, Apple Silicon, Windows, CPU seul), pilotés par un Active Directory.

Murmuration part de cette réalité : le matériel est déjà là, payé, et largement sous-utilisé. L'objectif est de le fédérer en un pool de calcul, sans envoyer une seule donnée dans le cloud et sans jamais voler son outil de travail à l'utilisateur assis au poste. Le tout en open-source, pour que n'importe quelle organisation puisse l'auditer, l'adapter et l'héberger chez elle.

1. Ce que Murmuration sait faire aujourd'hui

La fondation actuelle repose sur une décision structurante : le substrat du cluster est un pool de répliques, pas une agrégation de mémoire. Chaque poste capable fait tourner une copie entière d'un modèle qui tient dans sa VRAM/RAM (typiquement 7B–14B quantifié, jusqu'à ~30B sur les gros GPU). Une passerelle répartit les requêtes sur ces répliques.

Un endpoint compatible OpenAI

Côté client, rien d'exotique : Murmuration expose un contrat public stable et compatible OpenAI (/v1/chat/completions, /v1/embeddings, /v1/models), avec authentification adossée à l'Active Directory. Vos applications, scripts et outils existants parlent au cluster comme à n'importe quelle API LLM. Ce contrat ne change pas quand l'interne évolue.

Une priorité absolue : l'utilisateur assis au poste

Un poste est avant tout l'outil de travail de quelqu'un. Lui prendre le GPU ou le CPU pendant qu'il travaille est inacceptable. Murmuration applique donc un garde-fou de présence local sur chaque agent, avec une politique à trois niveaux :

Si l'utilisateur se remet à taper pendant une inférence, l'agent throttle immédiatement le moteur et signale au planificateur de ne plus l'élire. Objectif n°1 : l'utilisateur ne doit jamais subir de ralentissement perceptible.

Gros GPU d'abord, backends pluggables

Le planificateur score chaque poste (VRAM libre, niveau de GPU, présence, pénalité réseau) et envoie la requête au meilleur node qui a déjà le modèle chargé — sinon il en chauffe un. Un GPU dédié costaud passe avant un GPU moyen, lui-même avant Apple Silicon, lui-même avant le CPU. Derrière une interface Backend unique, deux moteurs cohabitent : Ollama pour les répliques (simple, Windows + Mac, CUDA + Metal) et llama.cpp RPC pour l'éclatement de modèle. Des backends futurs (vLLM, MLX…) s'y branchent sans toucher au planificateur.

2. Les limites, en toute honnêteté (et chiffrées)

C'est la partie qu'on ne voit jamais dans les annonces marketing. Pourtant, elle est essentielle pour décider si Murmuration répond à votre besoin. Trois murs techniques, mesurés, et assumés.

Pas d'agrégation mémoire transparente

L'intuition séduisante — « le gros modèle vit sur le serveur, les postes prêtent juste leur RAM/GPU » — n'est pas réalisable. Le calcul doit se faire là où se trouvent les poids. « Emprunter » de la mémoire distante pour de l'inférence n'existe pas : il faudrait envoyer une part du modèle sur chaque poste et l'y exécuter. Toute approche « mémoire partagée réseau » est donc écartée.

Un très gros modèle en interactif éclaté sur le parc : inutilisable

On pourrait être tenté d'éclater un modèle de classe 70B sur ~30 postes faibles. Les mesures publiques sur des clusters grand public (2025-2026) sont sans appel : 0,85 à 6 tokens par seconde. C'est utilisable en traitement par lots asynchrone, jamais en chat fluide.

Contre-intuitivement, le goulot d'étranglement n'est pas la bande passante. En pipeline, seul le vecteur d'activation traverse le réseau — environ 16 Ko par token en FP16, ~8 Ko en activations quantifiées 8-bit. Un simple lien 1 GbE porterait des milliers de tokens/s de pur trafic d'activations. Le vrai ennemi, c'est la latence en série (chaque token traverse les N machines l'une après l'autre, en décodage autorégressif) combinée à la compute des postes faibles. Les plafonds réseau seuls, compute ignorée, donnent déjà la mesure du problème :

La compute des postes faibles fait ensuite chuter le débit réel bien en dessous de ces plafonds. D'où la fourchette mesurée de 0,85 à 6 tok/s. Conséquence pratique : les très gros modèles restent sur un serveur central dédié ; le parc sert les modèles petits et moyens, l'overflow et les tâches parallélisables.

Pas de tensor parallel sur LAN ordinaire

Le tensor parallel — l'autre façon d'éclater un modèle — exige deux all-reduce synchrones bloquants par couche et par token (de l'ordre de 160 allers-retours pour 80 couches), sur le chemin critique. Cela suppose du NVLink/InfiniBand ou au minimum du 10 GbE. La documentation de vLLM est explicite : un tensor parallel efficace requiert une interconnexion très rapide. Sur un LAN d'entreprise ordinaire, c'est exclu. Pour tout éclatement, Murmuration n'utilise donc que du pipeline / ring parallel, et uniquement sur 2 à 4 nœuds stables — au-delà, la latence série tue le gain. Cet éclatement est réservé au mode batch, la nuit.

3. Ce qu'on attend prochainement

Ces limites ne sont pas des impasses : ce sont des hypothèses datées, consignées pour être réévaluées quand le matériel et les modèles progressent. Voici où en est le projet et ce qui vient.

La feuille de route détaillée, les issues et les milestones sont publics sur le dépôt GitHub. Les trois chantiers structurants sont détaillés ci-dessous.

Le mode nuit en pipeline

Quand les sessions sont fermées et les postes « libres », Murmuration peut basculer un groupe de 2 à 4 nœuds stables en pipeline (via llama.cpp RPC) pour faire tourner, en batch, un modèle un cran plus gros que ce qu'une seule machine encaisse. On n'attend pas du chat fluide : on draine pendant la nuit les tâches parallélisables où trente machines faibles brillent vraiment — embeddings, indexation RAG, classification, génération par lots.

Le « pari densité » : un 10x gratuit

C'est le pari stratégique du projet. La thèse : la capacité par gigaoctet des modèles augmente plus vite que tout le reste. Un 14B d'aujourd'hui rivalise déjà avec un 70B d'il y a dix-huit mois. Conséquence : on ne parie pas sur le réseau (un mur physique), on parie sur les modèles qui rétrécissent.

Le même pool de répliques qui sert un 14B aujourd'hui servira, dans 12-18 mois, un modèle aussi capable que les 70-200B actuels — parce qu'il tiendra dans la même VRAM. L'architecture ne change pas ; seuls les fichiers de modèles changent. Le 10x arrive tout seul, à condition que la fondation reste model-agnostic. C'est exactement pour ça que le contrat public est stable et que les backends sont pluggables.

La piste recherche : un sharding optimisé par l'IA

Second levier, plus spéculatif. Le sharding sur réseau lent n'est pas un mur physique absolu : c'est un problème d'optimisation difficile (quelle couche sur quel node, comment masquer la latence série, comment prefetcher et spéculer). Or la bande passante n'étant pas le facteur limitant, il reste des marges.

L'idée : confier cette optimisation à un modèle (type Fable, ou un futur « Mythos »). Quelques directions explorées, sans engagement pour la v1 : un planificateur de partition appris qui ingère le graphe du parc (compute, latence par lien, VRAM, présence) et produit le meilleur découpage ; du décodage spéculatif distribué (un petit modèle « draft » propose des tokens, vérifiés en lot par le modèle shardé) pour amortir la latence série ; du masquage de latence par prefetch agressif. La mesure de succès est simple et honnête : tok/s avant/après sur le même matériel et le même LAN.

Sources des chiffres : mesures publiques de clusters grand public (2025-2026) sur le sharding LLM — Petals (physique réseau), prima.cpp (ring + prefetch), llama.cpp RPC et benchmarks de clusters multi-machines. Les fourchettes de débit dépendent du matériel et du réseau ; elles sont consignées pour être réévaluées à chaque progrès matériel ou modèle.