Vektordatenbank-Dimensionierungs- und Auswahlrechner

Die praktische Frage hinter einer selbst gehosteten Vektordatenbank für RAG ist, welche Engine auf einen bestimmten Server passt und welche die Arbeitslast ausschließt. Der folgende Rechner beantwortet beides, basierend auf unserem Benchmark von sieben selbst gehosteten Vektordatenbanken, die mit angeglichenem Recall auf identischen Embeddings getestet wurden.

Erläuterung der Rechner-Metriken

Fünf Kontrollkästchen oben im Rechner benennen fünf gängige RAG-Arbeitslasten, und jedes entspricht einem gemessenen Grenzwert aus dem Benchmark, nicht einer Herstellerangabe. Ein gesetztes Häkchen filtert die Engine-Liste anhand einer bestimmten Zahl. Bleibt es deaktiviert, findet die Arbeitslast keine Anwendung und keine Engine wird danach gefiltert. Was jeder Schalter abfragt und die Messung dahinter:

Auswahl und Dimensionierung

Zwei Entscheidungen gehen einem laufenden Index voraus. Die erste ist die Auswahl, denn manche Engines können eine bestimmte Aufgabe nicht erfüllen. Der Rechner prüft jede Engine gegen die fünf oben genannten Anforderungsschalter und verwirft diejenigen, die scheitern. Die zweite ist die Dimensionierung, also welche der verbleibenden Engines auf die Maschine passen und mit welchem Spielraum. Für jeden Überlebenden meldet er passt, knapp oder passt nicht, zuzüglich der Anzahl der Vektoren, die der Server aufnehmen würde. Keine der beiden Entscheidungen hängt von der Retrieval-Qualität ab, denn die sieben Engines liegen innerhalb einer 0,014 nDCG-Spanne gegenüber einem exakten kNN-Orakel gleichauf.

Speicherbedarf bei 2,25 Mio. Vektoren

Bei 2,25 Mio. Vektoren maß der Benchmark zwei Speicherbedarfe, aufgeteilt danach, wo der Index liegt. Für die fünf In-Memory-Engines zeichnete er den Spitzen-RAM während Aufbau und Betrieb auf, von 17,0 GB (Milvus) bis 62,4 GB (Chroma). Für die zwei On-Disk-Engines zeichnete er den Index auf der Festplatte auf, 12,0 GB für LanceDB und 18,4 GB für pgvector, was pro Gigabyte deutlich günstiger ist. Diese Zahlen sind die Rohmessungen, nicht die Dimensionierungseingaben des Rechners. Der Rechner dimensioniert stattdessen den stationären Betrieb.

Für die In-Memory-Engines liegt dieser unter dem Aufbau-und-Betrieb-Spitzenwert, und für die On-Disk-Engines addiert er die Tabellenkopie und den Chunk-Text zusätzlich zum gemessenen Index, sodass seine Zahlen für denselben 2,25 Mio.-Korpus im RAM niedriger und auf der Festplatte höher ausfallen als die Balken hier. Die unten stehende Aufteilung gemessen versus modelliert gleicht beides ab. Der vollständige Pro-Engine-Benchmark hinter dem Rechner, über Genauigkeit, Geschwindigkeit, gefilterte und hybride Suche, Aufbaukosten und laufende Fluktuation hinweg, finden Sie im Open-Source-Vektordatenbank-Vergleich.

Das Dimensionierungsmodell

Die Eingaben sind die Korpusgröße, die Aufteilung in Chunks und das Embedding-Modell, und der Rechner leitet die zwei Zahlen ab, die Dimensionierung bestimmen. Korpusgröße und Chunking ergeben die Vektoranzahl. Ein 2-GB-Korpus (dezimal, 2 Milliarden Bytes) bei 4 Bytes pro Token entspricht 500 Mio. Token, und 512-Token-Chunks mit 15 % Überlappung schreiten mit einem Schritt von 512 × 0,85 = 435,2 Token voran, sodass die Anzahl round(500 Mio. ÷ 435,2) = 1.148.897 Vektoren beträgt. Das Embedding-Modell liefert die Dimension, daher ist die Eingabe eine Modellwahl, keine rohe Zahl, und bge-m3 setzt sie auf 1024.

Der Speicherbedarf jeder Engine ist dann ein Pro-Vektor-Kostenwert multipliziert mit der Vektoranzahl, zuzüglich eines festen Prozess-Sockels: footprint = base_gb + bytes_per_vector × N. Der Pro-Vektor-Kostenwert ist der Punkt, an dem die Engines auseinandergehen, denn eine Vektordatenbank speichert mehr als nur den rohen Vektor. Sie enthält auch den Indexgraphen, der die Suche beschleunigt, und, für echtes RAG, den Chunk-Text, den sie zurückgeben muss. Die folgende Tabelle zeigt die Pro-Vektor-Kosten, die das Speicherlayout jeder Engine bei 1024 Dimensionen in float32 erzeugt.

Zwei Layout-Fakten bewirken den Großteil der Trennung. Redis behält eine zweite Kopie jedes Vektors (ein Quell-Hash plus eine Kopie im Index) und kann den Chunk-Text nicht auslagern, daher ist es das schwerste im RAM. pgvector speichert jeden Vektor ebenfalls zweimal auf der Festplatte, einmal im Tabellen-Heap und einmal innerhalb des HNSW-Index, und sein Index rundet auf 8 KB Postgres-Seiten auf, sodass ein 1024-dimensionaler float32-Vektor eine ganze Seite für sich allein füllt. Die vier anderen In-Memory-Engines lagern den Chunk-Text auf die Festplatte aus, sodass ihre RAM-Kosten der Vektor plus ein kleiner Graph sind. Der Schalter Chunk-Text speichern steuert diese Nutzlast, etwa 2 KB pro Vektor bei 512 Token. Redis hält sie im RAM, jede andere Engine behält sie auf der Festplatte, und das Ausschalten des Schalters entfernt sie überall.

Der Prozess-Sockel wird einmal pro Engine hinzugefügt: 2,0 GB für Milvus, 0,5 für Weaviate, 0,3 für Chroma, 0,2 für Qdrant, 0,05 für Redis und 0 für die beiden On-Disk-Engines. Zusammengesetzt für den standardmäßigen 2-GB-Korpus (1,15 Mio. Vektoren) auf einem 16 GB, 200 GB Server benötigt Qdrant 5,1 GB RAM, Milvus und Weaviate 6,9 GB, Redis 12,5 GB, während pgvector 16,5 GB Festplatte und LanceDB 8,5 GB benötigt.

Das Urteil vergleicht diesen Speicherbedarf mit der Maschine auf der bindenden Ressource, und die 80 %-Linie ist bewusster Spielraum. Bei oder unter 80 % des RAM oder der Festplatte liest es passt, was etwa ein Fünftel der Maschine für den OS-Seiten-Cache, Abfragepuffer und Wachstum übrig lässt. Von 80 bis 100 % ist knapp, und mehr passt nicht. Die Zahl gilt für den stationären Betrieb, sodass das Aufbauen oder Neuaufbauen des Index auf derselben Maschine für die Dauer mehr RAM benötigt, näher am gemessenen Spitzenwert. Die gleiche Formel rückwärts angewendet ergibt die Kapazität, (box − base) ÷ bytes_per_vector: Derselbe 16 GB Server fasst nominal 1,47 Mio. Vektoren auf Redis, 3,7 Mio. auf Qdrant und, auf seiner 200 GB Festplatte, 14,0 Mio. auf pgvector und 27,1 Mio. auf LanceDB, jeweils innerhalb des Fehlerbands, das Tool daneben anzeigt, und nicht als harte Grenze. Das Einschalten der Quantisierung teilt den Vektoranteil (int8 durch 4x, Produktquantisierung durch 16x, binär durch 32x) für die Engines, die sie unterstützen, und das Wechseln des Embedding-Modells skaliert jede Zahl über die Dimension neu.

Gemessen versus modelliert

Der Rechner trennt, was der Benchmark gemessen hat, von dem, was er modelliert, da beide unterschiedliche Konfidenz tragen. Die RAM-Werte, die der Benchmark aufgezeichnet hat, sind ein Aufbau-und-Betrieb-Spitzenwert, der etwa zwei- bis dreimal höher liegt als der stationäre Betrieb, und für Weaviate wurde er durch ein hohes Go-Speicherlimit aufgebläht. Der Rechner dimensioniert nicht von diesem Spitzenwert aus. Er dimensioniert die fünf In-Memory-Engines nach der jeweils vom Hersteller dokumentierten Betriebsformel, den additiven Vektor-plus-Graph-Kosten in der Tabelle, und behält den gemessenen Spitzenwert als Obergrenzen-Prüfung. Die Messung zeichnet also auf, was der Benchmark beobachtet hat, während die Dimensionierung absichtlich darunter liegt.

Bei den beiden On-Disk-Engines ist es umgekehrt. Ihr Festplatten-Index wurde direkt gemessen und auf einem zurückgehaltenen Korpus auf 1 bis 2 Prozent genau gehalten, daher dimensioniert der Rechner sie anhand der Messung. Jede Kapazität trägt ein sichtbares Fehlerband, das diese Aufteilung widerspiegelt: 25 bis 30 Prozent für die modellierten In-Memory-Betriebsschätzungen, 15 Prozent für pgvector und 1 bis 2 Prozent für LanceDBs gemessene Festplatte. Zwei Eingaben sind als Annahmen statt als Messungen gekennzeichnet. Der RAM-Cache für die On-Disk-Engines ist auf 25 Prozent des Index festgelegt und ist editierbar, da ihr Betriebs-RAM nie gemessen wurde, und die Quantisierungsverhältnisse stammen aus der Literatur und nicht aus diesem Benchmark, sodass der tatsächliche Recall-Verlust mit den Daten variiert.

Die Fähigkeitsschranke

Die Auswahlhälfte des Rechners ist ein Satz binärer Fakten, keine Punktzahl. Die folgende Tabelle ist die Pro-Engine-Seite der obigen Schalter. Für jede Engine zeigt sie die Arbeitslasten, die sie ausschließen, und diejenigen, die sie noch bewältigt, aber mit einer gekennzeichneten Rate. Milvus und Weaviate haben bei keinem Schalter einen Ausschluss, weshalb sie als die sauberen Generalisten dastehen.

Redis wird bei der Dauerhaftigkeit gekennzeichnet statt ausgeschlossen, weil es mit einer Append-Only-Datei absturzsicher gemacht werden kann. Es wurde mit deaktivierter Persistenz gebenchmarkt, daher vermerkt die Kennzeichnung, dass die Grenze unsere Konfiguration ist, nicht die Engine.

Verpassen Sie nicht unsere Benchmarks und datengestützten Erkenntnisse. Die Schaltfläche öffnet Google; die Auswahl von AIMultiple bestätigt, dass Sie AIMultiple häufiger in den Google-Suchergebnissen sehen möchten.

Als bevorzugte Quelle hinzufügen

Benchmark-Methodik

Die Zahlen stammen aus einem Einzelserver-Benchmark der sieben Engines, jede für sich in einem fest zugewiesenen Docker-Container auf einer Hetzner CCX53 (32 vCPU, 128 GB RAM, NVMe). Jede Engine indizierte dieselben bge-m3-Vektoren (1024-dim, Cosinus auf L2-normalisiertem float32) und wurde bei einem angeglichenen Recall@10 von 0,95 gelesen, erreicht durch Durchlaufen ihres ef oder nprobe, mit k=10 und Seed 42. Die Korpora waren MedRAG-50k und TechQA-28k für die Qualität und eine 2,25 Mio.-Vektor MedRAG-Stufe für die Skalierung. Die vollständigen Statistiken, Konfidenzintervalle und Pro-Engine-Versionen finden Sie im Benchmark-Artikel.

Einschränkungen

Die In-Memory-Betriebswerte sind Herstellerformeln, kalibriert gegen einen Aufbau-und-Betrieb-Spitzenwert, keine direkte Betriebsmessung, daher tragen sie das 25- bis 30-Prozent-Band, das der Rechner anzeigt. Der Betriebs-RAM für pgvector und LanceDB ist eine ungemessene Cache-Annahme, weshalb der Rechner diese beiden auf der Festplatte dimensioniert. Die Deployment-Formen unterscheiden sich ebenfalls konstruktionsbedingt. LanceDB ist eine eingebettete Bibliothek, pgvector ist eine PostgreSQL-Erweiterung, die anderen fünf sind eigenständige Server, und Redis lief mit deaktivierter Persistenz, sodass der Speicherbedarf und die Raten jeder Engine ihre eigene Betriebsform widerspiegeln und nicht eine identische Konfiguration. Der Benchmark verwendete ein Embedding-Modell mit 1024 Dimensionen, sodass ein anderes Modell oder eine andere Dimensionszahl jeden Speicherbedarf verschiebt, weshalb das Modell eine Eingabe und keine feste Zahl ist. Verwaltete und cloudgehostete Engines sind ein separater Vergleich.

Weiterführende Lektüre

• Embedding-Modelle Benchmark
• Reranker Benchmark
• Vektordatenbank für RAG
• Open-Source-Embedding-Modelle
• Mehrsprachige Embedding-Modelle
• Multimodale Embeddings
• Agentic RAG Frameworks

Zitieren Sie diesen Benchmark

Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Vektordatenbank-Dimensionierungs- und Auswahlrechner}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/vector-database-for-rag}},
  note   = {AIMultiple. Abgerufen am 20. Juli 2026}
}

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher und Datenanalyst bei AIMultiple. Er entwirft und führt praxisnahe Benchmarks für KI- und LLM-Systeme durch.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten