Pourquoi votre IA coûte une fortune en RAM (et comment l'éviter)

LA RECHERCHE VECTORIELLE, C'EST LE MOTEUR CACHÉ DE L'IA

Ces dernières années, la recherche vectorielle est devenue un pilier de l'infrastructure IA. Elle alimente des outils comme les systèmes de questions-réponses (RAG), la recherche sémantique, ou encore la mémoire des agents IA. Le problème ? Les entreprises veulent fournir toujours plus de contexte à leurs agents, ce qui fait exploser la taille des index : de quelques millions de vecteurs, on passe à des centaines de millions, voire des milliards. À cette échelle, stocker ces index en RAM coûte des milliers d'euros par mois, et l'algorithme HNSW peut devenir un goulot d'étranglement.

COMMENT FONCTIONNE VRAIMENT LA RECHERCHE VECTORIELLE

Une base de données vectorielle repose sur trois éléments principaux : les embeddings (déjà bien expliqués ailleurs), et surtout les algorithmes de recherche. Il existe deux grandes approches pour exécuter une recherche :

La recherche exacte parcourt chaque vecteur de l'index et calcule la distance avec votre requête. C'est simple, précis, mais lent et peu scalable. Parfait pour des petits index ou des tests, mais inadapté à une utilisation en production. Fun fact : beaucoup de bases vectorielles modernes contournent la construction d'un index pour de petites collections, car le temps gagné en évitant cette étape dépasse largement le gain de performance.

L'autre option, bien plus répandue, ce sont les algorithmes de recherche approchée de plus proches voisins (ANN). Leur but ? Accélérer la recherche en évitant de parcourir tous les vecteurs. Au lieu de ça, ils créent des raccourcis pour atteindre rapidement le résultat. La plupart des algorithmes ANN modernes, comme HNSW ou DiskANN, utilisent une structure de graphe pour garantir des latences très faibles.

Attention : même si tous les algorithmes ANN visent le même objectif, leurs implémentations diffèrent. Chacun a ses propres compromis, ce qui rend crucial le choix de celui qui correspond à votre cas d'usage.

DEUX FAMILLES D'ALGORITHMES ANN À CONNAÎTRE

Dans cet article, nous allons nous concentrer sur deux groupes d'algorithmes ANN. Sachez qu'il est possible de stocker leurs structures de données soit sur disque, soit en RAM (au moins en partie), mais chaque option est optimisée pour un type de stockage spécifique. Voici pourquoi.

HNSW : LE ROI DE LA RECHERCHE EN RAM

HNSW (Hierarchical Navigable Small World) est l'algorithme le plus utilisé dans les bases vectorielles modernes. Son principe ? Utiliser une structure de graphe en couches pour connecter les vecteurs entre eux. Résultat : des temps de récupération ultra-rapides, surtout quand l'index entier tient en RAM. C'est idéal pour des cas d'usage de taille petite à moyenne.

Mais dès que l'index devient trop gros pour la RAM ou que son stockage devient trop cher, deux options s'offrent à vous :

• Déplacer les données sur disque, ce qui peut causer un effondrement des performances.
• Quantifier fortement les données, ce qui réduit la qualité des résultats.

Pourquoi un tel ralentissement ? Parce que la structure de HNSW n'est pas optimisée pour les accès disques non séquentiels. Chaque recherche nécessite plusieurs sauts entre les nœuds du graphe, ce qui génère énormément d'opérations d'entrée/sortie (I/O). Avec un trafic de lecture élevé, le disque devient le goulot d'étranglement, faisant passer la latence de quelques millisecondes à plusieurs centaines, voire plus sous une forte charge.

Les algorithmes optimisés pour la RAM sont extrêmement rapides, mais ils consomment énormément de mémoire. Et quand on les utilise avec des données stockées sur disque, ils reposent sur des accès aléatoires au disque, ce qui peut devenir un nouveau goulot d'étranglement pour des index dépassant les 100 millions de vecteurs.

Exemples de bases vectorielles utilisant HNSW : Qdrant, Milvus, pgvector, OpenSearch, Weaviate, Redis.

SPANN ET DISKANN : LES ALTERNATIVES ÉCONOMIQUES POUR LES GROS INDEX

Ces algorithmes sont conçus pour briser la limite de consommation RAM des algorithmes ANN en mémoire. Leur objectif ? Réduire les coûts de stockage tout en gardant une latence acceptable. Parfait si la latence n'est pas critique et que votre index doit être énorme.

SPANN : L'INVERSÉ QUI FAIT ÉCONOMISER DES MILLIERS

SPANN (Scalable Projection-based Approximate Nearest Neighbor Search) est un algorithme basé sur un index inversé (IVF). Les vecteurs sont regroupés en clusters, chacun représenté par un centroïde. L'idée ? Organiser les points en groupes, une propriété naturelle de l'espace des embeddings, puis sélectionner une représentation de centroïde pour la couche de routage.

Les centroïdes et la couche de routage peuvent être stockés en RAM, tandis que les vecteurs associés aux centroïdes sont stockés sur disque. Mieux encore : les vecteurs d'un même centroïde sont stockés séquentiellement sur disque, ce qui permet de les charger rapidement et efficacement. Pendant la recherche, les centroïdes servent à trouver les groupes de vecteurs les plus proches, puis seuls les vecteurs associés à ces centroïdes sont chargés depuis le disque pour un balayage complet.

Note : Contrairement à HNSW avec stockage sur disque, SPANN garantit que les vecteurs d'un même centroïde sont regroupés sur disque et chargés par blocs. Résultat ? Le nombre d'opérations d'entrée/sortie sur disque est drastiquement réduit, tout en gardant une latence acceptable.

Exemples de bases vectorielles utilisant SPANN : Turbopuffer (construit sur SPFresh, un successeur de SPANN), Chroma DB (cloud).

DISKANN : LE GRAPHE QUI MINIMISE LES SAUTS

DiskANN utilise une approche différente : un graphe à une seule couche appelé Vamana. Son principe ? Minimiser le nombre de sauts nécessaires pour trouver les k points les plus proches, et donc réduire le nombre d'opérations d'entrée/sortie aléatoires sur disque. Pour cela, il conserve des connexions à plus longue portée en plus des plus proches voisins, ce qui réduit le nombre de sauts nécessaires.

Les vecteurs originaux sont stockés sur disque, tandis qu'une version fortement quantifiée est stockée en RAM. Cette quantification supplémentaire contribue aussi à réduire le nombre d'opérations d'entrée/sortie nécessaires. Contrairement à SPANN, le graphe de DiskANN est construit sur chaque point, donc il évolue avec le jeu de données. À l'échelle du milliard de vecteurs, c'est un vrai défi mémoire : SPANN n'a besoin que de ses centroïdes en RAM, tandis que DiskANN doit stocker tout son graphe.

Les données sur disque ne sont pas regroupées, mais le routage est optimisé pour minimiser les accès disque en réduisant le nombre de sauts vers les vecteurs similaires. Résultat ? Une recherche ultra-efficace en pratique. Note : les détails internes de l'implémentation sont complexes, mais l'article original est disponible dans les références pour ceux qui veulent creuser.

COMPARAISON DES COÛTS : RAM VS DISQUE

Les prix varient selon les fournisseurs, régions et engagements, mais voici une estimation illustrative des coûts RAM vs disque pour un index de 100 millions de vecteurs en 1024 dimensions avec une précision float32.

Calculons : un vecteur en 1024 dimensions avec float32 occupe 4 Ko. Avec une réplication de production de 3, cela fait 12 Ko par vecteur. Pour 100 millions de vecteurs, cela représente 1,2 To de stockage. En utilisant une quantification scalaire (la plus courante), on réduit l'espace de stockage de 75%, soit 300 Go.

Coûts mensuels approximatifs :

• Stockage en RAM (non quantifié) : ~6 000$ par mois.
• Stockage en RAM (quantifié) : ~1 500$ par mois.
• Stockage sur disque (EBS) : ~96$ par mois.
• Stockage sur disque (SSD local) : ~240$ par mois.

Et comme tout est linéaire, l'écart ne fait que s'agrandir à mesure que l'index grossit, comme le font les systèmes agentiques actuels.

LES COÛTS ÉCONOMISÉS SONT-ILS GRATUITS ?

Non, bien sûr. Les algorithmes ANN optimisés pour le disque réduisent la facture, mais au prix d'une latence plus élevée. Même si la couche de routage permet de récupérer les données de manière efficace et de limiter l'exploration à un sous-ensemble plus petit, les données doivent toujours être chargées depuis le disque, ce qui est bien plus lent que depuis la RAM.

Pour beaucoup d'usages, ce ralentissement n'est pas un problème. Par exemple, dans un système RAG, les résultats de la base vectorielle sont ensuite transmis à un reranker et à un modèle de langage. Un délai de 100 ms sur la récupération ne sera pas le goulot d'étranglement principal. En revanche, pour des cas comme la mémoire des agents ou le contexte en temps réel, chaque milliseconde compte. Si plusieurs recherches sont nécessaires pour traiter une seule requête d'agent, la latence peut devenir critique.

Difficile de donner un chiffre précis pour la latence sur disque : tout dépend de la configuration. Par exemple, l'article sur SPANN rapporte un rappel de 90% en environ 1 ms à l'échelle du milliard de vecteurs, mais sur une seule machine avec l'index stocké sur SSD local. En conditions réelles, la situation change radicalement. Le benchmark de Turbopuffer sur un index de 10 millions de vecteurs montre une latence médiane de 14 ms quand l'index est chaud sur un stockage rapide, mais jusqu'à 874 ms quand il est froid et doit être récupéré depuis un stockage objet. C'est une différence de 60 fois sur les mêmes données, juste à cause de l'état du cache .

D'autres facteurs comme le matériel ou la température du cache peuvent faire varier la latence de 10 fois ou plus. En règle générale, les algorithmes ANN basés sur disque offrent une latence plus élevée que HNSW en RAM, simplement parce que l'accès à la RAM est bien plus rapide.

QUEL ALGORITHME CHOISIR ?

Le choix entre mémoire et disque dépend de votre cas d'usage. HNSW est une solution simple et polyvalente pour les index de taille petite à moyenne. Mais dès que votre index devient trop gros ou que le coût de la RAM devient prohibitif, il vaut mieux explorer les options basées sur disque.

Attention aux cas particuliers : des vecteurs de haute dimensionnalité peuvent saturer la RAM plus rapidement, tandis que des index de faible dimensionnalité mais de très grande taille peuvent tirer parti de la RAM plus longtemps. Pour les ingénieurs, il est crucial de prendre en compte ces cas limites et de faire un choix éclairé en fonction des compromis adaptés à leur situation.

LES LIMITES DE LA RECHERCHE EXACTE

La recherche exacte, qui parcourt tous les vecteurs de l'index, est simple et précise. Mais elle est aussi lente et peu scalable. Elle est parfaite pour les petits index ou les tests, mais dès que la taille de l'index dépasse quelques milliers de vecteurs, le temps de construction de l'index devient un frein. C'est pourquoi beaucoup de bases vectorielles modernes contournent cette étape et utilisent directement une recherche de plus proches voisins (kNN) pour les petites collections.

POURQUOI LES ALGORITHMES ANN SONT-ILS PLUS RAPIDES ?

Les algorithmes de recherche approchée de plus proches voisins (ANN) accélèrent la recherche en évitant de parcourir tous les vecteurs. Au lieu de cela, ils créent des raccourcis pour atteindre rapidement le résultat. La plupart des algorithmes ANN modernes, comme HNSW ou DiskANN, utilisent une structure de graphe pour garantir des latences très faibles. Cette structure permet de sauter directement vers les vecteurs les plus proches, sans avoir à vérifier chaque point un par un.

HNSW : UNE STRUCTURE EN COUCHES POUR DES RECHERCHES ULTRA-RAPIDES

HNSW utilise une structure de graphe hiérarchique pour connecter les vecteurs. Imaginez un réseau de métro où chaque station représente un vecteur, et les lignes relient les stations proches. Plus vous êtes haut dans la hiérarchie, plus les connexions sont larges et rapides. Résultat : une recherche peut être effectuée en quelques sauts seulement, même pour des index énormes.

Mais cette efficacité a un prix : la structure de HNSW n'est pas optimisée pour les accès disques non séquentiels. Chaque saut dans le graphe peut nécessiter un accès aléatoire au disque, ce qui ralentit considérablement la recherche. C'est pourquoi HNSW est surtout performant quand tout l'index tient en RAM.

SPANN : L'INDEX INVERSÉ QUI GROUPE LES VECTEURS

SPANN organise les vecteurs en clusters, chacun représenté par un centroïde. C'est comme un annuaire où chaque page regroupe des entrées similaires. Pendant la recherche, on identifie d'abord les centroïdes les plus proches, puis on charge uniquement les vecteurs associés à ces centroïdes depuis le disque. Résultat : moins d'accès disque et une recherche plus rapide.

Contrairement à HNSW, SPANN est conçu pour les gros index qui ne tiennent pas en RAM. Il minimise les opérations d'entrée/sortie en regroupant les vecteurs similaires sur disque, ce qui permet de les charger par blocs efficaces.

DISKANN : UN GRAPHE QUI MINIMISE LES SAUTS

DiskANN utilise un graphe appelé Vamana pour minimiser le nombre de sauts nécessaires à la recherche. Imaginez un réseau social où chaque personne est connectée à ses amis proches, mais aussi à quelques connaissances éloignées. Cela permet de trouver une personne en moins de sauts. DiskANN applique ce principe aux vecteurs : en gardant des connexions à plus longue portée, il réduit le nombre de sauts nécessaires pour trouver les vecteurs les plus proches.

Les vecteurs originaux sont stockés sur disque, mais une version quantifiée est stockée en RAM pour accélérer le routage. Résultat : une recherche ultra-efficace, même pour des index dépassant le milliard de vecteurs.

LA QUANTIFICATION : UNE SOLUTION PARTIELLE

La quantification réduit la taille des vecteurs en les compressant. Par exemple, une quantification scalaire peut réduire l'espace de stockage de 75%. Mais attention : cette compression peut aussi réduire la qualité des résultats. C'est un compromis à prendre en compte.

Pour un index de 100 millions de vecteurs en 1024 dimensions avec float32, la quantification scalaire réduit le stockage de 1,2 To à 300 Go. Mais même à ce prix, le stockage sur disque reste bien moins cher que sur RAM.

LE CASSE-TÊTE DES LATENCES SUR DISQUE

La latence sur disque dépend de nombreux facteurs : matériel, température du cache, type de stockage. Par exemple, un index chaud sur SSD local peut avoir une latence médiane de 14 ms, tandis que le même index froid sur stockage objet peut atteindre 874 ms. C'est une différence de 60 fois .

En règle générale, les algorithmes ANN basés sur disque sont plus lents que ceux en RAM, car l'accès à la RAM est bien plus rapide que l'accès au disque. Mais cette latence supplémentaire peut être acceptable pour beaucoup d'usages, comme le RAG, où la récupération des vecteurs n'est qu'une étape parmi d'autres.

QUEL STOCKAGE CHOISIR ? RAM OU DISQUE ?

Le choix dépend de vos priorités. Si la latence est critique et que votre budget est illimité, la RAM est la meilleure option. Mais si vous voulez réduire les coûts tout en gardant une latence acceptable, les algorithmes basés sur disque comme SPANN ou DiskANN sont des alternatives intéressantes.

Pensez aussi à la réplication : stocker trois copies de votre index en RAM peut rapidement faire exploser la facture. Les solutions basées sur disque permettent de réduire ces coûts tout en gardant une bonne performance.

LES FACTEURS QUI INFLUENCENT LA PERFORMANCE

Plusieurs éléments peuvent faire varier la performance des algorithmes ANN :

• Le matériel : un SSD rapide réduira la latence par rapport à un disque dur classique.
• La température du cache : un index chaud (déjà en cache) sera bien plus rapide qu'un index froid.
• La dimensionnalité des vecteurs : des vecteurs de haute dimensionnalité satureront plus vite la RAM.
• La taille de l'index : plus l'index est gros, plus les algorithmes basés sur disque deviennent intéressants.

COMMENT ÉVITER DE SE RUINER EN RAM

Si votre index dépasse les 100 millions de vecteurs, il est temps d'envisager des solutions basées sur disque. SPANN et DiskANN sont conçus pour gérer des index énormes sans exploser votre budget. Ils réduisent les coûts de stockage tout en gardant une latence acceptable pour la plupart des usages.

N'oubliez pas de tester les différents algorithmes avec votre jeu de données réel. Les performances peuvent varier énormément selon la configuration matérielle et les spécificités de votre index.

LE FUTUR DE LA RECHERCHE VECTORIELLE

Avec l'essor des systèmes agentiques, les index vectoriels vont continuer à grossir. Les algorithmes comme HNSW, SPANN et DiskANN évolueront pour offrir de meilleurs compromis entre coût, latence et qualité. Les solutions hybrides, combinant RAM et disque, pourraient aussi se généraliser pour tirer parti des avantages des deux approches.

En attendant, le choix de l'algorithme dépend de vos priorités : performance pure ou coût maîtrisé ?

EN RÉSUMÉ : QUEL ALGORITHME POUR QUEL CAS ?

Voici un guide rapide pour choisir le bon algorithme :

• HNSW : idéal pour les petits à moyens index, quand la RAM n'est pas un problème.
• SPANN : parfait pour les gros index, quand la latence n'est pas critique.
• DiskANN : le meilleur choix pour les index dépassant le milliard de vecteurs, avec un bon compromis latence/coût.
• Recherche exacte : uniquement pour les petits index ou les tests.