Publié le 23 septembre 2026 à 11:00 · Publication originale
Toutes commencent par les mêmes instructions.
Règles de sécurité, description du métier, format attendu, documentation interne: parfois plusieurs milliers de tokens identiques sont placés avant la question de l'utilisateur.
Sans optimisation, le modèle doit recalculer cette partie à chaque requête.
Il existe pourtant une possibilité: conserver les calculs déjà effectués.
Lorsqu'un transformeur lit un texte, ses couches d'attention produisent pour chaque token des représentations appelées clés et valeurs. Elles sont conservées dans le cache KV afin de ne pas être recalculées pendant la génération.
Si une nouvelle requête commence exactement par le même préfixe, une partie de ce travail peut être réutilisée.
C'est le cache de préfixe.
vLLM, moteur open source d'inférence, découpe notamment le cache KV en blocs et calcule une empreinte de leur contenu. Lorsqu'une nouvelle requête possède les mêmes premiers blocs, le moteur retrouve ceux déjà calculés et reprend à partir de là.
Le gain concerne surtout la phase de lecture du prompt, appelée "prefill". Le modèle doit toujours générer les nouveaux tokens de la réponse.
Cette distinction explique pourquoi deux requêtes contenant exactement la même quantité de texte peuvent ne pas demander la même quantité de calcul.
Mais un détail suffit à casser la réutilisation.
Changer un token au début du préfixe modifie la chaîne de blocs qui suit.
L'ordre dans lequel une application assemble instructions, documents et question devient donc une décision d'infrastructure.
Mettre les éléments stables en premier et les informations variables plus tard peut augmenter les possibilités de réutilisation.
Le texte envoyé au modèle possède ainsi une propriété rarement visible pour celui qui l'écrit: son ordre peut modifier le coût informatique de son traitement.
ULTRA®
Le cache de préfixe introduit même un problème de sécurité.
Un attaquant partageant l'infrastructure pourrait envoyer différents préfixes et observer leur temps de traitement. Une réponse anormalement rapide peut indiquer qu'un bloc identique existe déjà dans le cache.
Le temps devient alors un canal auxiliaire permettant d'inférer l'existence d'un contenu sans jamais le lire directement.
vLLM prévoit pour cela un "cache_salt". Cette valeur entre dans l'empreinte du premier bloc et empêche des requêtes appartenant à des domaines de confiance différents de partager leurs blocs KV.
Le moteur sait également déporter des blocs terminés de la mémoire GPU vers la mémoire CPU, plus lente mais plus abondante, puis les remonter lorsqu'ils sont réutilisés.
Conseil: mesurer séparément taux de cache, temps du premier token et débit de génération.
Un cache peut accélérer énormément la lecture d'un long contexte sans accélérer d'une seule opération la production des nouveaux tokens.