Pourquoi plusieurs collections RAG se disputent-elles la RAM d’un serveur domestique ?

Plusieurs collections RAG se disputent la RAM, car chacune conserve ses propres vecteurs, son graphe de recherche, ses index de métadonnées, ses caches et son ensemble de travail actif.

Un serveur domestique peut séparer les documents familiaux, les manuels techniques, les métadonnées des photos, les notes professionnelles et l’historique de la maison connectée en différentes collections RAG, pour des raisons de confidentialité ou pour obtenir des résultats plus précis. Les fichiers sources peuvent tenir aisément sur le disque, tandis que la couche de recherche consomme beaucoup plus de mémoire que prévu. Chaque collection peut charger un index de recherche approximative des plus proches voisins, des filtres de données, les métadonnées des segments, les pages récemment consultées et des tampons de requêtes ; les services de vectorisation et de reclassement ajoutent leurs propres modèles résidents à côté de ces collections.

Chaque collection crée une structure de recherche distincte

Une collection de vecteurs n’est pas simplement un dossier d’embeddings. Les moteurs de recherche conservent généralement les valeurs des vecteurs ainsi qu’un graphe de voisinage, ou une autre structure de recherche approximative, qui évite d’analyser chaque enregistrement.

Weaviate présente les vecteurs et les graphes HNSW comme deux grands consommateurs de mémoire dans un index de recherche approximative des plus proches voisins en mémoire.

Créer cinq collections peut donc signifier disposer de cinq index adressables indépendamment, même s’ils partagent le même modèle d’embeddings et s’exécutent dans un seul processus de base de données. La séparation n’améliore la gestion et la maintenance que lorsque ses avantages en matière de recherche justifient la multiplication des ensembles de travail.

Les dimensions et la surcharge des index multiplient la base

La mémoire brute des vecteurs augmente avec le nombre de vecteurs, le nombre de dimensions des embeddings et le nombre d’octets par composant. L’index interrogeable ajoute des liens de graphe, des identifiants, l’alignement, les métadonnées et la surcharge de l’allocateur à ce tableau brut.

Milvus fournit une formule de calcul de la mémoire des index de vecteurs et précise qu’un déploiement HNSW peut nécessiter beaucoup plus de mémoire que les seuls vecteurs non indexés.

Estimez chaque collection séparément, puis additionnez les résultats. Une collection contenant moins de documents peut néanmoins être coûteuse si elle utilise des embeddings à haute dimension, des composants en pleine précision ou un graphe réglé pour privilégier un rappel élevé.

La connectivité du graphe échange de la RAM contre du rappel et de la vitesse

HNSW relie chaque vecteur à des nœuds voisins. Un plus grand nombre de connexions peut améliorer la navigation et le rappel, mais chaque arête stockée consomme de la mémoire et rend la construction de l’index plus coûteuse.

Redis explique comment la connectivité du graphe est contrôlée par des paramètres qui arbitrent la taille de l’index, le rappel et le comportement de la recherche.

Différentes collections peuvent hériter des mêmes paramètres agressifs, même si une seule en a réellement besoin. Utilisez un profil moins gourmand en mémoire pour les petites archives ou les collections soumises à peu de requêtes simultanées, au lieu de régler chaque index pour la charge de recherche la plus exigeante.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Le mappage mémoire déplace la pression vers le cache de pages partagé

Placer les vecteurs ou les données du graphe sur le disque avec le mappage mémoire peut réduire l’allocation résidente permanente du processus. Cela ne libère pas les pages actives : le système d’exploitation continue de mettre en cache dans la RAM les blocs d’index récemment consultés.

La comparaison de la mémoire réalisée par Qdrant montre comment les vecteurs mappés en mémoire réduisent l’utilisation mesurée de la RAM, au prix d’un compromis sur la latence lorsque les données sont récupérées depuis le stockage.

Lorsque les requêtes passent d’une collection à l’autre, leurs pages fréquemment utilisées peuvent s’évincer mutuellement du cache de pages. Cette pression peut également évincer les données du système de fichiers utilisées par les applications photo, les conteneurs, les bases de données et les partages réseau du serveur domestique.

Les index plus volumineux que la RAM paient le prix en entrées-sorties de stockage

Un index peut dépasser la mémoire physique tout en restant interrogeable, mais une plus grande partie de chaque parcours de recherche doit alors être lue depuis le SSD. Les accès aléatoires et les défauts de cache font ainsi partie de la latence de récupération.

PlanetScale décrit des index de vecteurs plus volumineux que la RAM qui conservent en mémoire une structure de navigation plus petite, tout en déplaçant davantage de listes d’occurrences ou de données vectorielles vers le stockage.

Cela peut constituer un bon compromis sur un serveur domestique lorsque les recherches sont occasionnelles et que l’index se trouve sur un SSD rapide. C’est une mauvaise hypothèse lorsque plusieurs collections reçoivent des requêtes simultanées ou partagent un disque lent avec des bases de données applicatives et des charges multimédias.

Le stockage en double et les services distincts ajoutent des copies cachées

Le même embedding peut exister dans un magasin de documents, un index vectoriel, un cache applicatif ainsi qu’une collection de sauvegarde ou de préparation. Des conteneurs distincts peuvent également charger des modèles d’embeddings ou de reclassement identiques dans différents espaces d’adressage de processus.

L’analyse de Memgraph sur l’évitement du stockage vectoriel en double montre pourquoi l’architecture de l’index modifie le nombre de copies en mémoire conservées pour un même enregistrement interrogeable.

Le nombre de collections ne représente donc qu’une partie du budget. Répertoriez les vecteurs dupliqués, les anciennes versions d’index, les collections temporaires de reconstruction, les processus de modèles et les résultats mis en cache avant de conclure que la base de données vectorielle est la seule responsable.

Consolidez les collections en fonction des règles d’accès et de la charge

Utilisez des collections distinctes lorsqu’elles nécessitent des autorisations, des dimensions d’embeddings, des politiques de conservation, des calendriers de mise à jour ou des limites de défaillance différents. De simples étiquettes thématiques ne justifient pas toujours un index physique distinct.

Une collection partagée dotée de métadonnées de locataire, de propriétaire, de source ou de catégorie peut réutiliser un seul index, tandis que les filtres maintiennent la recherche dans le périmètre prévu. Testez le rappel filtré avant de consolider, car une collection mixte trop volumineuse peut entraîner ses propres coûts de classement et de maintenance.

L’explication de ZimaSpace sur les raisons pour lesquelles un environnement d’exécution d’IA local réserve de la mémoire aide à interpréter la surveillance : les pages et les caches conservés peuvent constituer un état de travail réutilisable plutôt qu’une fuite, mais ils restent en concurrence avec le reste du serveur.

Définissez un budget RAM avant d’ajouter une autre collection

Notez le nombre de vecteurs, leurs dimensions, leur précision, le type d’index, les paramètres du graphe, la taille de l’index de métadonnées, la mémoire résidente après mise en cache et la mémoire maximale pendant l’ingestion et les requêtes simultanées. Mesurez l’ensemble de la pile, et pas seulement le tableau de bord de la base de données.

Gardez une marge pour le système d’exploitation, le cache de pages, les conteneurs, les bases de données, le partage de fichiers et le modèle de langage local. Si l’activité du swap ou les défauts de pages majeurs augmentent lorsqu’une deuxième collection est interrogée, les ensembles de travail ne tiennent plus confortablement ensemble.

Réduisez les dimensions ou la précision lorsque les tests de rappel le permettent, diminuez la connectivité du graphe, déplacez les vecteurs froids vers un stockage avec mappage mémoire, limitez le nombre de requêtes simultanées, déchargez les modèles inutilisés et supprimez les collections obsolètes avant d’acheter davantage de RAM.

FAQ

Une seule grande collection RAG est-elle toujours plus efficace en mémoire ?

Elle évite souvent de dupliquer la surcharge des index, mais peut nécessiter un filtrage plus complexe et réduire la qualité des résultats lorsque des contenus sans rapport partagent le même espace de classement. Ne consolidez qu’après avoir testé les limites d’accès et le rappel.

Le mappage mémoire élimine-t-il la concurrence pour la RAM ?

Non. Il réduit les allocations résidentes permanentes, mais les pages d’index actives occupent toujours le cache de pages du système d’exploitation et peuvent évincer les pages utilisées par d’autres collections et applications.

Pourquoi la RAM reste-t-elle élevée après la fin d’une requête RAG ?

La base de données, l’allocateur, le système d’exploitation ou l’environnement d’exécution du modèle peut conserver des pages et des tampons réutilisables. Vérifiez si la mémoire est réutilisée lors des requêtes suivantes et si une activité de swap ou une pression entraînant l’arrêt par manque de mémoire apparaît avant de conclure à une fuite.