Combien de RAM faut-il pour un index RAG familial multilingue ?
Un index RAG familial multilingue tient souvent dans 16 à 32 Go de RAM, mais le nombre de segments et la conception de l’index comptent davantage que le seul nombre de langues.
Une archive domestique contenant 500 000 segments peut utiliser un seul embedding multilingue par segment plutôt qu’une copie par langue. La mémoire augmente néanmoins avec les dimensions des vecteurs, les liens du graphe, les métadonnées, les caches, les rerankers et le modèle de génération. L’objectif utile est donc un espace de travail maximal mesuré avec une marge, et non une règle en « gigaoctets par langue » en pleine charge.
Commencez par les vecteurs, puis ajoutez la structure de recherche
La mémoire brute des vecteurs correspond au nombre de segments multiplié par le nombre de dimensions et le nombre d’octets par valeur. En float32, 500 000 vecteurs de 768 dimensions contiennent environ 1,54 Go de coordonnées. Le float16 réduit de moitié cette charge de coordonnées, mais la prise en charge par la base de données et l’impact sur la précision doivent être vérifiés.
Une présentation de l’indexation par graphe HNSW explique pourquoi HNSW conserve un graphe de connexions entre voisins pour accélérer la recherche approximative. Ces connexions, les identifiants, l’alignement et la surcharge de l’allocateur s’ajoutent au calcul des vecteurs bruts.
Les filtres de métadonnées, les identifiants de documents, les caches de texte et les structures dupliquées lors de la construction peuvent dépasser les prévisions. Une base de données utilisant le disque peut tout de même conserver en mémoire les pages fréquemment consultées du graphe, tandis qu’un moteur en mémoire peut conserver presque la totalité de l’index. Les vecteurs bruts constituent un seuil minimal, pas le besoin final en RAM.
La couverture multilingue modifie davantage le nombre de segments que les calculs
Un modèle d’embedding multilingue associe plusieurs langues dans un même espace vectoriel : l’ajout d’une langue ne duplique donc pas automatiquement chaque vecteur. La RAM augmente lorsque les copies traduites sont segmentées séparément, que des index propres à chaque langue sont conservés ou que la tokenisation produit davantage de segments pour les mêmes documents.
Les recherches sur les embeddings multilingues évaluent des représentations partagées entre de nombreuses langues, ce qui favorise les conceptions avec un seul index lorsque le modèle choisi aligne correctement ces langues. La qualité de couverture peut varier selon la langue même lorsque la mémoire ne varie pas.
Le générateur et le reranker se partagent également la mémoire du système. Un serveur de 16 Go peut contenir un index modéré, mais commencer à utiliser intensivement le fichier d’échange lorsqu’un LLM, un processus d’OCR et le cache de la base de données fonctionnent simultanément. Une quantité de RAM supérieure ne corrige pas une faible qualité de recherche multilingue ; elle empêche seulement la pression mémoire de fausser le test.
Quand la fourchette de 16 à 32 Go cesse de s’appliquer
Seize gigaoctets sont plausibles pour plusieurs centaines de milliers de vecteurs compacts, avec le texte stocké sur disque et un petit modèle local. Trente-deux gigaoctets constituent un point de départ plus sûr pour environ un million de vecteurs de 768 dimensions, avec les services associés. Des dimensions supérieures, plusieurs réplicas, des index distincts par langue ou un LLM résident plus volumineux peuvent justifier 64 Go ou davantage.
Une présentation de la mémoire des index HNSW montre que les octets des vecteurs bruts peuvent ne représenter qu’une fraction de la mémoire totale de HNSW une fois les structures du graphe incluses. Les choix d’implémentation rendent tout ratio universel peu fiable.
Ces fourchettes deviennent inadaptées lorsque la base de données utilise la compression, le mappage mémoire, la quantification par produit ou un graphe configuré très différemment. Elles deviennent également inadaptées lors de la construction de l’index si le générateur conserve brièvement les anciennes et les nouvelles copies. Mesurez séparément les pics de recherche stabilisée et de reconstruction.
Dimensionnez la RAM à partir d’un espace de travail mesuré
Calculez d’abord les vecteurs bruts, puis ingérez 10 % du corpus prévu avec les dimensions finales, les métadonnées et les paramètres d’index définitifs. Mesurez la mémoire résidente après une recherche à chaud, des requêtes simultanées et une reconstruction. Ne multipliez que les composants qui évoluent linéairement, puis réservez au moins 25 % de marge de fonctionnement.
Exécutez le prototype à côté de la charge de travail prévue pour la base de données vectorielle domestique, car les pics du modèle et de la base de données peuvent se chevaucher. Consignez également l’activité du fichier d’échange et le taux de défauts de page.
Choisissez 16 Go uniquement lorsque le pic extrapolé reste inférieur à environ 12 Go ; choisissez 32 Go lorsqu’il reste inférieur à environ 24 Go. Passez à une capacité supérieure lorsque les reconstructions ou l’inférence simultanée franchissent cette limite. Recalculez après toute modification du découpage ou des dimensions des embeddings.
Produits recommandés
Centre Tech & IA
Plus à lire
Comment mesurer la qualité de la récupération RAG locale et interpréter le rappel, la précision et la couverture des citations
Créez un jeu de test RAG local, calculez les principales métriques de récupération, interprétez leurs compromis et vérifiez si les affirmations des réponses sont...
Pourquoi le calcul des fonctionnalités de la maison intelligente devient-il plus important lorsque le nombre de capteurs augmente à fréquence d’échantillonnage constante ?
Suivez les calculs par capteur et intercapteurs à mesure que le nombre d’appareils augmente, identifiez les coûts de fusion non linéaires et évaluez les...
Pourquoi le coût de l’évaluation du RAG devient-il plus important à mesure que la bibliothèque de documents s’agrandit, pour un même volume de requêtes ?
Comprenez pourquoi l’augmentation du corpus accroît l’effort d’évaluation du RAG sans augmenter le nombre de requêtes des utilisateurs, et comment les tests stratifiés maintiennent...
