Du Token-First au KV-First

6 juil.
8 min de lecture

Le token n'est pas un choix. C'est une contrainte matérielle — et ce n'est pas le bon niveau d'abstraction pour penser la compréhension d'un modèle.

Imaginez qu'en ouvrant un livre, vous deviez le relire du début. Non pas parce que vous avez oublié — parce que quelqu'un arrache vos marque-pages entre chaque lecture.

C'est ce que fait un modèle de langage. À chaque appel, il reconstruit sa compréhension du contexte depuis zéro. L'état qu'il avait produit — ce qu'il avait "compris" — est jeté entre les appels.

J'ai mesuré le coût de ce gaspillage sur mon propre travail. Environ 3 000 € de tokens pour construire une version de démonstration d'un logiciel. Huit modèles différents, des milliers d'appels API. À la fin du projet, j'ai fait le calcul — pas le coût total, mais ce qui avait été utile. Une part significative de ces tokens n'avait servi qu'à une chose : re-expliquer au modèle ce qu'il avait déjà compris lors de l'appel précédent.

Le même codebase, re-parsé. Le même contexte technique, re-injecté. La même architecture, re-décrite. À chaque nouvelle session, à chaque changement de modèle, à chaque timeout — on repart de zéro.

Ce n'est pas un bug. C'est l'architecture.

Pourquoi le token

Quand on parle d'IA générative, tout se mesure en tokens. La fenêtre de contexte : 128K tokens. Le coût : quelques centimes à quelques dollars par million de tokens. La mémoire : proportionnelle au nombre de tokens. La vitesse : tokens par seconde.

Le token est l'unité atomique. Tout le pipeline est construit autour de lui. Mais pourquoi ?

Un réseau de neurones ne lit pas du texte. Il calcule sur des nombres — des vecteurs de taille fixe. Il faut donc transformer chaque mot en un vecteur numérique avant de pouvoir le traiter. Mais les mots sont imprévisibles : certains sont courants, d'autres rares, d'autres n'existent pas encore. Impossible de leur attribuer à tous un vecteur à l'avance.

Le token résout ce problème. Au lieu de travailler sur les mots entiers, on les découpe en fragments plus courts et plus réguliers — des sous-unités qui reviennent souvent et couvrent n'importe quel texte. Chaque fragment reçoit un vecteur de dimension fixe. C'est la brique élémentaire que le modèle sait traiter.

Et c'est le GPU qui a fait de cette brique le centre de tout le système.

Un GPU n'est pas un processeur généraliste — c'est une machine spécialisée dans une seule opération : la multiplication de matrices. Des milliers de cœurs qui exécutent la même instruction en parallèle sur des blocs de données de taille fixe. L'environnement logiciel qui orchestre ça s'appelle CUDA — c'est la couche qui transforme le silicium brut en capacité de calcul pour l'IA. Et CUDA a un appétit très précis : des tenseurs réguliers, de taille prévisible, qui remplissent ses grilles de calcul de façon optimale.

Le token satisfait parfaitement cet appétit. L'opération centrale du transformer — le calcul d'attention — est une multiplication dense de ces vecteurs, massivement parallélisable. Le token nourrit le GPU de façon optimale. C'est pour ça qu'il est devenu l'unité de mesure de toute l'industrie — fenêtres, coûts, mémoire, vitesse : tout est compté en tokens.

Pas parce que c'est la meilleure façon de représenter du sens — parce que c'est la meilleure façon de remplir un GPU.

Le problème que personne ne nomme

Ce processus de reconstruction — le modèle qui parcourt le contexte fourni et construit un état interne à chaque appel — a un nom technique : le prefill. Et il est coûteux : proportionnel à la longueur du contexte.

Le prefill produit un état qui représente ce que le modèle a "compris" de l'ensemble. Mais quand l'appel se termine, cet état est détruit. Le modèle n'a pas de mémoire non pas parce qu'il est incapable de comprendre — parce que personne ne garde ce qu'il a compris.

C'est une observation que j'ai faite sous d'autres angles dans des articles précédents, sans la nommer. Dans Le cadavre exquis, je décrivais un modèle qui continue une phrase sans savoir où elle va.

"Ce n'est pas perdre le fil, c'est ne jamais en avoir eu".

Il manquait la cause infrastructurelle. La voici.

De la séquence à l'état

L'état interne que le modèle construit pendant le prefill a un nom technique : le KV cache (Key-Value cache). C'est le produit consolidé du traitement transformer — la sortie de l'opération de calcul, pas l'entrée.

Dans un système Token-First, le KV cache est un sous-produit éphémère. Il naît pendant l'inférence, il meurt après la génération.

Et si, au lieu de le jeter, on le gardait ?

C'est l'idée fondamentale de ce que j'appelle KV-First : élever le KV cache au rang d'artefact de premier ordre. Un objet nommé, versionné, vérifiable, transportable et persistant. L'unité de travail n'est plus "ce que le modèle reçoit" (des tokens) mais "ce que le modèle a compris" (un état interne).

Ce n'est pas une optimisation du Token-First. C'est un changement de niveau d'abstraction. On passe de la séquence à l'état.

Ce que ça change concrètement :

Persistence. Un codebase encodé une fois reste disponible indéfiniment. Plus de re-prefill.
Transport. L'état de compréhension peut circuler entre machines, entre sessions, entre nœuds d'un réseau. Imaginez un interprète qui, à la fin d'une session, au lieu de jeter ses notes, les archive — le lendemain, un autre interprète reprend ces notes et continue sans avoir écouté le discours original. Ce qu'il a entre les mains, ce ne sont pas les mots du discours, c'est l'état de compréhension de son prédécesseur.
Composition. Plusieurs artefacts KV — contexte de base, module spécifique, état de session — peuvent être assemblés en un seul contexte d'inférence.
Amortissement. Le coût du prefill est payé une fois et amorti sur N requêtes suivantes, qui ne font que décoder.

Prenons un codebase ou une base documentaire — un contexte lourd, stable, consulté régulièrement. Pour 100 000 tokens consultés 10 fois dans la journée, un système KV-First effectue le prefill une seule fois. Les 9 requêtes suivantes reprennent directement là où la première s'est arrêtée. Le ratio mesuré sur un cluster 3 nœuds Apple Silicon, avec un modèle Llama 3.2 3B et en réutilisation cross-session (artefact KV chargé depuis le stockage persistant vs prefill à froid sur le même contexte) : 6,3× de réduction du temps de premier token. Les détails du protocole de mesure sont dans le repo.

La fenêtre de contexte et ce qu'on a inventé pour la contourner

Le problème du Token-First ne s'arrête pas au re-calcul. Il y en a un deuxième, tout aussi structurel : la fenêtre de contexte est limitée.

Un modèle ne peut traiter qu'un certain nombre de tokens à la fois — 4K, 32K, 128K selon les architectures. Au-delà, le texte ne rentre pas. Le modèle ne peut tout simplement pas raisonner sur un corpus qui dépasse sa fenêtre.

L'industrie a produit plusieurs réponses à cette limite.

Côté cloud, le prompt caching (Anthropic, OpenAI, Google) met en cache le préfixe d'un prompt entre les appels — mais c'est un cache côté provider, opaque, limité à un préfixe monolithique, avec un TTL court et aucune persistance inter-session.

Côté infrastructure de serving, le paysage a avancé vite. vLLM, SGLang et LMCache gèrent désormais le KV cache comme une ressource persistante et réutilisable — plus comme un simple buffer interne. LMCache tourne en processus indépendant, survit aux crashes du moteur d'inférence, avec un stockage hiérarchique de la mémoire CPU jusqu'aux backends distribués. Mooncake Store — l'architecture derrière le serving de production de Kimi chez Moonshot AI — fournit un pool de KV cache distribué avec RDMA et transfert zero-copy, intégré dans vLLM, SGLang et TensorRT-LLM. L'industrie a reconnu ce que cet article défend : le KV cache est un artefact qu'on garde.

Ce que ces systèmes ne fournissent pas, c'est un standard. Chacun gère le KV à l'intérieur de ses propres murs, avec son propre format, son propre cycle de vie. Le KV cache persiste, mais il ne voyage pas — il n'existe pas de contrat de compatibilité entre runtimes, pas d'artefact portable qu'un système différent pourrait consommer sans réinventer l'encodage. L'infrastructure se construit. Le standard, non.

Mais le caching et la persistance ne sont pas les seules réponses à la fenêtre de contexte. Une autre stratégie est devenue la plus répandue : au lieu d'essayer de garder ce que le modèle a compris, réduire ce qui entre dans la fenêtre dès le départ. Cette approche, c'est le RAG (Retrieval-Augmented Generation) : sélectionner les fragments les plus pertinents avant de les soumettre au modèle. Un index par embeddings, une recherche par similarité, et seuls les passages jugés utiles sont injectés dans le contexte. C'est ingénieux — mais ça pose un paradoxe structurel : la pertinence d'un fragment n'est souvent déterminable qu'après avoir raisonné sur l'ensemble. Le retrieval décide avant, le raisonnement arrive après. Et un fragment extrait de son document perd son contexte d'émergence — le cadre conceptuel, les contraintes établies plus tôt, tout ce qui donne son sens au passage sans être dans le passage lui-même.

KV-First aborde le problème autrement. Si le corpus tient dans un artefact KV persistant, il n'a pas besoin d'être découpé. Le modèle a déjà raisonné sur l'ensemble lors du prefill initial. La compréhension globale est préservée dans les activations — elle influence le raisonnement sans occuper de place visible dans la fenêtre aux appels suivants.

Ce n'est pas un meilleur RAG. C'est une approche qui élimine le besoin de découpage pour les corpus stables où la cohérence globale compte plus que la pertinence locale — codebase, base réglementaire, dossier médical, corpus juridique. Pour les cas dynamiques, le RAG reste l'approche pertinente. Les deux ne sont pas sur le même axe.

Ce que ça ne fait pas

L'honnêteté impose des limites claires.

KV-First fonctionne aujourd'hui sur des transformers existants. La persistence et le transport d'artefacts KV sont implémentés, déployés et mesurés. Mais le KV cache reste contraint par l'architecture transformer : le mécanisme d'attention exige de matérialiser l'intégralité de l'artefact en mémoire. Un contexte de 100K tokens exige une VRAM proportionnelle, quelle que soit la fraction réellement utile à la requête en cours.

KV-First résout le problème du re-calcul. Pas celui de la mémoire.

Le KV cache, même persisté et transporté, reste un état interne opaque. On peut le stocker, le transporter, le composer au niveau de la position. On ne peut pas le modifier chirurgicalement au niveau du sens — il est impossible de dire "remplace Paris par Lyon dans la compréhension du modèle" sans re-parser le contexte.

C'est un substrat de transport, pas une base de données sémantique.

Un artefact KV est lié au modèle qui l'a produit. Changer de modèle invalide l'artefact — le transport cross-modèle est un problème ouvert, pas une capacité acquise.

Les gains sont mesurables et significatifs sur les corpus stables. Ils ne s'appliquent pas mécaniquement à tous les cas d'usage. Un dialogue conversationnel qui change à chaque tour, un flux de données temps réel — ce ne sont pas les cas où KV-First change la donne. Le cas d'usage naturel, c'est le contexte lourd qui change rarement et qui est consulté souvent : codebase, documentation, corpus réglementaire, base de connaissances.

Un changement de paradigme, pas une fonctionnalité

Le passage de token-first à KV-First n'est pas l'ajout d'un cache plus intelligent. C'est un changement dans ce qu'on considère comme l'unité fondamentale du système.

Le token reste essentiel — c'est l'interface entre le texte et le modèle, et c'est l'unité que le GPU sait traiter. Mais le token n'est pas le bon niveau pour penser la persistence, le transport et la composition de la compréhension d'un modèle.

Le KV cache l'est.

J'ai formalisé cette idée dans un framework technique — KV-First — publié en open source en mars 2026. Il définit des contrats de compatibilité pour les artefacts KV, des niveaux de conformance, et une suite de tests. C'est un point de départ, pas un aboutissement.

Le modèle, à chaque appel, comprend.

Ce qui manque, c'est quelqu'un pour garder ce qu'il a compris.