Au-delà du débat TurboQuant-RaBitQ : pourquoi la quantification vectorielle est importante pour les coûts d'infrastructure de l'IA

L'article TurboQuant de Google (ICLR 2026) fait état d'une compression 6x du cache KV avec une perte de précision proche de zéro - des résultats suffisamment frappants pour effacer 90 milliards de dollars des stocks de puces mémoire en une seule journée. SK Hynix a chuté de 12 %. Samsung a chuté de 7 %.

L'article a rapidement fait l'objet d'un examen minutieux. Jianyang Gao, premier auteur de RaBitQ (SIGMOD 2024), a soulevé des questions sur la relation entre la méthodologie de TurboQuant et ses travaux antérieurs sur la quantification vectorielle. (Nous publierons bientôt une conversation avec le Dr Gao - suivez-nous si vous êtes intéressé).

Cet article n'a pas pour but de prendre parti dans cette discussion. Ce qui nous a frappés, c'est quelque chose de plus grand : le fait qu'un seul article sur la quantification vectorielle ait pu déplacer 90 milliards de dollars de valeur marchande montre à quel point cette technologie est devenue essentielle pour l'infrastructure de l'IA. Qu'il s'agisse de la compression du cache KV dans les moteurs d'inférence ou de la compression des index dans les bases de données vectorielles, la capacité de réduire les données à haute dimension tout en préservant la qualité a d'énormes implications en termes de coûts - et c'est un problème sur lequel nous avons travaillé, en intégrant RaBitQ dans la base de données vectorielle Milvus et en la transformant en infrastructure de production.

Voici ce que nous allons couvrir : pourquoi la quantification vectorielle est si importante actuellement, comment TurboQuant et RaBitQ se comparent, ce qu'est RaBitQ et comment il fonctionne, le travail d'ingénierie derrière son intégration dans Milvus, et ce à quoi ressemble le paysage plus large de l'optimisation de la mémoire pour l'infrastructure de l'IA.

Pourquoi la quantification vectorielle est-elle importante pour les coûts d'infrastructure ?

La quantification vectorielle n'est pas une nouveauté. Ce qui est nouveau, c'est l'urgence avec laquelle l'industrie en a besoin. Au cours des deux dernières années, les paramètres LLM ont explosé, les fenêtres contextuelles sont passées de 4K à 128K+ tokens, et les données non structurées - texte, images, audio, vidéo - sont devenues une entrée de premier ordre pour les systèmes d'IA. Chacune de ces tendances crée davantage de vecteurs à haute dimension qui doivent être stockés, indexés et recherchés. Plus de vecteurs, plus de mémoire, plus de coûts.

Si vous utilisez la recherche vectorielle à grande échelle - pipelines RAG, moteurs de recommandation, récupération multimodale - le coût de la mémoire est probablement l'un de vos plus grands maux de tête en matière d'infrastructure.

Pendant le déploiement du modèle, chaque pile d'inférence LLM majeure s'appuie sur le cache KV - stockant les paires clé-valeur précédemment calculées afin que le mécanisme d'attention ne les recalcule pas pour chaque nouveau jeton. C'est ce qui rend possible l'inférence O(n) au lieu de O(n²). Tous les frameworks, de vLLM à TensorRT-LLM, en dépendent. Mais le cache KV peut consommer plus de mémoire GPU que les poids du modèle eux-mêmes. Des contextes plus longs, plus d'utilisateurs simultanés, et la spirale s'emballe rapidement.

La même pression s'exerce sur les bases de données vectorielles - des milliards de vecteurs en haute dimension stockés en mémoire, chacun d'eux étant un flottant de 32 bits par dimension. La quantification vectorielle comprime ces vecteurs de 32 bits flottants en représentations de 4 bits, 2 bits ou même 1 bit, ce qui permet de réduire la mémoire de 90 % ou plus. Qu'il s'agisse du cache KV dans votre moteur d'inférence ou des index dans votre base de données vectorielles, les mathématiques sous-jacentes sont les mêmes et les économies sont réelles. C'est pourquoi un seul article faisant état d'une percée dans ce domaine a fait fluctuer la valeur boursière de 90 milliards de dollars.

TurboQuant et RaBitQ : quelle est la différence ?

TurboQuant et RaBitQ reposent tous deux sur la même technique de base : l'application d'une rotation aléatoire(transformation de Johnson-Lindenstrauss) aux vecteurs d'entrée avant la quantification. Cette rotation transforme les données irrégulièrement distribuées en une distribution uniforme prévisible, ce qui facilite la quantification avec un faible taux d'erreur.

Au-delà de cette base commune, les deux logiciels ciblent des problèmes différents et adoptent des approches différentes :

	TurboQuant	RaBitQ
Cible	Cache KV dans l'inférence LLM (données éphémères, par demande)	Index vectoriels persistants dans les bases de données (données stockées)
Approche	Deux étapes : PolarQuant (quantificateur scalaire Lloyd-Max par coordonnée) + QJL (correction résiduelle à 1 bit)	En une étape : projection hypercube + estimateur de distance sans biais
Largeur des bits	clés de 3 bits, valeurs de 2 bits (précision mixte)	1 bit par dimension (avec des variantes multi-bits disponibles)
Valeur théorique	Taux de distorsion MSE quasi-optimal	Erreur d'estimation du produit intérieur asymptotiquement optimale (correspondant aux limites inférieures d'Alon-Klartag)
État de la production	Implémentations communautaires ; pas de publication officielle de Google	Livré dans Milvus 2.6, adopté par Faiss, VSAG, Elasticsearch

La principale différence pour les praticiens : TurboQuant optimise le cache KV transitoire à l'intérieur d'un moteur d'inférence, tandis que RaBitQ cible les index persistants qu'une base de données vectorielle construit, partage et interroge à travers des milliards de vecteurs. Pour le reste de cet article, nous nous concentrerons sur RaBitQ - l'algorithme que nous avons intégré et expédié en production dans Milvus.

Qu'est-ce que RaBitQ et que fournit-il ?

Voici d'abord les résultats : sur un ensemble de données de 10 millions de vecteurs à 768 dimensions, RaBitQ compresse chaque vecteur à 1/32 de sa taille d'origine tout en conservant un rappel supérieur à 94 %. Dans Milvus, cela se traduit par un débit de requête 3,6 fois supérieur à celui d'un index de pleine précision. Il ne s'agit pas d'une projection théorique, mais d'un résultat de référence obtenu avec Milvus 2.6.

Maintenant, comment on y arrive.

La quantification binaire traditionnelle compresse les vecteurs FP32 à 1 bit par dimension, soit une compression de 32x. La contrepartie : le rappel s'effondre parce que l'on a jeté trop d'informations. RaBitQ (Gao & Long, SIGMOD 2024) conserve la même compression 32x mais préserve les informations qui comptent réellement pour la recherche. Une version étendue (Gao & Long, SIGMOD 2025) prouve que cette compression est asymptotiquement optimale, correspondant aux limites inférieures théoriques établies par Alon & Klartag (FOCS 2017).

Pourquoi les angles sont-ils plus importants que les coordonnées en haute dimension ?

L'idée clé : en haute dimension, les angles entre les vecteurs sont plus stables et plus informatifs que les valeurs individuelles des coordonnées. Il s'agit d'une conséquence de la concentration des mesures - le même phénomène qui permet aux projections aléatoires de Johnson-Lindenstrauss de fonctionner.

En pratique, cela signifie qu'il est possible d'écarter les valeurs exactes des coordonnées d'un vecteur à haute dimension et de ne conserver que sa direction par rapport à l'ensemble des données. Les relations angulaires - dont dépend en fait la recherche du plus proche voisin - survivent à la compression.

Comment fonctionne RaBitQ ?

RaBitQ transforme cette vision géométrique en trois étapes :

Etape 1 : Normaliser. Centrer chaque vecteur par rapport au centroïde de l'ensemble de données et le mettre à l'échelle à une longueur unitaire. Cela convertit le problème en une estimation du produit intérieur entre les vecteurs unitaires - plus facile à analyser et à délimiter.

Étape 2 : Rotation aléatoire + projection hypercube. Appliquer une matrice orthogonale aléatoire (une rotation de type Johnson-Lindenstrauss) pour éliminer le biais vers un axe quelconque. Projetez chaque vecteur tourné sur le sommet le plus proche d'un hypercube {±1/√D}^D. Chaque dimension se réduit à un seul bit. Résultat : un code binaire de D bits par vecteur.

Étape 3 : Estimation impartiale de la distance. Construire un estimateur pour le produit intérieur entre une requête et le vecteur original (non quantifié). Il est prouvé que l'estimateur est sans biais avec une erreur limitée à O(1/√D). Pour des vecteurs à 768 dimensions, le rappel reste supérieur à 94 %.

Le calcul de la distance entre les vecteurs binaires se réduit à l'opération bitwise AND + popcount - des opérations que les CPU modernes exécutent en un seul cycle. C'est ce qui rend RaBitQ rapide, et pas seulement petit.

Pourquoi RaBitQ est-il pratique, et pas seulement théorique ?

• Aucune formation n'est nécessaire. Appliquez la rotation, vérifiez les signes. Pas d'optimisation itérative, pas d'apprentissage de codebook. Le temps d'indexation est comparable à la quantification du produit.
• Adapté au matériel. Le calcul de la distance est une opération de type bitwise AND + popcount. Les processeurs modernes (Intel IceLake+, AMD Zen 4+) disposent d'instructions AVX512VPOPCNTDQ dédiées. L'estimation à vecteur unique est trois fois plus rapide que les tables de recherche PQ.
• Flexibilité multi-bits. La bibliothèque RaBitQ prend en charge les variantes au-delà de 1 bit : 4 bits atteignent ~90% de rappel, 5 bits ~95%, 7 bits ~99% - le tout sans reranking.
• Composable. Se branche sur les structures d'index existantes telles que les index IVF et les graphes HNSW, et fonctionne avec FastScan pour le calcul de distance par lots.

Du papier à la production : Ce que nous avons construit pour expédier RaBitQ dans Milvus

Le code original de RaBitQ est un prototype de recherche sur une seule machine. Pour le faire fonctionner sur un cluster distribué avec partage, basculement et ingestion en temps réel, il a fallu résoudre quatre problèmes d'ingénierie. Chez Zilliz, nous sommes allés au-delà de la simple mise en œuvre de l'algorithme - le travail a porté sur l'intégration du moteur, l'accélération matérielle, l'optimisation de l'index et le réglage du temps d'exécution pour transformer RaBitQ en une capacité de niveau industriel au sein de Milvus. Vous trouverez plus de détails dans ce blog : Amener la compression vectorielle à l'extrême : Comment Milvus sert 3× plus de requêtes avec RaBitQ

Rendre RaBitQ prêt pour la distribution

Nous avons intégré RaBitQ directement dans Knowhere, le moteur de recherche principal de Milvus - pas comme un plugin, mais comme un type d'index natif avec des interfaces unifiées. Il fonctionne avec l'architecture distribuée complète de Milvus : sharding, partitionnement, mise à l'échelle dynamique et gestion des collections.

Le principal défi consiste à rendre le livre de codes de quantification (matrice de rotation, vecteurs centroïdes, paramètres de mise à l'échelle) conscient des segments, de sorte que chaque groupe construise et stocke son propre état de quantification. Les constructions d'index, les compacteurs et l'équilibrage de charge comprennent tous le nouveau type d'index de manière native.

Extraire chaque cycle de Popcount

La vitesse de RaBitQ provient de popcount - le comptage des bits dans les vecteurs binaires. L'algorithme est intrinsèquement rapide, mais le débit que vous obtenez dépend de la façon dont vous utilisez le matériel. Nous avons construit des chemins de code SIMD dédiés pour les deux architectures de serveur dominantes :

• x86 (Intel IceLake+ / AMD Zen 4+) : L'instruction VPOPCNTDQ de l'AVX-512 calcule le popcount sur plusieurs registres de 512 bits en parallèle. Les boucles internes de Knowhere sont restructurées pour regrouper les calculs de distance binaire en morceaux de largeur SIMD, afin de maximiser le débit.
• ARM (Graviton, Ampère) : Instructions SVE (Scalable Vector Extension) pour le même modèle de comptage parallèle de popcount - essentiel puisque les instances ARM sont de plus en plus courantes dans les déploiements de cloud optimisés en termes de coûts.

Élimination des frais généraux d'exécution

RaBitQ a besoin de paramètres auxiliaires en virgule flottante au moment de la requête : le centroïde de l'ensemble de données, les normes par vecteur et le produit intérieur entre chaque vecteur quantifié et son original (utilisé par l'estimateur de distance). Le calcul de ces paramètres par requête augmente le temps de latence. Le stockage des vecteurs originaux complets va à l'encontre de l'objectif de la compression.

Notre solution : pré-calculer et conserver ces paramètres pendant la construction de l'index, en les mettant en cache avec les codes binaires. La surcharge de mémoire est faible (quelques flottants par vecteur), mais elle élimine le calcul par requête et maintient la latence stable en cas de forte concurrence.

IVF_RABITQ : l'index que vous déployez réellement

À partir de Milvus 2.6, nous livrons IVF_RABITQ - Inverted File Index + RaBitQ quantization ( index de fichiers inversé + quantification RaBitQ). La recherche s'effectue en deux étapes :

1. Recherche grossière (IVF). Les K-moyennes divisent l'espace vectoriel en grappes. Au moment de la requête, seuls les nprobes clusters les plus proches sont analysés.
2. Recherche fine (RaBitQ). Au sein de chaque grappe, les distances sont estimées à l'aide de codes à 1 bit et de l'estimateur sans biais. Popcount se charge des tâches les plus lourdes.

Les résultats sur un ensemble de données de 768 dimensions et de 10 millions de vecteurs :

Métrique	IVF_FLAT (base)	IVF_RABITQ	IVF_RABITQ + SQ8 refine
Rappel	95.2%	94.7%	~95%
QPS	236	864	-
Empreinte mémoire	32 bits/dim	1 bit/dim (~3% de l'original)	~25% de l'original

Pour les charges de travail qui ne peuvent tolérer même un écart de rappel de 0,5 %, le paramètre refine_type ajoute une deuxième passe de notation : SQ6, SQ8, FP16, BF16 ou FP32. SQ8 est le choix le plus courant - il rétablit le rappel aux niveaux IVF_FLAT à environ 1/4 de la mémoire d'origine. Vous pouvez également appliquer la quantification scalaire au côté requête (SQ1-SQ8) indépendamment, ce qui vous donne deux boutons pour régler le compromis latence-rappel-coût par charge de travail.

Comment Milvus optimise la mémoire au-delà de la quantification

RaBitQ est le levier de compression le plus spectaculaire, mais il s'agit d'une couche dans une pile d'optimisation de la mémoire plus large :

Stratégie	Ce qu'il fait	Impact
Quantification de la pile complète	SQ8, PQ, RaBitQ à différents compromis précision/coût	Réduction de la mémoire de 4x à 32x
Optimisation de la structure de l'index	Compaction des graphes HNSW, déchargement SSD DiskANN, constructions d'index OOM-safe	Moins de DRAM par index, plus grands ensembles de données par nœud
E/S en mémoire (mmap)	Mappage des fichiers vectoriels sur le disque, chargement des pages à la demande via le cache de pages du système d'exploitation	Ensembles de données à l'échelle du téraoctet sans tout charger dans la RAM
Stockage hiérarchisé	Séparation des données chaudes/chaudes/froides avec planification automatique	Ne payer le prix de la mémoire que pour les données fréquemment consultées
Mise à l'échelle native dans le nuage(Zilliz Cloud, Milvus géré)	Allocation élastique de la mémoire, libération automatique des ressources inutilisées	Ne payez que ce que vous utilisez

Quantification complète

La compression extrême à 1 bit de RaBitQ n'est pas adaptée à toutes les charges de travail. Milvus propose une matrice de quantification complète : SQ8 et quantification par produit (PQ) pour les charges de travail qui nécessitent un compromis précision-coût équilibré, RaBitQ pour une compression maximale sur des ensembles de données ultra-larges et des configurations hybrides qui combinent plusieurs méthodes pour un contrôle précis.

Optimisation de la structure de l'index

Au-delà de la quantification, Milvus optimise en permanence la charge de mémoire dans ses structures d'index principales. Pour HNSW, nous avons réduit la redondance des listes d'adjacence afin de diminuer l'utilisation de la mémoire par graphe. DiskANN pousse les données vectorielles et les structures d'index vers le SSD, ce qui réduit considérablement la dépendance à la DRAM pour les grands ensembles de données. Nous avons également optimisé l'allocation de la mémoire intermédiaire pendant la construction de l'index afin d'éviter les défaillances OOM lors de la construction d'index sur des ensembles de données qui approchent les limites de la mémoire des nœuds.

Chargement intelligent de la mémoire

La prise en charge mmap (E/S mappées en mémoire) de Milvus mappe les données vectorielles sur des fichiers disque, en s'appuyant sur le cache de pages du système d'exploitation pour le chargement à la demande - il n'est pas nécessaire de charger toutes les données dans la mémoire au démarrage. Associé à des stratégies de chargement paresseux et segmenté qui évitent les pics de mémoire soudains, cela permet un fonctionnement fluide avec des ensembles de données vectorielles à l'échelle du To, pour une fraction du coût de la mémoire.

Stockage hiérarchisé

L'architecture de stockage à trois niveaux de Milvus couvre la mémoire, le disque SSD et le stockage d'objets : les données chaudes restent en mémoire pour une faible latence, les données tièdes sont mises en cache sur le disque SSD pour un équilibre entre les performances et le coût, et les données froides descendent vers le stockage d'objets pour minimiser les frais généraux. Le système gère automatiquement l'ordonnancement des données, sans qu'il soit nécessaire de modifier la couche applicative.

Évolution native dans le nuage

Dans le cadre de l'architecture distribuée de Milvus, le partage des données et l'équilibrage de la charge empêchent la surcharge de la mémoire d'un seul nœud. La mise en commun de la mémoire réduit la fragmentation et améliore l'utilisation. Zilliz Cloud (entièrement géré par Milvus) va encore plus loin avec une planification élastique pour une mise à l'échelle de la mémoire à la demande - en mode Serverless, les ressources inutilisées sont automatiquement libérées, ce qui réduit encore le coût total de possession.

Comment ces couches se complètent

Ces optimisations ne sont pas des alternatives - elles s'empilent. RaBitQ réduit les vecteurs. DiskANN conserve l'index sur le disque SSD. Mmap évite de charger des données froides en mémoire. Le stockage hiérarchisé pousse les données d'archivage vers le stockage objet. Résultat : un déploiement servant des milliards de vecteurs n'a pas besoin de milliards de vecteurs de RAM.

Démarrer

Alors que les volumes de données d'IA continuent d'augmenter, l'efficacité et le coût des bases de données vectorielles détermineront directement l'étendue de l'évolutivité des applications d'IA. Nous continuerons à investir dans une infrastructure vectorielle performante et peu coûteuse, afin que davantage d'applications d'IA puissent passer du stade du prototype à celui de la production.

Milvus est un logiciel libre. Pour essayer IVF_RABITQ :

• Consultez la documentation IVF_RABITQ pour obtenir des conseils de configuration et de réglage.
• Lisez l'article de blog sur l'intégration complète de RaBitQ pour obtenir des références plus approfondies et des détails sur la mise en œuvre.
• Rejoignez la communauté Milvus Slack pour poser des questions et apprendre des autres développeurs.
• Réservez une session gratuite Milvus Office Hours pour étudier votre cas d'utilisation.

Si vous préférez sauter l'étape de l'installation de l'infrastructure, Zilliz Cloud (Milvus entièrement géré) propose un niveau gratuit avec le support IVF_RABITQ.

Nous organiserons prochainement une interview avec le professeur Cheng Long (NTU, VectorDB@NTU) et le Dr. Jianyang Gao (ETH Zurich), premier auteur de RaBitQ, dans laquelle nous approfondirons la théorie de la quantification vectorielle et les prochaines étapes. Posez vos questions dans les commentaires.

Questions fréquemment posées

Que sont TurboQuant et RaBitQ ?

TurboQuant (Google, ICLR 2026) et RaBitQ (Gao & Long, SIGMOD 2024) sont deux méthodes de quantification vectorielle qui utilisent la rotation aléatoire pour compresser des vecteurs de haute dimension. TurboQuant vise la compression du cache KV dans l'inférence LLM, tandis que RaBitQ vise les index vectoriels persistants dans les bases de données. Ces deux méthodes ont contribué à la vague actuelle d'intérêt pour la quantification vectorielle, bien qu'elles résolvent des problèmes différents pour des systèmes différents.

Comment RaBitQ parvient-il à une quantification sur 1 bit sans détruire le rappel ?

RaBitQ exploite la concentration des mesures dans les espaces à haute dimension : les angles entre les vecteurs sont plus stables que les valeurs des coordonnées individuelles à mesure que la dimensionnalité augmente. Il normalise les vecteurs par rapport au centroïde de l'ensemble de données, puis projette chacun d'eux sur le sommet le plus proche d'un hypercube (réduisant chaque dimension à un seul bit). Un estimateur de distance sans biais avec une limite d'erreur prouvable maintient la précision de la recherche malgré la compression.

Qu'est-ce que IVF_RABITQ et quand dois-je l'utiliser ?

IVF_RABITQ est un type d'index vectoriel dans Milvus (disponible depuis la version 2.6) qui combine le regroupement de fichiers inversé avec la quantification à 1 bit de RaBitQ. Il atteint 94,7% de rappel à 3,6 fois le débit de IVF_FLAT, avec une utilisation de la mémoire d'environ 1/32 des vecteurs originaux. Utilisez-le lorsque vous devez effectuer des recherches vectorielles à grande échelle (des millions ou des milliards de vecteurs) et que le coût de la mémoire est une préoccupation majeure - ce qui est courant dans les charges de travail de RAG, de recommandation et de recherche multimodale.

Quel est le rapport entre la quantification vectorielle et la compression du cache KV dans les LLM ?

Les deux problèmes impliquent la compression de vecteurs à virgule flottante de haute dimension. Le cache KV stocke les paires clé-valeur du mécanisme d'attention Transformer ; à des longueurs de contexte importantes, il peut dépasser les poids du modèle en termes d'utilisation de la mémoire. Les techniques de quantification vectorielle telles que RaBitQ réduisent ces vecteurs à des représentations de bits inférieurs. Les mêmes principes mathématiques - concentration des mesures, rotation aléatoire, estimation impartiale de la distance - s'appliquent que vous compressiez des vecteurs dans un index de base de données ou dans le cache KV d'un moteur d'inférence.