La passerelle LLM open source KTMS 1.0 branche ses propres GPU au cloud et résiste aux pannes

KTMS (Keystone. The Model Switchboard) est une passerelle LLM open source écrite en Go : un point d'entrée unique par lequel les applications d'une entreprise accèdent aux modèles de différents fournisseurs. Les auteurs ont publié la version 1.0 et détaillé le comportement de la passerelle en production. On peut y brancher ses propres cartes graphiques et leur envoyer les requêtes avant celles destinées au cloud payant. Pour chacune des trois dépendances (Postgres, Redis, service de comptabilisation), le comportement en cas de panne est défini à l'avance. Les clés de chiffrement changent sans perte, et les releases sont signées et vérifiées. La mise à jour se fait sans arrêt du service.

Les GPU maison d'abord, le cloud en secours

Beaucoup d'équipes possèdent un Mac Studio ou une machine Linux dotée d'une bonne carte, inactive la moitié du temps. Pendant ce temps, la facture cloud grimpe pour des requêtes qu'un modèle local aurait aussi pu traiter. KTMS transforme ces machines en un vendeur à part, nommé local.

L'administrateur émet via gRPC une clé de nœud (affichée une seule fois) et enregistre un modèle. Sur la machine elle-même, il suffit de lancer un script. Celui-ci installe Ollama, le modèle et l'agent du nœud, configure les services d'arrière-plan et empêche l'ordinateur de se mettre en veille. Sur macOS, les droits d'administrateur ne sont pas nécessaires. En cas de problème, le même script lancé avec l'option --doctor indique la cause : Ollama ne répond pas, le modèle n'est pas chargé, Ollama tourne sur CPU via Rosetta, ou l'option --tls est incorrecte. Ollama, vLLM, TGI et llama.cpp sont pris en charge.

C'est la passerelle qui contacte le nœud, qui doit donc être joignable. L'agent peut monter un tunnel Cloudflare et placer un filtre devant le moteur. Seuls POST /v1/chat/completions et GET /v1/models passent par ce filtre, si bien qu'il est impossible de télécharger ou de supprimer un modèle depuis l'extérieur.

La sélection du nœud se fait en trois étapes :

• Filtre. Ne restent que les nœuds disposant du modèle voulu, d'un slot libre et d'une fenêtre de contexte suffisante. Les nœuds sains passent avant les nœuds suspects, et les nœuds « chauds » (modèle déjà en mémoire) avant les « froids ».
• Poids. Le poids de base est multiplié par une pénalité de charge, qui croît de façon quadratique avec l'occupation des slots, et par un correctif de vitesse. Ce correctif est calculé à partir de la vitesse de génération (tokens par seconde, poids 0,7) et du délai avant le premier token (poids 0,3), par rapport à la médiane de tous les nœuds hébergeant ce modèle.
• Choix. Un smooth weighted round-robin est appliqué, comme dans nginx.

La principale protection contre les ralentissements est l'estimation de la file d'attente selon la loi de Little : la profondeur de la file est multipliée par la durée attendue d'une requête. Si le résultat dépasse le queue_timeout_ms du modèle (2000 ms dans l'exemple), la requête passe immédiatement au modèle suivant de la chaîne. Pour les clients interactifs, la limite est de 250 ms. Le slot est un bail dans Redis, renouvelé tant que la génération se poursuit.

Politiques de placement : nodes_first (par défaut), nodes_only (sans nœud libre, c'est une erreur et le cloud n'est pas sollicité), cloud_first et cloud_only. Le choix peut se faire par un en-tête, par un champ de la requête ou par un suffixe du modèle, par exemple auto:nodes-only:high.

Ce que fait la passerelle quand Redis et Postgres tombent

Le principe : une panne de la comptabilisation ne doit pas devenir une panne du service.

• Redis. Les limites de requêtes et de tokens sont ignorées, sans comptabilisation. Pour les limites en dollars, un mode est à choisir : open laisse passer, closed rejette. Le cache est traité comme un échec (miss). L'état des nœuds est inconnu : ils sont donc ignorés et c'est le cloud qui répond. Après trois erreurs réseau consécutives, la passerelle cesse totalement de contacter Redis pendant 2 secondes, et un Redis bloqué ne coûte à une requête qu'un seul timeout.
• Postgres. Les clés vérifiées au cours des 5 dernières minutes continuent de fonctionner, les autres reçoivent auth_unavailable. La vérification est limitée à 3 secondes. La configuration provient du dernier instantané valide. Un batch dont l'idempotence ne peut pas être vérifiée est rejeté, afin de ne pas être facturé deux fois.
• Service de comptabilisation. Les événements s'accumulent en mémoire (jusqu'à 10 000), et les requêtes ne les attendent pas.

En cas de panne de Postgres, /readyz répond 200 avec le statut degraded tant que la fenêtre des clés connues est valide, puis 503 ensuite. Kubernetes ne redémarrera donc pas les pods prématurément. Cinq échecs consécutifs ouvrent le disjoncteur du vendeur, et une tentative de test passe au bout de 30 secondes. Il est conseillé de placer une alerte sur ktms_dependency_errors_total.

Clés, signatures des releases et mise à jour sans interruption

Les clés des vendeurs sont stockées dans Postgres, chiffrées en AES-256-GCM. Le keyring contenant les clés de chiffrement est transmis par la variable KTMS_ENCRYPTION_KEYS et n'est pas conservé dans la base. La rotation comporte trois étapes. Il faut d'abord ajouter la nouvelle version du keyring sur toutes les réplicas et attendre la fin du déploiement. Il faut ensuite appeler RotateEncryption : en une seule transaction, les clés des vendeurs et les tokens des nœuds sont rechiffrés. Enfin, on retire l'ancienne version lorsqu'il ne reste plus de sauvegarde qui en ait besoin. Un dump associé au keyring donne accès à toutes les clés en clair : il faut donc les conserver séparément.

Depuis la version 0.14.0, les images sont signées avec cosign en mode keyless : la signature est liée à l'identité du workflow dans GitHub Actions, et il n'y a rien à voler. Les images sont accompagnées d'un SBOM (liste des composants) et d'une SLSA-provenance (trace de l'endroit et de la manière dont l'image a été construite). Chaque pull request est vérifiée par govulncheck, et une release ne sort pas sans buf breaking ni test de mise à jour. Les auteurs précisent honnêtement les limites : la signature atteste l'origine, pas la sécurité. Quiconque obtient les droits sur le workflow de release pourra aussi signer une image malveillante.

Dans la branche 1.x, l'API publique ne casse pas. Les migrations s'appliquent au démarrage sous advisory-lock et ne font qu'ajouter du schéma : les anciennes réplicas fonctionnent donc sur la nouvelle base pendant que les nouvelles démarrent. Il n'y a pas de retour arrière : il faut revenir par la sauvegarde faite avant la mise à jour. Sur SIGTERM, les requêtes disposent de 30 secondes, et l'agent du nœud passe d'abord en drain.

Pour les équipes dont les GPU restent inutilisés, c'est un moyen prêt à l'emploi de réduire la facture cloud sans risquer de rester sans réponse en cas de surcharge. Avant la mise en production, il faut vérifier le TLS (la passerelle elle-même parle gRPC en plaintext), supprimer BOOTSTRAP_ADMIN_KEY, créer une clé distincte par client et surveiller les connexions Postgres (jusqu'à 25 par réplica).