Keystone retire le nom du modèle du code : cette passerelle LLM open source ajoute 0,64 ms

La ligne la plus coûteuse d'un microservice LLM, c'est model="gpt-4o". Elle traîne derrière elle sa clé de fournisseur, ses retries et une facture que personne ne peut décortiquer. L'équipe Keystone a publié la passerelle open source The Model Switchboard (KTMS), écrite en Go sous licence Apache 2.0, qui supprime entièrement cette ligne. Le service indique à la passerelle la difficulté de la tâche, et ce sont les règles qui décident quel modèle répond. Surcoût mesuré sur le banc d'essai : environ 0,64 ms au p50 et 1,1 ms au p99 à 200 RPS.

Quarante services et un seul nom de modèle

L'histoire est classique : le premier service reçoit une clé OpenAI, six mois plus tard on en compte quarante, chacun avec son secret, son wrapper de retries et son propre comptage de tokens. Tout se dégrade ensuite de façon prévisible. Un modèle meilleur ou moins cher sort : cela représente quarante pull requests et quarante déploiements, et la moitié des équipes ne migreront que dans un trimestre. Un fournisseur tombe : les quarante services plantent, parce que le fallback n'est pas écrit ou l'est de manière différente selon les équipes. La facture arrive : la clé est partagée, les appels n'ont pas de métadonnées, impossible de savoir qui a dépensé quoi.

Avec Keystone, le service transmet un effort (LOW, MEDIUM ou HIGH) et des attributs : langue, type de tâche, utilisateur. Pour la passerelle, les attributs ne sont que des paires clé-valeur que les règles comparent. Les clients Python n'ont même pas besoin de gRPC : le HTTP compatible OpenAI comprend les mêmes règles. L'effort s'encode dans le nom du modèle (auto:high), metadata devient des attributs, et le champ user alimente les plafonds.

Règles, canaris et juge à 250 ms

Les règles sont stockées dans Postgres et remplacées en bloc par un seul appel atomique. La règle applicable ayant la priorité la plus élevée l'emporte, et le champ use définit la chaîne de fallbacks, par convention du modèle économique vers le plus cher. La validation rejette tout jeu de règles où un effort n'a pas de règle sans attributs : une requête ne peut donc pas passer entre les mailles. Les réplicas récupèrent les modifications en 60 secondes. La commande ktms route explain affiche le trajet à l'avance, sans appeler de modèle.

On peut affecter des poids aux règles, par exemple [90, 10]. Lorsqu'un user_id ou un canary_key est présent, la répartition est « sticky » : un même utilisateur tombe toujours sur le même modèle. Un nouveau modèle peut ainsi être déployé auprès de 10 % de l'audience sans toucher aux services. Il existe aussi un routage shadow expérimental : une part du trafic est dupliquée de façon asynchrone vers le modèle candidat, et le juge compare les réponses et écrit le résultat dans les métriques.

Si le service ne connaît pas la complexité, le mode model: "auto" s'active. La passerelle interroge un modèle juge, qui renvoie non pas du texte mais une réponse typée avec des probabilités. Jev de TypeSafe et OpenAI Decisions sont pris en charge. L'échéance est stricte, 250 ms ; en cas d'erreur ou de juge trop lent, la requête part avec MEDIUM. Une complexité fixée explicitement prime toujours sur le juge, et le choix est visible dans les en-têtes X-KTMS-Route-Mode, X-KTMS-Judge-Score et X-KTMS-Judge-Model. Le choix par le juge est marqué comme expérimental dans la branche 1.x : seuls auto:high et ses équivalents sont stables.

Pannes de fournisseurs et dépenses sous contrôle

Les retries intégrés aux SDK des fournisseurs sont désactivés : une tentative du routeur correspond à un appel au fournisseur. Le routeur retente une fois sur le même modèle après un 429, un 5xx ou une coupure de connexion, puis parcourt la chaîne ; pour le streaming, cela ne fonctionne que jusqu'au premier chunk. Les mécanismes de protection :

• Circuit breaker sur le couple (fournisseur, modèle) : après 5 échecs consécutifs, le circuit s'ouvre, et au bout de 30 s une requête de test vérifie le modèle.
• Retry-After, retry-after-ms et google.rpc.RetryInfo chez Gemini : une attente allant jusqu'à 1 s est respectée sur place, une attente plus longue met le modèle en pause pour la clé concernée (5 minutes maximum par défaut).
• Si toute la chaîne est en pause, le client reçoit UNAVAILABLE vendors_unavailable avec un Retry-After honnête.

Les plafonds de dépenses se définissent en dollars par clé et par utilisateur, sur une journée UTC ou un mois, auxquels s'ajoute un budget mensuel d'équipe. Avant chaque appel, la passerelle réserve le pire cas (entrée × prix d'entrée + maximum de tokens × prix de sortie) via un unique script Lua dans Redis, puis recalcule le coût réel après la réponse. Les montants sont stockés en nano-dollars. Si un appel dépassait le plafond, il est rejeté, mais un modèle moins cher plus loin dans la chaîne peut encore répondre. Sans max_output_tokens, la réserve est calculée sur 4096 tokens : il vaut donc mieux toujours renseigner ce paramètre.

Autres fonctionnalités :

• Organisations et équipes avec listes de modèles autorisés et budgets mensuels ; org_id et team_id sont renseignés par la passerelle d'après la clé.
• Batch via les API des fournisseurs avec 50 % de remise, envoi idempotent par client_batch_id, prompts non stockés en base.
• Limitation de débit GCRA avec burst configurable et budgets de tokens journaliers avec une tolérance de 5 %.
• Un événement par appel vers light-tokenmeter ou tout service de comptabilisation gRPC.

Limites et marche à suivre

Fournisseurs pris en charge : OpenAI, Anthropic, Gemini, DeepSeek, Groq, Mistral, Azure OpenAI, Bedrock, tous les serveurs compatibles OpenAI, et TypeSafe pour les décisions. Un fournisseur exotique peut manquer à l'appel. Côté latence, Keystone fait moins bien qu'agentgateway, Apache APISIX et Kong. Banc d'essai : Google Cloud c3-standard-4 avec 4 vCPU et un upstream mock ; la passerelle a tenu au moins 4000 RPS. Sans Redis, les plafonds ne fonctionnent pas, et en cas de panne de Redis, les limites de requêtes et de tokens laissent passer le trafic. Pour les plafonds de dépenses, il est possible d'activer le mode strict SPEND_LIMITS_FAIL_MODE=closed.

Conclusion pratique pour les équipes qui gèrent des dizaines de services LLM : commencer par trois règles (LOW, MEDIUM, HIGH sans attributs) et des chaînes allant du modèle économique au plus cher, puis ajouter des règles à base d'attributs. Définir d'emblée max_output_tokens et des plafonds en dollars par clé, pour que la facture devienne lisible. Le schéma peut se reproduire dans une autre passerelle ; l'essentiel est de sortir le nom du modèle du code des services pour le placer dans la configuration.