Ce vieux GPU à 8 Go peut faire tourner 3 IA en même temps : voici comment

0.00.592.688 E ggmlbackendcudabuffertypeallocbuffer : allocation de 1536,00 MiB sur l'appareil 0 échouée : cudaMalloc a manqué de mémoire.
0.00.593.132 E llamainitfrom_model : échec d'initialisation du contexte : impossible d'allouer le buffer pour le cache KV.

UNE CATASTROPHE QUI PARLE À TOUT LE MONDE

Vous avez trois agents IA qui tournent chacun avec un modèle différent : un pour générer du code, un pour vérifier la sécurité, et un pour rédiger la documentation. Tout doit se faire en temps réel, sans latence. Problème : votre carte graphique est une antiquité, une NVIDIA GTX 1080 avec seulement 8 Go de VRAM. Impossible d'ajouter un deuxième modèle sans voir le troisième s'écrouler avec une erreur cudaMalloc failed: out of memory.

L'erreur est humaine, mais dans ce cas précis, elle vient d'un système conçu pour un seul utilisateur à la fois. Chaque modèle essaie de réserver l'intégralité du cache KV dès le démarrage, avant même d'avoir généré un seul token. Résultat : le premier modèle prend 6,5 Go sur 8, et les deux suivants n'ont plus rien. Le cache KV, c'est comme une place de parking réservée pour chaque mot généré. Si vous réservez 172 032 places d'un coup, même sur un petit modèle, ça fait mal.

POURQUOI LES TUTORIELS VOUS MENTENT (GENTIMENT)

Les tutoriels classiques vous disent : « Lancez trois processus séparés, ça devrait marcher ». Sauf que personne ne précise que chaque processus essaie de s'emparer de la mémoire vidéo comme un enfant dans un magasin de bonbons. Le premier modèle prend tout, les autres n'ont plus leur chance. Le système n'a pas de file d'attente, pas de comptabilité partagée. C'est comme si trois personnes essayaient de garer leur voiture sur une seule place : deux vont se faire klaxonner.

L'erreur n'est pas dans l'algorithme, mais dans l'absence de gestion des ressources. Il manque un comptable qui dit : « Non, tu ne peux pas réserver ça maintenant, il n'y a plus de place ». C'est exactement ce que propose l'outil lmxd, un démon C++ qui prend le contrôle de la carte graphique et décide qui a le Droit de l'utiliser.

LE COMPTABLE QUI SAUVE VOTRE GPU

Le cœur du système s'appelle le VRAM Ledger. Son rôle ? Vérifier que la somme de la mémoire déjà utilisée + la nouvelle réservation ne dépasse pas 90 % de la capacité totale. La règle est simple : currentlyused + newestimate ≤ 90 % cap.

Voici le code qui fait tout le travail, en quelques lignes seulement :

bool VramLedger::tryreserve(uint64t modeltablebytes) {
  // Une section critique pour éviter les conflits entre processus parallèles
  std::lock_guard lock(mu_);
  if (.initialized_) {
    return false;
  }
  uint64_t projected = 0;
  if (.addu64(allocatedbytes, modeltable_bytes, &projected)) {
    return false;
  }
  if (projected > maxvrambytes_) {
    return false;
  }
  allocatedbytes = projected;
  return true;
}

Le mutex est crucial : sans lui, deux processus pourraient passer la vérification en même temps et réserver plus que ce qui est disponible. Personne n'a envie de déboguer une course à la mémoire, surtout à 2 heures du matin.

LA BONNE ORDRE DES CHOSES : D'ABORD VÉRIFIER, ENSUITE CHARGER

L'erreur classique ? Charger le modèle d'abord, puis vérifier la mémoire. Résultat : vous avez déjà lu 1 Go de données sur le disque pour un modèle que vous allez refuser. Pire : vous avez lancé une allocation cudaMalloc qui va échouer, mais trop tard pour annuler le chargement. Book before you build, disent les développeurs : réserve d'abord, construis ensuite.

Le gestionnaire de modèles dans lmxd fait exactement ça. Il initialise le backend CUDA une seule fois pour toute la carte, et réutilise les modèles déjà chargés si deux agents demandent la même version. Plus besoin de gaspiller de la mémoire avec trois processus séparés.

bool LlamaSingleService::acquiremodel(const std::string& path, std::string* errout) {
  // Protège chaque point d'entrée pour éviter les conflits
  std::lock_guard lock(mu_);

  if (.backendinited) {
    // Initialise les backends CPU/GPU une seule fois
    llamabackendinit();
    backendinited = true;
  }

  const auto it = models_.find(path);
  if (it .= models_.end()) {
    // Réutilise un modèle déjà chargé et incrémente le compteur
    it->second.refcount += 1;
    return true;
  }

  // Charge un nouveau modèle si nécessaire
  llamamodelparams params = llamamodeldefault_params();
  llamamodel* model = llamamodelloadfromfile(path.cstr(), params);
  if (model == nullptr) {
    if (err_out .= nullptr) {
      *errout = "llamamodelloadfrom_file a échoué pour le chemin : " + path;
    }
    return false;
  }

  ModelSlot slot{};
  slot.model = model;
  slot.refcount = 1;
  models_.emplace(path, std::move(slot));
  return true;
}

LA DÉMONSTRATION EN PRATIQUE

Pour tester, rien de plus simple. On commence par trois modèles légers mais puissants : SmolLM2-360M-Instruct-Q4KM, Qwen2-0.5B-Instruct-Q4KM et Llama-3.2-1B-Instruct-Q4KM. Ensemble, ils pèsent environ 1,4 Go sur le disque. Sur une GTX 1080 avec 8 Go de VRAM, la mémoire utilisée avant tout lancement ? 22 Mo.

Première tentative avec la méthode classique : on lance le premier modèle, et hop, 6,5 Go sont réservés immédiatement. Le deuxième modèle essaie de s'ajouter : cudaMalloc échoue, le processus meurt. Le troisième aussi. Résultat : un seul modèle tourne, les deux autres laissent des logs d'erreur.

Avec lmxd, c'est différent. On lance le démon avec une table qui associe chaque modèle à sa taille sur disque. On utilise l'option --admission-percent 90 pour limiter l'utilisation à 90 % de la mémoire. Puis on enregistre les trois modèles via une socket Unix :

./build/src/lmxd --socket /tmp/lmxd.sock --vram-table configs/model_vram.example.txt &
nc -U /tmp/lmxd.sock <

OK schema=lmx-daemon/1
OK invoke=DECODE agent_id=smol
OK prompttokens=4 generatedtokens=24 stoppedoneos=false
OK elapsed_ms=125.495
OK kvswapevicted=qwen kvswaprestored=true
BEGIN_RESPONSE
[Weather]. I'm looking forward to seeing you all. I'm [Your Name] and I'm a [Your
END_RESPONSE

git clone  && cd 
cmake -S . -B build -DCMAKEBUILDTYPE=Release -DLMXWITHLLAMA_CUDA=ON
cmake --build build -j"$(nproc)"

# Démo de superposition (sans modèle requis) :
./build/src/layerstreamdemo

# Lancement du démon :
./build/src/lmxd --socket /tmp/lmxd.sock --vram-table configs/model_vram.example.txt &

# Enregistrement des modèles :
nc -U /tmp/lmxd.sock <