Almacenar diez millones de embeddings de 768 dimensiones en formato float32 exige unos 30,72 GB de memoria antes de contar metadatos, identificadores o estructuras de búsqueda. TurboVec propone reducir esa misma colección a cerca de 4 GB mediante TurboQuant, un algoritmo de Google Research que comprime los vectores sin entrenar previamente un libro de códigos con el corpus completo.
Las claves de TurboVec y TurboQuant en 30 segundos
- TurboQuant comprime vectores mediante normalización, rotación aleatoria y cuantización escalar.
- Diez millones de embeddings de 768 dimensiones pueden pasar de unos 31 GB a cerca de 4 GB con 4 bits.
- El método base no necesita entrenar un código específico para cada conjunto de datos.
- TurboVec ofrece una implementación en Rust con interfaces para Python y búsquedas filtradas.
- Sus primeras pruebas superan a FAISS entre un 10 % y un 19 % en ARM, aunque el resultado cambia según el procesador y la configuración.
La diferencia no procede de una nueva base de datos distribuida ni de añadir más memoria al servidor. TurboVec almacena cada coordenada utilizando dos o cuatro bits, frente a los 32 bits habituales de un número en coma flotante. La reducción permite mantener índices mucho mayores en RAM, mejorar el uso de las cachés del procesador y desplegar determinadas aplicaciones de generación aumentada mediante recuperación, conocidas como RAG, en máquinas más pequeñas.
Sin embargo, el titular necesita varios matices. Los 31 GB presuponen embeddings de 768 dimensiones y solo contabilizan los vectores. Tampoco todos los índices vectoriales almacenan sus datos en float32 sin compresión. FAISS, Qdrant, Elasticsearch, pgvector y otros motores ya ofrecen diferentes técnicas para reducir memoria, acelerar consultas o mover parte del índice a almacenamiento.
TurboVec no elimina la infraestructura. Lo que cambia es la cantidad necesaria para un caso concreto.
Cómo consigue TurboQuant reducir el tamaño de los vectores
TurboQuant nació como un trabajo de Google Research orientado a resolver un problema conocido de la cuantización vectorial: comprimir vectores de muchas dimensiones sin destruir las relaciones geométricas utilizadas durante la búsqueda.
Los sistemas tradicionales de cuantización de producto suelen dividir cada vector en grupos y entrenar un libro de códigos sobre una muestra representativa del conjunto. Ese entrenamiento identifica los centroides que se utilizarán después para representar los datos con menos bits.
El proceso funciona, pero introduce varias obligaciones. Hay que seleccionar una muestra, entrenar el cuantizador, conservar los libros de códigos y valorar si deben generarse de nuevo cuando cambia la distribución del corpus.
TurboQuant adopta otro camino. Su funcionamiento puede resumirse en cinco etapas:
| Etapa | Qué hace | Para qué sirve |
|---|---|---|
| Normalización | Separa la magnitud del vector y convierte el resto en una dirección unitaria | Permite comparar direcciones de manera consistente |
| Rotación aleatoria | Aplica la misma transformación ortogonal a todos los vectores | Hace que las coordenadas sigan una distribución matemática predecible |
| Cuantización escalar | Asigna cada coordenada a uno de varios intervalos precalculados | Reduce cada valor a dos o cuatro bits |
| Empaquetado | Agrupa los pequeños códigos dentro de bytes | Disminuye el espacio ocupado en memoria |
| Corrección de puntuación | Guarda un factor por vector para ajustar el producto interno | Reduce el sesgo introducido por la compresión |
La idea central es que, después de la rotación, las coordenadas se aproximan a una distribución beta conocida que converge hacia una distribución normal cuando aumenta la dimensión. Esto permite calcular de antemano los intervalos y centroides del cuantizador mediante el algoritmo Lloyd-Max.
Los valores no se obtienen entrenando un libro de códigos sobre todos los documentos. Esa propiedad hace que el método sea independiente de la distribución concreta del corpus y permita incorporar nuevos vectores sin reconstruir el índice completo.
El artículo de investigación afirma que TurboQuant se aproxima al límite teórico de distorsión de Shannon con una diferencia limitada a un factor constante cercano a 2,7. En las pruebas publicadas, también superó a distintas técnicas de cuantización de producto en recuperación de vecinos cercanos y redujo el tiempo de preparación del índice hasta hacerlo prácticamente inexistente.
De 31 GB a 4 GB: qué representa realmente la comparación
La operación que sustenta el ejemplo es sencilla:
| Representación | Cálculo por vector de 768 dimensiones | Memoria para 10 millones |
|---|---|---|
float32 | 768 × 4 bytes | 30,72 GB |
| Cuantización de 4 bits | 768 × 0,5 bytes | 3,84 GB |
| Cuantización de 2 bits | 768 × 0,25 bytes | 1,92 GB |
La cifra final será algo mayor porque el índice necesita almacenar normas, factores de corrección, identificadores, estructuras auxiliares y alineamiento de memoria. Aun así, la reducción frente a float32 sigue siendo considerable.
Un embedding de 1.536 dimensiones ocuparía el doble: aproximadamente 61,44 GB para diez millones de vectores sin comprimir. TurboVec indica que uno de estos vectores pasa de 6.144 bytes en float32 a 384 bytes cuando se representa con dos bits por coordenada, una reducción teórica de 16 veces para la parte estrictamente vectorial.
Este ahorro no implica que toda una plataforma RAG pase a ocupar 4 GB. Todavía deben almacenarse los documentos originales, sus fragmentos, los metadatos, los permisos, los índices textuales y las estructuras utilizadas para relacionar cada vector con su contenido.
La memoria vectorial puede ser una parte importante del sistema, pero no es la única.
TurboVec lleva el algoritmo a Rust y Python
TurboVec es una implementación independiente y de código abierto escrita en Rust. El proyecto incorpora interfaces para Python y utiliza instrucciones SIMD para calcular muchas puntuaciones en paralelo.
En ARM emplea kernels NEON. En procesadores x86 modernos puede utilizar AVX-512BW, con alternativas AVX2 y una ruta escalar para equipos más antiguos.
Sus desarrolladores aseguran que, en pruebas con 100.000 vectores, 1.000 consultas y un valor de k=64, TurboVec superó a FAISS IndexPQFastScan entre un 10 % y un 19 % en un Apple M3 Max. En un Intel Xeon Platinum 8481C venció por hasta aproximadamente un 5 % en las configuraciones de cuatro bits, mientras que quedó ligeramente por detrás de FAISS al utilizar dos bits.
Por tanto, no existe una superioridad absoluta frente a FAISS. El resultado depende de la arquitectura del procesador, las dimensiones del embedding, el número de bits, el paralelismo y el tipo de consulta.
| Alternativa | Compresión | Entrenamiento previo | Fortalezas | Límites |
|---|---|---|---|---|
| TurboVec | TurboQuant de 2 o 4 bits | No en el método base | Ingesta continua, bajo consumo de RAM y ejecución local | Proyecto joven y con menos recorrido en producción |
| FAISS IndexPQ | Cuantización de producto | Sí | Biblioteca madura, flexible y ampliamente probada | El entrenamiento y los libros de códigos complican las actualizaciones |
| FAISS HNSW | Habitualmente vectores completos | No para la compresión | Recall alto y búsqueda aproximada rápida | Consume bastante más memoria |
| pgvector | Exacta, HNSW o IVFFlat | Depende del índice | Mantiene datos y vectores en PostgreSQL | No está centrado en compresión extrema |
| Qdrant | Cuantización escalar, binaria y otras opciones | Según configuración | Filtros, persistencia y operación como base vectorial | Incorpora más componentes que una biblioteca local |
| Elasticsearch | Vectores, búsqueda textual e índices híbridos | Según técnica | Combina BM25, filtros y búsqueda semántica | Mayor consumo operativo para casos pequeños |
TurboVec también ofrece integraciones que buscan sustituir los almacenes vectoriales en memoria de LangChain, LlamaIndex, Haystack y Agno sin reconstruir toda la aplicación. El repositorio las presenta como reemplazos compatibles con las interfaces públicas y los mecanismos de persistencia de esos componentes de referencia.
Esto no significa que pueda sustituir sin cambios a cualquier base vectorial administrada. Una plataforma distribuida puede aportar replicación, copias de seguridad, alta disponibilidad, gestión multiusuario, controles operativos y escalado horizontal que no forman parte necesariamente de una biblioteca embebida.
Búsquedas filtradas sin recuperar resultados incorrectos
Una de las funciones más interesantes de TurboVec es el filtrado por identificadores dentro del propio kernel de búsqueda.
En numerosos sistemas RAG, el índice recupera primero los vectores más próximos y aplica después los filtros. El problema aparece cuando solo una fracción pequeña de los resultados pertenece al cliente, departamento, fecha o nivel de acceso solicitado. El sistema puede descartar casi todos los candidatos y devolver menos documentos de los esperados.
La alternativa habitual consiste en recuperar muchos más resultados de los necesarios y filtrarlos después. Esto aumenta el trabajo y tampoco garantiza que los mejores elementos autorizados aparezcan dentro de la primera selección.
TurboVec permite entregar una lista de identificadores admitidos o una máscara de posiciones. El kernel ignora los bloques que no contienen candidatos autorizados y selecciona los mejores resultados dentro del conjunto permitido.
Esta capacidad encaja especialmente bien en sistemas con varios clientes, controles de acceso por documento, filtros temporales o una primera fase de recuperación mediante SQL o BM25. No elimina la necesidad de aplicar permisos en la aplicación, pero evita que el filtro semántico se convierta en una operación posterior que degrade los resultados.
No necesita entrenamiento, pero TurboVec sí incorpora una calibración opcional
La afirmación de que TurboQuant no depende del conjunto de datos es correcta para el algoritmo base. Los intervalos de cuantización se derivan de una distribución matemática conocida y no de centroides aprendidos a partir del corpus.
La implementación actual de TurboVec añade, sin embargo, una variante denominada TQ+. Durante la primera incorporación de vectores calcula dos valores por coordenada, un desplazamiento y una escala, a partir de los percentiles 5 y 95 observados.
Esta calibración busca corregir desviaciones que aparecen en dimensiones finitas, sobre todo con embeddings de pocas dimensiones o configuraciones de dos bits. El ajuste queda congelado después de la primera carga y se reutiliza en las siguientes, por lo que no exige reconstruir el índice cuando crece el corpus.
No es equivalente al entrenamiento completo de un libro de códigos, pero sí introduce una pequeña dependencia respecto a los primeros datos incorporados. Esta diferencia importa cuando se presenta TurboVec como una solución totalmente ajena al dataset.
Privacidad local, siempre que todo el flujo permanezca local
TurboVec puede ejecutarse dentro de un servidor, una nube privada o una red aislada. No obliga a enviar el índice a un servicio administrado y puede combinarse con modelos de embeddings abiertos para mantener el flujo completo dentro de la infraestructura de la organización.
La privacidad no procede automáticamente del algoritmo. Si los documentos se envían a una API externa para generar los embeddings, parte de la información habrá salido de la red antes de llegar a TurboVec. También será necesario proteger los ficheros del índice, los documentos originales, las claves, las copias de seguridad y los registros de consultas.
Para un RAG privado, la cadena completa debería contemplar:
- generación local o controlada de embeddings;
- cifrado de datos almacenados y comunicaciones;
- aislamiento por usuario o cliente;
- filtros de autorización antes y durante la búsqueda;
- trazabilidad de las consultas;
- políticas de eliminación y retención.
TurboVec puede reducir el coste de una de esas capas. No sustituye el diseño de seguridad del sistema.
Su aportación más interesante es demostrar que una colección grande de embeddings no obliga necesariamente a desplegar una base vectorial distribuida ni un clúster con cientos de gigabytes de memoria. Para determinados proyectos, una biblioteca local, un servidor razonable y una cuantización bien escogida pueden ser suficientes.
Preguntas frecuentes
¿Cuánta memoria ocupan diez millones de embeddings?
Diez millones de vectores de 768 dimensiones en float32 ocupan aproximadamente 30,72 GB, sin incluir identificadores, metadatos ni estructuras del índice. Con cuatro bits por coordenada, la parte vectorial baja a unos 3,84 GB.
¿TurboVec necesita entrenar el índice?
El método base de TurboQuant no necesita entrenar un libro de códigos sobre el corpus. TurboVec incorpora una calibración TQ+ opcional durante la primera carga, pero no requiere reconstrucciones posteriores al añadir más vectores.
¿TurboVec es más rápido que FAISS?
En los benchmarks del proyecto supera a FAISS FastScan entre un 10 % y un 19 % en ARM. En x86 gana algunas pruebas de cuatro bits y queda ligeramente por detrás en varias configuraciones de dos bits.
¿Puede TurboVec sustituir una base de datos vectorial?
Puede hacerlo en aplicaciones locales o embebidas que no necesiten una plataforma distribuida. No ofrece automáticamente todas las funciones operativas de una base administrada, como replicación, alta disponibilidad, gobierno multiusuario o escalado entre nodos.
