Por que o RAG precisa de tanta RAM?

A busca vetorial rápida quer o índice residente em memória. Cada trecho de documento vira um embedding — um vetor de algumas centenas a alguns milhares de floats — e em milhões de trechos isso soma. Empurre o índice para o disco e a latência de busca dispara; manter a razão inteira pela qual você auto-hospedou (velocidade + controle) significa mantê-lo em RAM.

Quanta RAM para um dado corpus?

Sensação aproximada: algumas centenas de milhares de embeddings ficam bem em 2–4 GB. Poucos milhões, com o app e o SO ao redor deles, e você está em 16–32 GB. Dezenas de milhões ou vetores de alta dimensão e você entra em 48–80 GB, e além disso você divide entre servidores. Dimensão e tipo de índice mexem muito nisso, então meça o seu.

pgvector ou um motor dedicado como o Qdrant?

Se você já roda Postgres, o pgvector é o caminho de menor esforço — uma extensão, um banco de dados. Para milhões de vetores com filtragem pesada, um motor feito sob medida ganha o próprio serviço. Comece com o que você já opera; mude só quando a busca ficar lenta.

Por que auto-hospedar em vez de um serviço vetorial gerenciado?

Duas razões reais: seus embeddings frequentemente codificam dados privados (docs, notas, conteúdo de clientes), e auto-hospedar mantém isso num servidor que você controla. E é de custo fixo — serviços gerenciados medem por vetores e consultas, um VPS é um número mensal sem conta por consulta.

RAG auto-hospedado em escala: quanta RAM um índice vetorial de fato come

Todo tutorial de RAG roda num notebook com algumas centenas de documentos, e parece sem esforço. Depois você aponta para um corpus de verdade — os docs de uma empresa, anos de tickets, uma base de conhecimento — e de repente a memória é a conversa inteira.

O RAG não escala por CPU. Ele escala por RAM.

Por que o índice quer memória

A recuperação funciona transformando cada trecho de texto num embedding — um vetor, de algumas centenas a alguns milhares de números de comprimento. Buscar significa comparar seu vetor de consulta contra todos eles, rápido. "Rápido" é a palavra operativa: para baixa latência o índice precisa morar em RAM. No disco funciona, mas cada consulta paga uma penalidade, e a recuperação de baixa latência era o ponto de auto-hospedar em primeiro lugar.

Então a conta de memória escala com duas coisas: quantos trechos você tem, e quão largo é cada vetor.

Números reais, aproximadamente

Meça o seu — dimensão e tipo de índice mexem muito nisso — mas como sensação de partida:

Algumas centenas de milhares de embeddings — confortável em 2–4 GB. Uma base de conhecimento pessoal, os docs de um único produto.
Poucos milhões — com o app, o cliente do modelo e o SO ao redor, planeje 16–32 GB. Esta é uma base de conhecimento séria de empresa ou um RAG de múltiplas fontes.
Dezenas de milhões, ou vetores de alta dimensão — agora você está em 48–80 GB, e além disso em várias máquinas. Grandes acervos de documentos, recuperação multi-tenant, ou você está mantendo vários índices quentes de uma vez.

Um sistema multi-agente que também mantém um índice grande empilha os dois custos na mesma máquina — é assim que um plano de 32 GB vira um de 64 GB em silêncio.

A escolha do motor, brevemente

Se você já roda Postgres, o pgvector é a opção de menor esforço — é uma extensão, não um novo serviço para cuidar. Quando você tem milhões de vetores e quer busca filtrada rápida, um motor dedicado como o Qdrant ou o Weaviate ganha o processo separado. Não superengenheire no primeiro dia; rode o que você já opera e separe-o quando a busca de fato ficar lenta.

Por que se dar ao trabalho de auto-hospedar

Duas razões pelas quais as pessoas de fato fazem isso, e nenhuma é "para economizar alguns dólares":

Privacidade. Embeddings não são abstratos — eles codificam o texto de onde vieram. Seus docs, o conteúdo dos seus clientes, suas notas internas, transformados em vetores e enviados aos servidores de um terceiro. Auto-hospedar mantém isso numa máquina que você controla. Se o dado é sensível o bastante para você também estar pagando em cripto sem KYC, uma nuvem vetorial gerenciada desfaz o ponto inteiro.

Custo fixo. Serviços vetoriais gerenciados cobram por vetores armazenados e consultas rodadas. Um VPS é um número mensal e você pode martelá-lo o quanto quiser. Em escala, previsível bate medido.

O que isso significa para o dimensionamento

Comece medindo seu corpus, não chutando. Pegue sua contagem de embeddings e dimensão, carregue uma amostra, observe a memória residente, extrapole. Depois escolha um plano com folga para o índice mais tudo ao redor — o app, o cliente do modelo, espaço para crescer.

Para qualquer coisa além de alguns milhões de vetores mantidos de forma privada, a linha Pro roda de 32 a 80 GB com um IP dedicado e backups noturnos, o que importa quando o índice é o produto e perdê-lo dói.