TurboQuant Google : Tout savoir sur l’Optimisation de l’inférence LLM et Mon analyse pour la compression du cache KV

Par Guizeni Seifeddine.

Ce qu’il faut retenir de TurboQuant

• Une réduction spectaculaire de l’empreinte mémoire : L’algorithme permet de diviser la taille du cache KV (la mémoire de travail des conversations) par un facteur de 3 à 5 en production, ouvrant la voie à des contextes géants sur du matériel plus modeste.
• Un gain de vitesse réel mais surévalué : L’accélération de 8x mise en avant par Google est mesurée par rapport à une base FP32 obsolète. En conditions réelles face à du FP16, l’amélioration de la vitesse de calcul de l’attention tourne plutôt autour de 40 %.
• La supériorité de la version communautaire : La déclinaison d’origine de Google en 3 bits dégrade fortement les capacités de raisonnement complexe des modèles. C’est l’implémentation communautaire TurboQuant+ qui sauve la mise grâce à une approche asymétrique.

Le problème que j’observe au quotidien : le goulot d’étranglement du cache KV

Quand on déploie des modèles de langage à grande échelle, on se heurte très vite à un mur physique. Ce mur, c’est la mémoire de travail de l’IA, communément appelée le cache Key-Value (KV). Pour m’éviter de recalculer l’intégralité de l’historique de notre conversation à chaque nouveau mot généré, le modèle stocke une sorte de fiche de rechange ultra-rapide dans la RAM de la carte graphique.

Le problème est mathématique : ce cache KV grandit de manière linéaire avec la longueur du contexte et le nombre d’utilisateurs simultanés. Très vite, la mémoire sature, provoquant des erreurs de dépassement de capacité (Out-Of-Memory) ou des ralentissements catastrophiques. Les méthodes classiques de compression existent, mais elles souffrent d’un défaut majeur : elles imposent de conserver un catalogue lourd de constantes de décodage pour lire les données compressées, ce qui annule une grande partie des gains de place.

C’est dans ce contexte que Google Research a présenté TurboQuant dans un papier d’avril 2025, suivi d’une forte médiatisation début 2026. L’ambition affichée était de compresser ce cache KV jusqu’à environ 3 bits, réduisant l’empreinte mémoire d’un facteur 6 et accélérant le calcul de l’attention jusqu’à 8x sur des puces de type Nvidia H100, le tout sans réentraînement.

Comment fonctionne l’algorithme (les deux étapes clés)

L’intérêt de TurboQuant réside dans son approche dite “data-oblivious” (indépendante des données). Il s’applique à la volée sur les activations générées lors de l’inférence sans nécessiter de base de données d’entraînement spécifique ni modifier les poids profonds du modèle. Le processus repose sur une double manipulation mathématique.

Étape 1 : PolarQuant (La rotation orthogonale)

Imaginez que l’on doive ranger des objets aux formes complexes et disparates dans des cartons de taille standard. C’est presque impossible sans perdre de place. La première étape, PolarQuant, consiste à appliquer une rotation orthogonale aléatoire aux vecteurs de données. En faisant pivoter mathématiquement ces données, l’algorithme répartit uniformément leur énergie sur toutes les coordonnées. Les données prennent alors une distribution statistique prévisible (proche d’une loi gaussienne ou Beta).

Cette distribution étant connue à l’avance, nous n’avons plus besoin de stocker un dictionnaire de décodage volumineux. Un quantificateur scalaire optimal (calculé via l’algorithme de Lloyd-Max) est pré-calculé une fois pour toutes et applique une compression sur b-1 bits de manière extrêmement propre.

Étape 2 : La correction de résidus QJL (La réduction du biais)

La compression agressive basée sur l’erreur quadratique moyenne (MSE) a tendance à déformer les produits scalaires indispensables au calcul de l’attention des LLM. Pour corriger cela, TurboQuant récupère l’erreur de quantification résiduelle issue de la première étape et la passe à travers une transformée de Johnson-Lindenstrauss quantifiée à 1 bit (QJL).

Ce filtre de correction d’un seul bit fait office de correcteur d’erreurs statistiques. Il élimine le biais de calcul et restitue des scores d’attention très précis avec un coût mémoire supplémentaire dérisoire (1 bit d’overhead).

L’épreuve de la réalité : entre marketing et vrais chiffres

À sa sortie, l’annonce de Google a provoqué des secousses jusque sur les marchés financiers, entraînant une baisse temporaire du cours des actions de géants des puces mémoire comme Micron ($MU), sous l’hypothèse d’une baisse de la demande en mémoire DRAM dans les centres de données. Pourtant, à l’usage, nous avons rapidement tempéré ces promesses théoriques.

Le premier écart concerne la vitesse. Cette fameuse accélération de 8x est calculée par rapport à une référence non compressée en FP32 (32 bits). Or, dans mon travail quotidien, plus personne n’utilise de FP32 pour l’inférence en production ; nous tournons déjà tous sur des configurations optimisées en FP16 ou BF16. Face à ces standards réels, le gain de vitesse de calcul apporté par TurboQuant se situe plutôt aux alentours de 40 %. C’est un excellent résultat, mais bien éloigné des promesses initiales.

Ensuite vient la question de la précision en mode 3 bits. Les tests menés par la communauté open-source (notamment autour du projet vLLM) montrent que si la configuration en 4 bits préserve plus de 98 % de la précision, le passage brutal à 3 bits fait chuter les performances de près de 20 points sur les tâches complexes de logique, de programmation ou de mathématiques à long contexte.

Enfin, une controverse académique a éclaté sur Hacker News et OpenReview. Les créateurs d’un algorithme antérieur nommé RaBitQ ont souligné que Google avait minimisé leurs travaux sur la rotation aléatoire de vecteurs. De plus, Google avait comparé TurboQuant (exécuté sur GPU de pointe) à une version CPU non optimisée de RaBitQ pour gonfler ses courbes de performance. Face aux critiques, Google a dû mettre à jour son manuscrit pour corriger ses citations.

TurboQuant+ : La réponse de la communauté open-source

Puisque Google avait initialement partagé ses recherches sans publier le code source, des développeurs indépendants se sont regroupés sur GitHub pour proposer leur propre implémentation sous le nom de turboquant_plus (portée par le développeur “TheTom”). C’est cette version, TurboQuant+, qui a transformé la théorie en un outil véritablement exploitable en production grâce à plusieurs optimisations architecturales majeures.

• Le traitement asymétrique des Clés et Valeurs (K/V) : Les clés et les valeurs ne se comportent pas de la même façon dans la mémoire de l’IA. Les clés sont extrêmement sensibles à la perte de précision. TurboQuant+ choisit donc de conserver les clés à un niveau de précision plus élevé (8 bits) tout en compressant agressivement les valeurs à 3 ou 4 bits.
• La suppression du filtre QJL de Google : Les tests en conditions réelles ont révélé que la transformée QJL de Google injectait parfois plus d’erreurs qu’elle n’en corrigeait en interagissant avec la dernière couche du modèle. TurboQuant+ s’en passe totalement au profit d’une configuration d’algorithme plus propre.
• L’évitement des couches limites (Boundary-Layer Skipping) : La première et la toute dernière couche de calcul d’un LLM abritent les informations les plus cruciales. TurboQuant+ applique la règle “Boundary V” qui désactive la compression sur ces couches spécifiques. L’impact sur la mémoire globale est minime, mais la stabilité du modèle remonte en flèche.
• La dégradation temporelle du contexte (Temporal Context Decay) : Plus une information est ancienne dans une longue conversation, moins elle pèse sur la suite logique. TurboQuant+ réduit dynamiquement la précision des jetons les plus anciens (en passant par exemple de 3 bits à 2 bits) au fur et à mesure que la discussion s’allonge.
• La sensibilité des têtes d’attention (Attention-Head Awareness) : Toutes les têtes d’attention n’ont pas la même importance. Certaines gèrent la recherche de motifs à longue portée et cassent sous la compression, tandis que d’autres (“streaming heads”) sont très robustes. TurboQuant+ analyse cette sensibilité pour n’allouer la précision que là où elle est cruciale.

Résultats comparatifs et perplexité

La perplexité (PPL) mesure la confusion d’un modèle : plus elle est basse, plus l’IA génère du texte cohérent et précis. Voici les résultats observés lors de tests de stress sur des architectures denses (comme Qwen ou GLM) avec des fenêtres de contexte allant de 32K à 128K jetons :

• Configuration de référence non compressée (FP16/Q8) :
  • Perpexité moyenne : 4.74 (référence)
  • Taille du cache KV : 1.0x (aucune réduction)
  • Accord de génération sur le même jeton : 100 %
  • Test d’extraction d’information (“Needle in a Haystack”) : 100 % de réussite
• TurboQuant original de Google (Symétrique 3 bits) :
  • Perpexité moyenne : 6.19 (dégradation sensible de l’ordre de 1.4% à 3.4%)
  • Taille du cache KV : Réduite de 4.9x
  • Accord de génération sur le même jeton : ~86.4 % (sujet à des pertes de logique)
  • Test d’extraction d’information : Échoue sur les très grands contextes (>64K)
• TurboQuant+ (Profil asymétrique K4 / V3) :
  • Perpexité moyenne : 4.75 (à seulement 0.2 % de la référence !)
  • Taille du cache KV : Réduite de 4.7x
  • Accord de génération sur le même jeton : >95.5 % (fiable pour la production)
  • Test d’extraction d’information : 100 % de réussite préservé

Mise en pratique : configurer TurboQuant dans un moteur open-source

L’intégration de TurboQuant est devenue très simple car elle se gère via des drapeaux d’allocation mémoire au niveau du moteur d’inférence, sans altérer les fichiers de poids des modèles. L’écosystème vLLM intègre nativement ces mécanismes.

Étape 1 : Installation ou compilation

Pour une intégration rapide via le gestionnaire de paquets standard :

pip install turboquant-vllm[vllm]

Si vous préférez compiler l’outil directement depuis les sources pour obtenir les noyaux d’exécution Triton et CUDA optimisés :

git clone https://github.com
cd vllm

export CUDA_HOME=/usr/local/cuda-12.8
export VLLM_TARGET_DEVICE=cuda
export VLLM_USE_PRECOMPILED=0

pip install -e .

Étape 2 : Choix du profil de compression

Le moteur met à disposition différents profils selon vos priorités en matière de mémoire et de précision (l’extension nc indique l’activation de la correction de norme “Norm Correction” pour éviter les distorsions) :

• turboquant_k8v4 : Clés à 8 bits / Valeurs à 4 bits. Réduction mémoire de 2.6x. Priorité maximale à la préservation de la précision.
• turboquant_4bit_nc : Clés à 4 bits / Valeurs à 4 bits. Réduction mémoire de 3.8x. Compromis idéal pour la plupart des usages.
• turboquant_k3v4_nc : Clés à 3 bits / Valeurs à 4 bits. Réduction mémoire de 3.5x.
• turboquant_3bit_nc : Clés à 3 bits / Valeurs à 3 bits. Réduction mémoire de 4.9x. Réservé aux cas de compression extrême.

Étape 3 : Lancement du serveur d’inférence

Pour lancer votre modèle avec la configuration équilibrée en 4 bits, passez les paramètres d’attention personnalisés lors du démarrage du serveur vLLM :

vllm serve /path/to/your-llm-model \
  --attention-backend CUSTOM \
  --kv-cache-dtype turboquant_4bit_nc \
  --enable-turboquant

Utilisation alternative via Hugging Face Transformers

Si vous écrivez un script d’automatisation Python personnalisé, vous pouvez appeler la compression de manière dynamique en encapsulant l’objet de cache standard de Hugging Face :

from transformers import AutoModelForCausalLM, AutoTokenizer, DynamicCache
from turboquant_vllm import CompressedDynamicCache

# 1. Chargement classique du modèle et de son tokenizer
tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen3.5-8B")
model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen3.5-8B", device_map="cuda")

# 2. Initialisation du cache de base
base_cache = DynamicCache()

# 3. Encapsulation dans le gestionnaire de mémoire de TurboQuant
compressed_cache = CompressedDynamicCache(base_cache, head_dim=128, bits=4)

# 4. Génération de texte (la compression s'exécute de manière transparente en arrière-plan)
inputs = tokenizer("Summarize this document: ...", return_tensors="pt").to("cuda")
outputs = model.generate(**inputs, past_key_values=compressed_cache, max_new_tokens=100)

print(tokenizer.decode(outputs[0]))

Cas d’usage et intégrations logicielles

L’impact de ces travaux dépasse le cadre des LLM conversationnels. Dans les moteurs de recherche vectoriels comme Qdrant, l’intégration de ces techniques de compression permet d’obtenir un facteur de réduction de 8x sur l’indexation de bases de données géantes à des taux de rappel très proches de la quantification scalaire standard, surpassant largement la quantification binaire en matière de fidélité. Sur d’autres projets comme TurboVec, la réduction atteint parfois 16x sur de vastes catalogues d’embeddings.

Grâce aux efforts de portage, ces optimisations ont également franchi la frontière du matériel grand public. Le moteur llama.cpp propose des déclinaisons adaptées aux architectures Apple Silicon via l’implémentation turboquant-plus-mlx sur GitHub.

En exploitant des noyaux de calcul Apple Metal spécifiques et l’astuce de rotation de Walsh-Hadamard, on peut désormais faire tourner des modèles avec des fenêtres de contexte de 128K jetons entièrement confines dans la mémoire unifiée d’un simple Mac de bureau, sans déclencher de panne mémoire.