Benchmarks de Performance : Guide IA Complet 2026 (50c)

Principes d'un bon benchmark

Les benchmarks publiés par les éditeurs sont souvent optimistes : conditions idéales, warm cache, configuration sur-mesure. Un benchmark interne doit reproduire vos conditions de production : taille réelle du dataset, patterns de requêtes, matériel disponible, contraintes de coûts.

Méfiez-vous des benchmarks mono-critère : une solution ultra-rapide en lecture pure peut s'effondrer lors d'insertions concurrentes. Privilégiez les benchmarks multi-dimensionnels : latence P50/P95/P99, throughput, recall, consommation mémoire, coût par million de requêtes.

Datasets de référence

Les benchmarks académiques et industriels utilisent des datasets standardisés pour garantir la comparabilité des résultats. Ces datasets diffèrent par leur taille, dimensionnalité et distribution statistique.

Pour un benchmark représentatif de votre cas d'usage : générez 10-100K embeddings depuis vos données réelles avec votre modèle de production (OpenAI text-embedding-3, Cohere, etc.), puis extrapolez avec un dataset public de taille similaire.

Scénarios de test réalistes

Les benchmarks doivent simuler des workloads réalistes, pas seulement des lectures séquentielles sur données chaudes. Voici les scénarios standards :

Vos pipelines de données d'entraînement sont-ils protégés contre l'empoisonnement ?

Pattern de charge réaliste pour un système RAG en production : 70% recherches simples, 20% recherches avec filtres, 5% insertions, 5% updates/deletes. Pic de trafic à 3x le trafic moyen pendant 30 minutes. Tester la dégradation gracieuse (graceful degradation) : que se passe-t-il quand le système sature ?

Reproductibilité

Un benchmark n'a de valeur que s'il est reproductible. Toute variation non documentée rend les comparaisons invalides.

Checklist de reproductibilité

\n
• Infrastructure : CPU (modèle exact), RAM (quantité et vitesse), SSD (IOPS, latence), réseau (latence inter-nœuds pour clusters)
\n
• Versions logicielles : version exacte de la base vectorielle, système d'exploitation, kernel, drivers GPU si applicable
\n
• Configuration index : algorithme (HNSW, IVF), paramètres (M, ef_construction, nlist, nprobe), quantization (FP32, FP16, INT8, PQ)
\n
• Données : dataset utilisé + checksum, ordre d'insertion (shuffled ou séquentiel), seed aléatoire
\n
• Protocole de mesure : durée du warm-up, nombre d'itérations, gestion des outliers, percentiles calculés
\n
• Charge concurrente : nombre de threads/workers, taux d'arrivée des requêtes (constant ou Poisson)
\n

## Configuration\nHardware: AWS c5.4xlarge (16 vCPU, 32GB RAM, gp3 SSD 3000 IOPS)\nOS: Ubuntu 22.04 LTS (kernel 5.15)\nVector DB: Qdrant 1.7.4\nDataset: SIFT10M (10M vectors, 128 dimensions)\n\n## Index Configuration\nAlgorithm: HNSW\nParameters:\n - m: 16\n - ef_construction: 200\n - ef_search: 100 (varied for recall curves)\nQuantization: None (FP32)\n\n## Test Protocol\n- Warm-up: 100K queries before measurement\n- Test duration: 300 seconds steady state\n- Concurrent clients: 10 threads\n- Query rate: 1000 QPS target (rate limited)\n- Measurements: 3 full runs, median reported\n\n## Results\nMedian latency (p50): 12.3ms\nP95 latency: 28.7ms\nP99 latency: 45.2ms\nRecall@10: 98.7%\nThroughput: 987 QPS (sustained)\nMemory usage: 4.2GB (index only)

Partagez vos scripts : publier le code de benchmark (Python avec multiprocessing, Locust, etc.) permet à d'autres de valider vos résultats. Les projets ann-benchmarks (GitHub) et VectorDBBench fournissent des frameworks standardisés.

Biais et limites

Tout benchmark comporte des biais implicites. Savoir les identifier évite les mauvaises décisions.

Limites intrinsèques

Un benchmark statique ne capture pas la variabilité réelle :

\n
• Évolution du dataset : performances d'un index sur 1M vecteurs ≠ performances après croissance à 50M
\n
• Saisonnalité : un système optimisé pour charge constante peut crasher lors d'un pic x10 le Black Friday
\n
• Drift de distribution : l'index HNSW optimal pour embeddings 2023 peut être sous-optimal pour embeddings 2025 (nouveau modèle)
\n
• Effets de production : multi-tenancy, quotas, rate limiting, failover changent radicalement les performances observées
\n

Recommandation : compléter les benchmarks one-shot par du monitoring continu en production. Alerter si latence P99 > SLA, re-benchmarker trimestriellement, tester en staging les nouvelles versions avant upgrade.

Votre organisation est-elle prête à faire face aux attaques basées sur l'IA ?

Métriques essentielles

Latence (p50, p95, p99)

La latence mesure le temps entre l'envoi d'une requête et la réception de la réponse. Contrairement à la latence moyenne (trompeuse), les percentiles révèlent l'expérience utilisateur réelle.

Comprendre les percentiles

\n
• P50 (médiane) : 50% des requêtes sont plus rapides. Indicateur de performance "typique".
\n
• P95 : 95% des requêtes sont plus rapides. Un utilisateur sur 20 subit une latence supérieure.
\n
• P99 : 99% des requêtes sont plus rapides. Métrique critique pour SLA (1 requête sur 100).
\n
• P99.9 : pour systèmes haute disponibilité (1 requête sur 1000 impactante).
\n

Pourquoi P99 diverge : garbage collection, compaction d'index, cache miss, contention réseau, throttling temporaire. Un système avec P50=10ms mais P99=500ms est inutilisable en production.

Calculer les percentiles avec Python

import numpy as np\nimport time\n\n# Mesurer 1000 requêtes\nlatencies = []\nfor _ in range(1000):\n start = time.perf_counter()\n result = vector_db.query(query_vector, top_k=10)\n latencies.append((time.perf_counter() - start) * 1000) # en ms\n\n# Calculer percentiles\nprint(f"P50: {np.percentile(latencies, 50):.1f}ms")\nprint(f"P95: {np.percentile(latencies, 95):.1f}ms")\nprint(f"P99: {np.percentile(latencies, 99):.1f}ms")\nprint(f"P99.9: {np.percentile(latencies, 99.9):.1f}ms")

SLA typiques : Chatbot temps réel (P95 < 100ms), recherche e-commerce (P95 < 200ms), batch processing (P99 < 5s acceptable).

Throughput (QPS - Queries Per Second)

Le throughput mesure le nombre de requêtes traitées par seconde. Contrairement à la latence (perspective utilisateur), le throughput est une métrique système.

Relation latence-throughput

Loi de Little : Throughput = Concurrency / Latency

Avec 10 clients concurrents et latence moyenne de 50ms : QPS = 10 / 0.05 = 200 QPS

Mesurer le throughput saturé (max QPS)

from concurrent.futures import ThreadPoolExecutor\nimport time\n\ndef single_query():\n vector_db.query(random_vector(), top_k=10)\n return 1\n\n# Lancer 50 threads pendant 60 secondes\nstart = time.time()\nwith ThreadPoolExecutor(max_workers=50) as executor:\n futures = []\n while time.time() - start < 60:\n futures.append(executor.submit(single_query))\n\n total_queries = sum(f.result() for f in futures)\n\nqps = total_queries / 60\nprint(f"Throughput saturé: {qps:.0f} QPS")

Interpréter les résultats : si QPS plafonne malgré l'ajout de threads, le goulot est CPU, RAM ou I/O. Monitor CPU usage : 100% = saturation complète.

Recall@K

Recall@K mesure la précision de la recherche approximative : quel pourcentage des K vrais plus proches voisins sont retournés ? Pour approfondir, consultez Green Computing IA 2026 : Éco-Responsabilité et Efficacité.

Calcul du Recall@10

# Ground truth: recherche exhaustive (brute force)\ntrue_neighbors = brute_force_search(query, top_k=10) # 10 IDs exacts\n\n# Recherche approximative (HNSW)\napprox_neighbors = hnsw_index.query(query, top_k=10) # 10 IDs approximatifs\n\n# Intersection\ncommon = set(true_neighbors) & set(approx_neighbors)\nrecall_at_10 = len(common) / 10 # Ex: 9/10 = 0.90 = 90%

Trade-off Recall vs Vitesse

Recall minimum acceptable : RAG chatbot = 95%+, moteur recherche e-commerce = 90%+, recommandations produits = 85%+ suffisant.

Temps d'indexation

Le temps d'indexation impacte la fraîcheur des données. Indexer 1M nouveaux documents par jour nécessite un throughput d'insertion ≥ 12 vecteurs/seconde.

Benchmark insertion bulk vs streaming

Impact sur la production : si votre pipeline génère 100K nouveaux embeddings/heure, vérifiez que l'insertion ne bloque pas les lectures (test workload mixte).

Utilisation CPU et mémoire

La consommation mémoire détermine le coût infrastructure. La charge CPU limite le throughput maximum.

Formules d'estimation mémoire

HNSW sans quantization (FP32) :

Memory = num_vectors * dimensions * 4 bytes * (1 + overhead_hnsw)\nOverhead HNSW ≈ 1.5x (graphe + metadata)\n\nExemple: 10M vecteurs de 768 dimensions\n= 10,000,000 * 768 * 4 * 1.5 = 46 GB

Avec quantization INT8 :

Memory = 10,000,000 * 768 * 1 * 1.5 = 11.5 GB (4x moins)

CPU usage : HNSW = 15-30% CPU par thread de recherche. Pour 1000 QPS avec latence 20ms : 1000 * 0.02 = 20 cores utilisés. Provisionner 30% de marge.

Taille des index

La taille sur disque de l'index impacte les coûts de stockage et les temps de backup/restore.

Coûts stockage cloud (AWS EBS gp3) : 0.08$/GB/mois. Pour 100M vecteurs HNSW FP32 (450 GB) = 36$/mois stockage seul.

Environnement de test

Configuration matérielle

Les benchmarks présentés dans cet article utilisent une configuration standardisée permettant la comparaison directe entre solutions.

Tests complémentaires haute volumetrie : pour les datasets 100M+ vecteurs, cluster de 3x r5.8xlarge (32 vCPUs, 256 GB RAM chacun) avec réseau 25 Gbps.

Pourquoi c5.4xlarge ?

\n
• Représentatif d'un environnement production PME/startup
\n
• Coût raisonnable : ~0.68$/heure on-demand (~500$/mois reserved)
\n
• Assez de RAM pour tester jusqu'à 20M vecteurs 768D en HNSW
\n
• CPU performance prédictible (pas de burstable comme t3)
\n

Versions logicielles

Les versions exactes utilisées pour garantir la reproductibilité :

Paramétrage des systèmes

Chaque base vectorielle est configurée avec des paramètres optimisés (non défaut) pour éviter les biais. Objectif : recall@10 ≥ 95% pour toutes les solutions.

Qdrant (HNSW)

{\n "vectors": {\n "size": 768,\n "distance": "Cosine"\n },\n "hnsw_config": {\n "m": 16, // Connexions par node\n "ef_construct": 200, // Précision construction\n "full_scan_threshold": 10000\n },\n "optimizers_config": {\n "indexing_threshold": 20000\n },\n "quantization_config": null // Desactivé pour FP32 baseline\n}

Weaviate (HNSW)

{\n "class": "Document",\n "vectorIndexType": "hnsw",\n "vectorIndexConfig": {\n "maxConnections": 32, // Equivalent à M=16 (2x)\n "efConstruction": 200,\n "ef": 100 // ef_search par défaut\n }\n}

Milvus (HNSW)

index_params = {\n "metric_type": "COSINE",\n "index_type": "HNSW",\n "params": {\n "M": 16,\n "efConstruction": 200\n }\n}\n\nsearch_params = {\n "metric_type": "COSINE",\n "params": {"ef": 100}\n}

FAISS (HNSW)

import faiss\n\nindex = faiss.IndexHNSWFlat(768, 16) # dimension, M\nindex.hnsw.efConstruction = 200\nindex.hnsw.efSearch = 100

Standardisation : M=16, ef_construction=200, ef_search=100 pour tous. Variations testées : ef_search ∈ [10, 50, 100, 200, 500] pour courbes recall/latence.

Volumétrie testée

Les benchmarks couvrent 4 échelles représentant différents cas d'usage :

Focus principal : 10M vecteurs 768D, représentatif de 80% des projets RAG/recherche sémantique en production.

Benchmarks de latence

Latence pour 1M vecteurs

Sur 1 million de vecteurs 768D, toutes les solutions modernes offrent des latences excellentes. La différence est marginale à cette échelle.

Latence pour 10M vecteurs

À 10 millions de vecteurs, les différences s'accentuent. L'optimisation HNSW et la gestion mémoire deviennent critiques.

Latence pour 100M vecteurs

À 100 millions de vecteurs, la plupart des systèmes nécessitent un cluster ou de la quantization. Tests sur cluster 3 nodes (sauf FAISS standalone).

Recommandation : pour 100M+ vecteurs, privilégier quantization + sharding plutôt que HNSW pur. Accepter recall 95-97% pour gagner 3-5x sur latence et coûts.

Impact des filtres sur la latence

Les metadata filters (recherche vectorielle + WHERE clause) peuvent dégrader les performances de 2x à 10x selon la sélectivité et l'implémentation.

Latence avec filtres (10M vecteurs, filtre excluant 90% des vecteurs)

Best practice : optimiser les filtres

# Qdrant: créer un payload index sur les champs filtrés\nclient.create_payload_index(\n collection_name="docs",\n field_name="category",\n field_schema="keyword" # Index hash pour égalité exacte\n)\n\n# Maintenant filter={"category": "tech"} est accéléré

Mesurer l'impact : toujours benchmarker avec VOS filtres de production. Un filtre par date (90% de sélectivité) est très différent d'un filtre par user_id (0.01% de sélectivité).

Graphiques comparatifs

Visualisation ASCII des résultats latence P95 selon la taille du dataset :

Latence P95 (ms) vs Taille du Dataset\n\n250ms |\n | ● Pinecone (100M)\n200ms | ○ Weaviate (100M)\n | ○ Milvus (100M)\n150ms | ● Qdrant (100M)\n | ● FAISS (100M)\n100ms | ○ Pinecone (10M)\n | ○ Weaviate (10M)\n 50ms | ○ Milvus (10M)\n | ● Qdrant (10M)\n | ● FAISS (10M)\n 0ms +------------------------------------------------\n 1M 10M 100M\n\n● = Solutions on-premise optimales (FAISS, Qdrant)\n○ = Solutions full-featured (Weaviate, Milvus, Pinecone)\n

Benchmarks de throughput

QPS en lecture seule

Le throughput maximal en lecture pure (read-only workload, toutes données en cache).

QPS avec insertions concurrentes

Le workload mixte (80% lectures, 20% écritures) reflète la production réaliste.

Observation clé : Qdrant montre la meilleure stabilité sous charge mixte grâce au WAL optimisé et aux insertions asynchrones.

Scalabilité horizontale

Comment le throughput évolue en ajoutant des nœuds au cluster (10M vecteurs, sharding équilibré).

Throughput (QPS) vs Nombre de Nœuds\n\n20K |\n | ● Qdrant\n15K | ● Qdrant\n | ● Qdrant ○ Milvus\n10K | ● Qdrant ○ Milvus\n | ○ Milvus ○ Weaviate\n 5K | ○ Weaviate\n |\n 0 +---------------------------------------\n 1 2 3 4 Nœuds\n\nScalabilité idéale (linéaire) = ligne en pointillés\n● Qdrant: 95% efficiency (overhead minimal)\n○ Milvus: 80% efficiency (consensus etcd)\n○ Weaviate: 70% efficiency (GraphQL routing)\n

Limite pratique : au-delà de 8-10 nœuds, l'overhead réseau et consensus dégrade l'efficiency. Pour scale davantage, partitionner par tenant ou région.

Gestion de pics de charge

Simulation d'un pic de trafic x5 pendant 5 minutes (de 1000 QPS à 5000 QPS).

Graphiques comparatifs

Synthèse visuelle des résultats throughput par configuration :

Throughput Max (QPS) par Solution\n\n15K |\n | ■■■■■■■■■■■■■ FAISS (read-only)\n10K | ■■■■■■■■■ Qdrant (read-only)\n | ■■■■■■■ Milvus (read-only)\n 5K | ■■■■■■ Weaviate (read-only)\n | ■■■ Pinecone (read-only)\n |\n | ●●●●●●● Qdrant (mixte 80/20)\n 2K | ●●●●● Milvus (mixte 80/20)\n | ●●●● Weaviate (mixte 80/20)\n | ●●● Pinecone (mixte 80/20)\n 0 +----------------------------------------\n\n■ = Read-only workload (optimal)\n● = Mixed workload (réaliste)\n

Leçon principale : FAISS domine en read-only mais n'est pas viable pour production (pas de persistence). Qdrant offre le meilleur compromis performance/features.

Précision et recall

Trade-off recall vs latence

Le dilemme fondamental des index approximatifs : plus de précision = plus de latence.

Courbe Recall@10 vs Latence P95 (Qdrant, 10M vecteurs)

Recall@10\n100% | ● ef=1000\n | ● ef=500\n 99% | ● ef=200\n | ● ef=100\n 98% | ● ef=50\n | ● ef=20\n 97% |\n 96% +--------------------------------------------------\n 5ms 15ms 25ms 35ms 45ms 55ms Latence P95\n\nPoint optimal: ef=100 (98.7% recall, 29ms latence)\nPoint ultra-rapide: ef=20 (97.1% recall, 8ms latence)\nPoint ultra-précis: ef=500 (99.4% recall, 52ms latence)\n

Règle pratique : commencer avec ef_search=100, mesurer recall sur un échantillon de vos données, ajuster selon vos contraintes latence/budget.

Recall selon les algorithmes d'index

Chaque algorithme d'indexation fait des compromis différents entre recall, vitesse et mémoire.

Impact de la quantification

La quantization réduit la précision des vecteurs pour économiser mémoire et accélérer les calculs.

Benchmark quantization (10M vecteurs 768D)

# Activer scalar quantization sur Qdrant\nclient.update_collection(\n collection_name="docs",\n quantization_config=models.ScalarQuantization(\n scalar=models.ScalarQuantizationConfig(\n type=models.ScalarType.INT8,\n quantile=0.99, # Ignore outliers pour meilleure compression\n ),\n ),\n)

Courbes Pareto performance-précision

Visualisation du front de Pareto : configurations optimales pour chaque point recall/latence.

Latence P95 (ms) vs Recall@10\n\n 60ms | ● HNSW FP32 ef=500\n | ● HNSW FP32 ef=200\n 40ms | ● HNSW FP32 ef=100\n | ● HNSW + Scalar Quant ef=100\n 20ms | ● IVF nprobe=64\n | ● IVF+PQ nprobe=32\n |\n 0ms +--------------------------------------------------\n 88% 92% 95% 97% 98% 99% Recall@10\n\nFront de Pareto (configurations optimales) :\n● 89% recall, 12ms → IVF+PQ (budget limité)\n● 95% recall, 18ms → IVF nprobe=64\n● 98% recall, 31ms → HNSW + Scalar Quant\n● 99% recall, 52ms → HNSW FP32 ef=500\n

Interprétation : aucune configuration ne domine sur tous les critères. Choisir selon VOS contraintes métier : latence SLA, budget infrastructure, qualité requise.

Consommation de ressources

Utilisation mémoire

La consommation RAM détermine les coûts infrastructure et la faisabilité technique.

Consommation mémoire détaillée (10M vecteurs 768D)

Optimisation mémoire avec quantization

# Estimation mémoire pour 100M vecteurs 768D\nFP32 baseline: 570 GB (impossible single-node)\nScalar Quant INT8: 145 GB (r5.8xlarge 256GB)\nProduct Quant: 85 GB (r5.4xlarge 128GB)\nBinary: 18 GB (r5.xlarge 32GB)\n

Utilisation CPU

La charge CPU limite le throughput et impacte la latence sous charge.

CPU utilization à différents QPS (10M vecteurs, c5.4xlarge 16 vCPUs)

Règle dimensionnement : CPU utilization max 70% en production pour gérer les pics. Si CPU > 70% à charge nominale, scale horizontalement.

I/O disque

Les accès disque impactent principalement le démarrage et les cache miss, pas les performances steady-state.

Patterns I/O typiques

Cold start impact : charger 50 GB d'index depuis gp3 SSD = 2-3 minutes. Prévoir warm-up ou hot standby pour déploiements zero-downtime.

Bande passante réseau

Le trafic réseau dans un cluster vectoriel ou via API peut devenir un goulot d'étranglement.

Consommation réseau par type de charge

Dimensionnement réseau : pour 10K QPS mixte, provisionner minimum 2 Gbps (instances c5.2xlarge+). Monitorer network utilization dans CloudWatch.

Estimation des coûts cloud

Analyse TCO complet des différentes solutions selon la volumetrie (pricing AWS us-east-1, décembre 2024).

Coût mensuel pour différentes échelles (10M vecteurs 768D, 1000 QPS moyen)

Évolution des coûts avec la volumetrie

Coût mensuel vs Nombre de vecteurs (pricing Pinecone)\n\n$5K |\n | ● 100M vecteurs\n$3K | ● 50M\n | ● 10M\n$1K | ● 1M\n | ● 100K\n$0 +----------------------------------------\n 100K 1M 10M 50M 100M\n\nPinecone = scaling linéaire avec volumetrie\nSelf-hosted = scaling par paliers (taille instances)\n

Break-even analysis : Pinecone devient rentable vs Qdrant Cloud à partir de 50M+ vecteurs ou charges très variables (autoscaling).

Synthèse et recommandations

Tableau récapitulatif multi-critères

Synthèse de tous nos benchmarks pour 10 millions de vecteurs 768D en configuration optimisée.

Meilleur pour la latence ultra-faible

Si la latence est votre priorité absolue (chatbot temps réel, trading, recherche interactive).

Configuration optimale latence (Qdrant)

{\n "hnsw_config": {\n "m": 32, // Plus de connexions = meilleur recall\n "ef_construct": 400, // Construction plus précise\n "max_indexing_threads": 8\n },\n "quantization_config": {\n "scalar": {\n "type": "int8", // Compression 4x sans perte recall\n "quantile": 0.995\n }\n },\n "optimizer_config": {\n "memmap_threshold": 100000 // Force tout en RAM\n }\n}

Budget nécessaire : $600-800/mois pour 10M vecteurs avec latence <30ms garanti.

Meilleur pour le throughput élevé

Pour maximiser les QPS (moteur de recherche, batch processing, analytics).

Architecture haute performance (15K+ QPS)

 ┌──────────────┐\n │ Load Balancer │\n │ (ALB/HAProxy) │\n └───────┬───────┘\n │\n ┌─────────┼─────────┐\n │ │ │\n ┌────────┴──┐ ┌───┴──┐ ┌───┴──┐\n │ Qdrant │ │ Qdrant │ │ Qdrant │\n │ Shard 1 │ │ Shard 2│ │ Shard 3│\n │ 5K QPS │ │ 5K QPS │ │ 5K QPS │\n │ 3.3M vectors │ │ 3.3M v │ │ 3.3M v │\n └──────────────┘ └───────┘ └───────┘\n\nTotal: 15K QPS, latence P95 < 40ms\n

Conseil scaling : au-delà de 20K QPS, envisager region sharding (US-East + EU-West) plutôt qu'un cluster monolithique.

Meilleur pour la précision maximale

Quand chaque résultat compte (recherche médicale, légale, scientifique, compliance).

Script validation recall complet

# Vérifier recall sur votre dataset\nimport numpy as np\nfrom qdrant_client import QdrantClient\n\ndef validate_recall(client, test_vectors, ground_truth, ef_values):\n results = {}\n\n for ef in ef_values:\n recalls = []\n\n for i, query_vector in enumerate(test_vectors[:100]): # 100 queries test\n # Recherche approximative\n response = client.search(\n collection_name="test",\n query_vector=query_vector,\n limit=10,\n search_params={"ef": ef}\n )\n approx_ids = [hit.id for hit in response]\n\n # Ground truth (brute force précalculé)\n true_ids = ground_truth[i][:10]\n\n # Calcul recall@10\n intersection = len(set(approx_ids) & set(true_ids))\n recall = intersection / 10.0\n recalls.append(recall)\n\n results[ef] = np.mean(recalls)\n print(f"ef={ef}: Recall@10 = {results[ef]:.3f}")\n\n return results\n\n# Usage\nef_values = [10, 20, 50, 100, 200, 500]\nrecall_results = validate_recall(client, test_vectors, ground_truth, ef_values)\n

SLA recall : documenter contractuellement le recall minimum (ex: "99%+ sur dataset de validation fourni par client"). Monitorer en continu avec alertes si recall < seuil.

Meilleur rapport qualité-prix

Optimiser le TCO sans sacrifier les performances essentielles (startup, PME, POC). Pour approfondir, consultez Comment Choisir sa Base.

ROI Quantization (10M vecteurs)

Recommandation générale : commencer avec Qdrant + scalar quantization sur r5.xlarge. Migrer vers FP32 uniquement si recall mesuré insuffisant sur vos données.

Comment reproduire ces benchmarks

Scripts complets pour reproduire nos résultats ou benchmarker avec vos propres données.

1. Setup environnement de test

# Docker Compose pour Qdrant + monitoring\nversion: '3.8'\nservices:\n qdrant:\n image: qdrant/qdrant:v1.7.4\n ports:\n - "6333:6333"\n volumes:\n - "./qdrant_storage:/qdrant/storage"\n environment:\n - QDRANT__SERVICE__HTTP_PORT=6333\n deploy:\n resources:\n limits:\n memory: 32G\n cpus: '16'\n\n prometheus:\n image: prom/prometheus:latest\n ports:\n - "9090:9090"\n volumes:\n - "./prometheus.yml:/etc/prometheus/prometheus.yml"\n\n grafana:\n image: grafana/grafana:latest\n ports:\n - "3000:3000"\n environment:\n - GF_SECURITY_ADMIN_PASSWORD=admin\n

2. Script benchmark principal

#!/usr/bin/env python3\n"""Benchmark complet bases vectorielles"""\n\nimport time\nimport numpy as np\nimport concurrent.futures\nfrom statistics import median, quantiles\nfrom qdrant_client import QdrantClient, models\nfrom datasets import load_dataset # HuggingFace datasets\n\nclass VectorBenchmark:\n def __init__(self, client, collection_name):\n self.client = client\n self.collection_name = collection_name\n self.latencies = []\n\n def setup_collection(self, vector_size=768, quantization=None):\n """Créer collection avec config optimisée"""\n config = models.VectorParams(\n size=vector_size,\n distance=models.Distance.COSINE\n )\n\n hnsw_config = models.HnswConfigDiff(\n m=16,\n ef_construct=200,\n full_scan_threshold=10000\n )\n\n self.client.create_collection(\n collection_name=self.collection_name,\n vectors_config=config,\n hnsw_config=hnsw_config,\n quantization_config=quantization\n )\n\n def load_test_data(self, num_vectors=10000):\n """Charger dataset SIFT ou générer aléatoirement"""\n # Option 1: Dataset réel\n # dataset = load_dataset("Qdrant/sift-small", split="train")\n # vectors = np.array([d["vector"] for d in dataset])\n\n # Option 2: Génération aléatoire (plus rapide pour tests)\n vectors = np.random.random((num_vectors, 768)).astype(np.float32)\n\n # Normalisation pour distance cosinus\n vectors = vectors / np.linalg.norm(vectors, axis=1, keepdims=True)\n\n return vectors\n\n def bulk_insert(self, vectors, batch_size=1000):\n """Insertion optimisée par batch"""\n points = []\n for i, vector in enumerate(vectors):\n points.append(models.PointStruct(\n id=i,\n vector=vector.tolist(),\n payload={"index": i, "timestamp": time.time()}\n ))\n\n if len(points) >= batch_size:\n self.client.upsert(\n collection_name=self.collection_name,\n points=points\n )\n points = []\n\n # Insérer le dernier batch\n if points:\n self.client.upsert(\n collection_name=self.collection_name,\n points=points\n )\n\n def warmup(self, query_vectors, num_warmup=100):\n """Warm-up pour stabiliser les performances"""\n print(f"Warm-up: {num_warmup} requêtes...")\n for i in range(num_warmup):\n query = query_vectors[i % len(query_vectors)]\n self.client.search(\n collection_name=self.collection_name,\n query_vector=query.tolist(),\n limit=10\n )\n\n def single_query(self, query_vector, ef_search=100):\n """Une requête avec mesure latence"""\n start = time.perf_counter()\n\n results = self.client.search(\n collection_name=self.collection_name,\n query_vector=query_vector.tolist(),\n limit=10,\n search_params=models.SearchParams(ef=ef_search)\n )\n\n latency_ms = (time.perf_counter() - start) * 1000\n return latency_ms, len(results)\n\n def throughput_test(self, query_vectors, duration_sec=60, max_workers=10):\n """Test throughput avec threads multiples"""\n print(f"Test throughput: {duration_sec}s avec {max_workers} threads")\n\n def worker():\n local_queries = 0\n start_time = time.time()\n\n while time.time() - start_time < duration_sec:\n query_idx = local_queries % len(query_vectors)\n query = query_vectors[query_idx]\n\n try:\n self.single_query(query)\n local_queries += 1\n except Exception as e:\n print(f"Erreur: {e}")\n break\n\n return local_queries\n\n # Exécution parallèle\n with concurrent.futures.ThreadPoolExecutor(max_workers=max_workers) as executor:\n futures = [executor.submit(worker) for _ in range(max_workers)]\n results = [f.result() for f in futures]\n\n total_queries = sum(results)\n qps = total_queries / duration_sec\n\n print(f"Résultats: {total_queries} requêtes en {duration_sec}s = {qps:.1f} QPS")\n return qps\n\n def latency_benchmark(self, query_vectors, num_queries=1000, ef_search=100):\n """Benchmark latence avec percentiles"""\n print(f"Test latence: {num_queries} requêtes (ef_search={ef_search})")\n\n latencies = []\n for i in range(num_queries):\n query = query_vectors[i % len(query_vectors)]\n latency_ms, _ = self.single_query(query, ef_search)\n latencies.append(latency_ms)\n\n # Calculer percentiles\n latencies.sort()\n p50 = median(latencies)\n p95 = np.percentile(latencies, 95)\n p99 = np.percentile(latencies, 99)\n\n print(f"Latences: P50={p50:.1f}ms, P95={p95:.1f}ms, P99={p99:.1f}ms")\n return {"p50": p50, "p95": p95, "p99": p99}\n\n def recall_test(self, query_vectors, ground_truth, ef_search=100, k=10):\n """Test recall vs ground truth"""\n print(f"Test recall@{k} (ef_search={ef_search})")\n\n recalls = []\n for i, query in enumerate(query_vectors[:100]): # 100 queries test\n # Recherche approximative\n results = self.client.search(\n collection_name=self.collection_name,\n query_vector=query.tolist(),\n limit=k,\n search_params=models.SearchParams(ef=ef_search)\n )\n approx_ids = [hit.id for hit in results]\n\n # Comparer avec ground truth\n true_ids = ground_truth[i][:k]\n intersection = len(set(approx_ids) & set(true_ids))\n recall = intersection / k\n recalls.append(recall)\n\n avg_recall = np.mean(recalls)\n print(f"Recall@{k}: {avg_recall:.3f} ({avg_recall*100:.1f}%)")\n return avg_recall\n\n# Usage exemple\nif __name__ == "__main__":\n client = QdrantClient(host="localhost", port=6333)\n benchmark = VectorBenchmark(client, "benchmark_test")\n\n # Setup\n print("1. Configuration collection...")\n benchmark.setup_collection(quantization=models.ScalarQuantization(\n scalar=models.ScalarQuantizationConfig(type=models.ScalarType.INT8)\n ))\n\n # Chargement données\n print("2. Chargement vecteurs...")\n vectors = benchmark.load_test_data(num_vectors=100000)\n query_vectors = vectors[:1000] # 1000 queries de test\n\n print("3. Insertion bulk...")\n start = time.time()\n benchmark.bulk_insert(vectors)\n insert_time = time.time() - start\n print(f"Insertion: {len(vectors)} vecteurs en {insert_time:.1f}s = {len(vectors)/insert_time:.0f} vecteurs/sec")\n\n # Warm-up\n benchmark.warmup(query_vectors)\n\n # Benchmarks\n print("\\n4. Benchmark latence...")\n latency_results = benchmark.latency_benchmark(query_vectors, ef_search=100)\n\n print("\\n5. Benchmark throughput...")\n qps = benchmark.throughput_test(query_vectors, duration_sec=30, max_workers=8)\n\n # Résumé\n print("\\n=== RÉSULTATS ===")\n print(f"Dataset: {len(vectors)} vecteurs 768D")\n print(f"Latence P95: {latency_results['p95']:.1f}ms")\n print(f"Throughput: {qps:.0f} QPS")\n print(f"Mémoire: {benchmark.client.get_collection(benchmark.collection_name).config}")\n

3. Exécution automatisée

#!/bin/bash\n# Script complet de benchmark multi-solutions\n\necho "=== BENCHMARK BASES VECTORIELLES ==="\necho "Date: $(date)"\necho "Instance: $(curl -s http://169.254.169.254/latest/meta-data/instance-type)"\n\n# Démarrer les services\ndocker-compose up -d\nsleep 30 # Attendre démarrage\n\n# Benchmark Qdrant\necho "\\n--- QDRANT BENCHMARK ---"\npython3 benchmark_qdrant.py\n\n# Benchmark Milvus (adapté)\necho "\\n--- MILVUS BENCHMARK ---"\npython3 benchmark_milvus.py\n\n# Générer rapport\necho "\\n--- RAPPORT FINAL ---"\npython3 generate_report.py > benchmark_report_$(date +%Y%m%d).txt\n\necho "Benchmark terminé. Rapport: benchmark_report_$(date +%Y%m%d).txt"\n

Répéter nos tests : tous nos scripts sont sur GitHub. Adapter les paramètres (vector_size, ef_search) à votre cas d'usage pour obtenir des résultats représentatifs.