Transforme et vous vaincrez : comment Google compresse les LLMs 6x en changeant de coordonnées

Multiplier est difficile. Additionner est facile.

Tous les écoliers savent cela dès le primaire. Ce qu’ils ignorent, cependant, c’est que les logarithmes existent précisément pour exploiter cette asymétrie : transformer une multiplication en une addition, travailler dans un monde plus simple, puis annuler la transformation. Le résultat est correct et l’effort, une fraction.

Ce modèle — transformer un problème dans un espace où le résoudre est trivial, le résoudre, puis revenir — est l’un des principes les plus puissants de toute l’ingénierie. La FFT le fait avec les signaux. Les logarithmes le font avec les produits. Et aujourd’hui, Google vient de publier un article scientifique qui l’applique à la compression des modèles de langage.

Ce concept s’appelle TurboQuant, et l’idée est si ingénieuse qu’elle mérite un article.

Le problème : compresser sans dégrader

Les modèles de langage de grande taille (LLMs) modernes présentent un goulot d’étranglement, non pas dans le modèle lui-même, mais dans leur mémoire de travail. Chaque fois qu’un modèle génère du texte, il conserve en mémoire des structures appelées key-value cache (KV cache) — en gros, le “contexte” que le modèle doit garder en tête pour générer le mot suivant.

Dans un grand modèle avec un contexte allongé, le KV cache peut occuper des dizaines de gigaoctets de VRAM. C’est un problème sérieux : la VRAM d’un GPU est coûteuse, limitée et partagée avec d’autres processus.

La solution évidente est la quantification : réduire la précision de chaque nombre. Au lieu de stocker chaque valeur sur 32 bits (float32), on les entrepose sur 4 bits, voire 3. On passe ainsi d’une plage continue à une échelle discrète avec moins de niveaux. Cela fonctionne assez bien.

Jusqu’à ce que vous tombiez dans le piège.

Le piège des constantes de normalisation

Pour quantifier un bloc de nombres, vous devez connaître leur plage : leur minimum et maximum. Ces valeurs sont appelées constantes de normalisation, et vous devez les conserver avec une grande précision (16 bits) pour pouvoir reconstruire les valeurs originales.

Et voilà le hic : si vous quantifiez à 3 bits par nombre mais devez stocker une constante de 16 bits tous les 8 nombres, par exemple, ces constantes ajouteront 2 bits supplémentaires par nombre. Votre compression “à 3 bits” occupe en réalité 5 bits effectifs. Vous perdez presque la moitié du gain attendu.

C’est comme déménager dans un appartement plus petit et découvrir que les cartons de déménagement remplissent la moitié de l’espace.

Et vous ne pouvez pas simplement faire des blocs plus grands pour amortir les constantes, car des blocs plus grands signifient une approximation moins précise — la plage s’élargit et la précision baisse. Vous êtes pris entre deux forces opposées.

Ce problème est ouvert depuis des années. Tout le monde a essayé de le résoudre en inventant des meilleurs compresseurs : blocs adaptatifs, quantification non uniforme, schémas hybrides. Plus de complexité, plus de paramètres, pour peu de résultats.

Google a fait quelque chose de différent. Ils n’ont pas inventé un meilleur compresseur. Ils ont changé de coordonnées.

Le changement de coordonnées : des cartésiennes aux polaires

L’idée centrale de TurboQuant est d’appliquer une rotation aléatoire au vecteur avant de le quantifier, puis de transformer le résultat en coordonnées polaires.

Décortiquons cela.

Étape 1 : Rotation aléatoire

Imaginez que vous avez un vecteur dans un espace de haute dimension. Ses composants sont distribués de manière irrégulière — certaines dimensions ont des valeurs énormes, tandis que d’autres sont presque nulles. Ce déséquilibre est précisément la raison pour laquelle vous avez besoin de constantes de normalisation par bloc : chaque bloc a une plage différente.

Que se passe-t-il si vous multipliez le vecteur par une matrice de rotation aléatoire ? Géométriquement, vous faites pivoter le vecteur dans une orientation arbitraire. Le vecteur reste identique (même longueur, même relation avec les autres vecteurs), mais ses composants se redistribuent.

Et voici un résultat mathématique qui semble magique : dans les espaces de haute dimension, une rotation aléatoire rend les composants du vecteur presque uniformes. C’est un phénomène appelé concentration des mesures — en haute dimension, presque toute la masse d’une distribution se concentre autour de sa moyenne. Faites pivoter aléatoirement et tout devient homogène.

En langage simple : la rotation efface les pics et les vallées. Après rotation, tous les blocs ont des plages similaires. Et si tous les blocs ont des plages similaires… vous n’avez plus besoin d’enregistrer la plage de chacun.

Étape 2 : Transformation en coordonnées polaires

Après la rotation, TurboQuant transforme les vecteurs des coordonnées cartésiennes (x, y, z…) en coordonnées polaires (un rayon et plusieurs angles).

Pourquoi ? Parce que la rotation aléatoire a rendu les angles hautement prévisibles — ils sont concentrés dans des plages étroites et connues d’avance. Les limites de quantification sont fixes. Elles ne dépendent plus des données.

Cela signifie que : zéro constante de normalisation pour les angles. Le surplus qui consommait 1 à 2 bits par nombre disparaît. Il suffit de stocker le rayon (un nombre par vecteur) et les angles quantifiés avec des limites fixes.

flowchart LR
    subgraph avant["   Quantification classique   "]
        direction LR
        V1[" Vecteur initial "] --> B1[" Division en blocs "]
        B1 --> N1["&nbsp;Calcul des min/max&nbsp;<br/>par bloc&nbsp;"]
        N1 --> Q1["&nbsp;Quantification&nbsp;<br/>3 bits + 2 bits de surplus&nbsp;"]
    end

    subgraph apres["&nbsp;&nbsp;&nbsp;TurboQuant&nbsp;&nbsp;&nbsp;"]
        direction LR
        V2["&nbsp;Vecteur initial&nbsp;"] --> R2["&nbsp;Rotation&nbsp;<br/>aléatoire&nbsp;"]
        R2 --> P2["&nbsp;Coordonnées&nbsp;<br/>polaires&nbsp;"]
        P2 --> Q2["&nbsp;Quantification&nbsp;<br/>3 bits, surplus ≈ 0&nbsp;"]
    end

    avant ~~~ apres

L’astuce, c’est que la rotation est réversible. Pour récupérer le vecteur original, vous déquantifiez, revenez aux coordonnées cartésiennes et appliquez la rotation inverse. Le résultat est une compression 6x du KV cache sans perte de précision mesurable.

Pourquoi ça marche : ajouter de l’aléatoire réduit l’incertitude

C’est le point le plus contre-intuitif de l’article. Ajouter du bruit (par la rotation aléatoire) réduit l’incertitude. Cela peut sembler contradictoire, mais voici une explication élégante.

Sans la rotation, chaque vecteur a sa propre distribution interne. Certaines dimensions dominent, d’autres sont du bruit. Vous ne savez pas à l’avance quelle plage chaque bloc aura — cette incertitude vous oblige à mesurer et sauvegarder les plages.

Avec la rotation, vous forcez tous les vecteurs à partager une distribution statistique identique (grâce à la concentration des mesures). Vous n’avez plus besoin de mesurer quoi que ce soit, car vous savez déjà à l’avance comment les valeurs seront distribuées. L’aléatoire détruit l’information spécifique à chaque vecteur (qui ne vous servait à rien) et la remplace par une régularité prévisible (qui vous est utile).

C’est comme mélanger un jeu de cartes. Avant de mélanger, vous ne savez pas dans quel ordre elles se trouvent — vous devez regarder chaque carte. Après un mélange efficace, vous savez exactement comment elles sont ordonnées : dans un ordre aléatoire uniforme. Paradoxalement, vous en savez plus sur le jeu mélangé que sur le jeu initial si tout ce que vous devez prédire concerne des propriétés statistiques.

TurboQuant en chiffres

Google a évalué TurboQuant avec plusieurs benchmarks sur les modèles Gemma et Mistral. Les résultats :

Ce dernier point est crucial. La plupart des méthodes de quantification nécessitent un ensemble de calibration pour ajuster leurs paramètres. TurboQuant n’en a pas besoin. La rotation aléatoire fonctionne parfaitement, quels que soient les données, parce que la concentration des mesures est une propriété de l’espace, pas du contenu.

Le modèle que tout programmeur devrait appliquer

TurboQuant illustre un concept bien plus général qui mérite un nom : transforme et vainquez.

L’idée est simple : lorsqu’un problème vous résiste, demandez-vous si vous travaillez dans le bon espace. Parfois, la solution ne réside pas dans un algorithme plus brillant, mais dans une autre représentation du même problème.

Prenons quelques exemples familiers :

Dans tous ces cas, la difficulté ne réside pas spécifiquement dans le problème, mais dans la représentation. Changez de coordonnées et ce qui était complexe devient trivial.

À appliquer dès maintenant

Vous n’avez pas besoin de compresser des LLMs pour utiliser ce modèle. La prochaine fois que vous serez confronté à un problème qui “devrait être facile, mais ne l’est pas”, demandez-vous :

1. Suis-je dans le bon espace ? Si comparer deux éléments est complexe, vous devez peut-être normaliser avant de comparer. Si chercher quelque chose est trop lent, vous avez probablement besoin d’un index (qui n’est qu’une représentation alternative optimisée pour la recherche).

2. Existe-t-il une transformation connue dans mon domaine ? La FFT existe depuis 1965. Les transformées wavelet depuis les années 80. Les embeddings vectoriels depuis 2013. Bon nombre de problèmes “difficiles” disposent déjà de transformations standards qui les résolvent. Avant d’innover, vérifiez si quelqu’un n’a pas déjà trouvé les bonnes coordonnées.

3. Puis-je ajouter de l’aléatoire pour simplifier ? Le hachage, les projections aléatoires, les sketches probabilistes — tout cela fonctionne parce qu’ajouter un aléatoire contrôlé élimine une complexité inutile. Si votre problème est alourdi par une structure irrégulière, détruire délibérément cette structure peut être la solution.

La prochaine fois que vous forcez une solution

La leçon de TurboQuant n’est pas spécifiquement sur la compression. Elle vous invite à aller au-delà des tentatives d’amélioration isolées et à envisager de changer de perspective.

Pendant des années, la communauté de l’apprentissage automatique s’est heurtée aux constantes de normalisation en essayant des quantifications de plus en plus sophistiquées : des blocs plus grands, des niveaux plus fins, des algorithmes plus complexes. Tout cela en restant dans le cadre des coordonnées cartésiennes. Et tout ça pour des améliorations modestes.

Google n’a rien fait de cela. Ils ont pivoté les données, changé de coordonnées, et le problème a disparu. Ils ne l’ont pas résolu, ils l’ont dissous.

La prochaine fois que vous passez des heures à vous battre avec une solution qui ne s’ajuste pas parfaitement, arrêtez-vous un instant et demandez-vous : est-ce que je m’acharne contre le problème ou contre sa représentation ? Parce que si vous êtes dans le mauvais espace, le meilleur algorithme du monde ne pourra pas vous sauver.

Source: TurboQuant : Redéfinir l’efficacité de l’IA grâce à une compression extrême — Blog Google Research.