Kinference : un routeur vLLM qui voit le cache KV

Ce qui se passe

Buoyant, qui dit avoir vu ses clients peiner à faire tourner des modèles à poids ouverts chez eux, publie Kinference : un plan de contrôle open source sous Apache 2.0 pour bâtir une plateforme d'inférence avec vLLM sur Kubernetes. vLLM fait l'inférence ; Kinference apporte ce qui manque autour : limitation de débit en jetons, suivi d'usage et de coût par locataire, équilibrage de charge, politiques d'inférence. Il s'insère dans une pile existante : les clients envoient leur trafic compatible OpenAI ou Anthropic à son point d'entrée HTTP.

Le mécanisme

Un équilibreur Kubernetes classique répartit les requêtes sans savoir ce que chaque GPU a déjà en mémoire. Kinference tient compte de la taille des files d'attente, de l'historique de performance et du contenu du cache KV de chaque GPU, pour envoyer la requête au worker vLLM qui aura le moins de travail à faire. Le cache KV compte parce qu'un préfixe déjà calculé (un long prompt système, un historique de conversation) n'a pas à l'être deux fois.

Les règles se décrivent en YAML, sous forme d'InferencePolicy versionnables dans git :

apiVersion: kinference.buoyant.io/v1alpha1
kind: InferencePolicy
metadata:
  name: burst-policy
  namespace: inference
spec:
  rules:
  - name: burst-to-cloud
    route:
      exclude:
      - name: drop-overloaded-workers
        drop:
          backend:       { type: Local }
          queuedPrompts: { greaterThan: 2 }
      select:
      - { type: Local, minimize: PredictedTTFT }
      - { type: Provider, order: [bedrock, databricks] }

Cette politique écarte les workers locaux qui ont plus de deux prompts en file, vise d'abord le local au plus faible TTFT prévu, et déborde sur Bedrock puis Databricks. Le billet en montre deux autres : envoyer les requêtes de faible complexité vers un modèle moins cher, sauf si le cache rend le gros modèle plus rapide ; et une règle pii-stays-local qui interdit à toute requête classée comme contenant des données personnelles de quitter le cluster, avec onEmpty: Reject pour refuser plutôt que d'envoyer ailleurs.

Les métriques sont exposées par locataire : débit de jetons en entrée et en sortie, histogrammes de TTFT, de latence inter-jetons et de bout en bout, jetons de prompt en cache ou non (pour estimer le coût), saturation des GPU.

Les chiffres, et ce qu'ils valent

Sur ses propres bancs d'essai publics, face à l'équilibrage Kubernetes standard (kube-proxy) :

• TTFT médian réduit de 95 % et latence bout en bout de 45 %, sur un type de charge ;
• débit utile (goodput, requêtes par minute dans un objectif de latence) ×7,4 sur préfixe partagé et environ ×3,5 en multi-tours ; face à ces charges, kube-proxy n'atteint l'objectif à aucun niveau de concurrence.

Ce sont des mesures de l'éditeur, contre une référence simple. Elles disent ce que vaut la prise en compte du cache KV, pas ce que vaudra Kinference sur votre trafic.

Comment s'y prendre

L'installation passe par les CRD de Gateway API (version 1.5.1 dans le guide), puis par des charts Helm (gateway-crds, gateway, kinference-crds, kinference) tous installés avec --devel, donc en préversion, et les ressources sont en v1alpha1. Les étapes évolueront : suivez la documentation sur kinference.ai.

Si vous servez vLLM sur Kubernetes avec plusieurs réplicas, mesurez le TTFT avec et sans cette couche, sur votre propre trafic, avant de l'adopter. Sinon, passez votre chemin.

Source : le blog vLLM, qui renvoie au dépôt Kinference et aux bancs d'essai de Buoyant. Source en anglais.