Buoyant, l’entreprise qui développe Linkerd, a publié Kinference, un projet open source destiné à construire des plateformes d’inférence sur Kubernetes. Placé devant un ensemble de serveurs vLLM, il décide, pour chaque requête, vers quel serveur elle est envoyée. Le projet est distribué sous licence Apache 2.0 sur GitHub, dans sa version v0.1.0-alpha.7.
- Buoyant publie Kinference, un plan de contrôle open source pour l’inférence sur Kubernetes.
- Il choisit le serveur vLLM qui reçoit chaque requête, selon des politiques déclaratives.
- Selon Buoyant, la latence avant le premier token chute de 6,88 s à 0,31 s sur un trafic à préfixe partagé.
- Le projet reste en alpha, et la limitation de débit n’est pas encore livrée.
Une couche de contrôle au-dessus de vLLM
Kinference combine Kubernetes, la plateforme d’orchestration de conteneurs, et vLLM, le moteur qui fait tourner les modèles de langage. Selon la FAQ de Buoyant, vLLM constitue le plan de données, tandis que Kinference joue le rôle de plan de contrôle. Dans une même couche, il applique des politiques de routage, des limites de débit en tokens, un équilibrage de charge tenant compte du cache KV, c’est-à-dire la mémoire qui conserve les calculs déjà effectués, ainsi que des métriques par locataire.
Le système comprend deux éléments : une passerelle de trafic et un gestionnaire d’inférence. Ce dernier expose une interface gRPC, reçoit une requête et renvoie le point de terminaison retenu, ainsi que le corps de la requête éventuellement modifié. Il fonctionne avec un proxy, comme la Buoyant Gateway. Kinference surveille les événements du cache KV et les métriques du moteur, et s’appuie sur le crate dynamo-kv-router de NVIDIA pour traiter ces événements. Sa configuration repose sur cinq ressources Kubernetes : GatewayBackend, InferencePolicy, InferencePool, InferenceProvider et InferenceWorkerSet.
Les politiques d’inférence sont des règles déclaratives qui précisent comment chaque requête est routée ou rejetée. Elles peuvent s’appuyer sur le locataire, le modèle demandé, l’état des pools de GPU ou des étiquettes sémantiques. Le site du projet en présente plusieurs exemples, comme l’envoi de requêtes simples vers un modèle plus petit, ou le recours à un fournisseur cloud comme Bedrock lorsqu’un serveur compte plus de 2 requêtes en attente. Les politiques sont stockées dans git et peuvent être validées hors ligne avec l’outil en ligne de commande kinfctl.
Des résultats mesurés par Buoyant
Buoyant a comparé Kinference au simple équilibrage de charge de Kubernetes. Chaque configuration utilisait trois pods vLLM 0.31.0, chacun sur un GPU L40S, avec le modèle Qwen3.8-27B-FP8. Sur un trafic partageant un même préfixe, la latence médiane avant le premier token (TTFT) passe, selon Buoyant, de 6,88 s à 0,31 s, soit une baisse d’environ 95 %. Sans préfixe partagé, les chiffres sont de 6,92 s contre 6,83 s, sans différence significative selon l’éditeur.
Lors d’un test de capacité, le débit utile, mesuré en requêtes par minute respectant un objectif de TTFT, atteint 103,0 contre 14,0 req/min sur le trafic à préfixe partagé, soit environ 7,4 fois plus. Ces chiffres sont auto-déclarés. La référence est un routage aléatoire, et non un autre routeur tenant compte du cache, comme llm-d ou Dynamo. Buoyant précise par ailleurs que ses seuils de 8 s et 4 s conviennent davantage à des agents hors ligne qu’à des chatbots. Le tableau comparatif publié avec l’article présente l’angle distinctif de Kinference comme la gouvernance, à savoir les politiques, les alias de modèles, les replis vers des fournisseurs et la comptabilité par locataire, tandis que llm-d et Dynamo sont décrits comme plus performants sur le service brut.
Le projet reste en phase alpha. La limitation de débit, les classificateurs et la prise en charge de l’API Anthropic ne sont pas encore livrés.
