Cada embedding es una lista de números, y una base de datos vectorial almacena millones de ellos más un índice para buscarlos rápido. Antes de elegir un plan de base de datos o el tamaño de un servidor, necesitas saber cuánto ocupa todo eso. Esta calculadora estima el tamaño de los vectores en bruto, la sobrecarga del índice, los metadatos y las réplicas, y muestra cuánto puede ahorrar la cuantización.
Cómo funciona
El tamaño de los vectores en bruto es vectores × dimensiones × bytes por dimensión. Un vector float32 de 1.536 dimensiones ocupa 1.536 × 4 = 6.144 bytes, así que 10 millones de ellos son unos 61 GB antes de cualquier índice.
Un índice HNSW almacena un grafo de vecinos para hacer búsquedas aproximadas rápidas. Su capa inferior guarda hasta 2 × M enlaces por vector, almacenados como ID de 4 bytes, así que con M = 16 son unos 128 bytes por vector más un poco para las capas superiores. Los índices IVF añaden mucho menos, pero suelen requerir ajustes para lograr un buen recall. Un índice flat no añade nada y busca de forma exacta, pero es lento a gran escala.
La cuantización reduce los vectores. float16 reduce el tamaño a la mitad, int8 a la cuarta parte y la cuantización binaria lo deja en 1/32. El recall baja algo con cada paso, así que muchos sistemas mantienen los vectores comprimidos en memoria y reordenan los mejores resultados con copias de precisión completa en disco.
Los metadatos y las réplicas lo multiplican todo. Guardar el texto original del fragmento junto a cada vector puede superar con facilidad el tamaño de los propios vectores. Cada réplica almacena una copia completa. Las bases de datos reales también añaden su propia sobrecarga, así que trata estos resultados como una estimación de planificación y deja un margen del 20–50 %.
Un ejemplo resuelto
10 millones de embeddings del tamaño de los de OpenAI (1.536 dimensiones, float32) ocupan 61,44 GB como vectores en bruto. Un índice HNSW con M = 16 añade unos 1,34 GB, y 200 bytes de metadatos por vector añaden 2 GB, hasta 64,78 GB por copia. Con 2 réplicas necesitas unos 129,57 GB. Pasar a int8 reduce los vectores en bruto a 15,36 GB.
Más ejemplos
Pasar 10 millones de vectores de 1.536 dimensiones de float32 a cuantización int8 reduce el almacenamiento total de 129,57 GB a 37,41 GB con dos réplicas.
Usar embeddings de 768 dimensiones en lugar de 1.536 reduce aproximadamente a la mitad el almacenamiento de vectores: 68,13 GB en total.
Errores frecuentes
- Olvidar las réplicas, que multiplican el almacenamiento.
- Dejar fuera el índice y los metadatos.
- Elegir embeddings de muchas dimensiones cuando un modelo más pequeño rinde igual.
- No probar la calidad de la recuperación tras la cuantización.
Preguntas frecuentes
¿Cuánto almacenamiento necesitan los embeddings?
Multiplica el número de vectores por las dimensiones y por 4 bytes en float32. Un millón de vectores de 768 dimensiones necesitan unos 3,07 GB; un millón de vectores de 3.072 dimensiones necesitan unos 12,29 GB, antes del índice y los metadatos.
¿Cuánta memoria usa un índice HNSW?
Aproximadamente M × 2 × 4 bytes por vector para los enlaces del grafo, más los propios vectores si se mantienen en memoria, algo que hacen la mayoría de las implementaciones de HNSW por velocidad. Los vectores suelen dominar: el grafo es pequeño en comparación, salvo que M sea grande.
¿Perjudica la cuantización la calidad de la búsqueda?
Algo. int8 suele mantener un recall cercano al de la precisión completa. La cuantización binaria pierde más, por lo que normalmente se usa para una primera pasada rápida, y los mejores candidatos se vuelven a puntuar con los vectores completos. Prueba con tus propias consultas antes de cambiar.
¿Debo elegir menos dimensiones para ahorrar espacio?
Puede ayudar mucho. Algunos modelos de embeddings permiten acortar los vectores con solo una pequeña pérdida de calidad. Reducir las dimensiones a la mitad reduce a la mitad el almacenamiento de vectores y acelera la búsqueda. Compara antes la calidad de la recuperación con tus propios datos.
¿Por qué mi base de datos es más grande que esta estimación?
Las bases de datos añaden su propia sobrecarga: registros de escritura anticipada, registros eliminados a la espera de limpieza, archivos de segmentos e índices de payload sobre los campos de metadatos. Presupuesta un margen adicional además de esta estimación.