Hvorfor har RAG brug for så meget RAM?

Hurtig vektorsøgning vil have indekset residerende i hukommelsen. Hver dokumentbid bliver en embedding — en vektor af nogle få hundrede til et par tusinde floats — og ved millioner af bidder lægger det op. Skub indekset til disk, og søgeforsinkelsen springer; at bevare hele grunden til, at du self-hostede (hastighed + kontrol), betyder at holde det i RAM.

Hvor meget RAM til et givet korpus?

Groft fornemmet: et par hundrede tusinde embeddings sidder fint i 2–4 GB. Lave millioner, med appen og OS'et omkring dem, og du er på 16–32 GB. Titusinder eller højdimensionelle vektorer, og du er oppe på 48–80 GB, og forbi det deler du på tværs af servere. Dimension og indekstype rykker meget på dette, så mål dit eget.

pgvector eller en dedikeret motor som Qdrant?

Hvis du allerede kører Postgres, er pgvector den mindst besværlige vej — én udvidelse, én database. Til millioner af vektorer med tung filtrering tjener en formålsbygget motor sin separate tjeneste. Start med det, du allerede driver; flyt kun, når søgning bliver langsom.

Hvorfor self-hoste i stedet for en managed vektortjeneste?

To reelle grunde: dine embeddings koder ofte private data (dokumenter, noter, kundeindhold), og self-hosting holder det på en server, du kontrollerer. Og det er flad omkostning — managed-tjenester måler efter vektorer og forespørgsler, en VPS er ét månedligt tal uden regning per forespørgsel.

Self-hostet RAG i stor skala: hvor meget RAM et vektorindeks reelt æder

Hver RAG-tutorial kører på en bærbar med et par hundrede dokumenter, og det føles ubesværet. Så peger du den mod et rigtigt korpus — en virksomheds dokumenter, års tickets, en videnbase — og pludselig er hukommelse hele samtalen.

RAG skalerer ikke efter CPU. Det skalerer efter RAM.

Hvorfor indekset vil have hukommelse

Genfinding virker ved at forvandle hver tekstbid til en embedding — en vektor, nogle få hundrede til et par tusinde tal lang. Søgning betyder at sammenligne din forespørgselsvektor mod dem alle, hurtigt. "Hurtigt" er det operative ord: for lav forsinkelse skal indekset bo i RAM. På disk virker det, men hver forespørgsel betaler en straf, og genfinding med lav forsinkelse var hele pointen med at self-hoste i første omgang.

Så hukommelsesregningen skalerer med to ting: hvor mange bidder du har, og hvor bred hver vektor er.

Rigtige tal, groft

Mål dit eget — dimension og indekstype rykker meget på dette — men som en startfornemmelse:

Et par hundrede tusinde embeddings — komfortabelt i 2–4 GB. En personlig videnbase, ét produkts dokumenter.
Lave millioner — med appen, modelklienten og OS'et omkring det, planlæg efter 16–32 GB. Det er en seriøs virksomhedsvidenbase eller en multi-kilde-RAG.
Titusinder, eller højdimensionelle vektorer — nu er du på 48–80 GB, og forbi det på tværs af flere bokse. Store dokumentbeholdninger, multi-tenant-genfinding, eller du holder flere indekser varme på én gang.

Et multi-agent-system, der også holder et stort indeks, stabler begge omkostninger på samme boks — det er sådan et 32 GB-abonnement stille bliver til et 64 GB.

Motorvalget, kort

Hvis du allerede kører Postgres, er pgvector den mindst besværlige mulighed — det er en udvidelse, ikke en ny tjeneste at passe. Når du har millioner af vektorer og vil have hurtig filtreret søgning, tjener en dedikeret motor som Qdrant eller Weaviate den separate proces. Overkonstruér det ikke på dag ét; kør det, du allerede driver, og del det ud, når søgning faktisk sløver.

Hvorfor overhovedet self-hoste

To grunde til, at folk faktisk gør dette, og ingen af dem er "for at spare et par dollars":

Privatliv. Embeddings er ikke abstrakte — de koder den tekst, de kom fra. Dine dokumenter, dine kunders indhold, dine interne noter, forvandlet til vektorer og sendt til en tredjeparts servere. Self-hosting holder det på en maskine, du kontrollerer. Hvis dataene er følsomme nok til, at du også betaler i krypto uden KYC, underminerer en managed vektorsky hele pointen.

Flad omkostning. Managed vektortjenester fakturerer efter lagrede vektorer og kørte forespørgsler. En VPS er ét månedligt tal, og du kan hamre løs på den, så hårdt du vil. I stor skala slår forudsigeligt målt.

Hvad dette betyder for dimensionering

Start med at måle dit korpus, ikke med at gætte. Få dit embedding-antal og din dimension, indlæs et udsnit, hold øje med den residente hukommelse, ekstrapolér. Vælg så et abonnement med hovedrum til indekset plus alt omkring det — appen, modelklienten, plads til at vokse.

For alt forbi et par millioner vektorer holdt privat kører Pro-linjen 32 til 80 GB med en dedikeret IP og natlige backups, hvilket betyder noget, når indekset er produktet, og at miste det gør ondt.