EQVPS

VPS til selv-hostet RAG i skala

Retrieval-augmented generation holder op med at være en laptop-demo, når korpusset bliver rigtigt. Et vektor-indeks vil have RAM, og dine embeddings er dine private data. Her er dimensioneringsregnestykket, og hvorfor høj-hukommelses, no-KYC-hosting passer. Fra $55/md.

En RAG-demo på en laptop med to hundrede dokumenter føles ubesværet. Så peger du den mod et rigtigt korpus — en virksomheds dokumenter, års tickets, en faktisk vidensbase — og det hele bliver et hukommelsesproblem. Ikke et CPU-problem. Et hukommelses-et.

Her er den del, de fleste hosting-sider springer over: hurtig retrieval vil have indekset i RAM. Hvert stykke tekst bliver en embedding — en vektor et par hundrede til et par tusinde tal bred — og at søge betyder at sammenligne din forespørgsel mod dem alle, hurtigt. På disk virker det, men hver forespørgsel betaler en latensskat, og lav-latens-retrieval var grunden til, at du selv-hostede i første omgang.

Dimensioneringsregnestykket, ærligt

Mål dit eget korpus — dimension og indekstype rykker dette meget — men som et udgangspunkt:

Vi skrev hele RAM-kurven ud her, hvis du vil have detaljerne.

Hvorfor høj-hukommelse og no-KYC sammen

At leje 48 GB RAM er nemt. At leje det med krypto og uden identitetstjek er ikke — de fleste værter, der sælger seriøs hukommelse billigt, gør det bag et kort og en KYC-formular. Dine embeddings er ikke abstrakte tal; de indkoder teksten, de kom fra. Dine dokumenter, dine kunders indhold, gjort til vektorer. Hvis de data er følsomme nok til, at du betaler privat, ophæver en managed vektor-cloud hele pointen — og det gør en vært, der binder serveren til din identitet, også.

Den kombination — høj hukommelse, dedikeret IP, krypto, ingen KYC, natlige backups — er, hvad Pro-linjen er til. Den er ikke den billigste pr. gigabyte, og hvis du ikke har brug for privatliv, kan du finde RAM billigere andetsteds. Men hvis indekset er dit produkt, og det ikke kan forlade stedet, er dette den form, der passer.

Hvor du starter

Vælg en plan med råderum til indekset plus alt omkring det — appen, model-klienten, plads til at vokse. For de fleste rigtige korpora er det Pro-48 (48 GB); et stort går til Pro-64 eller Pro-80. Load en prøve først, hold øje med hukommelse, dimensionér ud fra tallet, du målte — ikke det, du frygtede.

Hvis din retrieval er en del af et større agent-system, holder samme boks ofte agent-flåden også — det er sådan, en 48 GB-plan stille bliver en 64 GB-en.

Klar til at deploye? Betal med krypto, ingen KYC — live på cirka et minut.

Deploy nu →

FAQ

Hvor meget RAM har min RAG-opsætning faktisk brug for?

Den skalerer med antal embeddings og vektorbredde. Et par hundrede tusinde chunks passer i 2–4 GB; lave millioner, med appen og OS'et omkring dem, lander på 16–32 GB; titusinder af millioner presser 48 GB og derover. Mål en prøve, hold øje med resident hukommelse, ekstrapolér — gæt ikke højt, du betaler bare for meget.

Hvorfor ikke bruge en managed vektortjeneste?

To grunde, folk faktisk selv-hoster: dine embeddings indkoder private data (dokumenter, noter, kundeindhold), så det betyder noget at holde dem på en maskine, du kontrollerer; og omkostningen er fast — en managed tjeneste måler efter vektorer og forespørgsler, en VPS er ét månedligt tal, du kan hamre så hårdt, du vil.

pgvector eller en dedikeret engine?

Hvis du allerede kører Postgres, er pgvector den mindst-besværlige vej — én extension. Til millioner af vektorer med tung filtrering fortjener en formålsbygget engine som Qdrant sin egen tjeneste. Start med det, du driver; del det ud, når søgning bliver langsom, ikke før.

Har jeg brug for en GPU til RAG?

Nej. Retrieval er CPU + RAM-arbejde — sammenligning af vektorer, ikke generering af tekst. Genereringstrinnet kalder din LLM (et API eller en separat model-vært). En høj-hukommelses-CPU-boks er præcis den rette form til retrieval-halvdelen.

Kommentarer

Ingen kommentarer endnu. Vær den første.

Skriv en kommentar

Kommentarer modereres, før de vises.