Batch API para LLM: millones de tokens a mitad de precio (2026)

Tienes un trabajo que ejecuta 5,000 solicitudes cada noche, tarda dos horas y nadie revisa el resultado hasta la mañana. Y lo estás pagando a precio de realtime — porque en algún punto del camino, “la API” se convirtió en “la API síncrona”, y el endpoint de batch con su descuento del 50% nunca llegó a la arquitectura.

Esa es la fuga de costos más común en los presupuestos de LLM de 2026: trabajo tolerante a demoras pagando tarifas de realtime. Todos los proveedores importantes ya descuentan las cargas de trabajo asíncronas en aproximadamente 50% — el mercado de la batch API para LLM se estandarizó en la mitad de precio — la batch API de OpenAI con su ventana de finalización de ~24 horas, Message Batches de Anthropic con una ventana de ~1 hora, el nivel batch de Gemini y DeepSeek aplicando la misma idea con sus precios pico/fuera de pico. El dinero está sobre la mesa, y esta guía trata de recogerlo: qué son las batch APIs, la matriz proveedor por proveedor, un flujo de trabajo que puedes copiar, la regla de decisión batch vs. realtime y la matemática de combinación que acumula los ahorros de batch con el caché y el routing.

Qué es la Batch API

En resumen: batch = envía ahora, recoge después, paga la mitad — todos los proveedores importantes se estandarizaron en la misma forma.

El mecanismo es consistente en todas partes: envías un archivo de solicitudes (JSONL), el proveedor las pone en cola, las procesa cuando la capacidad lo permite y recoges los resultados cuando el batch se completa. Sin streaming, sin latencia interactiva — el descuento es la compensación por la flexibilidad.

La matriz de proveedores 2026:

Proveedor	Descuento	Ventana de finalización	Notas
OpenAI	~50%	~24 horas	la implementación de referencia
Anthropic	~50%	~1 hora	la ventana más rápida de las cuatro
Gemini	~50%	nivel flexible	el batch se asigna al nivel de inferencia Flex
DeepSeek	precios fuera de pico	ventanas pico/fuera de pico	la misma idea vía el reloj, vigente desde agosto de 2026

La comparación entre proveedores sigue los detalles; el patrón es idéntico — si puedes esperar, pagas la mitad.

Por qué el procesamiento por batch ahorra dinero de verdad

En resumen: un 50% de descuento en la partida más grande de tu factura es una decisión de precios, no una optimización.

La matemática es deliberadamente aburrida. Supongamos que tu factura mensual es de $1,000 y el 60% es trabajo tolerante a demoras (evals, indexación, enriquecimiento, generación nocturna). Mover esos $600 al batch: $300 ahorrados al mes, $3,600 al año, cero cambios en calidad. Los tokens de salida son idénticos; la única diferencia es cuándo llegan.

Dos advertencias mantienen honesta la matemática:

1. El descuento se aplica a nivel del proveedor, no de la plataforma. Un endpoint unificado cobra lo que cobra el proveedor subyacente — las tarifas de batch pasan como tarifas de batch. Nuestro playbook de optimización de costos cubre la pila completa de palancas; el batch es la palanca con el menor costo de ingeniería.
2. El batch no es gratis. Es medio precio. La otra mitad todavía se beneficia del caché y el routing — que es la matemática de acumulación de la sección cinco.

Cómo construir un flujo de trabajo por batch

En resumen: el flujo tiene cuatro piezas — envío, idempotencia, recolección, recuperación — y la recuperación es la que todos se saltan.

El esqueleto, agnóstico al proveedor en su forma — el formato de solicitud sigue la documentación del endpoint de chat completions:

import json
from openai import OpenAI

client = OpenAI()  # point at your provider or unified endpoint

# 1. Build the JSONL request file
with open("batch.jsonl", "w") as f:
    for i, task in enumerate(tasks):
        f.write(json.dumps({
            "custom_id": f"task-{i}",          # idempotency key — never omit
            "method": "POST",
            "url": "/v1/chat/completions",
            "body": {"model": "gpt-4o-mini", "messages": task["messages"]},
        }) + "\n")

# 2. Submit once — the custom_id makes retries safe
batch = client.batches.create(input_file=upload(batch_path), endpoint="/v1/chat/completions")

# 3. Poll or webhook until complete, then map results back by custom_id
# 4. Recover: failed rows get re-queued into the NEXT batch, not re-run inline

Cuatro reglas que lo mantienen a nivel producción:

1. El custom_id es tu contrato. La idempotencia es lo que hace seguros los reintentos; sin ella, un parpadeo de red durante el envío duplica el trabajo y la factura.
2. Recoge por ID, no por orden. Los resultados del batch llegan en orden arbitrario; mapea el custom_id de vuelta a tus registros o escribirás mal el join dos veces.
3. Los webhooks superan al polling a escala. Un callback de finalización reemplaza el bucle de “revisar cada 5 minutos”; la referencia de códigos de error te dice qué fallos son reintentables.
4. La recuperación es una cola, no un parche. Las filas fallidas vuelven al siguiente ciclo de batch. Los equipos que reejecutan los fallos inline son los que descubren los límites de tasa del batch de la peor manera.

Cómo elegir: batch vs. realtime

En resumen: la decisión es una sola pregunta — ¿puede este trabajo esperar? — con dos excepciones explícitas donde la respuesta siempre es no.

La regla de decisión, expresada sin rodeos:

• ¿Puede el trabajo esperar una hora? Al batch.
• ¿Puede esperar un día? Al batch en el proveedor con la ventana que mejor encaje en tu presupuesto.
• ¿Hay un usuario esperando? Nunca al batch.
• ¿Es un bucle de agente? Nunca al batch.

La segunda excepción merece énfasis: los bucles de agente parecen candidatos al batch solo por su volumen de tokens, pero sus solicitudes están encadenadas causalmente — cada llamada depende de la anterior — lo que los hace interactivos por construcción. Las arquitecturas de voice agent y chatbot de soporte de esta serie son interactivas por la misma razón. El batch es para trabajo paralelizable con una fecha límite, y ese conjunto es más pequeño de lo que la mayoría de los equipos cree — lo que hace que el 50% sea aún más valioso donde sí aplica.

Cómo acumular ahorros: batch × caché × routing

En resumen: batch, caché y routing se multiplican — un trabajo de batch que reutiliza prefijos en caché en un modelo económico cuesta una fracción de la versión ingenua.

Las tres palancas no se superponen, que es exactamente por qué se acumulan:

1. Batch — 50% de descuento sobre la tarifa base para trabajo tolerante a demoras.
2. Prompt caching — prefijos de entrada en caché a ~0.1×, y los trabajos de batch son cargas de trabajo ideales para el caché: las mismas plantillas se ejecutan miles de veces, así que los prefijos byte-estables aciertan casi siempre. La guía de caché tiene la mecánica; la sinergia con el batch es el multiplicador.
3. Routing — el nivel de modelo para el batch es una decisión de routing: evals en un modelo de frontera porque estás midiendo la frontera; enriquecimiento en un modelo económico porque nadie lo lee. La documentación de optimización de producción cubre la mecánica del routing.

Un ejemplo resuelto: un trabajo de enriquecimiento nocturno de 10M de tokens. Tarifa base en un modelo de nivel medio: $30. Batch: $15. El mismo trabajo con prefijos estables acertando el caché a 0.1× en el lado de entrada (digamos que el 80% de los tokens están en caché): aproximadamente $4-6. El mismo trabajo, la misma calidad de salida, una config de routing y una plantilla de prompt estable después. El quickstart conecta el pipeline en minutos; el multiplicador es la parte que se compone.

Errores comunes que inflan tu factura

En resumen: cuatro formas de deshacer el descuento — cada una convierte silenciosamente el 50% de nuevo en 100%.

1. Evaluar sobre filas fallidas. Ejecuta tu eval solo sobre las filas completadas del batch; las filas fallidas son un problema de calidad de datos, e incluirlas produce una puntuación falsa contra la que optimizarás. La disciplina de eval estilo CI de la guía de testing de esta serie muestra el patrón.
2. Dejar que los resultados expiren. Los resultados del batch tienen ventanas de retención; un trabajo que termina mientras estás de vacaciones y expira antes de la recolección es un trabajo a precio completo sin salida. Conecta la recolección al evento de finalización, no a tu calendario.
3. Ignorar los límites de tasa específicos del batch. Las cuotas de batch son separadas de las de realtime — los equipos que asumen los mismos límites descubren su propio techo a mitad del batch.
4. Saltarse la idempotencia. Sin custom_id, no hay reintento seguro ni ruta de recuperación — los cuatro caracteres más caros que puedes omitir.

FAQ

¿Cuánto ahorran realmente las batch APIs?

Alrededor del 50% en los niveles batch de OpenAI, Anthropic y Gemini, con el esquema pico/fuera de pico de DeepSeek como equivalente basado en el reloj. Los ahorros son por token, así que escalan con tu volumen tolerante a demoras — la partida más grande de la mayoría de las facturas.

¿Cuánto tarda en completarse un batch?

La ventana de OpenAI es de ~24 horas, la de Anthropic de ~1 hora, la de Gemini está ligada a su nivel Flex y las ventanas fuera de pico de DeepSeek las define el reloj. Elige el proveedor cuya ventana se ajuste a tu fecha límite; el descuento es el mismo.

¿Puedo ejecutar evals en modo batch?

Sí — los evals son la carga de trabajo canónica del batch. Ejecútalos solo sobre las filas completadas, mantén la plantilla de prompt byte-estable para los aciertos de caché y haz que el CI dependa de la puntuación del batch completado.

¿El batch funciona con el prompt caching?

Excepcionalmente bien — los trabajos de batch repiten las mismas plantillas miles de veces, que es el perfil ideal de caché. Prefijos estables + batch = la acumulación de descuentos de esta guía.

¿Qué cargas de trabajo nunca deberían ir a batch?

Todo lo que un usuario espera, y todo lo que esté encadenado causalmente — los bucles de agente y el voice/chat interactivo son realtime por construcción. La decisión del batch es “¿puede esperar?”, no “¿es grande?”.

¿Los endpoints unificados transmiten los descuentos de batch?

Sí — las tarifas de batch son tarifas del proveedor, y el endpoint cobra lo que cobra el proveedor, con el descuento intacto. El trabajo del endpoint es una llave y un dashboard; el 50% es del proveedor y fluye a través de él.

Resumen

El panorama de la batch API para LLM en 2026 está notablemente estandarizado: aproximadamente 50% de descuento en todos los proveedores importantes, con las ventanas de finalización como único diferenciador real. La jugada es mecánica — encuentra la porción tolerante a demoras de tu carga de trabajo, muévela a batch, mantén los prefijos estables, enruta el nivel de modelo por tarea — y la combinación de batch, caché y routing suele quedar 60-80% por debajo de la factura ingenua. El descuento está sobre la mesa; la única pregunta es si tu arquitectura lo recoge.

Toma el 60% tolerante a demoras de tu factura y redúcelo a la mitad. Obtén tu API key de TokSpan — $5 gratis para gastar en tu primer batch — y deja que los costos por trabajo te muestren los ahorros.