kvcached : virtualiser le KV cache pour partager un GPU entre plusieurs moteurs

Le gaspillage que kvcached attaque

Dans un déploiement classique, un moteur d'inférence réserve au démarrage un bloc de mémoire GPU pour son KV cache et le garde. Si la charge est irrégulière, une partie de cette mémoire dort pendant que d'autres modèles attendent. Le README décrit la situation ainsi : kvcached permet à plusieurs LLM de partager la mémoire d'un GPU de façon élastique, au lieu du partitionnement rigide pratiqué aujourd'hui. Le problème visé n'est donc pas la vitesse de décodage, mais le taux d'occupation de la mémoire GPU sous charge variable. Le public visé est précis : ceux qui servent plusieurs modèles, ceux qui font du serverless où les modèles démarrent et s'arrêtent à la demande, et ceux qui assemblent des systèmes d'IA composés sur du matériel limité. Si vous servez un seul modèle en continu à pleine charge, le gain d'élasticité ne vous concerne pas.

Virtualiser l'adresse plutôt que la mémoire

Le mécanisme central est un découplage entre l'adressage virtuel GPU et l'allocation physique. Le moteur réserve d'abord de l'espace virtuel pour son KV cache, sans le doser en mémoire physique. La mémoire n'est rattachée que lorsque le cache est réellement utilisé, par un mapping établi à l'exécution. C'est la même idée que la mémoire virtuelle d'un système d'exploitation, transposée au KV cache. Deux conséquences pratiques en découlent : l'allocation devient pilotée par la demande, et la récupération de mémoire devient possible quand la charge retombe. Le dépôt parle d'un daemon, kvcached, d'où le nom. L'intégration ne se fait pas au niveau du noyau d'attention mais au niveau de la gestion mémoire du moteur, ce qui explique la liste restreinte de moteurs compatibles. Le README annonce aussi un routeur frontal et un mode veille, qui oriente les requêtes vers le bon modèle et endort les modèles inactifs. Ce sont deux briques distinctes de la bibliothèque de cache, et la documentation disponible reste plus mince sur leur configuration que sur le cache lui-même.

Ce que le dépôt documente réellement sur la compatibilité

La matrice de compatibilité est le point le plus concret du README. Pour SGLang, la version minimale est v0.4.9, testée jusqu'à v0.5.15. Pour vLLM, minimum v0.8.4, testé jusqu'à v0.24.0. Les types d'attention annoncés couvrent MHA, GQA, MLA, sliding window et hybride, avec des modèles cités comme DeepSeek-V3, Qwen3-8B, GPT-OSS-20B, Qwen3.5-9B et Gemma-4-E2B-it. Le README renvoie au point 425 du dépôt pour les résultats par modèle et par disposition de KV. C'est un aveu utile : la couverture n'est pas uniforme selon le couple moteur, modèle et type d'attention, et l'équipe préfère renvoyer à un suivi détaillé plutôt que de promettre une compatibilité générale. Les notes de version confirment cette progression par ajouts successifs : support du parallélisme de pipeline en mars 2026, puis modèles MLA et GPT-OSS hybride dans vLLM, avec une mise à jour du support GPT-OSS dans SGLang en v0.5.9. Une bibliothèque qui étend sa couverture par vagues de ce type demande de vérifier votre combinaison exacte, pas seulement la version du moteur.

Mise en route et clés de configuration

Le README présente kvcached comme une bibliothèque Python, compatible Python 3.9 à 3.13, et mentionne une interface en ligne de commande, désignée sous le nom de kvcached CLI, destinée à imposer des limites de mémoire. C'est le seul point de configuration nommé explicitement dans le matériel fourni : les limites de mémoire s'appliquent via cette CLI. Pour le reste, la documentation renvoie à un exemple de mise en route pour le prefix caching, dans le répertoire examples/09_prefix_caching, et à une documentation externe sur DeepWiki. Le README ne fournit pas de commande d'installation ni de fichier de configuration type dans l'extrait disponible. Je ne peux donc pas donner de commande pip ou de bloc de configuration sans inventer, ce qui serait pire que de l'admettre. Le point de départ réaliste est le répertoire d'exemples du dépôt, en particulier l'exemple 09 pour le prefix caching, et la page DeepWiki pour les détails d'intégration.

Prefix caching : une brique récente, avec une borne à régler

Le prefix caching a été ajouté en avril 2026. kvcached prend en charge l'automatic prefix caching (APC) pour vLLM et RadixCache pour SGLang, ce qui permet de réutiliser un préfixe entre requêtes tout en gardant la gestion élastique de la mémoire. Le README précise que cette fonctionnalité s'accompagne d'une borne mémoire configurable. C'est cohérent avec le reste du projet : réutiliser des préfixes signifie conserver des blocs plus longtemps, ce qui entre en tension directe avec l'objectif de récupération agressive de mémoire. La borne est donc le paramètre qui arbitre entre taux de réutilisation et élasticité. Le README ne donne pas de valeur par défaut ni de plage recommandée dans l'extrait fourni. Si vous activez le prefix caching, c'est le premier réglage à instrumenter vous-même, parce qu'il détermine si la bibliothèque vous fait gagner de la mémoire ou vous en fait perdre.

Quand kvcached n'est pas le bon outil

La limitation la plus nette est la dépendance à deux moteurs, SGLang et vLLM, et à des plages de versions précises. Un moteur maison, un runtime propriétaire ou une version de vLLM antérieure à v0.8.4 ne sont pas des cibles. La deuxième limite est la nature du gain : kvcached agit sur l'occupation mémoire, pas sur la latence. Si votre goulot est le temps de décodage ou le débit par requête, la virtualisation du cache ne le résoudra pas. Troisième point, moins visible : le découplage entre adressage virtuel et mémoire physique ajoute une couche de gestion dont le comportement en cas de saturation n'est pas décrit dans le README. Que se passe-t-il quand la mémoire physique manque alors que l'espace virtuel a été promis ? Le matériel fourni ne le dit pas. C'est précisément le scénario qu'un système à mémoire virtuelle doit traiter, et son absence de description est une raison de tester la saturation avant la mise en production, pas après.

Face à quoi on compare vraiment

L'alternative immédiate n'est pas un autre logiciel de cache, c'est le mode veille et le déchargement de modèles déjà présents dans les moteurs. vLLM propose un mécanisme de sleep qui libère la mémoire GPU d'un modèle inactif, et SGLang dispose de son propre cache radix. La différence d'approche est réelle : dans le mode sleep classique, un modèle dort et libère tout, puis doit être rechargé, ce qui coûte du temps et de la bande passante PCIe. kvcached conserve l'espace virtuel et ne rend que la mémoire physique non utilisée, si bien que le modèle n'a pas à être rechargé pour reprendre du service. C'est un arbitrage entre temps de réveil et granularité de la mémoire rendue. Le revers est que kvcached s'insère dans le moteur et suit ses versions, alors que le sleep est fourni avec le moteur et ne dépend d'aucun composant tiers. Une équipe qui n'a besoin que d'endormir un modèle entre deux pics n'a aucune raison d'ajouter une couche de virtualisation.

Coût de maintenance et licence

Le rythme de publication est irrégulier : v0.1.3 en janvier 2026, v0.1.4 en mars, v0.1.5 en avril. Le projet est encore en série 0.1.x, ce qui signifie que les interfaces ne sont pas stabilisées. Le vrai coût de maintenance ne vient pas des montées de version de kvcached elles-mêmes, mais du suivi des moteurs : chaque nouvelle version de vLLM ou de SGLang peut déplacer une interface interne de gestion mémoire dont dépend l'intégration. La matrice du README, avec ses bornes testées, est le contrat implicite que vous devrez maintenir à jour de votre côté. La licence est Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et d'état des modifications. Je ne donne pas d'avis juridique : faites relire le fichier LICENSE et les notices du dépôt si vous redistribuez. Le projet est également cité par Red Hat, dont le projet Sardeenz s'appuie sur kvcached pour du service multi-modèles dynamique sous Kubernetes et OpenShift, ce qui indique un usage en production au-delà du dépôt d'origine.

Conclusion éditoriale

kvcached convient aux équipes qui font tourner plusieurs modèles ou plusieurs charges sur un même GPU et qui acceptent de suivre une matrice de compatibilité par version de moteur. Il ne convient pas si vous dépendez d'une version de vLLM ou de SGLang en dehors des plages indiquées, ni si votre moteur est autre que ces deux-là. Avant de vous engager, vérifiez le point 425 du dépôt, qui documente les résultats par modèle et par disposition de KV, puis reproduisez votre propre modèle sur votre version exacte de moteur.

Sources officielles

1. Issues
2. License: Apache-2.0
3. ovg-project/kvcached on GitHub
4. README
5. Releases