Waarom concurreren meerdere RAG-collecties om RAM op een thuisserver?
Meerdere RAG-collecties concurreren om RAM, omdat elke collectie zijn eigen vectoren, zoekgrafiek, metadata-indexen, caches en actieve werkset bijhoudt.
Een thuisserver kan familiedocumenten, technische handleidingen, fotometadata, werkaantekeningen en smarthomegeschiedenis voor privacy of betere zoekresultaten opsplitsen in verschillende RAG-collecties. De bronbestanden passen misschien ruimschoots op schijf, terwijl de zoeklaag veel meer geheugen verbruikt dan verwacht. Elke collectie kan een approximate-nearest-neighbor-index, payloadfilters, segmentmetadata, recent gebruikte pagina’s en querybuffers laden; embedding- en rerankingservices voegen naast die collecties hun eigen residente modellen toe.
Elke collectie creëert een afzonderlijke zoekstructuur
Een vectorcollectie is niet alleen een map met embeddings. Zoekmachines onderhouden doorgaans de vectorwaarden en een buurtschapsgraph of een andere structuur voor benaderend zoeken, zodat niet elk record hoeft te worden gescand.
Weaviate noemt vectoren en HNSW-grafieken als twee belangrijke geheugengebruikers in een approximate-nearest-neighbor-index die volledig in het geheugen staat.
Vijf collecties aanmaken kan dus betekenen dat er vijf onafhankelijk adresseerbare indexen zijn, zelfs wanneer ze hetzelfde embeddingmodel delen en binnen één databaseproces draaien. Scheiding verbetert beleid en onderhoud alleen wanneer het voordeel voor het ophalen van gegevens opweegt tegen de vermenigvuldigde werksets.
Dimensies en indexoverhead vermenigvuldigen de basisbehoefte
Het ruwe geheugengebruik van vectoren groeit mee met het aantal vectoren, de embeddingdimensies en het aantal bytes per component. De doorzoekbare index voegt daar grafiekverbindingen, identificatiegegevens, uitlijning, metadata en overhead van de geheugenallocator aan toe.
Milvus biedt een formule voor het geheugen van vectorindexen en merkt op dat een HNSW-implementatie aanzienlijk meer geheugen kan vereisen dan alleen de niet-geïndexeerde vectoren.
Schat elke collectie afzonderlijk en tel ze daarna bij elkaar op. Een collectie met minder documenten kan toch duur zijn wanneer deze hoogdimensionale embeddings, componenten met volledige precisie of een grafiek gebruikt die is afgestemd op een hoge recall.
Grafiekconnectiviteit ruilt RAM in voor recall en snelheid
HNSW koppelt elke vector aan naburige knooppunten. Meer verbindingen kunnen navigatie en recall verbeteren, maar elke opgeslagen verbinding gebruikt geheugen en maakt het opbouwen van de index duurder.
Redis legt uit hoe grafiekconnectiviteit wordt geregeld met parameters die de indexgrootte afwegen tegen recall en zoekgedrag.
Verschillende collecties kunnen dezelfde agressieve standaardinstellingen overnemen, ook als slechts één collectie die nodig heeft. Gebruik een profiel met lager geheugengebruik voor kleine archieven of collecties met weinig gelijktijdige toegang, in plaats van elke index af te stemmen op de zwaarste zoekbelasting.
Memory mapping verplaatst de druk naar de gedeelde paginacache
Vectoren of grafiekgegevens op schijf plaatsen met memory mapping kan de permanent residente geheugentoewijzing van het proces verminderen. Actieve pagina’s worden daardoor niet vrij; het besturingssysteem bewaart recent gebruikte indexblokken nog steeds in de RAM-cache.
De geheugervergelijking van Qdrant laat zien hoe vectoren via memory mapping het gemeten RAM-gebruik verlagen, terwijl er een afweging in latentie ontstaat doordat gegevens via de opslag worden opgehaald.
Wanneer queries tussen meerdere collecties springen, kunnen hun veelgebruikte pagina’s elkaar uit de paginacache verdringen. Diezelfde druk kan ook bestanden verdringen die door foto-apps, containers, databases en netwerkshares op de thuisserver worden gebruikt.
Indexen die groter zijn dan RAM betalen met meer opslag-I/O
Een index kan groter zijn dan het fysieke geheugen en toch doorzoekbaar blijven, maar een groter deel van elk zoekpad moet dan van de SSD worden gelezen. Willekeurige toegang en cachemissers worden daardoor onderdeel van de latentie bij het ophalen van resultaten.
PlanetScale beschrijft indexen die groter zijn dan RAM en waarbij een kleinere navigatiestructuur in het geheugen blijft, terwijl meer postings of vectorgegevens naar de opslag worden verplaatst.
Dit kan een goed compromis zijn voor een thuisserver wanneer zoekopdrachten af en toe plaatsvinden en de index op snelle SSD-opslag staat. Het is een slechte aanname wanneer meerdere collecties gelijktijdige queries ontvangen of een trage schijf delen met applicatiedatabases en mediabelastingen.
Dubbele opslag en afzonderlijke services voegen verborgen kopieën toe
Dezelfde embedding kan bestaan in een documentopslag, een vectorindex, een applicatiecache en een back-up- of stagingcollectie. Afzonderlijke containers kunnen identieke embedding- of rerankingmodellen bovendien in verschillende procesadresruimten laden.
De bespreking van Memgraph over het vermijden van dubbele vectoropslag laat zien waarom de indexarchitectuur bepaalt hoeveel geheugenkopieën van één doorzoekbaar record worden bijgehouden.
Het aantal collecties is dus slechts één onderdeel van het budget. Breng dubbele vectoren, oude indexversies, tijdelijke collecties voor herbouw, modelprocessen en gecachte resultaten in kaart voordat je concludeert dat alleen de vectordatabase verantwoordelijk is.
Consolideer collecties op basis van toegangsbeleid en werklast
Gebruik afzonderlijke collecties wanneer ze verschillende rechten, embeddingdimensies, bewaarbeleid, updateschema’s of foutisolatie vereisen. Alleen thematische labels vereisen niet altijd een afzonderlijke fysieke index.
Een gedeelde collectie met metadata voor tenant, eigenaar, bron of categorie kan één index hergebruiken, terwijl filters ervoor zorgen dat het ophalen binnen het bedoelde bereik blijft. Test de recall met filters vóór consolidatie, omdat een te grote gemengde collectie eigen kosten voor rangschikking en onderhoud kan introduceren.
De uitleg van ZimaSpace over waarom een lokale AI-runtime geheugen reserveert helpt bij het interpreteren van monitoring: vastgehouden pagina’s en caches kunnen herbruikbare werkstatus zijn in plaats van een lek, maar ze concurreren nog steeds met de rest van de server.
Stel een RAM-budget vast voordat je een collectie toevoegt
Noteer het aantal vectoren, de dimensies, precisie, het indextype, de grafiekinstellingen, de grootte van de metadata-index, het residente geheugen na opwarming en het piekgeheugen tijdens import en gelijktijdige queries. Meet de volledige stack, niet alleen het dashboard van de database.
Houd ruimte over voor het besturingssysteem, de paginacache, containers, databases, bestandsdeling en het lokale taalmodel. Als swapactiviteit of ernstige paginacachemissers toenemen wanneer een tweede collectie wordt bevraagd, passen de werksets niet meer comfortabel samen.
Verlaag dimensies of precisie waar recalltests dat toestaan, verminder de grafiekconnectiviteit, verplaats koude vectoren naar opslag via memory mapping, beperk gelijktijdige queries, laad ongebruikte modellen uit en verwijder verouderde collecties voordat je meer RAM aanschaft.
Veelgestelde vragen
Is één grote RAG-collectie altijd efficiënter qua geheugen?
Vaak wordt dubbele indexoverhead vermeden, maar er kunnen complexere filters nodig zijn en de kwaliteit van het ophalen kan afnemen wanneer niet-gerelateerde inhoud dezelfde rangschikkingsruimte deelt. Consolideer pas nadat je toegangsgrenzen en recall hebt getest.
Elimineert memory mapping de concurrentie om RAM?
Nee. Het vermindert permanent residente geheugentoewijzingen, maar actieve indexpagina’s nemen nog steeds ruimte in de paginacache van het besturingssysteem in en kunnen pagina’s verdringen die door andere collecties en apps worden gebruikt.
Waarom blijft het RAM-gebruik hoog nadat een RAG-query is beëindigd?
De database, geheugenallocator, het besturingssysteem of de modelruntime kan herbruikbare pagina’s en buffers vasthouden. Controleer of het geheugen bij latere queries opnieuw wordt gebruikt en of swap- of out-of-memory-druk ontstaat voordat je het als een lek bestempelt.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Waarom worden voorspellingen voor slimme woningen minder nauwkeurig nadat routines door seizoensveranderingen zijn gewijzigd?
Seizoensgebonden routines veranderen de relatie tussen tijd, sensoren, aanwezigheid en gewenste acties, waardoor een model dat op oudere gewoonten is getraind verouderd raakt.
Waarom mist een thuis-NVR korte gebeurtenissen wanneer objecttracking is ingeschakeld?
Tracking heeft voldoende detecties nodig om een traject te starten en te bevestigen. Daardoor kan een object kortstondig verdwijnen voordat de NVR een geldig...
Waarom veranderen AI-fotolabels na een modelupgrade?
Een modelupgrade verandert de representatie en rangschikking die worden gebruikt om labels toe te wijzen, waardoor dezelfde foto verschillende semantische of betrouwbaarheidsgrenzen kan overschrijden.
