A primera vista, la API de embeddings solo cobra por los tokens de entrada y no produce tokens de salida. Sin embargo, después de unos meses de operar un proyecto de RAG, las razones por las que se excede el presupuesto no suelen ser «demasiadas consultas», sino el volumen total de documentos una vez divididos en fragmentos, la regeneración completa de embeddings al cambiar de modelo y la suma de almacenamiento y solicitudes de la base vectorial.

Este artículo desglosa esas partidas, propone un orden de estimación y establece prioridades para reducir costos. Los precios unitarios cambian; se rigen por la página de precios de modelos y por la documentación de cada proveedor. Aquí no fijamos cifras.

Nota: OpenAI, DeepSeek y otros nombres mencionados son marcas de sus respectivos titulares. Este artículo toma como ejemplo las interfaces habituales en octubre de 2026; los nombres de modelo, las reglas de facturación y los precios pueden cambiar, así que verifica las páginas oficiales antes de comprar.

1. Se factura el token de entrada, no la «cantidad de llamadas»

La mayoría de las interfaces de embeddings solo cobra la entrada y no genera costo por tokens de salida. La entrada es el texto que quieres vectorizar, incluidos títulos, cuerpo, texto convertido de tablas, etiquetas HTML, barras de navegación y espacios sobrantes.

Al estimar, hay cuatro factores que amplifican el consumo:

  • Diferencias de tokenizador: un carácter chino no equivale necesariamente a un token, y cada modelo segmenta de forma distinta. No estimes por número de caracteres: haz primero una llamada con una muestra pequeña y lee el campo usage de la respuesta.
  • Solapamiento entre fragmentos: para conservar contexto, es habitual aplicar un 10%–20% de solapamiento al dividir; ese texto se factura varias veces. Cuanto mayor el solapamiento, más caro resulta construir el índice.
  • Texto sucio: encabezados, pies de página, plantillas y directorios repetidos se cobran como tokens normales si no se limpian, pero no aportan valor a la recuperación.
  • Índices duplicados: si el mismo corpus se vectoriza en prueba, preproducción y producción, el costo se multiplica por la cantidad de entornos.
Partida Cuándo se genera Quién factura Puntos que suelen omitirse
Tokens de entrada Vectorización de documentos y consultas Proveedor de embeddings Solapamiento, encabezados y pies, índices duplicados
Tareas por lotes Indexación completa e incremental sin conexión Interfaz por lotes del proveedor Si el descuento por lotes se aplica de verdad
Regeneración de embeddings Cambio de modelo, dimensión o fragmentación Proveedor de embeddings Reejecución completa y doble almacenamiento durante la transición
Almacenamiento vectorial Vectores e índices en disco Base de datos vectorial o nube Réplicas, copias de seguridad, crecimiento del índice
Recuperación y salida de red Lectura de vectores en cada consulta Base de datos o nube Acceso entre regiones, QPS pico
Llamada de generación Envío del contexto recuperado al modelo Proveedor del modelo de lenguaje Suele imputarse por error al costo de embeddings

Vale la pena insistir en la última fila: que los embeddings sean económicos no significa que el costo total de RAG sea bajo. Los fragmentos recuperados se envían al modelo grande para generar la respuesta, y los tokens de entrada suelen costar mucho más que la vectorización. El presupuesto debe calcularse en dos tramos.

2. Interfaces por lotes: menor precio unitario a cambio de tiempo

La mayoría de las plataformas cobra la interfaz por lotes por debajo de la interfaz en tiempo real. El precio es la espera: la tarea se encola, la respuesta puede tardar horas y es posible que se limiten los modelos disponibles y el tamaño de cada solicitud. Los lotes sirven para la construcción inicial del índice, la sincronización incremental nocturna y la evaluación sin conexión; no para vectorizar preguntas de usuarios en tiempo real.

Antes de usarlos, verifica tres cosas:

  1. Si las tareas por lotes tienen una cuota independiente o compiten con las solicitudes en tiempo real.
  2. Si las solicitudes fallidas o parcialmente exitosas se cobran y quién asume el costo de los reintentos.
  3. Si el gateway traslada el descuento por lotes del proveedor. No todos lo hacen; pregúntalo antes de comprar o verifícalo con la primera factura.

Lote no significa concurrencia ilimitada. Enviar un millón de elementos de una vez puede activar límites de velocidad o hacer fracasar la tarea. Divide según el volumen, registra los tokens y el tiempo de cada lote y reintenta solo los lotes fallidos para no repetir todo el trabajo.

3. Regeneración de embeddings: el costo único más subestimado

Los siguientes cambios suelen exigir regenerar todos los embeddings:

  • Cambiar el modelo de embeddings, o actualizarlo y alterar el espacio vectorial.
  • Modificar la dimensión, ya que los vectores antiguos no pueden mezclarse con los nuevos.
  • Cambiar las reglas de fragmentación, limpieza o análisis de documentos.
  • Añadir un idioma para el que el modelo actual no rinde lo suficiente.

El costo de regenerar no es solo la llamada: también incluye el tiempo de reejecución, el almacenamiento de índices antiguos y nuevos en paralelo y la variación de calidad durante la transición. En bases de conocimiento grandes, esta partida puede superar la suma de todos los costos de consulta anteriores.

Medidas para reducir el riesgo:

  • Conserva el texto original como fuente de verdad; los vectores son datos derivados y pueden reconstruirse en cualquier momento.
  • Registra en los metadatos del índice el nombre del modelo, la versión, la dimensión y los parámetros de fragmentación.
  • Cuando el índice nuevo esté listo, compara con un conjunto fijo de preguntas antes de desviar el tráfico.
  • En el día a día, vectoriza solo documentos nuevos o modificados; trata la regeneración completa como una migración planificada.

4. Almacenamiento vectorial y salida de red: la segunda factura

La facturación de una base vectorial suele depender de cinco factores: capacidad de almacenamiento, memoria, número de réplicas, volumen de solicitudes y tráfico de salida. Para estimar la capacidad por cantidad de vectores, calcula primero el tamaño bruto: con 1536 dimensiones y float32, cada vector ocupa aproximadamente 6 KB; un millón ronda los 6 GB, y al sumar índices, metadatos y réplicas el consumo real puede multiplicarse.

Puntos que suelen pasarse por alto:

  • Dimensión: a mayor dimensión, más caros el almacenamiento y el cálculo de recuperación. Algunos modelos permiten reducir la dimensión de salida; confirma si está disponible y cuánto afecta la recuperación con tu propio conjunto de evaluación.
  • Réplicas y copias: las réplicas de alta disponibilidad multiplican el almacenamiento, y las políticas de copia también se facturan.
  • Volumen de solicitudes: las consultas crecen más rápido que la cantidad de documentos; elige el tamaño según QPS y no según el volumen de datos.
  • Salida de red: desplegar la aplicación y la base en regiones distintas, devolver muchos candidatos por consulta o sincronizar vectores entre varios entornos genera tráfico facturable. Mantener la aplicación en la misma región y limitar los candidatos devueltos ahorra una partida que pasa desapercibida.

A pequeña escala, PostgreSQL con pgvector suele ser suficiente; cuando crecen el volumen y la concurrencia, evalúa si una base vectorial gestionada justifica el sobreprecio.

5. Orden para estimar bien el costo mensual

  1. Cuenta los documentos de origen, su longitud media y los parámetros de fragmentación; calcula los tokens de entrada después de dividir, no los caracteres del texto original.
  2. Usa los registros reales de la última semana para contar las consultas diarias y su longitud media.
  3. Define el plan de regeneración para los próximos tres meses: si cambiarás de modelo, de fragmentación o de idiomas.
  4. Confirma con el proveedor de la base vectorial cómo se facturan almacenamiento, réplicas, copias, solicitudes y salida de red.
  5. Calcula por separado el «primer mes de construcción» y el «mes en régimen estable»; no mezcles ambos presupuestos.
  6. Deja un margen y corrige los coeficientes con la factura real de la primera semana.

El siguiente marco de estimación es reutilizable. Las cifras son marcadores de posición solo para el ejemplo; los precios unitarios se toman de precios de modelos y de la factura de la base vectorial.

# Marco de estimación: cifras de ejemplo, no precios reales de ningún proveedor
docs_tokens = 40_000_000       # Tokens de entrada del corpus completo tras fragmentar
query_tokens = 2_000_000       # Tokens de vectorización de consultas al mes
reindex_per_month = 1          # Regeneraciones completas por mes
vector_gb = 12                 # Vectores, índices y réplicas combinados

embed_price_per_1k = 0.0       # Completa con el precio por mil tokens de la página de precios
storage_price_per_gb = 0.0     # Completa con el precio por GB de la base vectorial

monthly_embed = (docs_tokens * reindex_per_month + query_tokens) / 1000 * embed_price_per_1k
monthly_storage = vector_gb * storage_price_per_gb
print(monthly_embed + monthly_storage)

6. El orden para reducir costos no debe invertirse

Primero se gobierna la entrada y después se considera cambiar a un modelo más barato. El orden aproximado es:

  1. Limpieza: elimina navegación, encabezados, pies y plantillas repetidas; extrae el cuerpo antes de fragmentar.
  2. Fragmentación: divide por límites semánticos y usa solo el solapamiento necesario; no lo trates como un seguro.
  3. Separación en frío y caliente: no todo el contenido archivado debe entrar en la base vectorial; vectorízalo cuando haga falta.
  4. Caché de consultas: reutiliza el vector de preguntas frecuentes idénticas para reducir llamadas repetidas.
  5. Lotes: usa la interfaz por lotes para la indexación sin conexión y la interfaz en tiempo real para las consultas.
  6. Optimización del almacenamiento: elige bien la dimensión, evalúa la cuantización y dimensiona las réplicas según las consultas.
  7. Separación de modelos: evalúa por separado embeddings y generación; no sacrifiques calidad de recuperación por ahorrar en vectores.

Si se invierte el orden, el resultado habitual es haber cambiado a un modelo de embeddings algo más barato mientras el solapamiento sigue alto, el texto sucio no se limpia y la regeneración es frecuente: la factura apenas cambia y la recuperación empeora.

Preguntas frecuentes

¿Por qué la API de embeddings no cobra tokens de salida?

Los embeddings devuelven un vector de longitud fija, no texto generado, así que normalmente solo se factura la entrada. Algunas plataformas pueden cobrar por separado capacidades como el almacenamiento; consulta su documentación.

¿La interfaz por lotes siempre es más barata que la de tiempo real?

Suele tener un precio unitario menor, pero hay que considerar los plazos, los reintentos y si el gateway traslada el descuento. No sirve para consultas que necesitan respuesta inmediata: el ahorro se compensa con el tiempo de espera.

Después de cambiar el modelo de embeddings, ¿se puede regenerar solo una parte de los documentos?

Los espacios vectoriales de modelos distintos normalmente no son compatibles, y mezclarlos desordena la recuperación. Lo prudente es reconstruir todo, crear un índice paralelo, evaluarlo y luego cambiar; regenerar solo una parte generalmente no es viable.

¿Por qué el almacenamiento vectorial puede costar más que las llamadas de embeddings?

Porque el almacenamiento se factura de forma continua por capacidad, réplicas, solicitudes y salida de red, mientras que la vectorización es un costo único cuando los documentos no cambian. Con muchos datos, réplicas y consultas frecuentes, la segunda factura supera con facilidad a la primera.

Si la estimación no coincide con la factura real, ¿qué revisar primero?

Revisa primero la amplificación de tokens por solapamiento y texto sucio; después, los índices duplicados en entornos de prueba, los reintentos fallidos y si el descuento por lotes se aplicó; por último, las réplicas y los costos de salida de red de la base vectorial.

Próximos pasos

Si necesitas un punto de entrada unificado, facturación por uso y varios modelos, puedes registrarte en ZSQH AI Gateway, construir un índice y hacer una consulta con un presupuesto pequeño, y estimar después con el consumo real. Los modelos y precios se rigen por precios de modelos.

Lecturas relacionadas: