Google a publié TurboQuant le 24 mars. En 48 heures, le papier avait 575 points sur Hacker News, les actions de Micron chutaient de 900 millions de dollars, et TechCrunch le comparait à l’algorithme de Pied Piper de Silicon Valley.
Un mois plus tard, le brouillard du battage médiatique s’est suffisamment dissipé pour répondre aux seules questions qui comptent : est-ce que ça marche ? Puis-je l’utiliser aujourd’hui ? Et celle que personne ne veut poser : est-ce vraiment nouveau ?
Ce que TurboQuant promet (résumé de 30 secondes)
Si vous avez déjà lu mon article précédent sur les mathématiques, sautez cette section.
TurboQuant compresse le cache KV des LLM — la mémoire de travail qui croît avec chaque token généré — en appliquant deux transformations :
- Rotation aléatoire du vecteur (redistribue les valeurs uniformément)
- Conversion en coordenées polaires (les angles restent dans des plages prévisibles → quantification sans surcharge)
Le résultat selon Google : compression 6x du cache KV, accélération 8x dans les logits d’attention sur H100, sans dégradation dans les benchmarks. Sans réentraînement. Sans calibration. Data-oblivious.
Cela semble trop beau. Voyons ce que dit la réalité.
L’écosystème réel : quelles implémentations existent
En un mois, au moins dix implémentations indépendantes ont émergé. Je les classe par maturité :
Tier 1 : Fonctionnelles avec benchmarks reproductibles
| Projet | Langage | Plateforme | Compression réelle | État |
|---|---|---|---|---|
| turboquant-mlx | Python/Metal | Apple Silicon | 4.7x (3-bit V3) | Benchmarks publiés, M4 Max |
| turboquant-pytorch | Python | CUDA | 5x (K4/V2) | From-scratch, tests vs papier |
| turboquant (0xSero) | Python | CUDA | 3-bit K, 2-bit V | Kernels Triton + vLLM |
Tier 2 : Fonctionnelles mais sans benchmarks indépendants
| Projet | Langage | Plateforme | Notes |
|---|---|---|---|
| SwiftLM | Swift | Apple Silicon | Serveur d’inférence natif, cache KV TurboQuant intégré |
| TurboVec (py-turboquant) | Rust + Python | CPU | Orienté vers la recherche vectorielle, pas de cache KV |
| turboquant_mlx | Python/Metal | Apple Silicon | 1-3 bit, asymétrique |
Tier 3 : PR dans de gros projets
- llama.cpp : Discussion #20969 — implémentation CPU avec tests, MSE dans les 1% du papier
- vLLM : PR en révision pour intégration native
La donnée qui compte : l’implémentation en MLX de sharpner obtient 4.7x de compression réelle sur M4 Max avec 3-bit Lloyd-Max. Pas 6x comme dit Google, mais bien une réduction substantielle. Dans un contexte de 16K tokens, le cache KV passe de 4.2 GB à 897 MB.
La découverte que personne n’attendait : QJL ne sert à rien
C’est ici que ça devient intéressant.
TurboQuant a deux phases : PolarQuant (rotation + polaires + quantification) et QJL (correction d’erreur avec Johnson-Lindenstrauss à 1 bit). Google présente les deux comme essentielles.
Mais plusieurs implémenteurs indépendants sont arrivés à la même conclusion : QJL dégrade les performances en pratique.
L’équipe de turboquant-pytorch l’a mesuré avec rigueur. Leur découverte : MSE-only (sans QJL) surpasse constamment MSE+QJL en token matching — la métrique qui compte vraiment pour la génération de texte. La différence est énorme à bas bits et encore visible à 8 bits.
En clair : la seconde moitié de TurboQuant, celle que Google présente comme correction d’erreurs, introduit plus d’erreurs qu’elle n’en corrige. 80% de la valeur réside dans PolarQuant seul.
Ce type de découverte — des composants qui fonctionnent dans le papier mais pas en production — c’est exactement ce qui sépare la recherche de l’ingénierie. Et c’est ce qui rend précieuses les implémentations indépendantes.
La controverse RaBitQ : l’éléphant dans la pièce
C’est le point que la couverture de TechCrunch et les threads Twitter ne mentionnent pas.
Le 31 mars, l’équipe de RaBitQ — une méthode de quantification vectorielle publiée en mai 2024 — a accusé formellement les auteurs de TurboQuant de trois choses :
1. Omission délibérée de similitude méthodologique. TurboQuant et RaBitQ appliquent tous deux des rotations aléatoires (transformées Johnson-Lindenstrauss) avant de quantifier. C’est l’astuce centrale des deux. Mais le papier de Google décrit RaBitQ comme “grid-based PQ” et omettre qu’il utilise la rotation. Le second auteur de TurboQuant connaissait parfaitement RaBitQ — il lui a demandé de l’aide pour le déboguer en janvier 2025.
2. Déformation des résultats théoriques. TurboQuant affirme que les garanties de RaBitQ sont “sous-optimales, probablement par analyse peu ajustée”. Mais RaBitQ a une preuve rigoureuse (Théorème 3.2) qu’il atteint les limites optimales asymptotiques établies par Alon et Klartag (FOCS 2017). Les auteurs de RaBitQ ont envoyé les corrections détaillées par email en mai 2025. Le second auteur de TurboQuant a confirmé les avoir partagées avec tous les co-auteurs. Le papier final n’a rien corrigé.
3. Setup expérimental biaisé. TurboQuant a comparé RaBitQ en utilisant une traduction dégradée en Python, single-core, avec le multithreading désactivé. TurboQuant tournait sur A100 GPU. RaBitQ a une implémentation C++ multithreadée publique. La comparaison de vitesse est, diplomatiquement parlant, peu représentative.
L’équipe RaBitQ a présenté une plainte formelle auprès du comité d’éthique d’ICLR et publié un commentaire sur OpenReview. Stanford NLP a amplifié la dénonciation.
Est-ce que cela invalide TurboQuant ? Non. PolarQuant fonctionne — les benchmarks des implémentations indépendantes le confirment. Mais le papier a un problème d’intégrité académique que Google Research n’a pas abordé publiquement. Et pour une entreprise qui veut être référente en recherche ouverte, le silence est significatif.
L’essayer aujourd’hui : trois chemins selon votre matériel
Chemin 1 : Apple Silicon avec MLX (recommandé pour Mac)
git clone https://github.com/sharpner/turboquant-mlx
cd turboquant-mlx
pip install -r requirements.txt
# Benchmark avec Llama 3.2 3B (4-bit weights)
python bench.py --model mlx-community/Llama-3.2-3B-Instruct-4bit \
--kv-bits 3 --method v3 --seq-len 8192
Résultats attendus sur M4 Pro (48 GB) :
- Compression cache KV : ~4.6x
- Throughput : ~98% de la baseline sans compression
- Perplexity : pratiquement identique à FP16
Chemin 2 : CUDA avec PyTorch
git clone https://github.com/tonbistudio/turboquant-pytorch
cd turboquant-pytorch
pip install -r requirements.txt
# Test de génération avec Qwen2.5-3B
python tests/generation_test.py --bits 4 --model Qwen/Qwen2.5-3B-Instruct
Découverte clé de l’équipe : K4/V2 (4 bits pour les clés, 2 pour les valeurs) donne ~5x de compression avec une qualité acceptable. L’asymétrique fonctionne mieux que le symétrique parce que les clés déterminent les motifs d’attention.
Chemin 3 : Serveur d’inférence natif en Swift
Si vous voulez un serveur compatible OpenAI qui fait tourner TurboQuant sur Apple Silicon sans Python :
git clone https://github.com/SharpAI/SwiftLM
cd SwiftLM
swift build -c release
# Servir Gemma 4 26B avec cache KV compressé
.build/release/SwiftLM serve --model mlx-community/gemma-4-26b-it-4bit \
--turbo-kv
SwiftLM rapporte 85 tok/s avec Gemma-4-26B-4bit sur M5 Pro. Le cache KV TurboQuant permet des contextes de 100K tokens qui sans compression ne tiendraient pas en mémoire.
Ce que vous NE pouvez PAS faire (encore)
Appliquer TurboQuant au modèle on-device d’Apple. Le framework FoundationModels d’iOS 26 / macOS 26 gère le cache KV en interne via LanguageModelSession. Il n’y a pas d’API pour l’intercepter, le compresser ni l’étendre. Le modèle d’Apple a 4K tokens de contexte et TurboQuant ne peut pas le changer — du moins pas avec les API publiques.
L’utiliser en production avec vLLM. Le PR existe, mais n’a pas été mergé. L’intégration des kernels Triton de 0xSero fonctionne mais n’a pas le niveau de testing qu’exige un framework de production.
Faire confiance aux benchmarks du papier pour la recherche vectorielle. Étant donné que la comparaison avec RaBitQ utilise un setup biaisé, les chiffres de recherche vectorielle du papier ne sont pas fiables. PolarQuant fonctionne ; les benchmarks comparatifs du papier, pas vraiment.
Le motif plus large : coordination vs compression
TurboQuant est un cas d’étude de quelque chose qui arrive de plus en plus en ML : la technique fonctionne, mais le récit autour est plus grand que la technique.
Ce qui marche vraiment, c’est PolarQuant : rotation aléatoire + coordenées polaires. C’est élégant, c’est pratique, et ça compresse le cache KV 4-5x sur du matériel réel. Pas 6x comme dit Google, pas 8x comme l’ont titré les journaux, mais suffisamment pour étendre les contextes d’un facteur 4 dans la même mémoire.
Ce qui ne marche pas si bien : QJL (la correction d’erreurs) et le récit d’originalité totale (RaBitQ faisait déjà des rotations aléatoires en 2024).
Et ce qui est inacceptable : un papier de Google dans ICLR qui déforme le travail précédent, utilise des benchmarks biaisés, et garde ensuite le silence quand on lui signale les erreurs. Ce n’est pas une erreur technique, c’est un problème institutionnel.
La prochaine fois qu’un papier d’un grand laboratoire promet 6x de compression sans coût, faites ce qu’ont fait les implémenteurs indépendants : prenez le code, mesurez vous-même, et préparez-vous à découvrir que la réalité se situe quelque part entre ce qui est promis et ce qui est utile. Ce qui est généralement, de toute façon, un endroit plutôt correct.
Sources :
- TurboQuant: Redefining AI Efficiency with Extreme Compression — Google Research Blog
- TurboQuant and RaBitQ: What the Public Story Gets Wrong — Jianyang Gao (auteur de RaBitQ)
- TurboQuant paper (ICLR 2026) — OpenReview
- Hacker News discussion (575 points, 166 commentaires)
Cet article a été rédigé en espagnol et traduit avec l’aide de l’IA.