EQVPS

VPS för självhostad RAG i skala

Retrieval-augmented generation slutar vara en laptop-demo så snart korpuset blir verkligt. En vektorindex vill ha RAM, och dina embeddings är din privata data. Här är dimensioneringsmatematiken och varför high-memory, no-KYC hosting passar. Från $55/mån.

En RAG-demo på en laptop med tvåhundra dokument känns ansträngningslös. Sedan riktar du den mot ett verkligt korpus — ett företags dokument, år av ärenden, en faktisk kunskapsbas — och det hela blir ett minnesproblem. Inte ett CPU-problem. Ett minnes-problem.

Här är delen de flesta hosting-sidor hoppar över: snabb retrieval vill ha indexet i RAM. Varje textchunk blir en embedding — en vektor ett par hundra till ett par tusen tal bred — och att söka innebär att jämföra din fråga mot dem alla, snabbt. På disk fungerar det, men varje fråga betalar en latensskatt, och low-latency retrieval var anledningen till att du självhostade från första början.

Dimensioneringsmatematiken, ärligt

Mät ditt eget korpus — dimension och indextyp svänger detta mycket — men som en startkänsla:

Vi skrev ut hela RAM-kurvan här om du vill ha detaljerna.

Varför high-memory och no-KYC tillsammans

Att hyra 48 GB RAM är lätt. Att hyra det med krypto och ingen identitetskontroll är det inte — de flesta hostar som säljer seriöst minne billigt gör det bakom ett kort och ett KYC-formulär. Dina embeddings är inte abstrakta tal; de kodar texten de kom från. Dina dokument, dina kunders innehåll, förvandlat till vektorer. Om den datan är känslig nog att du betalar privat, undergräver ett managed vektor-moln hela poängen — och det gör en host som knyter servern till din identitet också.

Den kombinationen — high memory, dedikerad IP, krypto, ingen KYC, nattliga säkerhetskopior — är vad Pro-linjen är till för. Det är inte det billigaste per gigabyte, och om du inte behöver integritet kan du hitta RAM billigare någon annanstans. Men om indexet är din produkt och det inte kan lämna, är detta formen som passar.

Var du ska börja

Välj ett plan med marginal för indexet plus allt runt det — appen, model-klienten, utrymme att växa. För de flesta verkliga korpora är det Pro-48 (48 GB); ett stort går till Pro-64 eller Pro-80. Ladda ett stickprov först, titta på minnet, dimensionera från talet du mätte — inte det du fruktade.

Om din retrieval är del av ett större agent-system håller samma box ofta agent-flottan också — så blir ett 48 GB-plan tyst ett 64 GB-plan.

Redo att distribuera? Betala med krypto, ingen KYC — igång på ungefär en minut.

Distribuera nu →

FAQ

Hur mycket RAM behöver min RAG-uppsättning faktiskt?

Det skalar med antal embeddings och vektorbredd. Ett par hundratusen chunks får plats i 2–4 GB; låga miljoner, med appen och OS:et runt dem, landar på 16–32 GB; tiotals miljoner driver 48 GB och bortom. Mät ett stickprov, titta på resident memory, extrapolera — gissa inte högt, du överbetalar bara.

Varför inte använda en managed vektortjänst?

Två skäl folk faktiskt självhostar: dina embeddings kodar privat data (dokument, anteckningar, kundinnehåll), så att hålla dem på en maskin du kontrollerar spelar roll; och kostnaden är fast — en managed tjänst mäter per vektor och fråga, en VPS är ett månatligt tal du kan hamra så hårt du vill.

pgvector eller en dedikerad motor?

Om du redan kör Postgres är pgvector vägen med minst ansträngning — ett tillägg. För miljoner vektorer med tung filtrering förtjänar en purpose-built motor som Qdrant sin egen tjänst. Börja med vad du driver; dela ut det när sökningen blir långsam, inte innan.

Behöver jag en GPU för RAG?

Nej. Retrieval är CPU + RAM-arbete — att jämföra vektorer, inte generera text. Genereringssteget anropar din LLM (en API, eller en separat model-host). En high-memory CPU-box är exakt rätt form för retrieval-halvan.

Kommentarer

Inga kommentarer än. Bli först.

Lämna en kommentar

Kommentarer modereras innan de visas.