turbovec: compresión 16x para vector search con Rust y TurboQuant

¿Qué es Turbovec y por qué debería importarte como founder?

Un corpus de 10 millones de documentos que ocupa 31 GB de RAM en formato float32 entra en 4 GB con turbovec — y busca más rápido que FAISS. Esta herramienta open-source implementa el algoritmo TurboQuant de Google Research, diseñado originalmente para comprimir la memoria clave-valor (KV cache) en modelos de lenguaje, y ahora disponible como índice vectorial listo para producción.

Si estás construyendo un sistema RAG, un motor de búsqueda semántica o cualquier producto donde los embeddings sean parte del core, turbovec resuelve el problema más caro de la infraestructura AI actual: la memoria. No requiere servidor gestionado, no envía datos fuera de tu máquina y se integra directamente con LangChain, LlamaIndex, Haystack y Agno.

¿Cómo funciona TurboQuant? El algoritmo detrás de la compresión

TurboQuant fue propuesto en abril de 2025 por Amir Zandieh, Majid Daliri, Majid Hadian y Vahab Mirrokni (el paper está en arXiv:2504.19874) y será presentado en ICLR 2026. A diferencia de la cuantización por producto (PQ) tradicional que usa FAISS, TurboQuant es data-oblivious: no necesita fase de entrenamiento ni ajuste de parámetros.

El proceso tiene cinco pasos:

1. Normalización. Se elimina la magnitud del vector y se almacena como un solo float. Cada vector queda como una dirección unitaria en una hypersfera.
2. Rotación aleatoria. Todos los vectores se multiplican por la misma matriz ortogonal aleatoria. Después de esto, cada coordenada sigue independientemente una distribución Beta que converge a Gaussiana en altas dimensiones — sin importar los datos originales.
3. Calibración por coordenada (TQ+). La distribución Beta es asintótica; en dimensiones finitas, las coordenadas individuales se desvían. TQ+ ajusta dos escalares por coordenada (desplazamiento y escala) mapeando los cuantiles empíricos sobre los centroides del codebook. Se llama una vez con una muestra representativa (~1024 filas) antes de agregar vectores. Sin calibración, el índice funciona como TurboQuant estándar.
4. Cuantización escalar Lloyd-Max. Dado que la distribución es conocida, se precomputan los límites óptimos de los buckets. Para 2-bit: 4 buckets; para 4-bit: 16 buckets. Estos se calculan desde las matemáticas, no desde los datos.
5. Bit-pack. Cada coordenada se empaqueta en bytes. Un vector de 1536 dimensiones pasa de 6.144 bytes (FP32) a 384 bytes (2-bit) — una compresión de 16x.

La búsqueda no descomprime ningún vector de la base de datos: rota la consulta una vez y puntúa directamente contra los valores del codebook usando kernels SIMD (NEON en ARM, AVX-512 en x86) con tablas de lookup por nibble.

Rendimiento: turbovec vs FAISS vs el mercado de bases de datos vectoriales

Los benchmarks del repositorio midieron 100K vectores OpenAI (d=1536 y d=3072), comparados contra FAISS IndexPQFastScan:

• Búsqueda: turbovec supera a FAISS en todas las configuraciones, promediando 3.4× más rápido a 4-bit y 23% más rápido a 2-bit en x86. En ARM, el promedio sube a 3.5× a 4-bit y 26% a 2-bit, gracias a kernels SDOT/SMMLA escritos a mano.
• Ingesta online: un add() individual tarda 6.3–19.7 µs (hasta 13.9× más rápido que FAISS). Un batch de 100 vectores amortiza a 4.6–16.3 µs/vector (hasta 15.1× más rápido).
• Eliminación: IdMapIndex.remove(id) opera en O(1) a 0.44–1.22 µs. FAISS repackea los códigos almacenados en cada eliminación: 0.19–1.02 segundos por operación a 100K vectores — un millón de veces más lento.
• Recall: TurboQuant alcanza ratios de recall superiores a FAISS en tres de cuatro configuraciones a d=1536 (ventaja de 0.9–2.9 puntos en R@1). A k=8, ambos llegan a 1.0 de recall.

Estos números cobran contexto cuando mirás el mercado actual. Según Meritshot, el mercado de bases de datos vectoriales se consolidó en 2026 alrededor de cuatro actores principales: Pinecone, Weaviate, Qdrant y Chroma. Qdrant — también construido en Rust — cerró una ronda Serie B de USD 50 millones a principios de 2026 y ofrece cuantización de hasta 2-bit (reducción de 16x en memoria). Pero incluso Qdrant Cloud cobra ~USD 65/mes por 10M vectores, mientras que Pinecone llega a USD 300–800/mes para el mismo volumen.

Con turbovec, la alternativa es autoalojamiento total: cero costo de licencia, cero dependencia de proveedor, y los mismos benchmarks de rendimiento. Un equipo que migró de Pinecone a Qdrant autoalojado reportó ahorro de USD 1.200 a USD 130 mensuales para 50M vectores.

¿Qué significa esto para tu startup?

Acción 1: Evaluá turbovec si tu stack RAG depende de memoria

Si tenés más de 1M de vectores y pagás por almacenamiento en un servicio gestionado, turbovec puede reducir tu factura entre 3x y 10x al eliminar el overhead del proveedor. La integración con LangChain y LlamaIndex es directa: reemplazás InMemoryVectorStore o SimpleVectorStore con una línea de import y mantenes toda la lógica de pipeline intacta.

# Reemplazo directo en LangChain
from turbovec import TurboQuantIndex
index = TurboQuantIndex(dim=1536, bit_width=4)

Acción 2: Usá filtros en tiempo de búsqueda para multi-tenancy

Si construís un producto B2B con tenants aislados, turbovec permite pasar una allowlist de IDs directamente al kernel SIMD. Los bloques sin slots permitidos se skippean antes de cualquier lookup — no pagás el costo completo de búsqueda y luego filtrás. Esto evita over-fetching sin penalizar el recall.

allowed = np.array(db.execute("SELECT id FROM docs WHERE tenant=?", (t,)).fetchall(),
                   dtype=np.uint64)
scores, ids = idx.search(query, k=10, allowlist=allowed)

Acción 3: Considerá la calibración TQ+ solo si trabajás con dimensiones bajas

La calibración opcional (index.calibrate(sample)) mejora el recall hasta +2.2 puntos porcentuales en @1 en embeddings de baja dimensionalidad (como GloVe d=200). Si usás embeddings de OpenAI (d=1536 o d=3072), el beneficio es marginal y probablemente no valga el paso adicional. Pero si trabajás con word embeddings o vectores cortos, la calibración paga.

Cuando NO usar turbovec

• Si necesitás búsqueda híbrida (vector + keyword BM25): Weaviate sigue siendo la mejor opción nativa.
• Si tu equipo no tiene capacidad operativa para autoalojar: Pinecone o Weaviate Cloud eliminán la fricción operacional.
• Si estás en etapa de prototipo con menos de 500K vectores: Chroma ofrece productividad inmediata sin complejidad.

El contexto más amplio: compresión como ventaja competitiva

Lo interesante de TurboQuant es que nació de un problema diferente: la compresión del KV cache en LLMs. Google Research lo desarrolló porque el caché crece linealmente con la longitud del contexto y el número de tokens concurrentes, convirtiéndose en el cuello de botella principal de inferencia. Lograron reducir la memoria del KV cache en 6x y obtener hasta 8x de velocidad en atención sobre GPUs H100, sin pérdida de precisión a 3.5 bits por canal.

Que el mismo algoritmo funcione tan bien para vector search no es casualidad: ambos problemas comparten la estructura geométrica de vectores de alta dimensión donde las distancias relativas importan más que los valores absolutos. La rotación aleatoria que hace la distribución de coordenadas predecible es universal — no depende de si estás comprimiendo embeddings de búsqueda o estados internos de un transformer.

Esto sugiere que la próxima frontera no será elegir entre diferentes algoritmos de cuantización, sino integrar compresión eficiente en todas las capas del stack AI simultáneamente: embeddings, KV cache, activations y weights. Los fundadores que entiendan esta convergencia tendrán una ventaja estructural en costos de infraestructura.

Fuentes

• GitHub – Turbovec
• Google Research Blog – TurboQuant
• Wikipedia – TurboQuant
• Meritshot – Vector Database Comparison 2026