Comprendre l'utilisation de la mémoire

Qdrant fonctionne avec deux types de mémoire :

• Mémoire résidente (aka RSSAnon) - mémoire utilisée pour les structures de données internes comme le suivi des ID, plus les composants qui doivent rester en RAM, comme les vecteurs quantifiés quand always_ram=true et les index de payload.

• OS page cache - mémoire utilisée pour la mise en cache des lectures disque, qui peut être libérée si nécessaire. Les vecteurs originaux sont normalement stockés dans le page cache, donc le service ne s'arrêtera pas si la RAM est pleine, mais les performances peuvent se dégrader.

Il est normal que le OS page cache occupe toute la RAM disponible, mais si la mémoire résidente dépasse 80% de la RAM totale, c'est le signe d'un problème.

Surveillance de l'utilisation de la mémoire

• Qdrant expose l'utilisation de la mémoire via le endpoint /metrics. Voir la documentation Monitoring.

<!-- ToDo: Talk about memory usage of each components once API is available -->

Quelle quantité de mémoire est nécessaire pour Qdrant ?

L'utilisation optimale de la mémoire dépend du cas d'usage.

• Pour les scénarios de recherche réguliers, des directives générales sont fournies dans la documentation Capacity planning.

Pour une ventilation détaillée de l'utilisation de la mémoire à grande échelle, voir Exemple d'utilisation de mémoire à grande échelle.

Les index de payload et le graphe HNSW nécessitent également de la mémoire, tout comme les vecteurs eux-mêmes, il est donc important de les prendre en compte dans les calculs.

De plus, Qdrant nécessite un peu de mémoire supplémentaire pour les optimisations. Durant l'optimisation, les segments optimisés sont entièrement chargés en RAM, il est donc important de laisser suffisamment de marge. Plus la max_segment_size est grande, plus de marge est nécessaire.

Quand mettre l'index HNSW sur disque

Mettre sur disque des composants fréquemment utilisés (comme l'index HNSW) peut causer une dégradation importante des performances. Il existe cependant certains scénarios où cela peut être une bonne option :

• Déploiements avec disques à faible latence - NVMe local ou similaire.
• Déploiements multi-tenant, où seul un sous-ensemble de tenants est fréquemment accédé, de sorte que seule une fraction des données et index est chargée en RAM à la fois.
• Pour les déploiements avec inline storage activé.

Comment minimiser l'empreinte mémoire

Le principal défi est de mettre sur disque les parties des données qui sont rarement accédées. Voici les principales techniques pour y parvenir :

• Utiliser la quantification pour stocker uniquement les vecteurs compressés en RAM documentation Quantization

• Utiliser les datatypes float16 ou int8 pour réduire l'utilisation de mémoire des vecteurs de 2x ou 4x respectivement, avec un compromis sur la précision. En savoir plus sur les datatypes de vecteurs dans la documentation

• Exploiter Matryoshka Representation Learning (MRL) pour stocker uniquement les petits vecteurs en RAM tout en gardant les grands vecteurs sur disque. Exemples de comment utiliser MRL avec Qdrant Cloud inference : documentation MRL

• Pour les déploiements multi-tenant avec de petits tenants, les vecteurs peuvent être stockés sur disque car les données du même tenant sont stockées ensemble documentation Multitenancy

• Pour les déploiements avec stockage local rapide et des exigences relativement faibles en débit de recherche, il peut être possible de stocker tous les composants du vector store sur disque. En savoir plus sur les implications de performance du stockage sur disque dans l'article

• Pour les environnements avec peu de RAM, envisagez la config async_scorer, qui active le support de io_uring pour l'accès parallèle au disque, ce qui peut améliorer significativement les performances du stockage sur disque. En savoir plus sur async_scorer dans l'article (disponible uniquement sur Linux avec kernel 5.11+)

• Envisagez de stocker les Sparse Vectors et le text payload sur disque, car ils sont généralement plus adaptés au disque que les vecteurs denses.

• Configurer les index de payload pour être stockés sur disque documentation

• Configurer les sparse vectors pour être stockés sur disque documentation