Pexon Consulting | 13 Min. Lesezeit | 15.07.2026
TL;DR
Eine Vektor-DB skalieren heißt: HNSW-Parameter (M, ef_construction, ef_search) gegen Recall, Latenz und Speicher austarieren, ab etwa 50 Mio Vektoren horizontal sharden und mit Quantisierung den RAM-Verbrauch drücken. Pexon Consulting, 80 Spezialisten, Microsoft Partner, 40+ RAG-Projekte, baut das als messbaren 6-Wochen-Pilot: Recall über 0,95 bei halbierter Latenz.
Wann eine Vektor-DB überhaupt skaliert werden muss
Die kurze Antwort: nicht so früh, wie die meisten denken. Ein einzelner Qdrant- oder Milvus-Node trägt mit HNSW komfortabel bis rund 50 Mio Vektoren, solange der Index in den RAM passt. Erst darüber, oder wenn Query-Latenz und Schreiblast gleichzeitig hochgehen, lohnt der Sprung auf Sharding. Vorher ist Skalierung meist ein Tuning-Problem, kein Infrastruktur-Problem.
Wir sehen in Projekten immer wieder denselben Fehler: Ein Team klagt über 400 ms Latenz und will sofort einen Cluster aufsetzen. In neun von zehn Fällen liegt es an einem falsch gesetzten ef_search oder daran, dass der HNSW-Index nicht mehr in den Arbeitsspeicher passt und auf Disk swappt. Bevor Sie horizontal skalieren, prüfen Sie diese drei Zahlen: Recall auf einem Ground-Truth-Set, p95-Latenz und Index-Größe im Verhältnis zum verfügbaren RAM.
Ein sauberer Trigger für echtes Sharding: Der Index passt nicht mehr auf eine Maschine (grob 384 GB RAM als praktische Obergrenze bei sinnvollen Instanzkosten), oder Sie brauchen mehr Query-Durchsatz, als ein Node liefert. Alles darunter ist Parameter-Arbeit. Wie das Zusammenspiel mit dem Rest der Pipeline aussieht, haben wir in unserer Anleitung zum RAG-Aufbau im Unternehmen beschrieben.
HNSW verstehen: die drei Parameter, die alles bestimmen
HNSW (Hierarchical Navigable Small World) ist der Standard-Graph-Index in Qdrant, Milvus und Weaviate. Er baut mehrere Ebenen von Nachbarschafts-Graphen und traversiert von grob nach fein. Drei Parameter steuern das Verhalten, und sie hängen alle am gleichen Trade-off-Dreieck: Recall gegen Latenz gegen Speicher. Man kann zwei davon optimieren, das dritte zahlt.
M ist die maximale Anzahl an Kanten pro Knoten. Default in Qdrant und Milvus ist 16, sinnvoller Bereich 4 bis 64. Ein höheres M macht den Graph dichter, verbessert Recall und Robustheit, kostet aber linear RAM (jede Kante ist ein Zeiger) und verlängert die Build-Zeit. Für Embeddings mit 768 bis 1536 Dimensionen fahren wir meist M zwischen 16 und 32. Über 48 gibt es selten noch messbaren Recall-Gewinn, nur mehr Speicherverbrauch.
ef_construction (in Qdrant ef_construct) ist die Beam-Breite beim Bauen: wie viele Kandidaten pro Einfügung geprüft werden. Default 64, Bereich 32 bis 500. Höher heißt besserer Graph und höherer Recall, aber der Index-Build wird spürbar langsamer. Das ist eine Einmal-Kosten pro Build, keine Query-Kosten, deshalb darf man hier großzügiger sein: 128 bis 256 ist bei uns Standard für Produktions-Collections.
ef_search (in Qdrant hnsw_ef, in Milvus ef) ist die Beam-Breite zur Query-Zeit. Das ist der einzige der drei Parameter, den Sie pro Request ändern können, ohne neu zu bauen. Default liegt bei 64 bis 100. Für Recall über 0,97 empfiehlt Milvus, ef von 100 auf 256 anzuheben. Genau hier liegt der größte Hebel im Alltag: ef_search ist Ihr Latenz-Recall-Regler zur Laufzeit.
Vergleichstabelle: Parameter x Wirkung
Unsere klare Empfehlung: Fassen Sie M und ef_construction einmal sauber an und lassen Sie sie dann in Ruhe. Der laufende Betrieb wird über ef_search gesteuert, weil er als einziger ohne Rebuild wirkt.
Praxis: eine HNSW-Config, die in Produktion hält
Am konkretesten wird es im Code. Der folgende Qdrant-Config-Block (getestet mit Qdrant 1.18, Stand Juli 2026) zeigt eine Collection für 1536-dimensionale Embeddings, ausgelegt auf Recall über 0,95 bei kontrollierter Latenz. Die Kommentare erklären, warum welcher Wert steht.
from qdrant_client import QdrantClient
from qdrant_client.models import (
Distance, VectorParams, HnswConfigDiff,
ScalarQuantization, ScalarQuantizationConfig, ScalarType,
)
client = QdrantClient(url="http://localhost:6333")
client.create_collection(
collection_name="wissensbasis",
vectors_config=VectorParams(
size=1536,
distance=Distance.COSINE,
),
# HNSW-Graph: dichter als Default, weil Recall vor Build-Zeit steht
hnsw_config=HnswConfigDiff(
m=32, # 32 Kanten pro Knoten (Default 16), mehr Recall
ef_construct=200, # Beam-Breite beim Bauen, einmalige Kosten
full_scan_threshold=10000, # kleine Segmente: brute-force statt HNSW
),
# Scalar-Quantisierung: int8 statt float32, viertelt den RAM-Bedarf
quantization_config=ScalarQuantization(
scalar=ScalarQuantizationConfig(
type=ScalarType.INT8,
quantile=0.99, # Ausreißer kappen, schützt Recall
always_ram=True, # quantisierte Vektoren im RAM halten
),
),
)Zur Query-Zeit setzen Sie ef_search bewusst pro Anfrage. So können Sie für einen teuren Analyse-Job hohen Recall fahren und für einen interaktiven Chatbot niedrige Latenz:
from qdrant_client.models import SearchParams, QuantizationSearchParams
treffer = client.query_points(
collection_name="wissensbasis",
query=frage_embedding, # Liste mit 1536 float-Werten
limit=8,
search_params=SearchParams(
hnsw_ef=256, # hoher Recall für diese Anfrage
quantization=QuantizationSearchParams(
rescore=True, # Rescoring gegen Originalvektoren gegen Recall-Verlust
oversampling=2.0,# doppelt so viele Kandidaten vor dem Rescoring
),
),
)Der Trick mit rescore=True und oversampling ist wichtig: Quantisierung allein kostet Recall, aber wenn Sie mehr Kandidaten grob (quantisiert) vorfiltern und die Top-Treffer gegen die Originalvektoren nachrechnen, holen Sie den Recall fast vollständig zurück. Genau dieses Muster brauchen Sie, um RAM zu sparen, ohne die Antwortqualität zu verlieren. Die offizielle Referenz dazu steht in der Qdrant Quantization-Dokumentation.
Quantisierung: der Hebel gegen die RAM-Rechnung
Quantisierung ist 2026 der wichtigste Skalierungs-Hebel, weil RAM die teuerste Ressource in jeder Vektor-DB ist. Rohe float32-Vektoren mit 1536 Dimensionen kosten pro Vektor rund 6 KB. Bei 100 Mio Vektoren sind das etwa 600 GB, nur für die Embeddings. Quantisierung komprimiert das um Faktor 4 bis 32, und die Tool-Hersteller haben hier zuletzt stark aufgeholt.
Es gibt drei Verfahren, die Sie kennen sollten. Scalar-Quantisierung (int8) viertelt den Speicher bei minimalem Recall-Verlust und ist der sichere Default für die meisten Fälle. Product-Quantisierung (PQ) komprimiert stärker, kostet aber mehr Recall und Rechenzeit. Binary-Quantisierung presst jede Dimension auf ein Bit, spart bis zu 32x RAM und funktioniert gut bei hochdimensionalen Embeddings ab 1024 Dimensionen, braucht aber zwingend Rescoring.
Qdrant 1.18 „TurboQuant“ (Release 11. Mai 2026) hat das Feld verschoben: Das Verfahren wendet eine Hadamard-Rotation auf die Vektoren an, verteilt die Varianz gleichmäßig über die Koordinaten und funktioniert dadurch über verschiedene Embedding-Modelle hinweg ohne datensatz-spezifisches Nachtunen. Auf der Milvus-Seite bringt Milvus 2.6 (GA auf Zilliz Cloud seit 20. Januar 2026) mit RaBitQ eine 1-Bit-Quantisierung plus SQ8-Refinement, die laut Zilliz 95% Recall bei einem Viertel des Speicherbedarfs hält.
Unser Rat: Starten Sie mit Scalar-int8 und Rescoring. Das ist der beste Kompromiss aus Aufwand und Ergebnis. Binary-Quantisierung lohnt erst, wenn RAM wirklich der Engpass ist und Sie das Rescoring sauber konfiguriert haben. Blind auf Binary umzustellen, ohne Rescoring, ist der schnellste Weg zu einem RAG-System, das plötzlich falsche Dokumente zurückgibt. Welche Embedding-Modelle sich dafür im deutschen Kontext eignen, haben wir separat für deutsche Embedding-Modelle wie BGE und E5 durchgerechnet.
Sharding: horizontal skalieren, wenn ein Node nicht mehr reicht
Sharding partitioniert die Collection auf mehrere Nodes, sobald ein einzelner Rechner an Kapazität oder Durchsatz scheitert. Qdrant skaliert im Cluster-Modus auf Milliarden Vektoren über konfigurierbare Shards; Milvus ist von Grund auf für verteilte Milliarden-Skalen gebaut und trennt Query-, Index- und Data-Nodes, was horizontales Skalieren einzelner Schichten erlaubt. Der Preis ist immer der gleiche: mehr Betriebs-Komplexität.
Zwei Sharding-Strategien sind relevant. Bei Auto-Sharding verteilt die DB die Vektoren per Hash gleichmäßig, jede Query fächert über alle Shards aus (Scatter-Gather). Das ist der einfache Weg und richtig, solange Sie keine natürliche Partition haben. Bei Custom-Sharding legen Sie einen Shard-Key fest, etwa Mandant oder Region, sodass eine Query nur den relevanten Shard trifft. Das spart massiv Latenz und ist bei Multi-Tenant-Szenarien fast immer die bessere Wahl.
Ein Fallstrick, den wir oft sehen: Zu viele Shards machen Scatter-Gather-Queries langsamer, nicht schneller, weil jede Query auf die langsamste Shard-Antwort wartet (Tail-Latenz). Faustregel aus unseren Projekten: So wenige Shards wie möglich, so viele wie für Kapazität und Durchsatz nötig. Bei Custom-Sharding mit sauberem Shard-Key können Sie oft mit deutlich weniger Shards auskommen als bei blindem Auto-Sharding. Qdrant 1.16 (19. November 2025) hat mit Tiered Multitenancy zusätzlich die Option gebracht, kleine und große Mandanten in einer Collection zu mischen und wachsende Tenants auf dedizierte Shards zu heben.
Für regulierte Kunden ist Sharding zudem ein Souveränitäts-Thema: Wo liegen welche Shards, und wie garantieren Sie Datentrennung zwischen Mandanten? Das gehört in die Architektur, nicht in den Betrieb nachgereicht. Wie wir das für Enterprise-Setups aufsetzen, zeigt unser Angebot für Advanced RAG Knowledge Bots.
Häufig gestellte Fragen
Was kostet es, eine Vektor-DB für Produktion zu skalieren?
Das hängt fast vollständig am RAM, nicht an Lizenzkosten (Qdrant und Milvus sind Open Source). Ein Single-Node für 50 Mio Vektoren mit Scalar-Quantisierung läuft auf einer Instanz für rund 800 bis 1.500 EUR pro Monat. Ein gesharderter Cluster für Milliarden Vektoren startet eher bei 5.000 EUR pro Monat aufwärts. Quantisierung ist der größte Kostenhebel, weil sie den RAM-Bedarf direkt viertelt bis 32-telt.
HNSW oder IVF: welcher Index für große Collections?
Für Datensätze unter 50 Mio Vektoren ist HNSW fast immer die richtige Wahl, weil es das beste Verhältnis aus Recall und Latenz liefert. IVF (und Varianten wie IVF_RABITQ in Milvus 2.6) wird interessant, wenn Sie in den Milliarden-Bereich gehen und Speicher wichtiger ist als die letzten Prozentpunkte Recall. In der Praxis fahren die meisten Enterprise-RAG-Systeme mit HNSW plus Quantisierung.
Wie hoch sollte ich ef_search setzen?
Fangen Sie beim Default (64 bis 100) an und heben Sie in Schritten an, während Sie Recall auf einem Ground-Truth-Set messen. Für Recall über 0,97 brauchen Sie meist 200 bis 256. Sobald der Recall-Zuwachs pro Latenz-Millisekunde flach wird, haben Sie den Sweet Spot. Der Wert ist pro Anfrage setzbar, Sie können also unterschiedliche Profile für Batch- und Interaktiv-Queries fahren.
Verliere ich durch Quantisierung viel Genauigkeit?
Mit Scalar-int8 und aktiviertem Rescoring liegt der Recall-Verlust meist unter einem Prozentpunkt, oft nicht messbar. Ohne Rescoring kann Binary-Quantisierung den Recall deutlich drücken. Die Regel: Je aggressiver die Kompression, desto wichtiger das Rescoring gegen die Originalvektoren. Testen Sie immer gegen ein eigenes Ground-Truth-Set, nicht gegen Hersteller-Benchmarks.
Ab wann sollte ich sharden statt nur zu tunen?
Sharden Sie erst, wenn der Index nicht mehr auf eine sinnvoll bezahlbare Maschine passt (grob ab 384 GB RAM-Bedarf) oder ein Node den nötigen Query-Durchsatz nicht liefert. Darunter lösen Sie fast alle Latenz- und Recall-Probleme über HNSW-Parameter und Quantisierung. Verfrühtes Sharding kauft Ihnen nur Betriebs-Komplexität, ohne ein reales Problem zu lösen.
Nächster Schritt
Wenn Sie gerade an der Schwelle stehen, wo Ihr RAG-System langsamer wird oder der RAM ausgeht: Bringen Sie Ihre Zahlen mit (Vektor-Anzahl, aktuelle Latenz, Recall-Ziel), und wir sagen Ihnen in einem Call, ob Tuning reicht oder Sharding nötig ist.
Verwandte Themen
→RAG-Qualität in fünf Stufen von Prototyp bis Produktion
→Qdrant on-premise sauber installieren
