Las API por lotes de los LLM reducen el precio a la mitad, pero solo para el tráfico que puede esperar

Cómo funciona el descuento por lotes

Entre los descuentos disponibles en los precios de los LLM, la API por lotes es el más sencillo: las solicitudes se envían como un archivo en lugar de un flujo, los resultados llegan en un plazo de 24 horas en lugar de un par de segundos y el precio se reduce a la mitad. No exige ingeniería de prompts, ni migración de modelo, ni sacrificio de calidad, y casi todos los grandes proveedores lo ofrecen con la misma cifra. Según el autor, la verdadera cuestión no es si funciona, sino si un 50% de rebaja debería ser la primera palanca de costes a la que recurrir — y para la mayoría de los equipos no debería serlo. La aritmética que sigue se calcula a partir del catálogo del sitio, verificado el 11.11.2026.

El 50% es un techo, no una tarifa

De los 18 modelos del catálogo, 16 ofrecen una modalidad por lotes, y todos la tarifan a exactamente la mitad del precio en tiempo real, tanto en entrada como en salida. Esa uniformidad hace que la cifra principal sea fácil de aplicar mal, porque el descuento solo alcanza al tráfico que realmente puede aplazarse:

ahorro efectivo = 50% × (proporción de llamadas que pueden esperar)

• 100% apto para lotes da un 50% de descuento
• 60% apto para lotes da un 30% de descuento
• 20% apto para lotes da un 10% de descuento

Pocos productos son totalmente aplazables. Un chatbot está en 0% porque hay un usuario esperando; un pipeline de RAG está en 0% en el momento de la consulta, aunque las pasadas de embeddings y resumen que hay detrás quizá no lo estén. Las cargas de trabajo que sí cumplen el requisito son las rutinarias: procesamiento documental nocturno, clasificación masiva, rellenos históricos, evaluaciones y generación de datos sintéticos. Por eso el arquetipo Document processor del sitio es el único preajuste que activa el modo por lotes de forma predeterminada.

Un ejemplo concreto

Para 5.000 documentos al día con 8.000 tokens de entrada y 800 de salida cada uno, y con el resto de parámetros por defecto del motor — un 8% de reintentos, una tasa de aciertos de caché del 40%, un 15% de sobrecoste de infraestructura y calibración del tokenizador por modelo — los costes mensuales son:

El ahorro queda justo por debajo del 50% en lugar de alcanzarlo exactamente. La diferencia la explican los reintentos: una llamada fallida sigue consumiendo tokens, y el motor tarifa ese sobrecoste a precios de tiempo real — una desviación pequeña y deliberadamente conservadora.

Lotes y caché no se suman

Esta es la parte que confunde a la gente, y la que provocó un error en el propio motor de los autores. Si la caché ahorra aproximadamente un 90% en la entrada y el modo por lotes un 50% en todo, resulta tentador sumar ambas cifras — o, de forma más razonable, esperar que el lote descuente otro 50% sobre una factura ya rebajada. Ninguna de las dos cosas ocurre.

Los proveedores acumulan los dos descuentos de forma multiplicativa, y la tarifa por lotes se aplica sobre lo que realmente se factura. Una lectura cacheada dentro de un trabajo por lotes cuesta cached_rate × 0.5, de modo que el descuento por lotes se calcula sobre el gasto posterior a la caché y no sobre el precio de lista:

in_spend      = in_cost - cache_savings        # what you're actually billed
batch_savings = (in_spend × 0.5 + out_cost × 0.5) × batch_pct

La consecuencia es poco intuitiva: con un 100% de elegibilidad para lotes, la factura es exactamente la mitad, y la tasa de aciertos de caché no altera ese resultado. La caché y el lote no son palancas aditivas que se apilen hacia un descuento mayor: la caché determina cuánto se gasta y el lote reduce a la mitad lo que resulte.

Aun así, conviene conocer un efecto de segundo orden. Como la caché reduce el lado de entrada de la factura, desplaza dónde actúa el descuento por lotes. En esta carga de trabajo, la entrada de Claude Sonnet 5.5 representa el 67% del coste bruto por llamada, pero una vez aplicada una tasa de aciertos del 40%, la entrada que aún se paga supone solo el 55% de la factura. Cuanto mejor es la caché, mayor parte del descuento por lotes recae en realidad sobre los tokens de salida: el trabajo intensivo en salida se beneficia más del lote de lo que sugiere la tarifa, mientras que el intensivo en entrada con buena caché se beneficia menos.

El artículo reconoce que esto se implementó mal en un principio: el motor aplicaba el descuento por lotes sobre el precio de lista de la entrada mientras restaba por separado el ahorro de caché de los mismos tokens, descontándolos dos veces e infravalorando los costes del procesador de documentos entre un 10% y un 27%. El error era mayor en los modelos con mayores descuentos de caché. Se corrigió el 31.08.2026 y la fórmula anterior es la que ahora está en producción. Los lectores pueden fijar su propia proporción elegible para lotes y su tasa de aciertos de caché en la calculadora del sitio.

Bajar de nivel sigue ganando al modo por lotes

El lote está limitado al 50%, pero la distancia entre niveles de capacidad no. En la misma carga de trabajo, Claude Sonnet 5.5 con todas las llamadas por lotes cuesta $2,648 al mes, mientras que Claude Haiku 5.5 a precio completo en tiempo real — respondiendo al instante — cuesta $262 al mes. El nivel más barato gana por aproximadamente un 90% y devuelve la latencia. El orden que el artículo recomienda interiorizar: elegir el nivel que la tarea realmente necesita, hacer funcionar la caché y solo entonces decidir qué puede esperar 24 horas. Acudir primero al lote significa aceptar una restricción dura de latencia para capturar la menor de las tres palancas.

Donde el modo por lotes ni siquiera existe

Dos de los 18 modelos carecen por completo de modalidad por lotes: Muse Spark Open 816B y Muse Glimmer 30B. Ambos son modelos de pesos abiertos servidos en plataformas de inferencia, y el artículo interpreta la ausencia como una decisión de producto y no como un descuido: esas plataformas venden latencia, así que una cola lenta y barata equivaldría a competir en el eje que deliberadamente rechazaron. Si la economía de los lotes es estructural para una arquitectura, esas filas quedan descartadas sin importar su precio.

El descuento de DeepSeek es un reloj, no un endpoint

Hay una excepción genuina que conviene conocer. DeepSeek no tiene API por lotes; lo que ofrece es precio fuera de hora punta, con un 50% de descuento en cada token fuera de las franjas 01:00–04:00 y 06:00–10:00 UTC. El sitio lo modela en los campos de lotes porque la aritmética es idéntica, pero el mecanismo es mejor en un aspecto concreto: la tarifa rebajada llega con latencia de tiempo real, solo que durante ciertas horas, algo que ninguna modalidad por lotes ofrece. Si el trabajo masivo ya se ejecuta de noche en una zona horaria europea o estadounidense, puede que ya esté pagando la tarifa rebajada sin cambiar nada.

Cuándo el 50% de descuento sí merece la pena

• Cuando el trabajo es genuinamente asíncrono — no que "los usuarios tolerarían la lentitud", sino que nadie espera en absoluto: trabajos nocturnos, rellenos históricos, evaluaciones, clasificación masiva.
• Después de haber elegido el nivel. Bajar de nivel suele superar todo el descuento por lotes y no cuesta latencia, así que debe hacerse primero.
• Cuando la proporción elegible es la mayor parte del volumen. Con un 20% de elegibilidad se persigue un 10% de ahorro añadiendo una cola, un bucle de sondeo y un modo de fallo: complejidad que hay que pagar en alguna parte.
• Cuando la cola de espera es tolerable. El SLA es "within 24 hours", no "en torno a una hora"; cualquier cosa con fecha límite diaria necesita una vía de respaldo en tiempo real, es decir, un segundo camino de código que mantener.
• No como sustituto de la caché. La caché reduce lo que se gasta y el lote lo divide a la mitad, de modo que la primera debería estar funcionando antes de aceptar una restricción de latencia por la segunda.