WAKMan sélectionne la politique d'éviction du KV-cache et devance LRU de 5 points

Le prefix caching des serveurs LLM fait gagner de l'argent et du temps, mais seulement tant que le bon préfixe reste en mémoire. La mémoire est limitée, et le résultat dépend de la politique d'éviction du KV-cache. Suhas Kumar Morisetty et trois autres auteurs, qui ont travaillé dans le cadre d'un stage chez Capital One, ont testé les stratégies courantes sur 20 mélanges de charge. Leur conclusion est simple : il n'existe pas de politique unique qui soit la meilleure. Ils proposent WAKMan, un gestionnaire qui choisit la politique d'éviction d'après le trafic réel. En moyenne, il améliore le hit rate de 5 points de pourcentage par rapport à LRU.

Pourquoi agents et chatbots n'attendent pas la même chose du cache

Le prefix caching permet au serveur de réutiliser les états Key-Value pour les requêtes dont le préfixe est commun avec des prompts précédents. Cela accélère l'étape de prefill et réduit la latence comme le coût de service. Mais le trafic de production réel est hétérogène : requêtes isolées, dialogues multitours, chaînes d'agents, ou n'importe quel mélange de ces cas.

Ces types de requêtes n'ont pas le même « délai de retour » vers un préfixe. Les étapes d'un agent reviennent en quelques secondes : elles ont besoin d'un cache qui retient ce qui est récent. Les prompts populaires et les longs dialogues reviennent après de nombreuses autres requêtes, et pour eux la fréquence d'accès compte davantage. Le premier cas correspond bien à LRU, le second aux politiques fondées sur la fréquence.

Où LRU gagne, où il perd

vLLM utilise LRU par défaut. Les auteurs l'ont comparé à S3FIFO, une politique orientée fréquence, et obtiennent un tableau qui remet en cause l'habitude de choisir une politique une fois pour toutes :

• sur les mélanges dominés par les requêtes agentiques, LRU obtient 12% de hits en plus que S3FIFO ;
• sur les autres mélanges, LRU est en retrait de S3FIFO jusqu'à 22% ;
• un seul paramètre de charge peut suffire à changer le gagnant au sein d'un même mélange.

Ce dernier point est le plus gênant pour les ingénieurs. On ne peut pas mesurer le trafic une fois, choisir une politique et l'oublier. Il suffit qu'un seul paramètre bouge pour que le leader de la veille se retrouve en queue de peloton.

Ce que fait WAKMan

WAKMan choisit la politique d'éviction à partir du trafic réel. Il n'a pas besoin de savoir quelles requêtes arrivent, ni de lire les prompts eux-mêmes. En production, c'est une condition importante : le contenu des requêtes est souvent sensible, en particulier dans une organisation comme une société financière, où le stage a eu lieu. Le gestionnaire se contente d'observer le comportement du trafic.

Résultats finaux de WAKMan :

• gain de hit rate sur LRU de 5 points de pourcentage en moyenne ;
• l'écart moyen le plus faible avec la politique optimale parmi toutes les approches comparées ;
• l'écart maximal le plus faible avec l'optimum parmi toutes les approches comparées ;
• évaluation sur 20 mélanges de charges single-turn, multi-turn et agentic.

Les deuxième et troisième points comptent plus que le gain moyen. Ils témoignent de la prévisibilité : WAKMan ne l'emporte pas forcément sur chaque mélange, mais il s'éloigne moins souvent, et de moins loin, de la meilleure option. Pour un opérateur d'inférence, cela vaut mieux qu'une belle victoire sur un benchmark précis.

Que faire quand la part des agents augmente

Les scénarios agentiques occupent rapidement une part croissante du trafic. Le profil du cache change avec eux : les retours « chauds » et courts deviennent plus nombreux, tandis que les prompts populaires et les longs dialogues restent en toile de fond. Si la politique d'éviction est figée dans le serveur et jamais réexaminée, une partie du gain du prefix caching est perdue. Cette perte prend la forme d'un prefill répété, c'est-à-dire de secondes GPU superflues et de latence en trop.

Conséquences pratiques pour ceux qui exploitent leur propre inférence sur vLLM :

• mesurez le hit rate séparément par type de charge, et pas seulement en moyenne sur le serveur ;
• ne considérez pas LRU comme un choix sûr en toutes circonstances : sur certains mélanges, il perd jusqu'à 22% face à S3FIFO ;
• revérifiez la politique chaque fois que la part du trafic agentique change ;
• évaluez les solutions sur le pire cas, et pas seulement sur le gain moyen.

WAKMan montre que le choix de la politique peut être automatisé sans accès au contenu des requêtes. Pour les grands déploiements, un gain de 5 points de pourcentage de hit rate signifie moins de calculs répétés sur chaque préfixe et une latence plus régulière sous trafic mixte.