Varför behöver RAG så mycket RAM?

Snabb vektorsökning vill ha indexet resident i minnet. Varje dokument-chunk blir en embedding — en vektor av ett par hundra till ett par tusen floats — och vid miljoner chunks adderas det. Tryck indexet till disk och sök-latens hoppar; att behålla hela anledningen till att du self-hostade (hastighet + kontroll) betyder att behålla det i RAM.

Hur mycket RAM för ett givet corpus?

Grov känsla: ett par hundratusen embeddings sitter fint i 2–4 GB. Låga miljoner, med appen och OS:et runt dem, och du är på 16–32 GB. Tiotals miljoner eller hög-dimension vektorer och du är på 48–80 GB, och därutöver delar du över servrar. Dimension och index-typ svänger detta mycket, så mät ditt eget.

pgvector eller en dedikerad engine som Qdrant?

Om du redan kör Postgres är pgvector minsta-ansträngnings-vägen — en extension, en databas. För miljoner vektorer med tung filtrering förtjänar en purpose-built engine sin separata tjänst. Börja med vad du redan driver; flytta bara när sökning blir långsam.

Varför self-hosta istället för en managed vektor-tjänst?

Två verkliga skäl: dina embeddings encoderar ofta privat data (docs, anteckningar, kund-content), och self-hosting håller det på en server du kontrollerar. Och det är platt kostnad — managed tjänster mäter per vektor och query, en VPS är ett månadstal utan per-query-räkning.

Self-hostad RAG i skala: hur mycket RAM ett vektorindex verkligen äter

Varje RAG-tutorial körs på en laptop med ett par hundra dokument, och det känns ansträngningslöst. Sedan riktar du det mot ett riktigt corpus — ett företags docs, år av tickets, en knowledge base — och plötsligt är minnet hela samtalet.

RAG skalar inte genom CPU. Det skalar genom RAM.

Varför indexet vill ha minne

Retrieval fungerar genom att förvandla varje chunk av text till en embedding — en vektor, ett par hundra till ett par tusen nummer lång. Sökning betyder att jämföra din query-vektor mot alla dem, snabbt. "Snabbt" är det operativa ordet: för låg latens behöver indexet leva i RAM. På disk fungerar det, men varje query betalar ett straff, och låg-latens retrieval var poängen med self-hosting i första hand.

Så minnesräkningen skalar med två saker: hur många chunks du har, och hur bred varje vektor är.

Riktiga siffror, grovt

Mät ditt eget — dimension och index-typ flyttar detta mycket — men som startkänsla:

Ett par hundratusen embeddings — bekvämt i 2–4 GB. En personlig knowledge base, en enskild produkts docs.
Låga miljoner — med appen, model-klienten, och OS:et runt det, planera för 16–32 GB. Detta är en seriös företags-knowledge-base eller en multi-source RAG.
Tiotals miljoner, eller hög-dimension vektorer — nu är du på 48–80 GB, och därutöver över flera boxar. Stora dokument-egendomar, multi-tenant retrieval, eller så håller du flera index varma samtidigt.

Ett multi-agent-system som också håller ett stort index staplar båda kostnaderna på samma box — så förvandlas ett 32 GB-plan tyst till ett 64 GB-plan.

Engine-valet, kort

Om du redan kör Postgres är pgvector minsta-ansträngnings-alternativet — det är en extension, inte en ny tjänst att pyssla om. När du har miljoner vektorer och vill ha snabb filtrerad sökning förtjänar en dedikerad engine som Qdrant eller Weaviate den separata processen. Över-engineer det inte dag ett; kör vad du redan driver och dela ut det när sökning faktiskt saktar ner.

Varför bry sig om self-hosting

Två skäl folk faktiskt gör detta, och inget av dem är "för att spara ett par dollar":

Integritet. Embeddings är inte abstrakta — de encoderar texten de kom från. Dina docs, dina kunders content, dina interna anteckningar, förvandlade till vektorer och skeppade till en tredje parts servrar. Self-hosting håller det på en maskin du kontrollerar. Om datan är känslig nog att du också betalar i krypto utan KYC, upphäver ett managed vektor-moln hela poängen.

Platt kostnad. Managed vektor-tjänster fakturerar per vektor lagrad och query körd. En VPS är ett månadstal och du kan hamra det så hårt du vill. I skala slår förutsägbart mätt.

Vad detta betyder för dimensionering

Börja med att mäta ditt corpus, inte med att gissa. Ta ditt embedding-antal och dimension, ladda ett sample, titta på det resident minnet, extrapolera. Välj sedan ett plan med utrymme för indexet plus allt runt det — appen, model-klienten, utrymme att växa.

För något förbi ett par miljoner privat hållna vektorer kör Pro-linjen 32 till 80 GB med en dedikerad IP och nattliga säkerhetskopior, vilket spelar roll när indexet är produkten och att förlora det gör ont.