Phase 0 — Le moteur : linkcpp, un plan de contrôle pour moteur d'inférence

moteur d'inférence livre un plan de données RPC capable mais aucun plan de contrôle. linkcpp ajoute la moitié manquante — découverte, planification, lancement et gateways — autour de binaires compilés au plus près de l'upstream.

Tout ce que Kvasir fait tourner commence ici. linkcpp est un plan de contrôle à source disponible (Business Source License) autour du plan de données RPC du moteur d'inférence : il exécute de grands modèles d'IA sur plusieurs GPU et machines avec des binaires ggml-rpc-server / llama-server compilés au plus près de l'upstream. Le plan de données ne porte qu'un petit ensemble de correctifs — tout le reste de ce qu'ajoute linkcpp est de l'orchestration.

Le manque

Un plan de données sans plan de contrôle

moteur d'inférence sait déjà répartir un modèle entre machines via RPC — mais quelqu'un doit découvrir les GPU, décider quelles couches vont où, lancer les bons workers avec les bons budgets, vérifier que chaque nœud parle le même protocole, et exposer une API que les développeurs peuvent réellement appeler. Le faire à la main pour un cluster est une corvée ; le faire pour un réseau ouvert d'appareils d'inconnus est impossible. Cette couche de coordination, c'est linkcpp.

Architecture

Un hub, des workers basés sur l'upstream, des gateways standard

Flux de requête — le hub orchestre, les binaires basés sur l'upstream calculent.

browser / SDK
  → hub :19000                      # FastAPI control plane (single Docker image)
  → GPU-less llama-server master    # per-controller, :8080+
  → ggml-rpc-server workers         # local slots, remote units, managed agents
A control deck orchestrating rows of inference engines below
  • Trois façons de rejoindre : des slots de nœud locaux fixes aux budgets VRAM/RAM/CPU éditables ; des unités distantes — enregistrer un autre hub et importer ses nœuds ; et des agents de nœud managés — services worker-only rejoignant par simple HTTP requête/réponse, volontairement sans flux persistant, pour survivre aux routages LAN/VPN simples.
  • Le gating de compatibilité est de premier ordre : chaque unité, nœud et agent rapporte une identité protocole/runtime-pack plus des détails de backend. Les désaccords d'unité, de runtime-pack, de révision moteur d'inférence et d'ABI RPC sont bloqués en dur avant bind, plan, load ou infer — les différences de backend (CUDA/Metal/Vulkan/CPU) sont suivies comme capacités, pas comme rejets.
  • Le planner lit les métadonnées GGUF et produit un placement contigu de couches par nœud, --tensor-split, des estimations de VRAM KV-cache/couche/expert, et un offload optionnel des FFN d'experts en RAM.
  • Gateways : chaque contrôleur expose des endpoints compatibles OpenAI (/v1/chat/completions, /v1/models) et Anthropic (/anthropic/v1/messages|models), adossés au même modèle chargé — les clients existants fonctionnent tels quels.

Cette séparation délibérée — un plan de données maintenu proche de l'upstream sous un plan de contrôle à source disponible — est ce sur quoi tout le reste se construit : le ring runtime, le marché de couches, et finalement l'essaim d'experts sont autant d'évolutions du plan de contrôle sur le même calcul.