Vektordatenbank Speicherbedarf berechnen

Wovon der Speicher abhängt

Den Vektordatenbank Speicherbedarf berechnet man im Kern mit Anzahl × Dimensionen × Bytes je Wert. Eine Million Embeddings mit 1.536 Embedding-Dimensionen in float32 belegen 1.000.000 × 1.536 × 4 Byte, also gut 6 GB. Dazu kommen Index-Overhead, IDs, Metadaten wie Quelltext oder Dateiname und gegebenenfalls Replikate für Ausfallsicherheit. Das Werkzeug rechnet alle Posten einzeln aus und zeigt, welcher Teil den Speicher dominiert.

HNSW (Hierarchical Navigable Small World) ist der verbreitetste Index in Qdrant, Weaviate, Milvus, pgvector und vielen anderen. Er speichert für jeden Vektor Verbindungen zu Nachbarn: in der untersten Ebene bis zu 2 × M, in höheren Ebenen bis zu M, jeweils als 4-Byte-Verweis. Bei M = 16 sind das gut 130 Byte je Vektor, bei kleinen Vektoren ein spürbarer Anteil. Die Berechnung folgt dem Speichermodell der Bibliothek hnswlib. IVF teilt die Vektoren in Listen um Zentren auf und braucht kaum Zusatzspeicher, ist aber bei gleicher Trefferquote meist langsamer.

Sparen lässt sich vor allem beim Format: float16 halbiert den Bedarf, int8 viertelt ihn, binäre Quantisierung braucht nur ein Zweiunddreißigstel. Product Quantization zerlegt jeden Vektor in Teilstücke und speichert je Stück nur die Nummer eines Codebuch-Eintrags, oft 32 bis 128 Byte je Vektor. Weil die Suchqualität dabei sinkt, behalten viele Systeme die float32-Originale auf der SSD und bewerten die besten Treffer damit neu (Rescoring). Was die Erzeugung der Embeddings kostet, berechnet der RAG-Kostenrechner.