Contexte et objectifs

Le prefix‑cache KV est le levier le plus efficace pour réduire le coût des agents LLM en réutilisant les préfixes de requêtes précédentes. Tous les stacks de service – vLLM, SGLang, LMCache ou Mooncake Store – utilisent LRU comme politique d'éviction par défaut, même si la littérature récente avance que LRU serait inadapté aux charges d'agents, où les sessions peuvent rester inactives pendant de longues périodes. L’auteur a donc construit un simulateur afin de tester trois variantes d’éviction et de vérifier si l’on pouvait surpasser le LRU de production.

Méthodologie du simulateur

Le simulateur est block‑granular et repose sur un modèle d’événements discrets. Trois contraintes essentielles sont modélisées : (1) les hits sont prefix‑contiguous ; un bloc manquant à la profondeur 3 rend inutilisables tous les blocs suivants même s’ils sont en mémoire, (2) la structure radix empêche l’éviction d’un bloc tant que l’un de ses enfants reste résident, ce qui signifie que le LRU s’applique uniquement aux feuilles du radix, et (3) la chaîne en cours d’exécution doit rester pinned. Le code de validation reproduit exactement les traces publiées :

make validate
sessions=393  requests=68266

Les métriques extraites comprennent la durée moyenne d’une session (p50 = 1.84 h, p90 = 28.36 h, max = 254.8 h), les intervalles entre requêtes (p50 = 2.1 s, p99 = 3426.3 s) et le taux d’occupation du processeur (duty‑cycle p50 = 13.9 %).

Analyse des résultats

La reproduction du tableau « hit‑rate vs capacité » de Mooncake montre une progression de 30 % à 50 % de taux de hit lorsque la capacité passe de 1 000 à 50 000 blocs, avec une saturation au‑delà. Un écart systématique de +4 à +6 points de pourcentage apparaît, inexpliqué malgré cinq définitions différentes du métrique, ce qui indique une possible divergence de version de trace. La différence entre un LRU plat et le LRU limité aux feuilles du radix est négligeable (0.02 pp), confirmant que la restriction n’apporte aucun avantage mesurable sur ce workload.

En découpant la recomputation selon le gap précédent, 33.1 % des tokens recomputés proviennent de requêtes arrivées <10 s après la précédente, alors que seules 17.5 % proviennent de gaps supérieurs à 5 min. Ainsi, les boucles d’outils de deux secondes, dont les ensembles de travail dépassent la capacité du cache (≈ 88 k tokens), sont la source dominante de miss, et non la prédiction de session morte. Le TTL de 300 s n’est jamais déclenché ; les évictions sont entièrement dictées par la contrainte de capacité, ce qui rend les politiques basées sur la « liveness » peu pertinentes.

Implications et limites

Lorsque le cache est saturé, la politique d’éviction a un impact marginal : même des alternatives comme LFU ou SLRU ne dépassent pas le LRU de base. La priorité doit donc être donnée à la provision de capacité plutôt qu’à l’optimisation du TTL ou à la détection de sessions inactives. Cependant, l’étude ne résout pas l’anomalie de +4–6 pp et ne fournit pas de trace détaillée du profil de tokens, ce qui limite la généralisation des conclusions à d’autres jeux de données. En résumé, le LRU reste difficile à battre dans les environnements agentic LLM, et les gains attendus proviennent surtout d’une augmentation de la taille du cache plutôt que d’un changement de politique d’éviction.