Cessez de payer pour stocker des embeddings : guide du CTO sur la quantification asymétrique

Vous payez pour stocker de l’air. Un embedding float32 de 1,536 dimensions fait ~6 Ko. À 50 millions d’éléments, cela représente 300 Go de vecteurs bruts — avant la surcharge d’index et les réplicas. La plupart des équipes ajoutent ensuite un graphe HNSW en RAM pour la vitesse, faisant exploser la mémoire vers plusieurs centaines de gigaoctets. Les factures cloud mensuelles suivent. Pendant ce temps, des résultats récents sur la quantification asymétrique montrent que vous pouvez réduire cette empreinte de 90 à 97 % avec une qualité de récupération quasi sans perte. Traduction : moins de machines et moins chères ; des cold starts plus rapides ; et la possibilité de tourner sur des CPU standards, voire à l’edge.

Ce n’est pas une curiosité de recherche. C’est prêt pour la production en 2026 grâce à des bibliothèques matures comme FAISS et ScaNN, et c’est pris en charge par les systèmes vectoriels populaires. Si vous exploitez un système RAG, de la recherche de similarité, des recommandations ou de la déduplication à grande échelle, la quantification asymétrique (AQ) doit figurer immédiatement sur votre feuille de route.

Ce qu’est réellement la quantification asymétrique (et pourquoi elle fonctionne)

La quantification compresse des vecteurs float de grande dimension en codes compacts. Avec la quantification asymétrique, vous conservez la requête en float mais stockez les vecteurs de la base en codes compressés, puis vous calculez les distances via le calcul de distance asymétrique (ADC). Comme vous ne quantifiez pas la requête, vous évitez la plus grande chute de précision tout en capturant presque tous les gains de stockage et de bande passante.

Les piliers sont :

• Product Quantization (PQ) : on découpe un vecteur de dimension D en m sous‑vecteurs ; on apprend un petit codebook par sous‑espace (par ex., 256 centroïdes = 8 bits). Un vecteur devient m octets de codes. Configurations typiques : D=1,536, m=96, 8 bits → 96 octets par vecteur.
• Optimized PQ (OPQ) : on apprend une rotation de l’espace pour répartir le signal plus uniformément entre sous‑espaces, améliorant le rappel à taille de code constante.
• IVF‑PQ : un index en deux étapes : un quantificateur grossier (IVF) restreint la recherche à quelques clusters ; au sein de chacun, le PQ compresse les résidus. Cela donne des latences amies du CPU à très grande échelle.

Des résultats publics récents montrent jusqu’à ~97 % de réduction de stockage avec une perte de rappel minimale sur des tâches de recherche standard. En pratique, nous observons régulièrement 90–95 % de réduction à 0,95–0,99 de recall@10 par rapport au baseline float, si vous :

• Entraînez l’OPQ avec suffisamment de données (≥1–5 M d’échantillons représentatifs).
• Ajustez le nombre de listes IVF et de probes selon votre budget de latence.
• Utilisez un reranking (par ex., produit scalaire ou un cross‑encoder) sur les top‑K candidats.

Pourquoi cela compte pour votre TCO

Prenons une configuration banale pour illustrer le calcul :

• Embedding : 1,536‑d float32 (≈6 Ko/vecteur).
• Corpus : 50 M d’éléments → 300 Go de vecteurs bruts.
• Surcharge d’index HNSW : souvent 1–2× la taille des vecteurs, selon les réglages M/ef. Supposons 1,5× → 450 Go en RAM.
• HA/facteur de réplication 2–3× sur les nœuds → 900–1,350 Go d’empreinte effective.

Résultat : vous louez toute l’année plusieurs instances avec 256–512 Go de RAM (CPU ou GPU) pour rester sous 100 ms en charge. Selon la région et la génération, cela représente aisément 6 k$–12 k$/mois rien qu’en compute, souvent plus que la facture de stockage de la base vectorielle.

Inversez maintenant le design :

• PQ avec m=96, 8 bits → ~96 octets/vecteur (plus un petit métadonné IVF). Cela fait ~4,8 Go pour 50 M de vecteurs (codes bruts), typiquement 10–20× plus petit que le baseline float une fois la surcharge d’index incluse.
• Utilisez IVF‑PQ sur CPU. Conservez les codes sur NVMe ; mettez en cache les listes chaudes et les LUT en mémoire. Avec un tuning raisonnable, attendez‑vous à une latence p95 sous 20–40 ms sur des CPU modernes à 95 % de recall@10 pour des corpus de 50 M–200 M.
• L’empreinte de calcul tombe à une ou deux instances de 64–128 Go par réplique, souvent 1,5 k$–3 k$/mois par nœud. Les cold starts sont plus rapides ; les reconstructions n’exigent pas des volumes éphémères de classe pétaoctet.

Toutes les charges n’auront pas exactement cette courbe, mais la direction est constante : le PQ vous fait passer de conceptions limitées par la mémoire à des conceptions équilibrées entre cache et stockage, moins chères, plus élastiques, et plus faciles à exécuter sur plusieurs régions (ou on‑prem) sans pénurie de GPU.

Quand il faut (et ne faut pas) utiliser la quantification asymétrique

Adoptez l’AQ si vous cochez la plupart de ces cases :

• Corpus ≥ 10 M d’éléments, ou recherche multi‑tenant avec de nombreux locataires actifs.
• SLO de latence ≥ 20 ms p95 pour l’étape vectorielle (vous pouvez gratter davantage avec du cache et des probes plus étroites).
• Modèle d’embedding stable pendant au moins 3–6 mois. Des changements fréquents de modèle augmentent le coût de maintenance des codebooks.
• Produit scalaire (dot‑product) ou L2 comme distance. Si vous avez un métrique spécialisée, vérifiez la prise en charge par la bibliothèque.
• Étape de reranking disponible pour récupérer la qualité long‑tail (par ex., top‑200 candidats → cross‑encoder@K=50).

Réfléchissez à deux fois si :

• Vous opérez de petits corpus (≤1 M) qui tiennent déjà en RAM avec HNSW pour un coût négligeable.
• Votre SLO est ultra‑bas (p. ex., 5 ms p95) et vous pouvez vous offrir des GPU/des index RAM finement optimisés.
• Vos embeddings changent chaque semaine et vous ne pouvez pas financer des reconstructions d’index en double.

L’architecture : IVF‑PQ avec ADC, plus reranking

Pour la plupart des CTOs, un choix par défaut sûr en 2026 ressemble à ceci :

1. Partition grossière (IVF) : entraînez un k‑means avec k dans la plage 16k–262k selon la taille du corpus. Règle empirique : commencez vers k ≈ sqrt(N) et affinez en fonction des probes/latence.
2. Codage des résidus avec OPQ+PQ : apprenez une rotation OPQ ; entraînez le PQ sur les résidus avec m choisi de sorte que m octets/vecteur respecte votre objectif de stockage. Couramment m=64–128 avec des codes 8 bits.
3. Calcul de distance asymétrique : conservez la requête en float ; pour chaque liste sondée, construisez une table de correspondance (LUT) des distances entre la requête et chaque codebook des sous‑quantificateurs. Les distances ADC se réduisent à des additions sur les LUT, ce qui est cache‑friendly sur CPU.
4. Ensemble de candidats + rerank : renvoyez 500–2 000 candidats issus de l’ADC ; rerankez avec les floats originaux si vous stockez un petit cache de floats pour les éléments chauds, ou utilisez un cross‑encoder pour la précision@K.

Ce pattern est implémenté dans FAISS (IndexIVFPQ, IndexIVF{HNSW,PQ}) et le flux de partitionnement + hachage asymétrique de ScaNN. De nombreuses bases vectorielles l’exposent en interne. Vous n’avez pas besoin de réécrire votre stack.

Un plan de déploiement concret sur 60–90 jours

Jours 0–15 : référence et cible

• Fixez votre référentiel : verrouillez un benchmark représentatif : 10–20 vraies requêtes par sujet de tête, 10k–100k paires annotées, évaluez en recall@10 et nDCG@10.
• Enregistrez les coûts actuels : empreinte RAM de HNSW (ou de votre ANN courant), types d’instances, QPS, latences p95/p99, et $/QPS mensuels.
• Définissez un budget de risque : par ex., ≥0,97 de recall@10 du baseline et ≤10 ms de p95 supplémentaires pour l’étape vectorielle. Mettez‑le par écrit.

Jours 15–45 : entraînement, construction, tuning

• Échantillonnez les données d’entraînement : 1–5 M de vecteurs couvrant tenants/locales ; gardez un set de validation.
• Entraînez OPQ et IVF : commencez avec OPQ m=96 (8 bits). Pour l’IVF, démarrez à k ≈ sqrt(N) ; testez nprobe 10–200.
• Construisez l’IVFPQ : stockez les codes sur NVMe ; pré‑calculez des statistiques par liste ; activez mmap lorsque disponible.
• Mesurez les compromis : balayez m ∈ {64, 96, 128}, bits de code ∈ {6, 8}, nprobe ∈ {8, 16, 32, 64, 128}. Tracez rappel vs p95 vs %CPU.
• Stratégie de reranking : essayez deux étapes : IVFPQ@1k → cross‑encoder@50 (ou produit scalaire float si vous pouvez mettre en cache les floats pour les éléments de tête). Validez le gain sur les requêtes long‑tail.

Jours 45–75 : exécution en shadow et sécurité

• Double exécution : servez les utilisateurs via la voie baseline ; en parallèle, exécutez en shadow le chemin PQ pour 5–10 % du trafic aléatoire. Journalisez des résultats intercalés pour estimer le rappel en ligne et les deltas de CTR.
• Moniteurs de dérive : alertez sur un déplacement de la distribution de similarité cosinus entre la requête et le top‑K ; c’est un indicateur précoce de vieillissement des codebooks.
• Plan de reconstruction à chaud : entraînez des codebooks en parallèle chaque semaine ; basculez le trafic via un feature flag. Conservez les deux derniers codebooks actifs pour rollback.

Jours 75–90 : bascule et capture des économies

• Bascule progressive : 10 % → 50 % → 100 % des tenants. Conservez l’ANN baseline en repli pendant une fenêtre définie.
• Dimensionnez correctement les instances : passez de 512 Go de RAM à 64–128 Go ; scalez horizontalement pour le QPS, pas à cause de la pression mémoire.
• Capitalisez les économies : suivez la réduction $/QPS. D’expérience, un PQ bien réglé peut réduire le compute de la recherche vectorielle de 2–5× et le stockage de 10–30× sans impact utilisateur mesurable.

Modes de défaillance fréquents (et comment les éviter)

• Entraîner sur la mauvaise distribution : vos codebooks apprennent ce que vous leur donnez. Si vous excluez certaines langues, tenants ou modalités, attendez‑vous à des chutes de rappel en production. Correctif : échantillonnage stratifié et ré‑entraînement périodique.
• IVF sous‑dimensionné : trop peu de listes ou de probes brident le rappel. Correctif : augmentez k ou nprobe ; mettez en cache les LUT et les listes chaudes ; vérifiez l’affinité NUMA.
• Ignorer le rerank à forte compression : sous ~64–96 octets/vecteur, attendez‑vous à plus d’approximation. Correctif : rerankez toujours un petit ensemble de candidats.
• Churn de modèle sans double indexation : changer de modèle d’embedding invalide les codebooks. Correctif : maintenez deux index complets ; reconstruisez en arrière‑plan ; basculez via des flags.
• Décalage MIPS vs L2 : si vous utilisez le produit scalaire, assurez‑vous que votre index et votre bibliothèque optimisent pour MIPS (maximum inner product search). Certains stacks convertissent MIPS→L2 avec des astuces (p. ex., augmentation de norme). Vérifiez.

Choix d’outillage pérennes

• FAISS : éprouvée, GPU et CPU, support profond de PQ/IVF, hybrides HNSW. À utiliser pour un maximum de contrôle et de portabilité.
• ScaNN : très performant sur CPU avec partitionnement + hachage asymétrique ; bons réglages par défaut.
• Bases vectorielles : Milvus, Qdrant, Weaviate et des services commerciaux exposent IVF‑PQ/HNSW‑PQ. Attention aux plafonds cachés de configuration (par ex., tailles maxi de codebooks) et aux rappels opaques.
• Rerankers : pour des requêtes multilingues ou très métier, un petit cross‑encoder (par ex., classe MiniLM) à K=50–200 récupère souvent les 1–2 derniers points de précision pour quelques millisecondes.

Un modèle de coût simple à expliquer à la finance

Cadrez clairement le business case :

• Baseline : 3× r5b.16xlarge (512 Go) pour HNSW + 2× m6i.8xlarge pour l’API + réplication de stockage → 8 k$–14 k$/mois tout compris, plus les frais de base vectorielle managée.
• Avec PQ : 2× m7i.4xlarge (64 Go) pour IVFPQ + 2× m6i.8xlarge pour l’API → 3 k$–6 k$/mois, stockage 10–30× plus petit. Même trafic, mêmes métriques utilisateur.
• Payback : 30–60 jours en incluant le temps d’ingénierie ponctuel, en supposant une réduction compute de 2–5× et un ré‑aménagement infra modeste.

Même si vos SKUs et prix exacts diffèrent, la finance comprendra le passage de réplicas contraints par la mémoire à des nœuds équilibrés par le stockage avec les mêmes SLO (ou meilleurs).

Quid des GPU ?

Les GPU excellent quand il faut une latence ultra‑basse à très haut QPS ou si vous êtes déjà sur GPU en amont. Mais avec IVFPQ+ADC, des CPU modernes tiennent moins de 40 ms p95 pour des dizaines à centaines de millions de vecteurs. Si vous conservez des GPU, vous pouvez quand même quantifier pour faire tenir de plus grands corpus en mémoire device ou réduire la bande passante PCIe.

Edge et on‑device : le dividende d’optionalité

La compression est un choix d’architecture, pas seulement un hack de coût. Avec 96 octets/vecteur, un index de 5 M d’éléments représente ≈480 Mo de codes. Soudain :

• La multi‑région devient raisonnable sans drames de transferts inter‑régions.
• Les déploiements privés on‑prem chez des comptes régulés tiennent sur 1–2 serveurs commoditisés.
• La recherche on‑device ou dans le navigateur pour de petits corpus (≤500 k) devient viable avec WASM ou des bibliothèques NN mobiles, ouvrant de nouvelles surfaces produit respectueuses de la vie privée.

Angle nearshore Brazil : qui va réellement faire le tuning fastidieux ?

Rien de tout cela n’est de la science des fusées, mais c’est du travail de systèmes : échantillonnage, entraînement, construction d’index, instrumentation d’observabilité, et itérations jusqu’à ce que la frontière rappel/latence soit au bon endroit. C’est aussi le genre d’ingénierie qui est dépriorisée… jusqu’à l’arrivée de la facture. Des équipes nearshore aguerries à FAISS/ScaNN peuvent vous livrer un déploiement PQ opérationnel en 6–10 semaines, puis revenir chaque trimestre pour réentraîner les codebooks et redimensionner les clusters à mesure que votre corpus croît. Vous captez les économies sans bâtir une équipe « infra vectorielle » permanente.

Conformité et confidentialité : plus petit peut être plus sûr

Des codes compressés fuient moins de signal brut que des floats. Ce n’est pas une panacée de conformité, mais cela réduit la surface de risque d’exfiltration vectorielle. Vous devriez tout de même :

• Chiffrer au repos et en transit ; gérer des clés par tenant.
• Nettoyer les PII avant l’embedding lorsque c’est possible.
• Construire des pipelines de suppression qui se propagent aux caches float et aux magasins PQ.

Note sur le buzz vs la réalité

Hacker News s’enthousiasme pour « 97 % de réduction de stockage avec une récupération quasi sans perte ». C’est atteignable — mais seulement si vous le traitez comme une fonctionnalité de production, pas comme un tour de force de benchmark. La différence se fait dans votre échantillonnage, vos moniteurs de dérive et un reranker qui couvre le dernier kilomètre. Faites cela, et vous vous demanderez pourquoi vous avez un jour payé pour garder 600 Go de floats au chaud en RAM.

Points clés

• La quantification asymétrique (IVF‑PQ + ADC) peut réduire le stockage des vecteurs de 90–97 % avec 0,95–0,99 de recall@10 par rapport aux baselines float.
• Attendez‑vous à 2–5× d’économies compute et à un passage de clusters contraints par la RAM vers des nœuds adossés au NVMe, favorables au CPU.
• Adoptez avec un plan sur 60–90 jours : baseline, entraînement OPQ/PQ, exécution en shadow, et bascule avec reranking.
• Surveillez la dérive de distribution, les IVF sous‑dimensionnés et le churn de modèle ; corrigez avec échantillonnage stratifié, tuning des probes et reconstructions à double index.
• La compression ouvre des options edge/on‑prem et peut réduire le risque de fuite de données par rapport aux floats bruts.