Precios de inferencia por lotes de la API de IA: cuándo los trabajos asíncronos permiten ahorrar dinero

Los precios de inferencia por lotes (batch) funcionan intercambiando latencia de respuesta por una tarifa por token más baja: usted envía un trabajo, el proveedor lo procesa dentro de una ventana definida (comúnmente hasta 24 horas) y usted paga menos de lo que pagaría por una llamada síncrona en tiempo real. Si ese intercambio vale la pena depende totalmente de si su carga de trabajo puede tolerar la espera.

Este artículo compara la inferencia por lotes (asíncrona) con las llamadas de API síncronas estándar, basándose en la documentación de la API de batch publicada por OpenAI y Google, y establece un marco de decisión sobre cuándo la ruta asíncrona realmente ahorra dinero para su producto.

Puntos clave

• OpenAI y Gemini publican una API de batch que acepta trabajos para procesamiento asíncrono a una tarifa con descuento frente a las llamadas síncronas; confirme el porcentaje de descuento exacto actual en la página de precios de cada proveedor antes de presupuestar, ya que las tarifas pueden cambiar.
• La inferencia por lotes se adapta a cargas de trabajo que toleran una ventana de respuesta en lugar de necesitar una respuesta inmediata: clasificación masiva, generación de embeddings, evaluación offline, etiquetado de conjuntos de datos y trabajos de backfill.
• El chat en tiempo real, los agentes de codificación y las funciones interactivas del producto generalmente no se ajustan a los precios por lotes, porque la ventana de procesamiento los hace inutilizables para la interacción en vivo del usuario.
• Los mayores ahorros acumulados suelen provenir de combinar descuentos por lotes con la selección de modelos y el trabajo de eficiencia de prompts; consulte /models/rankings y la guía de reducción de costos de API de IA para conocer las otras palancas.

Qué significa realmente la inferencia por lotes

Las llamadas de API síncronas devuelven una respuesta tan pronto como el modelo termina de generarla, generalmente en segundos. Usted paga una tarifa por token vinculada a esa inmediatez. La inferencia por lotes invierte el modelo: en lugar de un intercambio único de solicitud-respuesta, usted envía un archivo o una lista de solicitudes como un trabajo. El proveedor pone el trabajo en cola, lo procesa durante una ventana que él controla y pone los resultados a su disposición para que los recupere una vez completado.

Esta no es una técnica de inferencia nueva dentro del modelo. Es un contrato comercial y operativo diferente. El proveedor puede programar su carga de trabajo frente a capacidad sobrante o fuera de las horas pico y, a cambio, cobra menos por token de lo que cobraría por una solicitud que debe atender al instante.

Tanto OpenAI como Google documentan este patrón para sus respectivas API:

• La referencia de la Batch API de OpenAI describe la creación de un objeto de batch a partir de un archivo de solicitudes cargado, el seguimiento de su estado y la recuperación de la salida una vez que el trabajo se completa (platform.openai.com/docs/api-reference/batch/object).
• La documentación de la Gemini Batch API de Google describe un modelo comparable: enviar un lote de solicitudes, el trabajo se ejecuta de forma asíncrona y los resultados se recuperan después del procesamiento (ai.google.dev/gemini-api/docs/batch-api).

La mecánica difiere ligeramente entre proveedores (envío basado en archivos, objetos de trabajo, sondeo de estado, recuperación de salida), pero la forma subyacente es consistente: envíe ahora, recoja después, pague menos por token que el equivalente síncrono. Consulte la documentación actual de cada proveedor para conocer la ventana de procesamiento exacta y la tasa de descuento que se aplica a su cuenta y modelo, ya que estos detalles son específicos del proveedor y están sujetos a cambios.

Cómo funcionan las dos API de batch documentadas

A nivel mecánico, ambos proveedores siguen un ciclo de vida similar:

1. Preparar solicitudes. Usted reúne las solicitudes de inferencia individuales que desea procesar, generalmente formateadas como un archivo (OpenAI acepta un archivo de solicitudes codificadas por un ID personalizado; Gemini acepta un lote de solicitudes estructuradas).
2. Enviar el trabajo. Usted crea un objeto de batch o recurso de trabajo que hace referencia a su entrada cargada.
3. Sondear o esperar a que se complete. El trabajo pasa por estados (en cola, en progreso, completado o fallido) hasta que el proveedor termina de procesar dentro de su ventana documentada.
4. Recuperar salida. Una vez completado, usted descarga o obtiene el archivo de salida o el conjunto de resultados, haciendo coincidir cada respuesta con su solicitud original por ID.

Ninguno de los proveedores procesa trabajos por lotes al instante. Ese es el punto central del modelo de precios: el trabajo se ejecuta según el cronograma del proveedor, no el suyo, y usted acepta un retraso limitado a cambio de una tarifa más baja. Si su producto no puede tolerar ese retraso, los precios por lotes no están disponibles para usted, independientemente de cuánto ahorraría en papel.

Cuándo los precios por lotes ahorran dinero: una lista de verificación de decisiones

Utilice esta lista de verificación antes de enrutar una carga de trabajo a un endpoint de batch:

• ¿Tiene la carga de trabajo una forma natural no interactiva? La clasificación de un conjunto de datos, la generación de embeddings para un corpus de documentos, los barridos de moderación de contenido o los trabajos de resumen nocturnos encajan perfectamente.
• ¿Puede su producto tolerar la ventana de procesamiento documentada? Si un usuario o sistema posterior necesita el resultado en segundos o minutos, el batch no encaja.
• ¿Es el volumen lo suficientemente grande como para importar? Los descuentos por lotes se aplican por token, por lo que los ahorros absolutos escalan con el volumen. Un puñado de solicitudes no moverá su factura significativamente en ningún sentido.
• ¿Es la tarea idempotente o se puede reintentar de forma segura? Debido a que los trabajos por lotes se ejecutan de forma asíncrona y pueden fallar parcialmente, su pipeline debe manejar el reenvío o la finalización parcial sin corromper el estado posterior.
• ¿Su capa de orquestación ya admite el sondeo de trabajos asíncronos? Si está construyendo este patrón por primera vez, presupueste tiempo de ingeniería para el envío de trabajos, el sondeo de estado y la conciliación de resultados.

Dimensión	API Síncrona	API de Batch (asíncrona)
Latencia	Segundos, típicamente	Minutos a horas, limitado por la ventana documentada del proveedor
Precios	Tarifa estándar por token	Tarifa con descuento por token frente a la síncrona, según documentación del proveedor
Mejor uso	Chat, agentes, funciones de producto en vivo	Clasificación masiva, embeddings, evaluación offline, backfills
Manejo de fallos	Error inmediato en la llamada	Estado a nivel de trabajo; posibles fallos parciales dentro de un lote
Sobrecarga de ingeniería	Solicitud-respuesta simple	Requiere lógica de envío de trabajo, sondeo y recuperación de salida
Orden de salida	Coincide con el orden de llamada	Coincide por ID de solicitud personalizado, no por orden de llamada

Cuándo los precios por lotes no encajan

La inferencia por lotes es una mala opción para cualquier cosa donde una persona o un sistema posterior esté esperando la respuesta. Esto incluye:

• Agentes conversacionales y productos de chat. Un usuario espera una respuesta en segundos, no después de una ventana de procesamiento.
• Asistentes de codificación y flujos de trabajo de codificación agentic. Las herramientas construidas alrededor de modelos como Claude Sonnet 5 o Kimi K2.7 Code dependen de ciclos de retroalimentación estrechos entre el desarrollador y el modelo; el procesamiento por lotes rompería la interacción por completo.
• Generación de contenido en tiempo real para funciones orientadas al usuario, incluida la generación de imágenes o videos bajo demanda a través de API como Nano Banana Pro o Veo 3, donde el usuario está viendo un indicador de progreso.
• Cualquier cosa con un requisito de latencia de nivel de servicio, incluso si ese requisito es flexible (digamos, menos de un minuto). Las ventanas de batch se miden típicamente en horas, no en segundos.

Si parte de su pipeline es en tiempo real y otra no, divida el trabajo. Enrute la parte interactiva a través de la API síncrona y envíe la parte masiva y tolerante a retrasos (reindexación nocturna, reetiquetado de conjuntos de datos, ejecuciones de evaluación) al endpoint de batch.

Una forma de solicitud práctica

El esquema exacto difiere entre el objeto de batch de OpenAI y la API de batch de Gemini, así que trate lo siguiente como una forma ilustrativa en lugar de una copia literal del formato de solicitud de cualquiera de los proveedores. Confirme los nombres de campo exactos y los endpoints con la documentación actual antes de implementar esto.

# 1. Prepare un archivo de solicitudes, cada una con un ID personalizado
{"custom_id": "req-001", "method": "POST", "url": "/v1/chat/completions",
 "body": {"model": "your-selected-model", "messages": [{"role": "user", "content": "Classify this ticket."}]}}
{"custom_id": "req-002", "method": "POST", "url": "/v1/chat/completions",
 "body": {"model": "your-selected-model", "messages": [{"role": "user", "content": "Classify this ticket."}]}}

# 2. Envíe el trabajo de batch
POST /v1/batches
{
  "input_file_id": "file-abc123",
  "endpoint": "/v1/chat/completions",
  "completion_window": "24h"
}

# 3. Sondear el estado del trabajo
GET /v1/batches/{batch_id}
# devuelve estado: queued | in_progress | completed | failed

# 4. Recuperar salida una vez completado
GET /v1/files/{output_file_id}/content
# haga coincidir cada respuesta con su solicitud por custom_id

El patrón de ingeniería central es el mismo independientemente del proveedor: cree su archivo de solicitud con ID estables, envíe el trabajo, sondee la finalización y concilie la salida con su lista de solicitudes original. Construya lógica de reintento alrededor de fallos parciales a nivel de trabajo, ya que un lote puede completarse con algunas solicitudes individuales fallidas incluso si el trabajo en sí tiene éxito.

Combinación de descuentos por lotes con selección de modelos

Los precios por lotes son una palanca. Se combinan con, en lugar de reemplazar, las decisiones a nivel de modelo y prompt cubiertas en AI model routing benchmark y la guía de reducción de costos de API de IA. Una carga de trabajo que sea elegible para batch y atendida por un modelo de menor costo, como DeepSeek V4 Flash, GLM-5.2 o Gemini 3.5 Flash para tareas amigables con el enrutamiento, generalmente verá mayores ahorros absolutos que aplicando cualquiera de las palancas por separado. Antes de comprometer un gran trabajo masivo a un solo modelo y nivel de precios, verifique los precios y el posicionamiento actuales por modelo en /models/rankings, ya que los precios relativos entre los modelos de frontera y los de bajo costo cambian a medida que los proveedores actualizan sus ofertas.

Para los equipos que evalúan si construir soporte para batch, el cálculo es sencillo: estime su volumen mensual de tokens para tareas tolerantes a retrasos, compare el descuento por lotes documentado con su gasto síncrono actual en ese mismo volumen y compárelo con el costo de ingeniería de construir la lógica de envío de trabajos y sondeo. Si el volumen es pequeño, el descuento puede no compensar la complejidad añadida.

Limitaciones

Esta comparación se basa en la mecánica general documentada por OpenAI y Google para sus API de batch observada el 14-07-2026. Los porcentajes de descuento exactos, las longitudes de las ventanas de procesamiento, la disponibilidad por modelo y los requisitos de formato de archivo son específicos del proveedor, cambian con el tiempo y no se vuelven a indicar aquí como números fijos. Verifique los precios y términos actuales de batch directamente con la documentación de cada proveedor antes de presupuestar o construir. Este artículo tampoco cubre el soporte de batch de todos los proveedores de modelos; verifique si su modelo y proveedor elegidos publican un endpoint de batch antes de planificar en torno a uno.

Preguntas frecuentes

¿Qué tan más barato es la inferencia por lotes que las llamadas síncronas? Tanto OpenAI como Google documentan un descuento para el procesamiento por lotes en relación con su tarifa síncrona estándar, pero el porcentaje exacto es específico del proveedor y del momento. Consulte la página de precios actual de su proveedor y modelo antes de estimar los ahorros.

¿Qué sucede si mi trabajo de batch no termina dentro de la ventana de procesamiento? La documentación del proveedor describe los estados del trabajo (como en cola, en progreso, completado y fallido). Revise la documentación de cada proveedor sobre cómo maneja los trabajos que exceden la ventana de finalización, ya que el comportamiento puede diferir según el proveedor y está sujeto a cambios.

¿Puedo usar inferencia por lotes para funciones de chat en tiempo real? No. Los trabajos por lotes se procesan de forma asíncrona dentro de una ventana que puede durar desde minutos hasta muchas horas, lo que los hace inadecuados para cualquier carga de trabajo donde un usuario o sistema esté esperando una respuesta inmediata. Use la API síncrona para funciones interactivas y reserve los endpoints de batch para tareas de alto volumen tolerantes a retrasos.

Si está evaluando si los precios por lotes se ajustan a su carga de trabajo, compare las tarifas y clasificaciones actuales por modelo, luego comience mapeando sus trabajos tolerantes a retrasos con la lista de verificación anterior antes de comprometer tiempo de ingeniería en la lógica de envío de trabajos y sondeo.