Milvus : la base vectorielle des gros volumes
Milvus est une base de données vectorielle open source conçue pour la grande échelle : milliards de vecteurs, déploiement distribué, choix d'index très large. Sur une machine unique elle existe aussi en version allégée, ce qui permet de commencer petit sans changer d'outil plus tard. Reste à savoir si votre corpus justifie cette puissance — pour beaucoup de projets locaux, la réponse est non, et c'est une information utile.
#Ce que Milvus vise
La plupart des bases vectorielles visent le projet d'équipe. Milvus vise l'échelle industrielle : séparation du stockage et du calcul, montée en charge horizontale, et un catalogue d'index qui laisse arbitrer finement entre précision, mémoire et vitesse. C'est un choix d'architecture, pas un simple ensemble de fonctions.
Cette ambition a un revers direct : sur un corpus de cinquante mille passages, cette puissance ne se voit pas, et la complexité, elle, se voit tout de suite. La question à se poser n'est donc pas « est-ce la meilleure base vectorielle » mais « mon corpus atteindra-t-il la taille où ces choix comptent ».
#Une architecture en composants
Tes documents, ton IA : un RAG local fiable sur tes PDF, notes et mails — sans rien envoyer dans le cloud.
- Espace en ligne à vie
- PDF + fichiers
- Remboursé 30 j
En déploiement complet, Milvus n'est pas un processus mais un ensemble : des nœuds de requête, des nœuds de données, un service de coordination, un stockage objet, un journal de messages. Chaque partie se dimensionne indépendamment, ce qui est exactement ce qu'on veut à grande échelle et exactement ce dont on se passe sur un poste de travail.
#Les index, et lequel prendre
| Index | Compromis | Quand |
|---|---|---|
| Exact | Précision parfaite, parcours complet | Jusqu'à quelques dizaines de milliers de vecteurs |
| Graphe (HNSW) | Requêtes rapides, mémoire élevée | Le défaut raisonnable en dessous du million |
| Partitions inversées | Construction rapide, réglages à ajuster | Gros volumes, mémoire contrainte |
| Quantification produit | Mémoire divisée, précision entamée | Quand l'index ne tient plus en mémoire |
| Sur disque | Capacité au prix de la latence | Corpus dépassant largement la RAM disponible |
Le conseil qui fait gagner le plus de temps reste le même partout : commencer par l'exact. Les index approchés résolvent un problème d'échelle, et les adopter avant d'avoir ce problème achète des paramètres à régler et un rappel à mesurer, en échange de millisecondes que personne n'a remarquées.
#En local : ce que ça implique
- Ressources
- Le déploiement complet réclame plusieurs conteneurs et plusieurs gigaoctets de mémoire vive, avant même votre modèle de langage.
- Mémoire des vecteurs
- Environ 4 Ko par vecteur de 1 024 dimensions en pleine précision, hors index. C'est cette arithmétique qui décide de l'architecture, pas les fonctionnalités.
- Exploitation
- Sauvegardes, montées de version, surveillance : une vraie base de données demande un vrai exploitant.
- Le GPU reste au modèle
- L'encodage des documents et l'inférence se disputent déjà la carte ; la recherche vectorielle, elle, est surtout affaire de processeur et de mémoire.
#Quand Milvus est le bon choix
| Situation | Ce qui convient |
|---|---|
| Millions de vecteurs, croissance continue | Milvus |
| Besoin d'arbitrer finement mémoire contre précision | Milvus |
| Corpus d'équipe, filtres, quelques centaines de milliers de passages | Une base dédiée plus simple |
| PostgreSQL déjà en place | L'extension vectorielle de PostgreSQL |
| Application mono-processus | Une base embarquée ou une bibliothèque |
- Qdrant : le service dédié plus simple à exploiter
- pgvector : rester dans PostgreSQL
- La chaîne RAG complète en Python
#FAQ
Milvus est-il gratuit ?+
Faut-il un GPU ?+
Peut-on l'utiliser sur un seul poste ?+
Milvus ou Qdrant ?+
Combien de mémoire pour un million de vecteurs ?+
Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.