Keystone détaille le fonctionnement technique de son passerelle pour modèles de langage
2 novembre 2026 · 2 min de lecture
Également publié en Español
Keystone a présenté les détails d'exploitation de son logiciel de passerelle pour modèles de langage, nommé The Model Switchboard (KTMS), qui est disponible en open-source et développé en Go.
Le système permet d'intégrer des machines locales, telles que des ordinateurs Linux ou Mac Studio, comme des fournisseurs de services. Ces nœuds locaux sont prioritaires pour traiter les requêtes afin de réduire les coûts liés aux services de cloud. L'administrateur enregistre un modèle avec l'identifiant de fournisseur local et attribue une clé de nœud. Un script installe ensuite Ollama, le modèle et l'agent du nœud en tant que services d'arrière-plan. Le système supporte les moteurs vLLM, TGI, llama.cpp et Ollama.
L'agent du nœud envoie un signal d'activité toutes les cinq secondes, incluant les métriques du processeur graphique et l'état de la file d'attente. Le routeur sélectionne les nœuds en fonction de la disponibilité du modèle, de la fenêtre de contexte et de la santé du nœud. Le choix final utilise un algorithme de round-robin pondéré lisse, similaire à celui de nginx. Le poids d'un nœud est calculé selon son poids de base, une pénalité liée à la charge et un ajustement de vitesse basé sur la vitesse de génération et le temps avant le premier jeton.
Pour éviter des attentes excessives sur les nœuds locaux, la passerelle utilise la loi de Little pour estimer le temps d'attente. Si ce délai dépasse le seuil configuré, la requête est redirigée vers un modèle de cloud. Les politiques de routage peuvent être définies via des en-têtes, des champs de requête ou des suffixes de modèle.
La passerelle dépend de trois composants : Postgres pour la configuration et les clés, Redis pour les limites et le cache, et un service de comptabilité. En cas de panne du service de comptabilité, le trafic continue sans comptage. Si Redis échoue, les nœuds sont ignorés au profit du cloud et les clés vérifiées durant les cinq dernières minutes restent valides. Une panne de Postgres entraîne l'utilisation du dernier instantané réussi, tandis que les requêtes dont l'idempotence ne peut être vérifiée sont rejetées.
La sécurité des clés de fournisseurs est assurée par un chiffrement AES-256-GCM. Les clés de chiffrement sont gérées via une variable d'environnement versionnée. Le système permet la rotation des clés via une fonction RotateEncryption qui rechiffre toutes les clés de fournisseurs et les jetons de nœuds dans une seule transaction.