RAG autoalojado a escala: cuánta RAM come realmente un índice vectorial

Cada tutorial de RAG corre en un portátil con unos pocos cientos de documentos, y se siente sin esfuerzo. Luego lo apuntas a un corpus real — los docs de una empresa, años de tickets, una base de conocimiento — y de repente la memoria es toda la conversación.

RAG no escala por CPU. Escala por RAM.

Por qué el índice quiere memoria

El retrieval funciona convirtiendo cada chunk de texto en un embedding — un vector, de unos pocos cientos a un par de miles de números de largo. Buscar significa comparar tu vector de consulta contra todos ellos, rápido. «Rápido» es la palabra operativa: para baja latencia el índice necesita vivir en RAM. En disco funciona, pero cada consulta paga una penalización, y el retrieval de baja latencia era el sentido de autoalojar en primer lugar.

Así que la factura de memoria escala con dos cosas: cuántos chunks tienes, y cómo de ancho es cada vector.

Números reales, grosso modo

Mide el tuyo — la dimensión y el tipo de índice mueven esto mucho — pero como sensación de partida:

• Unos pocos cientos de miles de embeddings — cómodo en 2–4 GB. Una base de conocimiento personal, los docs de un solo producto.
• Millones bajos — con la app, el cliente del modelo y el OS alrededor, planea 16–32 GB. Esta es una base de conocimiento de empresa seria o un RAG multi-fuente.
• Decenas de millones, o vectores de alta dimensión — ahora estás en 48–80 GB, y por encima de eso entre varias máquinas. Grandes patrimonios de documentos, retrieval multi-tenant, o mantienes varios índices calientes a la vez.

Un sistema multiagente que además mantiene un índice grande apila ambos costes en la misma máquina — así es como un plan de 32 GB se convierte en uno de 64 GB en silencio.

La elección del motor, brevemente

Si ya ejecutas Postgres, pgvector es la opción de menor esfuerzo — es una extensión, no un nuevo servicio que babysittear. Cuando tienes millones de vectores y quieres búsqueda filtrada rápida, un motor dedicado como Qdrant o Weaviate se gana el proceso aparte. No lo sobre-ingenierices el primer día; ejecuta lo que ya operas y splittéalo cuando la búsqueda de verdad se ralentice.

Por qué molestarse en autoalojar

Dos razones por las que la gente hace esto de verdad, y ninguna es «para ahorrar unos dólares»:

Privacidad. Los embeddings no son abstractos — codifican el texto del que vinieron. Tus docs, el contenido de tus clientes, tus notas internas, convertidos en vectores y enviados a los servidores de un tercero. El autoalojamiento mantiene eso en una máquina que controlas. Si los datos son lo bastante sensibles como para que además estés pagando en cripto sin KYC, una nube vectorial gestionada deshace todo el sentido.

Coste plano. Los servicios vectoriales gestionados facturan por vectores almacenados y consultas ejecutadas. Un VPS es una cifra mensual y puedes martillearlo tan fuerte como quieras. A escala, predecible gana a medido.

Qué significa esto para el dimensionamiento

Empieza midiendo tu corpus, no adivinando. Consigue tu recuento de embeddings y dimensión, carga una muestra, vigila la memoria residente, extrapola. Luego elige un plan con margen para el índice más todo lo que hay alrededor — la app, el cliente del modelo, espacio para crecer.

Para cualquier cosa por encima de un par de millones de vectores mantenidos de forma privada, la línea Pro corre de 32 a 80 GB con una IP dedicada y copias de seguridad nocturnas, lo que importa cuando el índice es el producto y perderlo duele.