Wie viel Vektorspeicher benötigen eine Million Dokumentabschnitte aus dem privaten Zuhause?
Eine Million Chunks benötigen allein für gängige Float32-Vektoren ungefähr 1,5–6,1 GB – noch ohne Graph-Indizes, Metadaten, Text, Replikate und Arbeitsbereich.
Die Berechnung beginnt mit den Dimensionen, nicht mit der Dokumentanzahl: Eine Million 768-dimensionale Float32-Vektoren enthalten 768 Millionen Vier-Byte-Werte, also etwa 3,07 GB im Dezimalsystem. Ein einsetzbarer Speicher ist größer, da er Vektoren identifizieren, effizient durchsuchen, Metadaten filtern, Chunk-Text speichern und die Indexwartung während der Such- und Wartungsvorgänge auf dem Server bewältigen muss.
Rohe Vektor-Bytes bilden die reproduzierbare Untergrenze
Multiplizieren Sie die Chunk-Anzahl mit den Embedding-Dimensionen und den Bytes pro Koordinate. Bei einer Million Float32-Vektoren benötigen 384 Dimensionen 1,536 GB, 768 Dimensionen 3,072 GB und 1.536 Dimensionen 6,144 GB. Binäre Gigabytes erscheinen in der Anzeige etwa sieben Prozent kleiner.
Eine Übersicht zur Skalierung zeigt dieselbe Beziehung beim rohen Vektorspeicher: Die Anzahl der Dimensionen multipliziert mit der Wertbreite bestimmt die Koordinaten-Nutzdaten vor den Datenbankstrukturen.
Float16 kann die Vektorkomponente halbieren, und Int8 oder Produktquantisierung kann sie weiter reduzieren. Komprimierung kann den Recall beeinflussen und erfordert Unterstützung durch die Datenbank. Die Quelldokumente und der generierte Chunk-Text sind in diesen Zahlen nicht enthalten.
Indizes und Metadaten können mit den Koordinaten mithalten
Eine flache Suche fügt vergleichsweise wenig Indexstruktur hinzu, durchsucht jedoch viele Vektoren. HNSW speichert Nachbarverknüpfungen und mehrere Graph-Ebenen, um den Suchaufwand zu reduzieren. Vektor-IDs, Löschmarkierungen, Filter, Ausrichtung und Datenbankseiten verursachen zusätzlichen Overhead.
Eine Einführung in die HNSW-Konnektivität erläutert, warum Graph-Konnektivität die ungefähre Suche beschleunigt, dabei aber zusätzlichen Arbeitsspeicher und Speicherplatz benötigt. Die konfigurierte Anzahl der Nachbarn verändert diese Kosten direkt.
Metadaten unterscheiden sich noch stärker. Eine kompakte Dokument-ID und ein Sprachcode können einige Dutzend Bytes hinzufügen; wiederholte Pfade, Berechtigungen und vollständiger Chunk-Text können Hunderte oder Tausende Bytes ausmachen. Speichern Sie Text konsequent einmalig oder innerhalb der Vektordatenbank, bevor Sie Gesamtsummen vergleichen.
Wann eine einzelne Speicherschätzung scheitert
Ein praktischer Planungsbereich für eine Million 768-dimensionale Float32-Chunks liegt häufig bei 5–12 GB für Vektoren plus einen ungefähren Index, noch ohne umfangreichen Text und Replikate. Dies ist ein Budgetierungsbereich, keine Garantie für ein bestimmtes Format.
Ein Vergleich von Vektorarchitekturen schätzt einen HNSW-Speicher-Overhead, der bei einigen HNSW-Konfigurationen die rohen Koordinaten deutlich übersteigt. Engine-Standards und Graph-Parameter bestimmen den tatsächlichen Multiplikator.
Die Spanne versagt bei mehreren Embeddings pro Chunk, hybriden Keyword-Indizes, Replikation, Snapshots oder Neuaufbauten, bei denen Daten vorübergehend doppelt vorhanden sind. Ein komprimierter, festplattenbasierter Speicher kann dadurch auch überschätzt werden. „Eine Million Chunks“ reicht nicht aus, wenn Dimension, Datentyp, Index, Metadaten und Kopienanzahl nicht genannt werden.
Hochrechnung aus einer zehnprozentigen Indexstichprobe
Fügen Sie 100.000 repräsentative Chunks mit dem endgültigen Embedding-Datentyp, Metadatenschema und den Indexparametern ein. Messen Sie nach der Komprimierung die Größen der rohen Vektorspalte, des Index, der Metadaten, des Texts, des Write-Ahead-Logs und der Snapshots separat. Hochskalierbare Komponenten werden mit zehn multipliziert; berücksichtigen Sie zusätzlich Reserven für Neuaufbau und Backups.
Führen Sie den Test auf der vorgesehenen Speicher-Arbeitsebene durch, da Komprimierung und Dateisystemzuweisung die physischen Gesamtsummen beeinflussen. Vermeiden Sie Hochrechnungen aus leeren Datenbankdateien.
Planen Sie mindestens die gemessene Gesamtsumme im Dauerbetrieb plus eine temporäre Indexkopie und 20 Prozent freien Speicherplatz ein. Wenn Replikation aktiviert ist, multiplizieren Sie nur die replizierten Komponenten. Wiederholen Sie die Stichprobe, sobald sich Dimensionen, Metadaten oder HNSW-Nachbareinstellungen ändern.
Empfohlene Produkte
Tech- & KI-Zentrum
Mehr zum Lesen
So messen Sie die lokale RAG-Abrufqualität und interpretieren Recall, Precision und Zitatabdeckung
Erstellen Sie einen lokalen RAG-Testsatz, berechnen Sie zentrale Retrieval-Metriken, interpretieren Sie deren Zielkonflikte und prüfen Sie, ob die Antwortaussagen durch die zitierten Belege gestützt...
Warum wird die Berechnung von Smart-Home-Funktionen bei gleicher Abtastrate wichtiger, je mehr Sensoren vorhanden sind?
Verfolge die Berechnungen pro Sensor und über mehrere Sensoren hinweg, während die Anzahl der Geräte steigt, ermittle nichtlineare Fusionskosten und benchmarke die Feature-Pipeline, bevor...
Warum werden die Kosten der RAG-Evaluierung bei gleichbleibender Abfragezahl wichtiger, je größer die Dokumentbibliothek wird?
Verstehen Sie, warum das Wachstum des Korpus den Bewertungsaufwand für RAG ohne zusätzliche Nutzeranfragen erhöht und wie geschichtete Tests die Kosten an das Risiko...
