Tensormesh lance une plateforme pour réduire les coûts d’inférence des grands modèles de langage grâce à la réutilisation du cache KV

Chaque fois qu’un assistant IA reçoit un long document, il doit en traiter le contenu avant de pouvoir commencer à répondre. Lorsque les mêmes documents, consignes ou historiques de conversation réapparaissent, une grande partie de ce traitement peut être répétée. À l’échelle d’une entreprise, ces répétitions peuvent mobiliser une coûteuse capacité GPU sans apporter de travail utile.

Tensormesh s’attaque à ce problème avec Tensormesh Platform, annoncée le 14 octobre 2026. L’entreprise, dont l’équipe a créé le projet open source LMCache, propose aux organisations qui exécutent de grands modèles de langage sur leur propre infrastructure une couche de gestion d’entreprise pour la mise en cache des paires clé-valeur, ou cache KV.

La plateforme gère l’état d’inférence réutilisable dans la mémoire GPU, la mémoire CPU et le stockage. L’objectif est simple : réduire le volume de traitement des requêtes que le parc de GPU doit répéter, tout en donnant aux opérateurs les moyens de contrôler la conservation, le partage et le suivi de cet état mis en cache.

Pourquoi le cache KV est important

L’inférence des grands modèles de langage comporte deux étapes importantes. Pendant le préremplissage, le modèle traite la requête en entrée. Pendant le décodage, il génère la réponse jeton par jeton. Le cache KV stocke un état intermédiaire lié à l’attention, qui permet au modèle de se référer aux jetons déjà traités sans tout recalculer depuis le début.

La réutilisation de cet état entre plusieurs requêtes peut réduire le travail de préremplissage lorsque le contexte d’entrée se répète. Un assistant d’assistance, par exemple, peut consulter le même manuel produit pour répondre à des centaines de questions différentes. Un agent peut inclure à plusieurs reprises les mêmes consignes ou les mêmes outils, tout en traitant des tâches différentes.

Cette méthode diffère de la mise en cache d’une réponse terminée. Le système peut réutiliser les calculs associés au contexte partagé tout en générant une nouvelle réponse à une nouvelle question.

La documentation de vLLM sur la mise en cache automatique des préfixes décrit cet avantage pour les requêtes répétées portant sur des documents et les conversations à plusieurs tours. Elle en précise aussi une limite importante : la mise en cache des préfixes accélère le traitement des requêtes, et non la génération de nouveaux jetons de sortie. Les charges de travail composées principalement de réponses longues ou d’entrées largement différentes peuvent en tirer moins de bénéfices.

Pour les acheteurs d’entreprise, la question utile est de savoir quelle part de leur charge de travail réelle comporte un contexte réutilisable, et si celui-ci peut être récupéré plus rapidement et à moindre coût que s’il fallait le recalculer.

Faire d’un cache une infrastructure gérée

Dans son annonce, Tensormesh met en avant cinq priorités opérationnelles : la sécurité, l’observabilité, la résilience, la gestion des politiques et la prise en charge de plusieurs locataires. Elles répondent aux besoins pratiques de protection des données mises en cache, de suivi des performances, de reprise après une défaillance, de contrôle de la conservation et de l’éviction, ainsi que de séparation des équipes ou des clients sur une infrastructure partagée.

L’entreprise décrit également des API de contrôleur permettant d’épingler, de localiser, de déplacer, de compresser et d’effacer les entrées du cache. La gestion du cycle de vie du cache devient ainsi une responsabilité opérationnelle explicite, au lieu d’être entièrement laissée aux processus d’inférence individuels.

Le projet LMCache sous-jacent sépare la gestion du cache du moteur de service et permet le déchargement et la récupération des données entre plusieurs niveaux de stockage. Sa documentation décrit la réutilisation entre les requêtes, les sessions et les instances du moteur, avec des systèmes de stockage et de transport modulaires.

La plateforme d’entreprise s’appuie sur ces bases. Selon son guide d’installation, un opérateur Kubernetes gère les composants du moteur de cache, avec des serveurs de cache sur les nœuds GPU et un coordinateur chargé de coordonner l’ensemble du parc. Helm sert au déploiement, tandis qu’une interface web et des outils en ligne de commande facilitent l’exploitation.

Cette architecture est importante, car la mémoire GPU est une ressource limitée. Y conserver toutes les requêtes susceptibles d’être réutilisées entrerait en concurrence avec les autres besoins liés à l’inférence. Le transfert des états moins utiles à court terme vers la mémoire hôte ou le stockage peut augmenter le volume de données conservées, même si leur récupération entraîne ses propres coûts en bande passante et en latence.

Au-delà des préfixes de requête identiques

La mise en cache des préfixes fonctionne bien lorsque deux requêtes commencent par les mêmes jetons. La génération augmentée par récupération, ou RAG, peut poser davantage de difficultés : une application récupère des documents pertinents, mais ceux-ci peuvent apparaître dans un ordre différent ou après des textes préliminaires différents.

Prenons deux requêtes hypothétiques qui utilisent les mêmes documents. La première contient le document A, puis le document B ; la seconde contient le document B, puis le document A. Toutes deux comportent des éléments réutilisables, mais leur début commun peut être court.

Tensormesh utilise CacheBlend pour étendre la réutilisation au-delà du début d’une requête. La documentation de LMCache explique que cette méthode recalcule sélectivement une fraction des jetons tout en réutilisant des blocs mis en cache. Ce recalcul est important, car le contexte entourant un bloc peut influer sur l’état interne du modèle.

L’article de recherche sur CacheBlend, présenté à EuroSys 2025, fait état d’un délai avant le premier jeton 2,2 à 3,3 fois plus rapide et d’un débit 2,8 à 5 fois supérieur à ceux du recalcul complet du cache KV pour les charges de travail évaluées. Les auteurs ont évalué trois modèles open source et quatre jeux de données de référence.

Il s’agit de résultats de recherche obtenus dans des conditions précises, et non d’économies garanties pour chaque déploiement de Tensormesh. Ils montrent néanmoins pourquoi la réutilisation au-delà d’un préfixe partagé est intéressante sur le plan technique : elle peut permettre de récupérer des calculs utiles que la mise en correspondance conventionnelle des préfixes ne détecterait pas.

Réutilisation entre nœuds et importance de la prise en charge propre à chaque version

L’annonce de lancement décrit les transferts KV entre pairs, qui permettent à un nœud de récupérer l’état mis en cache sur un autre. La documentation produit de l’entreprise décrit également la séparation des étapes de préremplissage et de décodage. Cette séparation dissocie le traitement des invites de la génération des sorties, de sorte que les deux étapes puissent s’exécuter sur des processus de travail différents.

Ces approches complémentaires permettent d’organiser l’inférence. Le partage d’un état compatible peut éviter de le recalculer sur un autre nœud ; la séparation des étapes peut permettre aux équipes d’infrastructure d’allouer les ressources différemment en fonction de leurs besoins de traitement.

Toutefois, les informations publiques ne concordent pas entièrement sur l’état de disponibilité. La présentation du lancement décrit le partage entre nœuds et la séparation des étapes, tandis que la matrice de compatibilité par version, datée du 17 septembre, indique que les transferts entre pairs et la séparation des étapes figurent sur la feuille de route. La documentation des fonctionnalités comprend également des pages de prévisualisation.

La même matrice distingue les fonctionnalités vérifiées lors des tests de Tensormesh de celles qui sont prises en charge en amont, mais nécessitent des tests supplémentaires avant une mise en production. Elle indique que vLLM et NVIDIA Dynamo sont des moteurs d’inférence vérifiés, tandis que SGLang et TensorRT-LLM figurent sur la feuille de route.

La formulation générale de l’annonce sur la compatibilité décrit donc une orientation de conception, et non la preuve que chaque combinaison de modèles et d’infrastructures a été validée. Les équipes doivent vérifier la version exacte, le moteur d’inférence, le modèle et le mode de mise en cache qu’elles comptent déployer.

La présentation du lancement décrit précisément vLLM sur Kubernetes avec des GPU NVIDIA ou des GPU AMD Instinct pris en charge via ROCm, ainsi qu’un stockage reposant sur un système de fichiers. Elle indique que la mise en cache ne reposant pas sur les préfixes pour les modèles denses et la prise en charge de SGLang sont prévues. Elle précise également que le cache fonctionne en complément des modèles hébergés sur l’infrastructure de l’entreprise ; il ne s’agit pas d’un module additionnel que l’on peut rattacher à n’importe quelle API de modèle hébergé.

Dans quels cas le modèle économique pourrait être viable

Les applications les plus prometteuses sont celles qui traitent régulièrement un important contexte partagé : assistants s’appuyant sur les connaissances internes, services d’analyse de documents et agents qui consultent à nouveau un ensemble stable d’instructions ou de documents de référence.

Une évaluation utile comparerait les performances avec un cache froid et un cache chaud, à partir d’un trafic représentatif. Les opérateurs devraient mesurer le délai avant le premier jeton, le débit, le temps de récupération du cache, l’utilisation des GPU, ainsi que les coûts de mémoire, de stockage et de réseau liés à la conservation de l’état.

Le taux de succès du cache ne suffit pas à lui seul. Un taux élevé n’est utile que si le travail récupéré apporte un bénéfice net, une fois pris en compte le surcoût des transferts et de la gestion. De même, l’accélération de l’émission du premier jeton ne signifie pas nécessairement que la réponse entière sera produite proportionnellement plus vite.

La qualité des réponses doit faire l’objet d’une vérification distincte, en particulier lorsque des blocs mis en cache sont combinés dans des contextes différents. Le recalcul sélectif de CacheBlend vise à résoudre ce problème, mais les tests en production doivent porter sur les propres documents de l’organisation, ses formats d’invites et ses configurations de modèles.

La conservation des données et l’isolation des locataires prennent également davantage d’importance lorsque le cache dépasse le cadre d’un processus unique. Les questions opérationnelles pertinentes portent notamment sur les personnes autorisées à réutiliser une entrée, la durée pendant laquelle elle reste disponible et les effets des changements de politique ou des demandes de suppression sur l’état enregistré. Les fonctionnalités de gestion annoncées par Tensormesh sont conçues pour permettre de contrôler ces décisions.

Un pari pragmatique : éviter de répéter le travail

Selon l’annonce de l’entreprise, Tensormesh Platform est disponible depuis le lancement. Son importance tient au fait qu’elle traite l’état d’inférence comme une ressource pouvant être gérée à l’échelle d’un parc, en conservant les calculs réutilisables au-delà de la durée de vie immédiate d’une requête.

Pour les entreprises qui exploitent leur propre infrastructure LLM, cette approche offre un levier d’efficacité concret : réutiliser davantage le travail de traitement des invites déjà effectué. Le résultat dépendra de la répétitivité des charges de travail, de la compatibilité du cache et du coût des transferts de données ; mais il s’agit de paramètres techniques mesurables que les équipes peuvent évaluer à partir de leur propre trafic.