Le 25 mars, Google Research a publié un article, et de nombreuses personnes sur Twitter l'ont appelé "Pied Piper" – l'entreprise fictive de la série Silicon Valley qui a failli changer l'histoire d'Internet grâce à un algorithme de compression.
La comparaison est un peu exagérée, mais pas si absurde.
La proposition centrale de TurboQuant : compresser l'utilisation mémoire du cache KV lors de l'inférence de grands modèles d'au moins 6 fois, sans réentraînement et sans perte de précision. Sur un GPU H100, la version TurboQuant 4 bits est jusqu'à 8 fois plus rapide que la version standard 32 bits.
Ce que ce chiffre signifie en termes de coûts réels est simple à calculer.
Qu'est-ce que le cache KV et pourquoi le compresser
Lors de l'inférence de grands modèles (quand vous posez une question et que le modèle répond), une zone mémoire appelée cache KV (cache clé-valeur) est nécessaire. Elle stocke les résultats intermédiaires du mécanisme d'attention, évitant au modèle de tout recalculer à chaque fois.
Le problème : plus la fenêtre de contexte est longue, plus le cache KV est volumineux. De nombreux modèles actuels ont des fenêtres de contexte de millions de tokens, et le cache KV peut consommer la majeure partie de la mémoire d'une carte A100/H100. Cela limite directement le nombre d'utilisateurs pouvant être servis simultanément et la durée des conversations.
C'est l'une des principales raisons du coût élevé de l'inférence IA.
L'objectif de TurboQuant est de compresser cette mémoire.
Deux étapes : PolarQuant + QJL
TurboQuant combine deux algorithmes : PolarQuant et QJL (Quantized Johnson-Lindenstrauss).
Étape 1 – PolarQuant : Conversion des vecteurs du système de coordonnées cartésiennes aux coordonnées polaires.
Cette conversion présente un avantage crucial : dans les coordonnées cartésiennes, chaque direction a une plage de valeurs différente, ce qui nécessite de stocker un coefficient de normalisation lors de la quantification (compression), augmentant le coût mémoire. En coordonnées polaires, les données sont décomposées en "magnitude" et "direction", et la direction est mappée sur une grille circulaire régulière, éliminant le besoin de l'étape de normalisation supplémentaire et rendant la perte de précision plus contrôlable.
Étape 2 – QJL : Utilisation de la transformée de Johnson-Lindenstrauss pour traiter l'erreur résiduelle.
Cette méthode compresse chaque valeur de vecteur à seulement 1 bit de signe (+1 ou -1), avec un coût mémoire proche de zéro. Combiné à un estimateur spécialement calibré, il garantit que la précision du calcul du score d'attention n'est pas compromise.
La combinaison des deux étapes compresse chaque valeur du cache KV de 16 bits à 3 bits, soit un taux de compression supérieur à 6.
Chiffres de performance clés
| Scénario de test | Résultat |
|---|---|
| Taux de compression mémoire du cache KV | Au moins 6 fois (test LongBench sans perte de précision) |
| Largeur de bits de quantification | De 16 bits à 3 bits |
| Gain de vitesse sur H100 | Version TurboQuant 4 bits jusqu'à 8 fois plus rapide |
| Réentraînement nécessaire ? | Non |
Dans les tests de recherche vectorielle, TurboQuant a constamment surpassé les bases PQ et RabbitQ en taux de rappel 1@k, tandis que le temps de construction de l'index était presque négligeable.
Importance et limites
Le PDG de Cloudflare, Matthew Prince, a qualifié TurboQuant de "moment DeepSeek de Google". C'est une affirmation un peu forte, mais la perspective est juste : DeepSeek a réduit les coûts d'entraînement grâce à l'optimisation technique, TurboQuant réduit les coûts d'inférence grâce aux algorithmes de compression. La logique est la même.
Cependant, il y a une limite importante à préciser : TurboQuant ne concerne que la mémoire d'inférence, pas la mémoire d'entraînement. Il n'affecte en rien la puissance de calcul et la mémoire nécessaires pour entraîner les grands modèles. Par conséquent, il ne change pas le paysage de "qui peut entraîner le modèle le plus puissant", mais seulement "combien coûte l'exécution du modèle".
Une autre réalité est que TurboQuant est encore un résultat de laboratoire, qui sera officiellement présenté à l'ICLR 2026 (fin avril), et n'a pas encore été déployé à grande échelle dans des produits réels. Il n'y a actuellement aucune information publique sur l'intégration de TurboQuant par Google dans le service d'inférence de la gamme Gemini.
Il y a encore une distance entre l'article et le produit – l'adaptation technique, la vérification de stabilité et les tests de régression sont des processus chronophages. Cependant, étant donné que les frameworks d'inférence populaires comme vLLM ont déjà des intégrations communautaires de TurboQuant (des implémentations de noyau Triton sont déjà apparues sur GitHub), le délai d'entrée dans un environnement de production réel ne devrait pas être trop long.
Si elle est finalement mise en œuvre, la combinaison d'une compression mémoire de 6 fois et d'un gain de vitesse de 8 fois aura un impact réel sur la structure des coûts de l'inférence IA – pas du type "benchmark joli, inutile en pratique".
Les responsables de la recherche sont Amir Zandieh (Research Scientist) et Vahab Mirrokni (Google Fellow, VP).
Source de référence : TurboQuant: Redefining AI efficiency with extreme compression (Google Research) ; Google unveils TurboQuant, a new AI memory compression algorithm (TechCrunch) ; CocoLoop ; Google's TurboQuant compresses AI memory by 6x, rattles chip stocks (The Next Web)