Pourquoi le RAG a-t-il besoin d'autant de RAM ?

Une recherche vectorielle rapide veut l'index résident en mémoire. Chaque chunk de document devient un embedding — un vecteur de quelques centaines à quelques milliers de flottants — et à des millions de chunks, cela s'additionne. Poussez l'index sur disque et la latence de recherche bondit ; garder toute la raison pour laquelle vous avez auto-hébergé (vitesse + contrôle) signifie le garder en RAM.

Combien de RAM pour un corpus donné ?

Ordre de grandeur : quelques centaines de milliers d'embeddings tiennent bien dans 2–4 Go. Quelques millions, avec l'application et l'OS autour, et vous êtes à 16–32 Go. Des dizaines de millions ou des vecteurs de haute dimension et vous êtes à 48–80 Go, et au-delà vous répartissez sur plusieurs serveurs. La dimension et le type d'index font beaucoup varier cela, alors mesurez le vôtre.

pgvector ou un moteur dédié comme Qdrant ?

Si vous faites déjà tourner Postgres, pgvector est la voie la moins coûteuse — une extension, une base de données. Pour des millions de vecteurs avec un filtrage lourd, un moteur dédié mérite son propre service. Commencez avec ce que vous exploitez déjà ; ne migrez que quand la recherche ralentit.

Pourquoi auto-héberger plutôt qu'un service vectoriel managé ?

Deux vraies raisons : vos embeddings encodent souvent des données privées (docs, notes, contenu client), et l'auto-hébergement garde cela sur un serveur que vous contrôlez. Et c'est un coût fixe — les services managés facturent aux vecteurs et aux requêtes, un VPS est un seul chiffre mensuel sans facture à la requête.

RAG auto-hébergé à grande échelle : combien de RAM un index vectoriel consomme vraiment

Chaque tutoriel RAG tourne sur un portable avec quelques centaines de documents, et cela semble sans effort. Puis vous le pointez sur un corpus réel — la documentation d'une entreprise, des années de tickets, une base de connaissances — et soudain la mémoire est toute la conversation.

Le RAG n'évolue pas par le CPU. Il évolue par la RAM.

Pourquoi l'index veut de la mémoire

La récupération fonctionne en transformant chaque chunk de texte en embedding — un vecteur, de quelques centaines à quelques milliers de nombres de long. Chercher signifie comparer votre vecteur de requête à tous, vite. « Vite » est le mot clé : pour une faible latence, l'index doit vivre en RAM. Sur disque ça fonctionne, mais chaque requête paie une pénalité, et la récupération à faible latence était l'objectif de l'auto-hébergement au départ.

Donc la facture de mémoire évolue avec deux choses : combien de chunks vous avez, et la largeur de chaque vecteur.

De vrais chiffres, approximativement

Mesurez le vôtre — la dimension et le type d'index font beaucoup bouger cela — mais comme point de départ :

Quelques centaines de milliers d'embeddings — confortable dans 2–4 Go. Une base de connaissances personnelle, la documentation d'un seul produit.
Quelques millions — avec l'application, le client de modèle et l'OS autour, prévoyez 16–32 Go. C'est une base de connaissances d'entreprise sérieuse ou un RAG multi-sources.
Des dizaines de millions, ou des vecteurs de haute dimension — maintenant vous êtes à 48–80 Go, et au-delà sur plusieurs machines. Grands parcs documentaires, récupération multi-tenant, ou vous gardez plusieurs index chauds à la fois.

Un système multi-agents qui détient aussi un gros index empile les deux coûts sur la même machine — c'est ainsi qu'une offre 32 Go devient discrètement une 64 Go.

Le choix du moteur, brièvement

Si vous faites déjà tourner Postgres, pgvector est l'option la moins coûteuse — c'est une extension, pas un nouveau service à surveiller. Quand vous avez des millions de vecteurs et voulez une recherche filtrée rapide, un moteur dédié comme Qdrant ou Weaviate mérite son processus séparé. Ne sur-concevez pas dès le premier jour ; faites tourner ce que vous exploitez déjà et séparez-le quand la recherche ralentit réellement.

Pourquoi se donner la peine d'auto-héberger

Deux raisons pour lesquelles les gens le font vraiment, et aucune n'est « pour économiser quelques dollars » :

La confidentialité. Les embeddings ne sont pas abstraits — ils encodent le texte dont ils proviennent. Vos docs, le contenu de vos clients, vos notes internes, transformés en vecteurs et expédiés vers les serveurs d'un tiers. L'auto-hébergement garde cela sur une machine que vous contrôlez. Si les données sont assez sensibles pour que vous payiez aussi en crypto sans KYC, un cloud vectoriel managé annule tout l'intérêt.

Un coût fixe. Les services vectoriels managés facturent aux vecteurs stockés et aux requêtes exécutées. Un VPS est un seul chiffre mensuel et vous pouvez le marteler autant que vous voulez. À grande échelle, prévisible bat facturé à l'usage.

Ce que cela signifie pour le dimensionnement

Commencez par mesurer votre corpus, pas par deviner. Obtenez votre nombre d'embeddings et votre dimension, chargez un échantillon, surveillez la mémoire résidente, extrapolez. Puis choisissez une offre avec de la marge pour l'index plus tout ce qui l'entoure — l'application, le client de modèle, de la place pour grandir.

Pour tout ce qui dépasse quelques millions de vecteurs gardés en privé, la gamme Pro fait tourner de 32 à 80 Go avec une IP dédiée et des sauvegardes nocturnes, ce qui compte quand l'index est le produit et que le perdre fait mal.