Calculadora Embeddings
Calcula los costos iniciales de construcción de índices y los costos mensuales de consultas para 15+ modelos de incrustación, incluyendo OpenAI, Voyage, Cohere, Gemini, Mistral, Together y otros. También proporciona un listado con dimensiones, tokens máximos y compatibilidad con Matryoshka Representation Learning (MRL).
📚 Construcción
🔍 Consulta
📊 Stats
| Modelo | Dim | Max tok | $/MT | Índice | Consulta/mes | Total | MRL |
|---|
※ Precios a partir de abril de 2026. MRL = Matryoshka Representation Learning (las dimensiones se pueden reducir retroactivamente).
📖 Dónde se suele tropezar
Estima el coste puntual de construir un índice de embeddings y el coste mensual de consultarlo, para un tamaño de corpus y un modelo dados. Todo se ejecuta en el navegador. Lo que ves aquí es sólo el cargo de la API. El total real de un sistema RAG incluye además la factura mensual de la base de datos vectorial, el coste de volver a incrustar al reindexar y el coste de inferencia de pasar los fragmentos recuperados a un LLM; en la mayoría de diseños, esa última partida es decenas de veces el coste de los embeddings.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| Decidir sólo por el coste de construcción | Descubrir que incrustar cien mil documentos cuesta unos pocos dólares tranquiliza, pero esa cifra ocurre una vez. Lo que de verdad se acumula es volver a incrustar cada vez que cambia un documento y incrustar cada consulta de búsqueda. Con diez mil consultas al día son trescientas mil incrustaciones de consulta al mes, para siempre. | Suma tres partidas por separado: construcción una vez, actualizaciones por su frecuencia y consultas por el volumen mensual. Incrustar una consulta son unas pocas decenas de tokens, así que usar un modelo más barato para las consultas resulta tentador; pero documentos y consultas deben usar el mismo modelo, porque las distancias entre espacios vectoriales distintos no significan nada. Si el modelo ofrece una opción de dimensión reducida, esa es la palanca práctica. |
| Elegir el modelo con más dimensiones | El número de dimensiones repercute directamente en el almacenamiento y la memoria de la base vectorial. Tres mil dimensiones en float32 son 12 KB por vector, así que un millón de documentos son 12 GB. La mitad de dimensiones, la mitad de espacio. Este lado del almacenamiento suele acabar pesando más que el cargo de la API, y la latencia de búsqueda también escala con las dimensiones. | Construye primero con pocas dimensiones, mide la precisión y súbelas sólo si hace falta. Para muchas aplicaciones bastan 768 a 1024. Un modelo con reducción de dimensión te deja bajar el tamaño de salida sin cambiar de modelo, así que el rehacer es pequeño. A una escala donde el almacenamiento duele, cuantizar de float32 a int8 lo reduce a la cuarta parte, normalmente por unos pocos puntos de precisión. |
| No presupuestar un cambio de modelo | Cambiar de modelo de embeddings invalida todos los vectores que ya tienes. Los espacios son distintos, así que mezclar viejos y nuevos y medir distancias entre ellos no tiene sentido. Eso hace obligatorio volver a incrustar todo el corpus, al coste completo de la construcción original. Las generaciones de modelos se renuevan cada uno o dos años, así que es cuestión de cuándo, no de si. | Desde el diseño, guarda junto a cada vector qué modelo lo produjo. Poder distinguir la generación antigua decide cuánto trabajo supone una migración. Conserva también el texto original: volver a incrustar lo necesita, y si sólo tiraste los fragmentos vuelves a empezar por recuperar los documentos. Migra ejecutando el índice antiguo y el nuevo en paralelo y comparando la calidad de recuperación antes de cambiar. |
La forma más eficaz de recortar coste es incrustar menos de entrada. Indexar sólo lo que de verdad se busca, en vez de todos los documentos de la empresa, sale más barato, más rápido y más preciso: cada documento ajeno es una fuente más de ruido en los resultados. Evita también volver a incrustarlo todo en cada actualización: guarda un hash por documento y reincrusta sólo lo que cambió, y el coste recurrente cae mucho. El diseño del troceado está en el troceador de texto para RAG, y la estimación de tokens en el contador de tokens.
📖 Cómo usar
-
1
Tamaño índiceDocs × tokens
-
2
Consultas/mesQueries × tokens
-
3
ComparaCosto/dim/precisión
❓ Preguntas frecuentes
¿Una vez?
¿Dimensiones?
¿OSS?
🐛 ¿Encontró un problema con esta herramienta?
Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
¡Gracias por tu reporte!
Tu reporte llegó al operador y se usará para mejorar.