PrefixSim : un simulateur ouvert de cache KV compare plus de 40 politiques d’éviction

Si vous exploitez des LLM en production, vous avez certainement déjà entendu parler de la mise en cache des préfixes. Le principe est simple : de nombreuses requêtes commencent de la même manière, avec un prompt système, une description des outils ou un historique de conversation. Inutile de recalculer leur cache KV à chaque fois : on peut le conserver et le réutiliser. Mais la mémoire GPU est limitée et, tôt ou tard, le cache doit évincer certains éléments. Ce choix détermine la quantité de temps GPU gaspillée.

C’est précisément le problème auquel s’attaque PrefixSim, un projet rendu public par Juncheng Yang (@1a1a11a). Il s’agit d’un simulateur rapide de cache de blocs KV pour le service d’inférence des LLM. Ses auteurs ont également publié deux jeux de données contenant des traces de charge. Une réserve : le message d’origine sur X s’interrompt en pleine phrase. Nous nous en tenons donc ici aux informations qu’il donne explicitement. Pour les détails, notamment le format des traces et la licence, il faut consulter le dépôt.

Quel problème résout-il ?

Les politiques de cache classiques, comme LRU, ont été conçues pour des pages web et des blocs de disque. Les blocs KV ont d’autres particularités. Ils sont organisés en arbre de préfixes : un bloc situé au début d’une chaîne est nécessaire à tous ceux qui le suivent. Évincer un bloc « ancien » situé à la racine revient à rendre toute une branche inutilisable. Par ailleurs, tous les blocs n’ont pas le même coût de calcul : recalculer un long préfixe coûte bien plus cher que recalculer un préfixe court.

Le taux de succès du cache, ou hit rate, peut donc être trompeur ici. Les auteurs de PrefixSim désignent explicitement les économies de calcul, ou compute savings, comme critère principal : quelle quantité de travail de prefill a-t-on pu éviter ? Deux politiques affichant le même taux de succès peuvent produire des économies de ressources GPU très différentes.

À quoi cela ressemble-t-il en pratique ?

Imaginez un assistant conversationnel doté d’un long prompt système et utilisé dans des dizaines de milliers de sessions par jour. Vous prenez une trace réelle de requêtes et la rejouez dans le simulateur avec différentes politiques d’éviction. Selon l’auteur, il y en a plus de 40. Vous obtenez alors celle qui économise le plus de calculs pour la quantité de mémoire que vous consacrez au cache.

Le mot essentiel est ici « réelles ». Les charges synthétiques produisent souvent de beaux chiffres qui ne se retrouvent pas en production. La publication de deux jeux de données ouverts de traces de service d’inférence est donc utile en soi : elle offre à la communauté une base commune de comparaison, au lieu d’une collection de benchmarks internes impossibles à comparer.

Autre intérêt du simulateur : le coût des expérimentations. Tester une politique d’éviction sur un cluster en production est long et risqué : il faut modifier le moteur, déployer les changements et attendre un trafic représentatif. Une simulation sur une trace enregistrée prend quelques minutes et ne perturbe rien.

Comment l’utiliser ?

Si vous construisez votre propre infrastructure d’inférence ou optimisez vLLM, SGLang et d’autres moteurs similaires, PrefixSim permet de vérifier si vous passez à côté d’économies. Enregistrez une trace de votre charge de travail, rejouez-la dans le simulateur et comparez votre politique actuelle aux autres options. Si l’écart de calculs de prefill économisés est significatif, vous avez un argument pour améliorer le cache. Sinon, vous saurez au moins que la solution standard répond à vos besoins.

Pour les responsables produit et les fondateurs, l’enjeu est ailleurs : l’efficacité du cache influe directement sur le délai avant le premier token et sur le coût de revient d’une requête. Pour les services utilisant de longs préfixes communs — agents, assistants RAG ou assistants de programmation — cela peut représenter un poste de dépenses conséquent.

Limites

Un simulateur reste un modèle. Il ne prend pas en compte tout ce qui se passe dans un moteur réel : fragmentation de la mémoire, ordonnanceur, saturation des files d’attente. Les résultats obtenus sur les traces de certaines entreprises ne se transposeront pas nécessairement à votre charge de travail. Nous n’avons pas non plus vu de validations indépendantes à ce stade : au moment de la publication, il s’agit d’une annonce sur X ayant enregistré environ 7 500 vues. Mais en tant qu’outil et ensemble de données ouvertes consacré à un domaine du service d’inférence des LLM encore débattu et sous-estimé, le projet semble mériter qu’on lui consacre une soirée.