Benchmarks de Performance : | Guide IA Complet 2026

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 ?

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

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)

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

Weaviate (HNSW)

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

Milvus (HNSW)

index_params = {
  "metric_type": "COSINE",
  "index_type": "HNSW",
  "params": {
    "M": 16,
    "efConstruction": 200
  }
}

search_params = {
  "metric_type": "COSINE",
  "params": {"ef": 100}
}

FAISS (HNSW)

import faiss

index = faiss.IndexHNSWFlat(768, 16)  # dimension, M
index.hnsw.efConstruction = 200
index.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
client.create_payload_index(
    collection_name="docs",
    field_name="category",
    field_schema="keyword"  # Index hash pour égalité exacte
)

# 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

250ms |
      |                                              ● Pinecone (100M)
200ms |                              ○ Weaviate (100M)
      |                          ○ Milvus (100M)
150ms |                      ● Qdrant (100M)
      |          ● FAISS (100M)
100ms |                  ○ Pinecone (10M)
      |              ○ Weaviate (10M)
 50ms |          ○ Milvus (10M)
      |      ● Qdrant (10M)
      |  ● FAISS (10M)
  0ms +------------------------------------------------
      1M                 10M                  100M

● = Solutions on-premise optimales (FAISS, Qdrant)
○ = Solutions full-featured (Weaviate, Milvus, Pinecone)

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

20K |
    |                            ● Qdrant
15K |                    ● Qdrant
    |            ● Qdrant        ○ Milvus
10K |    ● Qdrant       ○ Milvus
    |    ○ Milvus       ○ Weaviate
 5K |    ○ Weaviate
    |
  0 +---------------------------------------
    1         2         3         4  Nœuds

Scalabilité idéale (linéaire) = ligne en pointillés
● Qdrant: 95% efficiency (overhead minimal)
○ Milvus: 80% efficiency (consensus etcd)
○ Weaviate: 70% efficiency (GraphQL routing)

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.

Perspectives et evolution

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

15K |
    |  ■■■■■■■■■■■■■  FAISS (read-only)
10K |  ■■■■■■■■■    Qdrant (read-only)
    |  ■■■■■■■      Milvus (read-only)
 5K |  ■■■■■■        Weaviate (read-only)
    |  ■■■            Pinecone (read-only)
    |
    |  ●●●●●●●      Qdrant (mixte 80/20)
 2K |  ●●●●●        Milvus (mixte 80/20)
    |  ●●●●          Weaviate (mixte 80/20)
    |  ●●●            Pinecone (mixte 80/20)
  0 +----------------------------------------

■ = Read-only workload (optimal)
● = Mixed workload (réaliste)

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
100% |                                        ● ef=1000
     |                              ● ef=500
 99% |                      ● ef=200
     |              ● ef=100
 98% |      ● ef=50
     |  ● ef=20
 97% |
 96% +--------------------------------------------------
     5ms   15ms   25ms   35ms   45ms   55ms  Latence P95

Point optimal: ef=100 (98.7% recall, 29ms latence)
Point ultra-rapide: ef=20 (97.1% recall, 8ms latence)
Point ultra-précis: ef=500 (99.4% recall, 52ms latence)

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
client.update_collection(
    collection_name="docs",
    quantization_config=models.ScalarQuantization(
        scalar=models.ScalarQuantizationConfig(
            type=models.ScalarType.INT8,
            quantile=0.99,  # Ignore outliers pour meilleure compression
        ),
    ),
)

Courbes Pareto performance-précision

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

Latence P95 (ms) vs Recall@10

 60ms |                                          ● HNSW FP32 ef=500
      |                              ● HNSW FP32 ef=200
 40ms |                      ● HNSW FP32 ef=100
      |              ● HNSW + Scalar Quant ef=100
 20ms |      ● IVF nprobe=64
      |  ● IVF+PQ nprobe=32
      |
  0ms +--------------------------------------------------
      88%    92%    95%    97%    98%    99%   Recall@10

Front de Pareto (configurations optimales) :
● 89% recall, 12ms → IVF+PQ (budget limité)
● 95% recall, 18ms → IVF nprobe=64
● 98% recall, 31ms → HNSW + Scalar Quant
● 99% recall, 52ms → HNSW FP32 ef=500

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
FP32 baseline:     570 GB  (impossible single-node)
Scalar Quant INT8: 145 GB  (r5.8xlarge 256GB)
Product Quant:      85 GB  (r5.4xlarge 128GB)
Binary:             18 GB  (r5.xlarge 32GB)

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.

Mise en pratique et recommandations

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)

$5K  |
     |                                    ● 100M vecteurs
$3K  |                        ● 50M
     |              ● 10M
$1K  |      ● 1M
     |  ● 100K
$0   +----------------------------------------
     100K    1M     10M    50M    100M

Pinecone = scaling linéaire avec volumetrie
Self-hosted = scaling par paliers (taille instances)

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)

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

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)

                    ┌──────────────┐
                    │ Load Balancer  │
                    │ (ALB/HAProxy)  │
                    └───────┬───────┘
                            │
             ┌─────────┼─────────┐
             │              │              │
    ┌────────┴──┐  ┌───┴──┐  ┌───┴──┐
    │ Qdrant       │  │ Qdrant │  │ Qdrant │
    │ Shard 1      │  │ Shard 2│  │ Shard 3│
    │ 5K QPS       │  │ 5K QPS │  │ 5K QPS │
    │ 3.3M vectors │  │ 3.3M v │  │ 3.3M v │
    └──────────────┘  └───────┘  └───────┘

Total: 15K QPS, latence P95 < 40ms

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).

Mise en pratique et recommandations

Script validation recall complet

# Vérifier recall sur votre dataset
import numpy as np
from qdrant_client import QdrantClient

def validate_recall(client, test_vectors, ground_truth, ef_values):
    results = {}

    for ef in ef_values:
        recalls = []

        for i, query_vector in enumerate(test_vectors[:100]):  # 100 queries test
            # Recherche approximative
            response = client.search(
                collection_name="test",
                query_vector=query_vector,
                limit=10,
                search_params={"ef": ef}
            )
            approx_ids = [hit.id for hit in response]

            # Ground truth (brute force précalculé)
            true_ids = ground_truth[i][:10]

            # Calcul recall@10
            intersection = len(set(approx_ids) & set(true_ids))
            recall = intersection / 10.0
            recalls.append(recall)

        results[ef] = np.mean(recalls)
        print(f"ef={ef}: Recall@10 = {results[ef]:.3f}")

    return results

# Usage
ef_values = [10, 20, 50, 100, 200, 500]
recall_results = validate_recall(client, test_vectors, ground_truth, ef_values)

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.

Analyse approfondie et recommandations

1. Setup environnement de test

# Docker Compose pour Qdrant + monitoring
version: '3.8'
services:
  qdrant:
    image: qdrant/qdrant:v1.7.4
    ports:
      - "6333:6333"
    volumes:
      - "./qdrant_storage:/qdrant/storage"
    environment:
      - QDRANT__SERVICE__HTTP_PORT=6333
    deploy:
      resources:
        limits:
          memory: 32G
          cpus: '16'

  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - "./prometheus.yml:/etc/prometheus/prometheus.yml"

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin

2. Script benchmark principal

#!/usr/bin/env python3
"""Benchmark complet bases vectorielles"""

import time
import numpy as np
import concurrent.futures
from statistics import median, quantiles
from qdrant_client import QdrantClient, models
from datasets import load_dataset  # HuggingFace datasets

class VectorBenchmark:
    def __init__(self, client, collection_name):
        self.client = client
        self.collection_name = collection_name
        self.latencies = []

    def setup_collection(self, vector_size=768, quantization=None):
        """Créer collection avec config optimisée"""
        config = models.VectorParams(
            size=vector_size,
            distance=models.Distance.COSINE
        )

        hnsw_config = models.HnswConfigDiff(
            m=16,
            ef_construct=200,
            full_scan_threshold=10000
        )

        self.client.create_collection(
            collection_name=self.collection_name,
            vectors_config=config,
            hnsw_config=hnsw_config,
            quantization_config=quantization
        )

    def load_test_data(self, num_vectors=10000):
        """Charger dataset SIFT ou générer aléatoirement"""
        # Option 1: Dataset réel
        # dataset = load_dataset("Qdrant/sift-small", split="train")
        # vectors = np.array([d["vector"] for d in dataset])

        # Option 2: Génération aléatoire (plus rapide pour tests)
        vectors = np.random.random((num_vectors, 768)).astype(np.float32)

        # Normalisation pour distance cosinus
        vectors = vectors / np.linalg.norm(vectors, axis=1, keepdims=True)

        return vectors

    def bulk_insert(self, vectors, batch_size=1000):
        """Insertion optimisée par batch"""
        points = []
        for i, vector in enumerate(vectors):
            points.append(models.PointStruct(
                id=i,
                vector=vector.tolist(),
                payload={"index": i, "timestamp": time.time()}
            ))

            if len(points) >= batch_size:
                self.client.upsert(
                    collection_name=self.collection_name,
                    points=points
                )
                points = []

        # Insérer le dernier batch
        if points:
            self.client.upsert(
                collection_name=self.collection_name,
                points=points
            )

    def warmup(self, query_vectors, num_warmup=100):
        """Warm-up pour stabiliser les performances"""
        print(f"Warm-up: {num_warmup} requêtes...")
        for i in range(num_warmup):
            query = query_vectors[i % len(query_vectors)]
            self.client.search(
                collection_name=self.collection_name,
                query_vector=query.tolist(),
                limit=10
            )

    def single_query(self, query_vector, ef_search=100):
        """Une requête avec mesure latence"""
        start = time.perf_counter()

        results = self.client.search(
            collection_name=self.collection_name,
            query_vector=query_vector.tolist(),
            limit=10,
            search_params=models.SearchParams(ef=ef_search)
        )

        latency_ms = (time.perf_counter() - start) * 1000
        return latency_ms, len(results)

    def throughput_test(self, query_vectors, duration_sec=60, max_workers=10):
        """Test throughput avec threads multiples"""
        print(f"Test throughput: {duration_sec}s avec {max_workers} threads")

        def worker():
            local_queries = 0
            start_time = time.time()

            while time.time() - start_time < duration_sec:
                query_idx = local_queries % len(query_vectors)
                query = query_vectors[query_idx]

                try:
                    self.single_query(query)
                    local_queries += 1
                except Exception as e:
                    print(f"Erreur: {e}")
                    break

            return local_queries

        # Exécution parallèle
        with concurrent.futures.ThreadPoolExecutor(max_workers=max_workers) as executor:
            futures = [executor.submit(worker) for _ in range(max_workers)]
            results = [f.result() for f in futures]

        total_queries = sum(results)
        qps = total_queries / duration_sec

        print(f"Résultats: {total_queries} requêtes en {duration_sec}s = {qps:.1f} QPS")
        return qps

    def latency_benchmark(self, query_vectors, num_queries=1000, ef_search=100):
        """Benchmark latence avec percentiles"""
        print(f"Test latence: {num_queries} requêtes (ef_search={ef_search})")

        latencies = []
        for i in range(num_queries):
            query = query_vectors[i % len(query_vectors)]
            latency_ms, _ = self.single_query(query, ef_search)
            latencies.append(latency_ms)

        # Calculer percentiles
        latencies.sort()
        p50 = median(latencies)
        p95 = np.percentile(latencies, 95)
        p99 = np.percentile(latencies, 99)

        print(f"Latences: P50={p50:.1f}ms, P95={p95:.1f}ms, P99={p99:.1f}ms")
        return {"p50": p50, "p95": p95, "p99": p99}

    def recall_test(self, query_vectors, ground_truth, ef_search=100, k=10):
        """Test recall vs ground truth"""
        print(f"Test recall@{k} (ef_search={ef_search})")

        recalls = []
        for i, query in enumerate(query_vectors[:100]):  # 100 queries test
            # Recherche approximative
            results = self.client.search(
                collection_name=self.collection_name,
                query_vector=query.tolist(),
                limit=k,
                search_params=models.SearchParams(ef=ef_search)
            )
            approx_ids = [hit.id for hit in results]

            # Comparer avec ground truth
            true_ids = ground_truth[i][:k]
            intersection = len(set(approx_ids) & set(true_ids))
            recall = intersection / k
            recalls.append(recall)

        avg_recall = np.mean(recalls)
        print(f"Recall@{k}: {avg_recall:.3f} ({avg_recall*100:.1f}%)")
        return avg_recall

# Usage exemple
if __name__ == "__main__":
    client = QdrantClient(host="localhost", port=6333)
    benchmark = VectorBenchmark(client, "benchmark_test")

    # Setup
    print("1. Configuration collection...")
    benchmark.setup_collection(quantization=models.ScalarQuantization(
        scalar=models.ScalarQuantizationConfig(type=models.ScalarType.INT8)
    ))

    # Chargement données
    print("2. Chargement vecteurs...")
    vectors = benchmark.load_test_data(num_vectors=100000)
    query_vectors = vectors[:1000]  # 1000 queries de test

    print("3. Insertion bulk...")
    start = time.time()
    benchmark.bulk_insert(vectors)
    insert_time = time.time() - start
    print(f"Insertion: {len(vectors)} vecteurs en {insert_time:.1f}s = {len(vectors)/insert_time:.0f} vecteurs/sec")

    # Warm-up
    benchmark.warmup(query_vectors)

    # Benchmarks
    print("\n4. Benchmark latence...")
    latency_results = benchmark.latency_benchmark(query_vectors, ef_search=100)

    print("\n5. Benchmark throughput...")
    qps = benchmark.throughput_test(query_vectors, duration_sec=30, max_workers=8)

    # Résumé
    print("\n=== RÉSULTATS ===")
    print(f"Dataset: {len(vectors)} vecteurs 768D")
    print(f"Latence P95: {latency_results['p95']:.1f}ms")
    print(f"Throughput: {qps:.0f} QPS")
    print(f"Mémoire: {benchmark.client.get_collection(benchmark.collection_name).config}")

3. Exécution automatisée

#!/bin/bash
# Script complet de benchmark multi-solutions

echo "=== BENCHMARK BASES VECTORIELLES ==="
echo "Date: $(date)"
echo "Instance: $(curl -s http://169.254.169.254/latest/meta-data/instance-type)"

# Démarrer les services
docker-compose up -d
sleep 30  # Attendre démarrage

# Benchmark Qdrant
echo "\n--- QDRANT BENCHMARK ---"
python3 benchmark_qdrant.py

# Benchmark Milvus (adapté)
echo "\n--- MILVUS BENCHMARK ---"
python3 benchmark_milvus.py

# Générer rapport
echo "\n--- RAPPORT FINAL ---"
python3 generate_report.py > benchmark_report_$(date +%Y%m%d).txt

echo "Benchmark terminé. Rapport: benchmark_report_$(date +%Y%m%d).txt"

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.