LMCache : mutualiser le cache des LLM pour servir plus vite et moins cher
Toute pile d’IA en production finit par se heurter au même mur économique : le coût et la latence du premier token. Chaque appel à un LLM commence par calculer la même chose, le prefill du contexte, c’est à dire le passage de tous les tokens d’entrée dans le réseau pour produire le cache d’attention (KV cache). Pour un agent qui rappelle son prompt système à chaque tour, un RAG qui réinjecte les mêmes documents à chaque requête, ou un chat multi-tours qui renvoie l’historique complet, c’est du calcul jeté à la poubelle à chaque appel. LMCache, projet open source sous licence Apache 2.0 issu de l’Université de Chicago et désormais soutenu par la communauté vLLM, propose un cache KV mutualisé, persistant et distribué, capable de réduire le temps au premier token d’un facteur 3 à 10 sur les usages typiques.
Le problème : un cache cher à reconstruire
Quand vLLM (ou un autre moteur d’inférence) traite une requête, il calcule le KV cache des tokens d’entrée, puis génère token après token en lisant ce cache. Le KV cache, c’est de la mémoire GPU dédiée, typiquement quelques mégaoctets par millier de tokens. Tant que la session reste active dans la même instance, vLLM sait réutiliser le préfixe partagé via son prefix caching interne. Mais dès qu’on change d’instance, qu’on relance le serveur, ou qu’on dépasse la mémoire allouée, le cache disparaît et il faut tout recalculer.
Or, sur une charge typique de production, les mêmes blocs reviennent sans cesse : prompts système de 2 000 à 8 000 tokens, documents RAG, exemples few-shot, historiques de conversation. LMCache part de ce constat : ce KV cache, on peut le stocker ailleurs que dans la VRAM, et le faire voyager d’une instance à l’autre.
Le principe : KV cache comme une donnée de premier rang
LMCache traite le KV cache exactement comme on traite n’importe quelle donnée chaude dans une infrastructure moderne : il est stocké, indexé, compressé, et déplacé dans une hiérarchie mémoire à plusieurs étages. Concrètement, trois niveaux de stockage cohabitent :
- GPU HBM : le cache reste où il est calculé tant qu’il y a de la place
- RAM CPU : éviction vers la mémoire centrale, accès en quelques millisecondes
- Stockage local ou réseau : NVMe local, Redis, objet S3, ou serveur LMCache dédié, pour persister au delà d’un redémarrage et partager entre instances
L’innovation principale, c’est la capacité de réutiliser un préfixe même quand il n’est pas en tête du nouveau prompt. LMCache implémente le CacheBlend, un mécanisme qui découpe le KV cache en chunks et recolle dynamiquement les morceaux qu’on retrouve dans la requête, à n’importe quelle position. Pour un RAG qui injecte trois documents parmi cent dans un ordre variable, c’est décisif.
Ce que ça change en pratique
Sur les benchmarks publiés et reproductibles, l’effet est massif sur les charges typiques d’agents et de RAG. Quelques ordres de grandeur observés en 2025 et 2026 :
- Multi-tours : temps au premier token divisé par 5 à 10 après la deuxième question, là où vLLM seul recalcule l’historique complet à chaque relance d’instance
- RAG : gain de 3 à 7 sur le TTFT quand les documents injectés font partie d’un corpus pré-chauffé, indépendamment de leur position dans le prompt
- Agents multi-étapes : économies cumulées sur la boucle perception, action, observation, particulièrement visibles quand le prompt système dépasse 4 000 tokens
- Coût : baisse de 30 à 70 pour cent de la facture GPU à débit équivalent, ou multiplication du débit utile à parc constant
Architecture et intégration vLLM
LMCache se déploie en deux topologies principales. La plus simple : cache local, où chaque instance vLLM utilise sa propre RAM et un disque NVMe pour persister. Cela suffit déjà à survivre aux redémarrages et à absorber les pics. La plus puissante : cache distribué, où un ou plusieurs serveurs LMCache dédiés (un démon en Python avec un store en Rust) servent un pool d’instances vLLM, qui se synchronisent via un protocole bas niveau optimisé pour les transferts de tenseurs.
Côté code, l’intégration vLLM se fait par un seul flag à l’API ou dans la config :
# Lancer vLLM avec LMCache local
vllm serve mistralai/Mistral-Small-3-24B-Instruct \
--kv-transfer-config \
'{"kv_connector":"LMCacheConnectorV1","kv_role":"kv_both"}'
# Configurer LMCache pour persister sur disque local
export LMCACHE_LOCAL_DISK="file:///var/cache/lmcache"
export LMCACHE_MAX_LOCAL_DISK_SIZE="200" # Go
export LMCACHE_CHUNK_SIZE="256"
Pour le déploiement distribué, on ajoute simplement l’URL du serveur LMCache et on choisit la stratégie d’éviction. Les développeurs maintiennent aussi une intégration avec SGLang, et une compatibilité expérimentale avec TGI (Text Generation Inference) de Hugging Face.
Cas d’usage où ça vaut le coup
LMCache brille sur trois familles de charges. D’abord, les plateformes RAG avec un corpus stable et un prompt système long : le préfixe est réutilisé à chaque appel, le gain est immédiat. Ensuite, les agents IA qui font tourner LangGraph, Pydantic AI ou Hermes, et qui rappellent à chaque tour un contexte de plusieurs milliers de tokens : on évite le coût d’amorçage à chaque pas. Enfin, les chats multi-tours sur une flotte vLLM derrière un load balancer, où une question peut arriver sur une instance différente de la précédente : LMCache rapatrie le cache, l’instance n’a pas besoin de tout recalculer.
À l’inverse, sur des charges purement one shot avec des prompts courts et tous différents, le gain est faible et l’overhead de transfert peut même nuire. Le mesurer avant de déployer reste indispensable.
Limites à connaître
Trois points méritent vigilance. Premièrement, le KV cache est spécifique au modèle : changer de modèle, de quantization ou même de version invalide tout. Deuxièmement, la cohérence du tokenizer doit être garantie : la moindre différence de tokenisation fait diverger le cache. Troisièmement, le stockage du KV cache occupe de la place, environ 0,5 à 2 Mo par millier de tokens selon la précision, ce qui devient significatif pour des corpus de plusieurs millions de tokens : prévoir le dimensionnement et les politiques d’éviction (LRU, TTL, taille max).
Pour aller plus loin
LMCache s’inscrit dans une famille d’outils qui rendent l’inférence LLM industriellement viable, aux côtés de vLLM (le moteur), LiteLLM (le proxy unifié), Langfuse (l’observabilité), et plus récemment LLMLingua (la compression de prompt) déjà couverts sur ce site. Pour un opérateur qui sert plusieurs milliers de requêtes par jour avec des prompts longs, c’est typiquement le projet qui paye sa migration en moins d’un mois.
Le code, la documentation et les benchmarks reproductibles sont disponibles sur le dépôt GitHub officiel LMCache/LMCache, et la communauté maintient un canal Slack actif. Le projet est inclus comme première classe dans la roadmap vLLM 2026, ce qui en fait un pari raisonnable pour une mise en production.
