Perché il RAG ha bisogno di così tanta RAM?

La ricerca vettoriale veloce vuole l'indice residente in memoria. Ogni chunk di documento diventa un embedding — un vettore da qualche centinaio a un paio di migliaia di float — e a milioni di chunk questo si accumula. Spingi l'indice su disco e la latenza di ricerca schizza; tenere l'intero motivo per cui hai fatto self-hosting (velocità + controllo) significa tenerlo in RAM.

Quanta RAM per un dato corpus?

Sensazione approssimativa: qualche centinaio di migliaia di embedding sta bene in 2–4 GB. Milioni bassi, con l'app e l'OS attorno, e sei a 16–32 GB. Decine di milioni o vettori ad alta dimensione e sei sui 48–80 GB, e oltre spezzi su più server. Dimensione e tipo di indice fanno oscillare molto questo, quindi misura il tuo.

pgvector o un motore dedicato come Qdrant?

Se già usi Postgres, pgvector è la via di minor sforzo — un'estensione, un database. Per milioni di vettori con filtri pesanti, un motore dedicato si guadagna il servizio separato. Inizia con ciò che già gestisci; passa oltre solo quando la ricerca rallenta.

Perché fare self-hosting invece di un servizio vettoriale gestito?

Due motivi reali: i tuoi embedding codificano spesso dati privati (documenti, note, contenuti dei clienti), e il self-hosting li tiene su un server che controlli. Ed è a costo fisso — i servizi gestiti fatturano per vettori e query, un VPS è un unico numero mensile senza conto per query.

RAG self-hosted su scala: quanta RAM divora davvero un indice vettoriale

Ogni tutorial RAG gira su un laptop con qualche centinaio di documenti, e sembra senza sforzo. Poi lo punti su un corpus reale — i documenti di un'azienda, anni di ticket, una knowledge base — e all'improvviso la memoria è tutta la conversazione.

Il RAG non scala per CPU. Scala per RAM.

Perché l'indice vuole memoria

Il recupero funziona trasformando ogni chunk di testo in un embedding — un vettore, lungo da qualche centinaio a un paio di migliaia di numeri. Cercare significa confrontare il tuo vettore di query con tutti loro, velocemente. "Velocemente" è la parola operativa: per bassa latenza l'indice deve vivere in RAM. Su disco funziona, ma ogni query paga una penalità, e il recupero a bassa latenza era il punto del self-hosting in primo luogo.

Quindi il conto della memoria scala con due cose: quanti chunk hai, e quanto largo è ciascun vettore.

Numeri reali, grosso modo

Misura il tuo — dimensione e tipo di indice muovono molto questo — ma come sensazione di partenza:

Qualche centinaio di migliaia di embedding — comodo in 2–4 GB. Una knowledge base personale, i documenti di un singolo prodotto.
Milioni bassi — con l'app, il client del modello e l'OS attorno, prevedi 16–32 GB. È una seria knowledge base aziendale o un RAG multi-sorgente.
Decine di milioni, o vettori ad alta dimensione — ora sei sui 48–80 GB, e oltre su diverse macchine. Grandi patrimoni documentali, recupero multi-tenant, o tieni diversi indici caldi in una volta.

Un sistema multi-agente che tiene anche un grande indice accumula entrambi i costi sulla stessa macchina — è così che un piano da 32 GB si trasforma silenziosamente in uno da 64 GB.

La scelta del motore, in breve

Se già usi Postgres, pgvector è l'opzione di minor sforzo — è un'estensione, non un nuovo servizio da accudire. Quando hai milioni di vettori e vuoi ricerca filtrata veloce, un motore dedicato come Qdrant o Weaviate si guadagna il processo separato. Non fare over-engineering al primo giorno; fai girare ciò che già gestisci e separalo quando la ricerca rallenta davvero.

Perché darsi la pena del self-hosting

Due motivi per cui la gente lo fa davvero, e nessuno è "per risparmiare qualche dollaro":

Privacy. Gli embedding non sono astratti — codificano il testo da cui vengono. I tuoi documenti, i contenuti dei tuoi clienti, le tue note interne, trasformati in vettori e spediti ai server di una terza parte. Il self-hosting li tiene su una macchina che controlli. Se il dato è abbastanza sensibile da farti anche pagare in crypto senza KYC, un cloud vettoriale gestito disfa tutto il senso.

Costo fisso. I servizi vettoriali gestiti fatturano per vettori memorizzati e query eseguite. Un VPS è un unico numero mensile e puoi martellarlo quanto vuoi. Su scala, prevedibile batte a consumo.

Cosa significa questo per il dimensionamento

Inizia misurando il tuo corpus, non tirando a indovinare. Ottieni il conteggio degli embedding e la dimensione, carica un campione, guarda la memoria residente, estrapola. Poi scegli un piano con margine per l'indice più tutto ciò che gli sta attorno — l'app, il client del modello, spazio per crescere.

Per qualsiasi cosa oltre un paio di milioni di vettori tenuti in privato, la linea Pro gira da 32 a 80 GB con un IP dedicato e backup notturni, cosa che conta quando l'indice è il prodotto e perderlo fa male.