¿Cuánta RAM se necesita para un índice RAG familiar multilingüe?
Un índice RAG familiar multilingüe suele caber en 16–32 GB de RAM, pero el número de fragmentos y el diseño del índice importan más que la cantidad de idiomas por sí sola.
Un archivo doméstico con 500.000 fragmentos puede usar una incrustación multilingüe por fragmento en lugar de una copia por idioma. La memoria sigue aumentando debido a las dimensiones de los vectores, los enlaces del grafo, los metadatos, las cachés, los rerankers y el modelo generativo. Por tanto, el objetivo útil es medir el conjunto de trabajo máximo con margen suficiente, no aplicar una regla de «gigabytes por idioma» bajo carga máxima.
Empieza por los vectores y después añade la estructura de búsqueda
La memoria bruta de los vectores es el número de fragmentos multiplicado por las dimensiones y los bytes por valor. Con float32, 500.000 vectores de 768 dimensiones contienen aproximadamente 1,54 GB de coordenadas. Float16 reduce a la mitad esa carga de coordenadas, aunque es necesario verificar la compatibilidad de la base de datos y el comportamiento de la precisión.
Una explicación general de la indexación de grafos HNSW explica por qué HNSW mantiene un grafo de conexiones entre vecinos para realizar búsquedas aproximadas rápidas. Esas conexiones, los identificadores, la alineación y la sobrecarga del asignador se suman al cálculo de los vectores sin procesar.
Los filtros de metadatos, los identificadores de documentos, las cachés de texto y las estructuras duplicadas durante la compilación pueden superar las expectativas. Una base de datos respaldada en disco puede mantener en memoria las páginas activas del grafo, mientras que un motor en memoria puede conservar casi todo el índice. Los vectores sin procesar son el mínimo, no el requisito final de RAM.
La cobertura multilingüe cambia más los fragmentos que la aritmética
Un modelo de incrustaciones multilingüe asigna varios idiomas a un mismo espacio vectorial, por lo que añadir un idioma no duplica automáticamente todos los vectores. La RAM aumenta cuando las copias traducidas se fragmentan por separado, se mantienen índices específicos por idioma o la tokenización produce más fragmentos para los mismos documentos.
La investigación sobre incrustaciones multilingües evalúa representaciones compartidas en muchos idiomas y respalda los diseños con un solo índice cuando el modelo elegido alinea adecuadamente esos idiomas. La calidad de la cobertura puede variar según el idioma aunque la memoria no lo haga.
El generador y el reranker también compiten por la memoria del sistema. Un servidor de 16 GB puede albergar un índice moderado, pero recurrir mucho al intercambio de páginas cuando un LLM, un proceso de OCR y la caché de la base de datos se ejecutan conjuntamente. Una mayor cantidad de RAM no corrige una recuperación multilingüe deficiente; solo evita que la presión de memoria distorsione la prueba.
Cuándo deja de aplicarse el rango de 16–32 GB
Dieciséis gigabytes es una cifra plausible para cientos de miles de vectores compactos con texto respaldado en disco y un modelo local pequeño. Treinta y dos gigabytes es un punto de partida más seguro cerca de un millón de vectores de 768 dimensiones, además de los servicios. Unas dimensiones mayores, varias réplicas, índices separados por idioma o un LLM residente de mayor tamaño pueden justificar 64 GB o más.
Un análisis sobre la memoria de los índices HNSW muestra que los bytes de los vectores sin procesar pueden representar solo una fracción de la memoria total de HNSW una vez incluidas las estructuras del grafo. Las decisiones de implementación hacen que cualquier proporción universal sea poco segura.
Estos rangos dejan de ser válidos cuando la base de datos utiliza compresión, mapeo de memoria, cuantización de producto o un grafo configurado de forma muy distinta. También dejan de serlo durante la creación del índice si el creador mantiene brevemente copias antiguas y nuevas. Mide por separado los picos de las búsquedas estables y de las reconstrucciones.
Dimensiona la RAM a partir de un conjunto de trabajo medido
Calcula primero los vectores sin procesar y después ingiere el diez por ciento del corpus previsto con las dimensiones finales, los metadatos y los parámetros del índice. Mide la memoria residente tras realizar búsquedas en caliente, consultas simultáneas y una reconstrucción. Multiplica solo los componentes que escalan linealmente y reserva después al menos un 25 % de margen operativo.
Ejecuta el prototipo junto con la carga de trabajo prevista de la base de datos vectorial doméstica, porque los picos del modelo y de la base de datos pueden coincidir. Registra también la actividad de intercambio y la tasa de fallos de página.
Elige 16 GB solo cuando el pico extrapolado se mantenga por debajo de aproximadamente 12 GB; elige 32 GB cuando se mantenga por debajo de aproximadamente 24 GB. Pasa a una capacidad superior cuando las reconstrucciones o la inferencia simultánea superen ese límite. Vuelve a calcular después de cambiar la fragmentación o las dimensiones de las incrustaciones.
Productos recomendados
Centro de Tecnología e IA
Más para leer
Cómo medir la calidad de recuperación de RAG local e interpretar la exhaustividad, la precisión y la cobertura de citas
Crea un conjunto de pruebas RAG local, calcula las métricas principales de recuperación, interpreta sus ventajas y desventajas, y audita si las afirmaciones de...
¿Por qué es cada vez más importante la computación de funciones del hogar inteligente a medida que aumenta la cantidad de sensores con la misma frecuencia de muestreo?
Rastrea el procesamiento por sensor y entre sensores a medida que aumenta el número de dispositivos, identifica los costos no lineales de la fusión...
¿Por qué importa más el costo de evaluar RAG a medida que crece la biblioteca de documentos con el mismo volumen de consultas?
Comprende por qué el crecimiento del corpus aumenta el esfuerzo de evaluación de RAG sin más consultas de los usuarios y cómo las pruebas...
