Murmuration

La nuée d'étourneaux : des dizaines de machines de bureau faibles qui se meuvent comme un seul organisme.

Murmuration transforme un parc de machines de bureau hétérogènes (Windows + macOS), piloté par Active Directory, en un pool de calcul LLM distribué, exposé via un endpoint OpenAI-compatible. Il privilégie les gros GPU, donne la priorité absolue à l'utilisateur assis au poste, et est conçu pour gagner en puissance automatiquement à mesure que les modèles deviennent plus denses.

Projet open-source · Org JAIKIN-SASU · Licence MIT.

---

Pourquoi

Acheter des GPU cloud coûte cher et expédie vos données ailleurs. Pendant ce temps, un parc de PME dort la nuit et tourne au ralenti le jour. Murmuration récolte cette capacité existante pour servir des modèles d'IA en local, sous votre contrôle.

L'intention : démocratiser le calcul IA, réutiliser le matériel déjà payé, garder les données sur site.

Ce que Murmuration fait (et ne fait pas)

✅ Pool de répliques : chaque poste capable sert une copie d'un modèle qui tient chez lui (7B–14B quantifié, plus sur les gros GPU) ; la gateway répartit les requêtes. ✅ Priorité utilisateur : un poste dont l'utilisateur est actif sort du pool. ✅ Gros GPU d'abord, auto-scaling par profondeur de file. ✅ Endpoint OpenAI-compatible : vos clients existants marchent sans changement. ✅ Failover borné : retry sur une autre réplique et cooldown du node fautif. ✅ Charge réelle : chaque routage réserve immédiatement le node pour répartir les requêtes concurrentes entre les répliques. ✅ Hétérogène : NVIDIA (CUDA), Apple Silicon (Metal), CPU — via Ollama. ✅ Prévu pour les modèles CPU-native : backend bitnet-cpp réservé pour les modèles 1.58-bit/BitNet quand ils deviennent utiles en production.

❌ Pas d'agrégation mémoire transparente entre machines (physiquement impossible). ❌ Pas d'inférence interactive d'un très gros modèle éclaté sur le parc : sur LAN ordinaire, ça plafonne à 0,85–6 tok/s (utilisable en batch nuit uniquement, 2-4 nœuds). ❌ Pas de tensor parallel sur réseau ordinaire (réservé InfiniBand/NVLink).

Le détail chiffré est dans docs/PROBLEMS-AND-CONSTRAINTS.md. Le benchmark des projets voisins et les concepts retenus sont dans docs/OPEN-SOURCE-LANDSCAPE.md.

Architecture

Clients ──HTTP (API OpenAI) ─▶  CONTROL PLANE (murmur server)
                                  gateway · scheduler · registry · file batch
                                          │ HTTP/JSON (heartbeat + télémétrie)
                                          ▼
                         AGENTS (murmur agent, 1/poste) ─▶ Ollama / llama.cpp RPC

Détail dans docs/DESIGN.md et les ADR.

Démarrage rapide

Prérequis : Go 1.26+ et Ollama sur les postes.

# 1. Construire le binaire
make build      # → bin/murmur

# 2. Sur le serveur : lancer le control plane
bin/murmur server --addr :8080 --token MON_TOKEN

# 3. Sur chaque poste : lancer l'agent (Ollama doit tourner localement)
bin/murmur agent --server http://serveur:8080 \
  --token MON_TOKEN \
  --ollama http://127.0.0.1:11434 \
  --gpu-vendor nvidia --gpu-vram-mb 24000 \
  --presence free

L'agent ouvre par défaut un proxy d'inférence minimal sur le port 11435, joignable uniquement avec le token partagé. Il annonce automatiquement l'adresse LAN utilisée pour atteindre le serveur : Ollama peut donc rester lié à 127.0.0.1:11434. Ouvrez le port TCP 11435 entre le control plane et les postes, ou utilisez --listen / --advertise-url si le réseau impose une adresse précise.

Sans override manuel, GPU et VRAM sont auto-détectés. La présence démarre en mode sûr active ; passez explicitement --presence idle ou --presence free tant que les sondes de présence natives ne sont pas installées.

Appeler l'endpoint comme l'API OpenAI :

curl http://serveur:8080/v1/chat/completions \
  -H "Authorization: Bearer MON_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3:8b","messages":[{"role":"user","content":"Bonjour"}]}'

GET /v1/models liste les modèles chargés sur le parc. stream:true est supporté (SSE). Voir aussi les exemples Python et JavaScript avec les SDK OpenAI. GET /metrics expose les compteurs Prometheus du control plane (requêtes, erreurs, retries, tokens, latence cumulée, modèles, nodes et requêtes en vol) ; il utilise le même Bearer token que l'API.

Trois leviers de 10x

1. Pari densité (dès maintenant) — quand un 14B atteindra la qualité d'un 70B d'aujourd'hui, le même parc servira « du gros » sans rien changer. ADR-0006
2. CPU-native 1.58-bit (proposé) — BitNet/bitnet.cpp peut rendre les postes CPU-only utiles pour des modèles et batchs adaptés, sans GPU. ADR-0009
3. Sharding optimisé par IA (recherche) — un modèle planifie la découpe et masque la latence pour 10x les tok/s du mode nuit. ADR-0007

Développement

make test       # tests + couverture
make vet        # go vet
make cover      # rapport HTML de couverture
make dist       # binaires Windows / macOS / Linux

Statut

v0.2 — fondation + détection GPU automatique (NVIDIA / Apple Silicon). v0.1 livrait le control plane, le scheduler présence-aware, la gateway OpenAI, le backend Ollama et l'agent cross-plateforme. Détail dans le CHANGELOG. Prochaines étapes (v0.3) : connecteur Active Directory, mode nuit pipeline. Voir la feuille de route et les issues.

Contribuer

Voir CONTRIBUTING.md. Les PR sont bienvenues.

Licence

MIT © 2026 JAIKIN SASU.