galahad-kv conserve le KV-cache sur NVMe et charge un bloc 2,8–4,3 fois plus vite qu'un recalcul

Des chercheurs ont évalué une couche mémoire pour LLM qui ne recalcule pas le prompt à chaque fois, mais récupère sur disque un état KV déjà prêt. Le paquet galahad-kv a été testé sur 50 millions de tokens de texte public réel, via vLLM sur une seule NVIDIA H100, avec les modèles Gemma 4 12B et Gemma 4 31B. Les 100 blocs vérifiés sur 100 sont revenus du stockage sans recalcul. Le chargement s'est avéré 2,8–4,3 fois plus rapide, et le GPU a consommé 8,8–12,3 fois moins d'énergie.

Comment fonctionne la couche mémoire

Un modèle n'exploite que le texte qui tient dans sa fenêtre de contexte. De plus, à chaque envoi de prompt, il recalcule son état interne KV (key-value), même si le texte n'a pas changé. Sur de longs contextes, ce recalcul coûte du temps et de l'énergie.

Galahad-kv découpe le flux en blocs d'environ 16 000 tokens. L'état KV de chaque bloc est écrit sur un disque NVMe local chiffré, puis restitué à l'identique, octet pour octet, lors de l'accès. Selon une estimation grossière, 50 millions de tokens donnent environ 3 100 blocs. Le stockage se mesure alors en téraoctets.

Les auteurs le précisent d'emblée : il s'agit d'une réutilisation de l'état sauvegardé. La fenêtre d'attention reste inchangée, un seul bloc est chargé à la fois, et la qualité de la réponse dépend du modèle lui-même.

Ce que montrent les mesures

Le test a tourné sur une seule H100 sous vLLM, avec des blocs vérifiés jusqu'à une profondeur de 50 millions de tokens. Principales métriques :

• 100 blocs sur 100 vérifiés ont été chargés depuis le stockage chiffré sans recalcul, sur les deux modèles, à des profondeurs de 0 à 50 millions de tokens ;
• le chargement d'un bloc est 2,8–4,3 fois plus rapide que le recalcul ;
• la consommation d'énergie du GPU est 8,8–12,3 fois plus faible ;
• la mémoire GPU est restée stable sur l'ensemble du flux de 50 millions de tokens ;
• Gemma 4 12B a répondu correctement à 82 questions sur 100, Gemma 4 31B à 98 sur 100 ;
• aucun des deux modèles n'a inventé de réponse.

Le dernier point compte autant que la vitesse. Face à des questions sur des faits placés des millions de tokens avant la requête, un modèle échoue le plus souvent en répondant avec aplomb à côté de la plaque. Ici, les erreurs se limitaient à l'absence de bonne réponse, sans hallucination. L'écart entre 82 et 98 % montre que la couche mémoire livre l'état, mais que c'est au modèle de le lire correctement. Le plus gros s'en sort nettement mieux.

Les limites et les usages concernés

L'approche comporte trois limites. L'écriture de la mémoire a un coût unique : chaque bloc doit être calculé et sauvegardé une fois. Le stockage exige des téraoctets de NVMe local. Enfin, un seul bloc est chargé à la fois : les questions qui demandent de croiser des faits issus de nombreux endroits du corpus ne sont donc pas couvertes par ce test. Il s'agit d'un preprint en première version, et aucune reproduction indépendante n'est visible pour l'instant. Mais les auteurs décrivent un protocole conçu pour se prémunir contre les moyens classiques de tromper les benchmarks de long contexte, et proposent une reproduction sur un seul GPU avec des logiciels publics et une licence gratuite du paquet.

La conclusion pratique pour les ingénieurs est la suivante. L'approche a du sens lorsqu'un même grand volume de texte est lu en boucle : dépôts de code, documentation, archives, longue histoire d'un agent. Dans ces cas, le recalcul du préfixe absorbe l'essentiel du temps GPU.

Avant de déployer, trois points sont à chiffrer : combien de téraoctets de NVMe votre corpus exigera, si l'écriture unique est amortie à votre fréquence d'accès, et si votre modèle suffit pour lire avec précision un bloc chargé. Une seule H100 et la pile publique décrite dans l'article suffisent pour vérifier. Un essai sur vos propres données montrera vite si les chiffres de 2,8–4,3 fois en vitesse et de 8,8–12,3 fois en énergie se confirment.