Cómo ProsGrow redujo un 75% el almacenamiento de vectores RAG sin procesar

El problema: la recuperación tiene dos costes de recursos distintos

Un sistema RAG privado paga por codificar documentos, almacenar sus vectores y ordenar resultados de búsqueda. Su punto de operación útil depende de qué cambios de calidad son aceptables y dónde está limitada la capacidad. ProsGrow evaluó estas decisiones sistemáticamente, utilizando las representaciones admitidas por Qwen y las rutas de precisión de vLLM.

Elegimos vectores de 1,024 dimensiones con un 75% menos de bytes de vectores sin procesar y, en un experimento independiente, FP8 dinámico con un 69.10% más de rendimiento de embeddings. Cada opción tiene su propia contrapartida de calidad.

Decisión 1: conservar las dimensiones que justifican su almacenamiento

Partimos de la salida nativa de 4,096 dimensiones de Qwen3-Embedding-8B. En el conjunto completo de prueba de SciFact, esta referencia FP16 obtuvo 0.79279 en nDCG@10, una medida de relevancia que premia documentos útiles en las primeras posiciones. Reducir la salida a 1,024 dimensiones obtuvo 0.78944: el 99.58% del nDCG@10 de referencia.

Una compresión más agresiva produjo una mayor pérdida de calidad de ordenación. Elegimos 1,024 dimensiones para este corpus, con Recall@100 pasando de 0.98000 a 0.97333. El 99.58% de retención se refiere específicamente al nDCG@10 de este experimento de dimensiones FP16.

Dónde ayudan los vectores más pequeños y dónde no

Qwen3-Embedding-8B proporciona representaciones Matryoshka, compatibles con el entorno de embeddings de vLLM. Esta capacidad original permite vectores útiles más cortos. La contribución de ProsGrow fue evaluar el equilibrio resultante entre almacenamiento y calidad para la carga de trabajo.

Para 100 millones de vectores float32, el almacenamiento sin procesar calculado baja de 1.64 TB a 0.41 TB. El tamaño total de la base de datos y la latencia de búsqueda aún deben medirse con el índice real.

El codificador seguía calculando su anchura oculta nativa, y el rendimiento cambió como máximo un 1.2% entre las dimensiones probadas. La mejora posterior del 69.10% proviene del experimento independiente de precisión.

Decisión 2: usar FP8 para aumentar de forma medida la capacidad de codificación

Manteniendo constantes las dimensiones de salida y la carga de entradas cortas, FP8 dinámico produjo 319,951 tokens de entrada/segundo entre ocho réplicas, frente a 189,213 con FP16. La menor de las dos ejecuciones FP8 del nodo da la mejora del 69.10%.

La ruta de ejecución más rápida proviene del soporte de FP8 dinámico de vLLM. ProsGrow verificó que los kernels FP8 previstos se ejecutaban en todas las GPU y evaluó conjuntamente la precisión, la concurrencia y la ubicación de réplicas. Aumentar la concurrencia más allá de la configuración elegida añadió poca capacidad y aproximadamente duplicó la latencia media.

La caché de prefijos permaneció desactivada en las comparaciones finales para que las entradas repetitivas del benchmark no sustituyeran el trabajo del transformer por reutilización de caché.

Este nodo optimizado también consumió un 44.19% menos de energía de las placas GPU por millón de tokens de entrada: 3.921 Wh frente a 7.025 Wh. Es una mejora energética de GPU medida; la energía del servidor y de las instalaciones queda fuera de la métrica.

El coste de FP8 en calidad es una decisión independiente

Repetimos la evaluación completa de calidad de SciFact con un control FP16 equivalente y dos arranques FP8. Con 1,024 dimensiones, el resultado conservador de FP8 obtuvo 0.786211 nDCG@10 frente a 0.789717 del control FP16 equivalente: 0.003506 menos. Recall@100 se mantuvo en 0.97333.

El otro arranque FP8 obtuvo 0.790021 nDCG@10. Publicamos la puntuación menor para que la decisión de aceptación sea conservadora. La retención anterior del 99.58% pertenece solo al experimento original de dimensiones; no es una garantía conjunta de calidad para la reducción de dimensiones y FP8.

Reordenación: dedicar cómputo a candidatos que pueden cambiar la respuesta

Para Qwen3-Reranker-8B elegimos 20 documentos completos por consulta. El estudio de la política modificó tanto la cantidad de candidatos como el truncamiento de documentos, por lo que su efecto no puede atribuirse solo a la cantidad. La política elegida obtuvo 0.80482 nDCG@10, con un conjunto de candidatos menor que equilibra ahorro de cómputo y exhaustividad de recuperación.

Bajo esas especificaciones fijas de 20 documentos, FP8 dinámico mejoró el rendimiento aislado de 2.7444 a 4.6958 búsquedas/segundo, un 71.10% más. El resultado conservador de ocho réplicas pasó de 21.6248 a 44.4738 búsquedas/segundo: de 77,849 a 160,106 búsquedas top-20/hora, o +105.66%. nDCG@10 pasó de 0.804821 a 0.803368 y Recall@20 permaneció en 0.94000.

En dos arranques, el resultado del nodo superó ocho veces la tasa FP8 aislada; la causa sigue sin resolverse tras la auditoría. Su capacidad se aplica a esta configuración exacta. La comparación aislada del 71.10% es la guía más clara sobre el beneficio de precisión por GPU.

Qué cambia para un cliente

Para un corpus que supera el criterio de calidad de 1,024 dimensiones, los datos vectoriales se reducen en tres cuartas partes. Para una tarea de indexación con entradas cortas que también supera el criterio FP8, el rendimiento medido equivale a unos 52 minutos por cada mil millones de tokens de entrada, frente a 88 minutos en la referencia FP16. Son estimaciones de tiempo de procesamiento calculadas a la tasa del benchmark.

Esto deja margen para actualizar el índice con más frecuencia. La búsqueda en línea necesita un plan de capacidad conjunto: las tasas de embeddings y reordenación del nodo completo se midieron por separado.

La contribución de ProsGrow consiste en elegir y validar un punto de operación según los requisitos de la carga. Un piloto de cliente necesita sus propias evaluaciones de relevancia y la ruta completa de recuperación, incluida la calidad de respuesta y la latencia p95. El benchmark establece compromisos entre componentes; un servicio de producción necesita validación conjunta.

Coste modelado de los dos componentes independientes

Con uso remunerado completo, el modelo de infraestructura de septiembre sitúa los embeddings en $0.00453–$0.00646 por millón de tokens de entrada y la reordenación top-20 en $0.03258–$0.04644 por 1,000 búsquedas, para costes de compra del nodo de $100,000–$150,000. El cálculo utiliza la tasa medida de nodo completo propia de cada componente: 319,951 tokens de entrada/s o 44.4738 búsquedas/s.

Estos escenarios suponen amortización a tres años, mantenimiento anual del 5%, 720 horas/mes, electricidad a $0.10/kWh, un multiplicador de consumo eléctrico de 1.30 y 6 kW de potencia activa del servidor. Eso da un coste modelado de infraestructura de $5.22–$7.44 por hora de nodo activo. El valor de 6 kW es una hipótesis de cartera; es independiente de la mejora medida de energía de las placas GPU descrita arriba. Una demanda menor reparte el coste fijo entre menos unidades vendidas.

Cada componente utilizó las ocho GPU en pruebas independientes; sus máximos no pueden sumarse como capacidad de servicio simultánea. Los costes excluyen almacenamiento, operaciones de la aplicación, personal, red, reservas del servicio y generación de respuestas. El coste por respuesta aceptada requiere validación de extremo a extremo.

Metodología y limitaciones

• Hardware y modelos: ocho GPU RTX PRO 6000 Blackwell Server Edition, con 96 GB de memoria nominal cada una y una réplica por GPU. Los embeddings utilizaron Qwen/Qwen3-Embedding-8B, revisión 1d8ad4ca9b3dd8059ad90a75d4983776a23d44af; la reordenación utilizó Qwen/Qwen3-Reranker-8B, revisión 77d193c791ed757ca307ee72715aa132723da912.
• Entorno de ejecución: vLLM 0.25.1; la comparación de precisión utilizó activaciones float16 con pesos FP8 dinámicos y una ruta de kernels FP8 verificada. Las comparaciones finales desactivaron la caché de prefijos.
• Capacidad de embeddings: entradas cortas sintéticas en solicitudes de 64 entradas, con una media de 56 tokens de modelo por entrada y 1,024 dimensiones devueltas. Cada ejecución del nodo procesó 65,536 entradas. La ventana común FP8 elegida fue de 11.467 segundos; las dos ejecuciones difirieron un 0.47% y no hubo solicitudes fallidas. La calidad con documentos reales se evaluó por separado.
• Calidad de recuperación: conjunto completo de prueba BEIR SciFact: 5,183 documentos con título y resumen, 300 consultas y valoraciones oficiales de relevancia, evaluados con la instrucción de consulta del publicador y búsqueda exhaustiva por coseno. SciFact es un benchmark del ámbito científico; otros corpus e índices aproximados pueden comportarse de otro modo.
• Límite de la medición del reordenador: cada ejecución del nodo procesó 2,400 búsquedas con 20 documentos completos por búsqueda. Los candidatos se fijaron a partir de la referencia densa FP16 de 1,024 dimensiones, por lo que no se mide una canalización conjunta de embeddings FP8 y reordenación. Publicamos los valores menores observados de rendimiento y calidad.
• Tiempos y despliegue: las ventanas de API con calentamiento abarcan desde el inicio de la primera réplica hasta la última finalización. Se excluyen el arranque y la construcción de la carga útil. Los conectores, la fragmentación, las operaciones de la base de datos vectorial, la generación y las colas de producción requieren un piloto de extremo a extremo. Las cifras por hora y por mil millones de tokens son conversiones aritméticas, no pruebas prolongadas.
• Almacenamiento y energía: la reducción del 75% se refiere a vectores sin procesar con la misma precisión de almacenamiento; los metadatos, las estructuras de índices, las réplicas y las copias de seguridad añaden sobrecarga. Las cifras energéticas solo cubren las placas GPU. Son comparaciones locales de configuraciones concretas, sin afirmar una comparación de costes con una API gestionada de modelo equivalente.

Recuperación RAG privada y búsqueda semántica

Para los equipos que planifican generación privada aumentada por recuperación (RAG), este estudio separa el almacenamiento de vectores de embeddings, la capacidad de indexación de documentos y la calidad de reordenación. Estas mediciones pueden orientar la infraestructura de búsqueda semántica, pero unos vectores más pequeños no demuestran por sí solos consultas más rápidas a la base de datos. El despliegue debe validar relevancia, tiempo de respuesta y calidad de respuestas en toda la canalización de recuperación.