Voor één miljoen chunks is ongeveer 1,5–6,1 GB nodig voor alleen de gebruikelijke float32-vectoren, vóór grafiekindexen, metadata, tekst, replica’s en werkruimte.
De berekening begint bij de dimensies, niet bij het aantal documenten: één miljoen vectoren met 768 dimensies bevatten 768 miljoen vierbytewaarden, oftewel ongeveer 3,07 GB in decimale eenheden. Een inzetbare opslag is groter, omdat vectoren moeten worden geïdentificeerd, efficiënt doorzocht, van metadatafilters voorzien en van chunktekst worden opgeslagen. Daarnaast moet de opslag indexonderhoud kunnen uitvoeren tijdens zowel zoek- als onderhoudsactiviteiten op de server.
Ruwe vectorbytes vormen de reproduceerbare ondergrens
Vermenigvuldig het aantal chunks met het aantal embeddingdimensies en het aantal bytes per coördinaat. Voor één miljoen float32-vectoren gebruiken 384 dimensies 1,536 GB, 768 dimensies 3,072 GB en 1.536 dimensies 6,144 GB. Binaire gigabytes lijken in de weergegeven eenheden ongeveer zeven procent kleiner.
Een overzicht van schaling laat dezelfde relatie voor ruwe vectoropslag zien: het aantal dimensies vermenigvuldigd met de waardebreedte bepaalt de coördinaatpayload vóór databasestructuren worden meegerekend.
Float16 kan het vectoronderdeel halveren en int8 of productkwantisatie kan het verder verkleinen. Compressie kan de recall beïnvloeden en vereist ondersteuning door de database. De brondocumenten en gegenereerde chunktekst zijn niet in deze cijfers inbegrepen.
Indexen en metadata kunnen de coördinaten evenaren
Een vlakke zoekopdracht voegt relatief weinig indexstructuur toe, maar scant veel vectoren. HNSW slaat buurverbindingen en meerdere grafieklagen op om het zoekwerk te beperken. Vector-ID’s, verwijderde-recordtombstones, filters, uitlijning en databasepagina’s zorgen voor extra overhead.
Een introductie tot HNSW-connectiviteit beschrijft waarom grafiekconnectiviteit approximate search versnelt en tegelijk extra geheugen en opslag gebruikt. Het geconfigureerde aantal buren verandert die kosten rechtstreeks.
Metadata varieert nog sterker. Een compacte document-ID en taalcode kunnen tientallen bytes toevoegen; herhaalde paden, machtigingen en volledige chunktekst kunnen honderden of duizenden bytes toevoegen. Sla tekst consequent één keer of in de vectordatabase op voordat je totalen vergelijkt.
Wanneer één opslagraming tekortschiet
Een praktisch planningsbereik voor één miljoen chunks met 768-dimensionale float32-vectoren is vaak 5–12 GB voor vectoren plus een approximate index, vóór omvangrijke tekst en replica’s. Dit is een budgetteringsbereik, geen garantie voor een specifiek formaat.
Een vergelijking van vectorarchitecturen raamt HNSW-opslago overhead die bij sommige HNSW-configuraties aanzienlijk groter is dan de ruwe coördinaten. Engine-standaardwaarden en grafiekparameters bepalen de werkelijke vermenigvuldigingsfactor.
Het bereik schiet tekort bij meerdere embeddings per chunk, hybride trefwoordindexen, replicatie, snapshots of rebuilds waarbij gegevens tijdelijk worden gedupliceerd. Het kan ook een gecomprimeerde, op schijf gebaseerde opslag overschatten. “Eén miljoen chunks” is onvoldoende tenzij dimensie, dtype, index, metadata en aantal kopieën worden vermeld.
Extrapoleer vanuit een indexproef van tien procent
Voeg 100.000 representatieve chunks toe met het uiteindelijke embedding-dtype, metadataschema en de indexparameters. Meet de onbewerkte vector kolom, index, metadata, tekst, write-ahead-log en snapshotbytes afzonderlijk na compactie. Extrapoleer schaalbare onderdelen met een factor tien en voeg marge toe voor rebuilds en back-ups.
Voer de test uit op de beoogde opslagwerkruimte-opslaglaag, omdat compressie en bestandssysteemtoewijzing de fysieke totalen beïnvloeden. Extrapoleer niet vanuit lege databasebestanden.
Reserveer minimaal het gemeten stabiele totaal plus één tijdelijke indexkopie en 20 procent vrije ruimte. Als replicatie is ingeschakeld, vermenigvuldig dan alleen de gerepliceerde onderdelen. Herhaal de proef telkens wanneer dimensies, metadata of HNSW-instellingen voor het aantal buren veranderen.
Tech & AI HUB
Meer om te lezen

Hoe je de kwaliteit van lokale RAG-opvragingen meet en recall, precisie en citatiedekking interpreteert
Bouw een lokale RAG-testset, bereken de belangrijkste retrievalmetrics, interpreteer de afwegingen ertussen en controleer of beweringen in antwoorden worden ondersteund door aangehaald bewijs.

Waarom wordt computation in smart homes belangrijker naarmate het aantal sensoren toeneemt bij dezelfde bemonsteringsfrequentie?
Houd de berekeningen per sensor en tussen sensoren bij naarmate het aantal apparaten toeneemt, identificeer niet-lineaire fusiekosten en benchmark de functiepijplijn voordat automatiseringen vertraging...

Waarom worden de kosten van RAG-evaluatie belangrijker naarmate de documentbibliotheek groeit bij hetzelfde aantal zoekopdrachten?
Begrijp waarom groei van het corpus de evaluatie-inspanning voor RAG verhoogt zonder meer gebruikersvragen, en hoe gestratificeerde tests de kosten aan het risico koppelen.

