Hoeveel vectoropslag is er nodig voor één miljoen chunks van thuisdocumenten?

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

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.

-15% OFF
Single board computer zimaboard2

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

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.