Conditional Program compresse la mémoire n-gram de DeepSeek de 203 à 51 Go avec 2 bits par code

Les tables de mémoire n-gram offrent à un modèle de langage une capacité supplémentaire sans quasiment aucun surcoût de calcul : seules quelques lignes sont lues pour chaque token. Le prix à payer, c'est le volume. Pour répondre à n'importe quelle entrée possible, la table entière doit rester accessible. Un nouvel article repéré sur Hugging Face Daily Papers propose le format Conditional Program (CP), qui stocke les lignes à raison de 2 bits par code et ne reconstruit que celles que l'entrée demande. Pour la table de DeepSeek, la taille passe de 203 à 51 Go, et la divergence KL en sortie est inférieure de 41–63 % à celle d'un arrondi naïf sur 2 bits.

Comment fonctionne CP

L'idée est de ne pas quantifier la table comme un tenseur monolithique, mais de décrire chaque ligne par une entrée compacte. Chaque ligne possède un code court et une échelle locale. Le programme qui retransforme le code en vecteur est le même pour toutes les lignes. Il n'est stocké qu'une seule fois pour toute la table, et son coût rapporté à une ligne est quasi nul.

Les auteurs l'implémentent avec trois composants. Le premier est le treillis gaussien (trellis), un codebook structuré dans lequel le code sélectionne un chemin dans le treillis plutôt qu'une entrée d'une liste explicite. Le deuxième est la restauration de la norme : après décodage, la longueur du vecteur est ramenée à sa valeur d'origine, pour que la quantification ne décale pas l'échelle des activations. Le troisième est constitué des entrées de lignes décodables indépendamment. C'est l'exigence clé pour une mémoire conditionnelle : lire une ligne ne nécessite pas de décompresser les blocs voisins.

C'est ce dernier point qui distingue ce problème de la compression classique des poids. Dans ce cas, le décodage se fait par lots, couche par couche. Ici, les accès sont aléatoires et rares, et le format doit supporter l'accès arbitraire.

Ce que montrent les mesures

Les auteurs ont analysé trois familles de mémoires n-gram entraînées. Leur conclusion est double. Les statistiques de chaque coordonnée sont proches d'une loi gaussienne, ce qui justifie le treillis gaussien. En revanche, des relations apprises subsistent entre les lignes, et on ne peut pas les traiter comme du bruit. Malgré cela, à budget de stockage égal, le treillis commun a surpassé à la fois les codebooks ajustés aux données et les variantes avec correction de bas rang (low-rank residual) testées par les auteurs.

Les chiffres clés de l'abstract :

• code : 2 bits par élément, plus une échelle locale par ligne ;
• KL en sortie inférieure de 41–63 % par rapport au round-to-nearest sur 2 bits ;
• table DeepSeek : 203 Go → 51 Go, soit environ 4 fois moins ;
• format : programme de reconstruction commun, entrées de lignes indépendantes ;
• validation sur trois familles de n-gram memory entraînées.

Un mot sur le gain de facteur quatre. Si la table d'origine est stockée en 16 bits, 2 bits purs donneraient une compression d'un facteur huit. L'abstract n'explique pas l'écart. Le surcoût des échelles et des entrées de lignes peut en expliquer une partie, mais il faut le vérifier dans le texte complet de l'article.

En pratique : à quoi sert la mémoire libérée

L'effet pratique principal est formulé dans l'article lui-même : quand la table réside sur le GPU, les gigaoctets libérés peuvent être alloués à des charges plus lourdes. Contexte plus long, davantage de requêtes simultanées, batch plus grand. La mémoire de la carte graphique est presque toujours limitée par le KV-cache, et les 150 Go économisés sur la table se convertissent directement en marge pour lui.

Pour les équipes qui déploient des modèles à mémoire conditionnelle, il existe une autre option. Il est plus simple de garder une table de 51 Go entièrement sur l'accélérateur qu'une table de 203 Go, sans la déporter en mémoire hôte avec une latence à chaque accès. Cela écarte l'un des principaux arguments contre la mémoire n-gram en production.

Il faut aussi rester prudent. La métrique de qualité de l'abstract est la KL de la distribution de sortie, et non un ensemble de benchmarks sur des tâches. Avant d'intégrer CP dans une pile d'inférence, il faut observer le comportement de la table 2 bits sur des tâches réelles, et mesurer le coût du décodage d'une ligne sur GPU sous forte charge. Mais la direction est claire : la mémoire conditionnelle dispose désormais d'un moyen de payer sa capacité en dizaines de gigaoctets, et non en téraoctets.