WAKMan : un gestionnaire de cache pour serveurs LLM qui choisit lui-même sa stratégie et gagne jusqu'à 5 points de pourcentage de taux de réussite

Pourquoi une seule règle ne fonctionne pas pour tous les cas

Les serveurs hébergeant de grands modèles de langage consacrent une part notable de leur puissance de calcul à retraiter le même contexte. Si deux requêtes commencent par le même fragment de texte — par exemple une instruction système ou un historique de dialogue — le serveur peut calculer une seule fois les "clés" et "valeurs" internes du modèle pour ce fragment, puis simplement réutiliser le résultat déjà en mémoire de la carte graphique, au lieu de tout recalculer. C'est ce qu'on appelle la réutilisation de préfixe, et elle accélère réellement les réponses tout en réduisant les coûts d'exploitation.

Le problème est que la mémoire de la carte graphique est limitée, et qu'il faut constamment libérer de l'espace pour ce cache en évinçant les anciennes entrées. La règle choisie pour décider quoi évincer déterminera directement combien de fois le serveur pourra réutiliser des données déjà calculées. Des chercheurs de l'Université du Maryland et de Capital One ont montré qu'il n'existe pas de règle universelle — et proposent WAKMan, un système qui sélectionne lui-même la stratégie adaptée en observant le trafic réel.

Le trafic vers les serveurs LLM est généralement mixte : il comprend des questions ponctuelles sans mémoire des messages précédents, des dialogues multi-tours avec un historique de conversation, et des scénarios agentiques où un système d'IA exécute lui-même une série d'étapes consécutives en quelques secondes.

Ces trois types de requêtes présentent des schémas de réutilisation des données fondamentalement différents :

• Les étapes agentiques reviennent au contexte commun presque instantanément, en quelques secondes, ce qui favorise la règle « évincer les plus anciens » (LRU) — qui est d'ailleurs la norme dans le moteur populaire vLLM.
• Les requêtes fixes populaires (par exemple les instructions système de services fréquemment utilisés) et les longs dialogues reviennent à leur contexte après de nombreuses autres requêtes sans rapport. Pour eux, ce n'est pas la fraîcheur qui compte, mais la fréquence d'utilisation — et c'est là que la règle S3FIFO l'emporte, en protégeant les blocs fréquemment demandés d'une éviction par du "bruit" ponctuel.

Les auteurs ont testé les deux règles sur 20 flux de requêtes mélangés artificiellement, avec des proportions variables de scénarios ponctuels, multi-tours et agentiques. LRU battait S3FIFO sur les mélanges orientés agents, avec jusqu'à 12 % de réussites de cache supplémentaires, mais perdait jusqu'à 22 % sur les mélanges dominés par les dialogues et les requêtes répétées. Plus frappant encore : même en gardant la composition du trafic fixe, il suffit de modifier un seul paramètre — par exemple le nombre moyen de répliques dans un dialogue ou la longueur du texte d'entrée d'une requête ponctuelle — pour inverser le vainqueur.

Sur le même mélange de requêtes, LRU l'emportait avec des dialogues courts de 2 répliques, tandis que S3FIFO l'emportait avec des dialogues de 8 répliques, avec un écart de 15,4 points de pourcentage.

Comment fonctionne WAKMan

L'idée de WAKMan est de ne pas deviner le type de trafic à l'avance, mais de le tester en permanence dans la pratique. Le système maintient, à côté du serveur réel, deux copies "fantômes" du cache — l'une avec la règle LRU, l'autre avec la règle S3FIFO — et fait rejouer sur elles le journal des requêtes récentes de l'intervalle de temps écoulé. La stratégie gagnante est celle qui, sur ce même ensemble de requêtes, a obtenu le plus de correspondances avec les données déjà en cache. Le serveur bascule sur elle jusqu'à la vérification suivante.

Pour cela, WAKMan n'a besoin de connaître ni le contenu des requêtes, ni leur type, ni le numéro de réplique dans un dialogue — il utilise uniquement les hachages des blocs de données que vLLM calcule déjà en fonctionnement normal. C'est important, car en pratique, le serveur est souvent physiquement incapable de déterminer le type de requête : l'historique du dialogue est assemblé côté client, et les exigences de confidentialité et de séparation des données interdisent au serveur de "lire" le contenu des requêtes pour en deviner la nature.

Résultats et limites

Lors d'expériences menées avec le modèle Gemma, déployé via vLLM sur quatre cartes graphiques NVIDIA RTX PRO 6000, WAKMan a obtenu en moyenne 5 points de pourcentage de réussites de cache supplémentaires par rapport à la règle LRU, standard dans vLLM. Parmi les trois stratégies testées — LRU pur, S3FIFO pur et WAKMan dynamique — c'est bien WAKMan qui a affiché l'écart moyen et l'écart maximal les plus faibles par rapport à un cache idéal de taille infinie, qui pourrait théoriquement tout conserver.

La principale faiblesse de cette approche réside dans le délai de réaction : la décision de changer de stratégie n'est pas instantanée, elle est prise à la fin de l'intervalle écoulé, et si la nature du trafic change brutalement juste après un basculement, une partie des requêtes de cet intervalle sera traitée par une stratégie non optimale. Les auteurs notent également qu'il est possible d'ajouter d'autres stratégies d'éviction de cache à leur système, à condition de pouvoir en simuler le comportement sans matériel réel — l'ensemble des stratégies "candidates" ne se limite donc pas à LRU et S3FIFO.

Pour les équipes qui exploitent des produits LLM avec un trafic mixte — une partie des utilisateurs mène de longs dialogues, une autre utilise des scénarios agentiques, une autre pose simplement des questions ponctuelles — la conclusion est pratique : une stratégie de mise en cache figée perd presque à coup sûr en performance sur une partie du trafic, et il est pertinent d'intégrer dès maintenant un mécanisme de basculement adaptatif au niveau de l'infrastructure, plutôt que de choisir « la » bonne règle une fois pour toutes.