)
¿Qué es la inferencia por lotes en LLMs?
La inferencia por lotes en LLMs es la práctica de agrupar múltiples solicitudes de IA en un único trabajo que se procesa de forma asíncrona, en lugar de enviar cada una en tiempo real. La Batch API de OpenAI y la Message Batches API de Anthropic ofrecen un 50% de descuento en costes para el procesamiento asíncrono por lotes, con resultados entregados en un máximo de 24 horas. La contrapartida es la latencia: el procesamiento por lotes no es para interacciones de usuario en directo, sino para cualquier carga de trabajo donde ninguna persona está esperando la respuesta en este momento.
TL;DR - Puntos clave
- La Batch API de OpenAI y la Message Batches API de Anthropic ofrecen un 50% de descuento frente a las APIs síncronas para el procesamiento asíncrono
- OpenAI admite hasta 50.000 solicitudes por archivo de lote (máx. 200 MB); Anthropic admite hasta 10.000 solicitudes por lote
- Ambos proveedores garantizan la finalización en 24 horas; los lotes de Anthropic suelen terminar en menos de 1 hora
- Los límites de tasa de lotes son un grupo separado al de tus límites estándar: usarlos no consume tu cuota síncrona
- El procesamiento por lotes es adecuado para clasificación, procesamiento de documentos, evaluación de modelos, etiquetado de datasets y generación de embeddings
- El procesamiento por lotes no es adecuado para chat en tiempo real, sistemas de seguridad en directo ni flujos donde el usuario está esperando la respuesta
- El descuento de lotes de Anthropic se acumula con los descuentos de caché de prompts, multiplicando el ahorro
- NeuralTrust TrustGate aplica políticas de enrutamiento por lotes automáticamente a nivel de gateway
Mitad de precio. Mismo modelo. Misma calidad de salida. Solo que no es instantáneo. Si tienes cargas de trabajo que no necesitan una respuesta en tiempo real, estás dejando el 50% de tu presupuesto de IA sobre la mesa. Esta guía explica cuándo procesar por lotes, cómo implementarlo en OpenAI y Anthropic, y qué falla si lo haces mal.
)
¿Por qué pagas precios en tiempo real por trabajo que no necesita una respuesta en tiempo real?
Imagina tu pipeline del lunes por la mañana. Tu sistema procesa 40.000 tickets de soporte al cliente a través de un clasificador para etiquetarlos por categoría y prioridad. Nadie está esperando los resultados ahora mismo. Los datos alimentan un informe que el equipo de operaciones lee a mediodía.
Estás enviando esas 40.000 solicitudes de forma síncrona. Una a una. Pagando el precio completo por cada una.
Ese es el problema. La mayoría de los equipos usan por defecto la inferencia síncrona porque es más sencilla de configurar. Llamas a la API, recibes la respuesta, sigues adelante. Pero la inferencia síncrona tiene un precio pensado para la velocidad. Estás pagando una prima por latencia de milisegundos en cargas de trabajo que no la necesitan.
OpenAI y Anthropic lo detectaron. Ambos construyeron una solución. Ambos la ponen al mismo precio: un 50% de descuento para las cargas de trabajo que estés dispuesto a ejecutar de forma asíncrona.
No es un descuento pequeño. A escala, es la diferencia entre un presupuesto de IA sostenible y uno que no lo es.
)
Cómo funciona el procesamiento por lotes
El mecanismo es sencillo. En lugar de enviar 1.000 solicitudes una a una, las agrupas en un archivo y las envías como un único trabajo. El proveedor procesa el trabajo de forma asíncrona y te entrega los resultados cuando termina.
Sin magia. Sin reentrenamiento. Los mismos modelos, los mismos prompts, la misma calidad de salida. Solo un mecanismo de entrega diferente.
Tres cosas cambian:
- El tiempo. No recibes la respuesta en 300 ms. La recibes en menos de 24 horas. En la práctica, mucho antes: Anthropic informa de que la mayoría de los lotes se completan en menos de 1 hora.
- El coste. Un 50% de descuento en tokens de entrada y salida en comparación con las llamadas API síncronas. Tanto OpenAI como Anthropic lo aplican de forma idéntica.
- Los límites de tasa. Tus solicitudes por lotes salen de una cuota separada. Los límites de tasa de la Batch API de OpenAI son un grupo independiente: no tocan tus límites estándar por modelo. Ejecutar un trabajo por lotes grande no limitará el tráfico en tiempo real de tu producción.
Batch API de OpenAI
La Batch API de OpenAI acepta un archivo JSONL donde cada línea es una solicitud API independiente. Subes el archivo, inicias el trabajo, consultas el estado y recuperas los resultados.
Especificaciones clave:
- Hasta 50.000 solicitudes por archivo de lote
- Límite de tamaño de archivo: 200 MB
- Ventana de finalización: 24 horas
- Descuento: 50% de ahorro en tokens de entrada y salida frente a la API síncrona
- Modelos compatibles: GPT-4o, GPT-4o mini, o3-mini y otros
Cada línea de tu JSONL tiene el aspecto de una solicitud estándar de chat completion, envuelta en un campo custom_id que usas para relacionar los resultados con las entradas. La gestión de errores es tu responsabilidad: si algunas solicitudes individuales fallan dentro del lote, el trabajo se completa igualmente; compruebas el estado por solicitud en el archivo de salida.
El grupo de límites de tasa separado tiene mucha importancia en la práctica. Equipos con tráfico síncrono de alto volumen han evitado históricamente el procesamiento por lotes por temor a consumir su cuota. Con un grupo separado, esa preocupación desaparece.
Message Batches API de Anthropic
La Message Batches API de Anthropic sigue el mismo patrón con algunas diferencias en los límites.
Especificaciones clave:
- Hasta 10.000 solicitudes por lote
- Finalización: típicamente menos de 1 hora, garantizado en 24 horas
- Descuento: 50% de ahorro en tokens de entrada y salida
- Modelos compatibles: Claude Sonnet 4.6, Claude Haiku 4.5 y otros
- Disponible en la API de Anthropic, AWS Bedrock y Google Cloud
Una ventaja que se multiplica: el descuento de lotes de Anthropic se acumula con los descuentos de caché de prompts. Si las solicitudes de tu lote comparten un system prompt común o un bloque de contexto grande, el descuento de tokens de entrada en caché se aplica sobre el 50% de descuento por lotes. Esa combinación puede reducir el coste efectivo por token significativamente más que cualquiera de los dos descuentos por separado.
La implementación es directa. Envías una lista de objetos requests, cada uno con un custom_id y un bloque params estándar en el formato de la Messages API. Consultas el estado del lote mediante una petición GET simple y recuperas los resultados cuando el estado muestra ended.
Qué cargas de trabajo son adecuadas para el procesamiento por lotes
Esta es la decisión que importa. El procesamiento por lotes no es para todo. Si te equivocas, frustrarás a los usuarios o romperás flujos críticos de seguridad.
El procesamiento por lotes encaja bien:
-
Clasificación y etiquetado a escala. Categorizar tickets, etiquetar contenido, enrutar documentos. Nadie espera estos resultados en tiempo real.
-
Procesamiento de documentos. Trabajos de resumen, extracción y transformación sobre un dataset fijo. Los resultados alimentan un sistema downstream, no a un usuario en directo.
-
Evaluación y benchmarking de modelos. Ejecutar miles de prompts de evaluación contra una nueva versión del modelo o un cambio en el prompt. Necesitas los resultados antes de una decisión de despliegue, no antes de una interacción de usuario.
-
Etiquetado y aumentación de datasets. Usar un LLM para anotar o limpiar datos de entrenamiento. Completamente offline. El procesamiento por lotes es ideal.
-
Generación de embeddings. Construir o actualizar un índice vectorial. Alto volumen, sin requisito de latencia.
-
Informes nocturnos y semanales. Cualquier trabajo de analítica programado que agrega salidas de LLMs en un dashboard o informe. El procesamiento por lotes no encaja:
-
Chat en tiempo real y copilotos. Los usuarios están esperando. Una respuesta en 24 horas no es una respuesta.
-
Sistemas de seguridad en directo. Si la salida del LLM determina si la acción de un usuario está permitida, esa decisión debe ser síncrona.
-
Detección de fraude y anomalías. Cualquier flujo que deba bloquear o marcar antes de que una transacción o evento se complete.
-
UX con streaming. Si la experiencia depende de ver los tokens llegar de forma incremental, el procesamiento por lotes rompe la experiencia de usuario por completo.
)
La disyuntiva entre latencia y coste
El 50% de descuento es real. La latencia también. Necesitas entender ambos antes de comprometer una carga de trabajo al procesamiento por lotes.
Inferencia en tiempo real: respuestas en 300-800 ms. Cuesta el doble por token. Adecuada para cualquier interacción de cara al usuario.
Inferencia asíncrona por lotes: respuestas en minutos u horas. Cuesta la mitad. Adecuada para cualquier carga de trabajo que puedas permitirte ejecutar en segundo plano.
El error que cometen los equipos es tratar esto como algo binario. No lo es. La mayoría de los sistemas en producción deberían ejecutar ambos en paralelo: síncrono para el tráfico de usuarios en directo, por lotes para la capa de procesamiento offline que corre junto a él.
¿Tu trabajo de re-ranking nocturno? Por lotes. ¿Tu clasificador de tickets de soporte que se ejecuta cada 15 minutos sobre tickets acumulados? Por lotes. ¿Tu asistente de chat en directo? Síncrono. ¿Tu evaluación de prueba A/B que se ejecuta sobre las conversaciones de ayer? Por lotes.
La pregunta clave para cada llamada LLM en tu sistema: ¿hay una persona esperando esta respuesta ahora mismo? Si la respuesta es no, tienes un candidato para procesamiento por lotes.
Comparativa de procesamiento por lotes de un vistazo
| Batch API de OpenAI | Message Batches de Anthropic | |
|---|---|---|
| Descuento | 50% en entrada + salida | 50% en entrada + salida |
| Máximo de solicitudes por lote | 50.000 | 10.000 |
| Tamaño máximo de archivo | 200 MB | N/A |
| SLA de finalización | 24 horas | 24 horas |
| Finalización típica | Horas | Menos de 1 hora |
| Grupo de límites de tasa | Separado del síncrono | Separado del síncrono |
| Se acumula con caché de prompt | Sí | Sí |
| Gestión de errores | Por solicitud en archivo de salida | Por solicitud en resultados |
Qué falla y cómo gestionarlo
El procesamiento por lotes traslada la responsabilidad de la recuperación de errores a ti. A diferencia de las llamadas síncronas, donde una solicitud fallida es una excepción que capturas de inmediato, un trabajo por lotes se completa aunque algunas solicitudes individuales dentro de él hayan fallado.
Tres cosas que debes incorporar en tu implementación:
1. Comprobación del estado por solicitud.
Cuando recuperes los resultados del lote, comprueba el campo de estado de cada solicitud individualmente. Un lote con estado "correcto" a nivel superior puede tener elementos fallidos dentro. Diseña tu lógica de parseo para separar los éxitos de los errores antes de procesar los resultados.
2. Lógica de reintento para los elementos fallidos.
Extrae los IDs de las solicitudes fallidas, reconstruye las entradas originales y reenvíalas como un nuevo lote o mediante fallback síncrono. No asumas que un lote completado significa resultados completos.
3. Procesamiento downstream idempotente.
El sistema que consume los resultados del lote debe poder procesar el mismo archivo de resultados dos veces sin producir efectos duplicados. Los lotes en ocasiones re-entregan resultados o tienen problemas de recuperación parcial. Haz que tu consumidor sea idempotente.
La guía de monitorización del uso de tokens de IA explica cómo instrumentar trabajos por lotes junto a tu tráfico síncrono para que tus datos de costes y atribución sean coherentes independientemente de qué ruta toma cada solicitud.
Aplicación a nivel de gateway
Implementar el enrutamiento por lotes a nivel de aplicación funciona. El problema es la consistencia: cada equipo necesita saber qué cargas de trabajo enviar por lotes, cada nuevo pipeline arranca con valores síncronos por defecto, y no hay aplicación forzada si un equipo lo olvida.
NeuralTrust TrustGate aplica políticas de enrutamiento por lotes a nivel de gateway. Las rutas que configuras como aptas para lotes se dirigen automáticamente a la batch API, con max_tokens, modelo y etiquetas de atribución aplicados de forma coherente. Tu cuota síncrona se mantiene limpia. Tu cuota de lotes se usa donde debe usarse.
Esto encaja con la guía de enrutamiento de modelos LLM: enruta por complejidad a nivel de modelo y por tolerancia a la latencia a nivel síncrono/lote. Ambas decisiones ocurren en el gateway, no en el código de aplicación.
Para una visión completa de las palancas de reducción de costes, la guía de reducción de costes LLM y el pilar de optimización de tokens de IA explican cómo el procesamiento por lotes encaja junto a la caché, la compresión y el enrutamiento en una estrategia de costes completa.
Preguntas frecuentes acerca de LLM batching e inferencia asíncrona:
1. ¿Cuándo debo usar inferencia por lotes en lugar de inferencia en tiempo real?
Usa inferencia por lotes cuando ninguna persona está esperando el resultado en tiempo real. Buenos candidatos: pipelines de clasificación, procesamiento de documentos, evaluación de modelos, etiquetado de datasets, generación de embeddings y cualquier trabajo de informes programado. Mantén la inferencia síncrona para chat en directo, sistemas de seguridad, detección de fraude y cualquier UX donde el usuario ve la respuesta mientras se genera.
2. ¿Cuánto cuesta la Batch API de OpenAI?
La Batch API de OpenAI cuesta un 50% menos que la API síncrona estándar tanto para tokens de entrada como de salida. El descuento se aplica a todos los modelos compatibles. Los límites de tasa de la Batch API son un grupo separado al de tus límites estándar, por lo que los trabajos por lotes no afectan a tu cuota síncrona.
3. ¿Cuánto tardan en completarse los trabajos por lotes?
OpenAI garantiza la finalización en 24 horas. Anthropic garantiza 24 horas pero informa de que la mayoría de los lotes se completan en menos de 1 hora. El tiempo real de finalización depende de la carga de la cola en el momento del envío y del tamaño del lote.
4. ¿Puedo usar el procesamiento por lotes con la caché de prompts?
Sí. En la API de Anthropic, el descuento de Message Batches se acumula con los descuentos de caché de prompts. Si las solicitudes de tu lote comparten un bloque de contexto común grande (system prompt, documentos), el descuento de tokens de entrada en caché se aplica sobre el 50% de descuento por lotes, multiplicando el ahorro.
5. ¿Qué ocurre si algunas solicitudes de mi lote fallan?
El trabajo por lotes se completa aunque fallen solicitudes individuales dentro de él. Eres responsable de comprobar el estado por solicitud en el archivo de resultados, extraer los elementos fallidos y reenviarlos. Diseña tu consumidor de resultados para que sea idempotente y separar los éxitos de los errores antes de cualquier procesamiento downstream.
Artículos relacionados:
- Optimización de Tokens de IA: Guía Completa para Reducir los Costes de LLM
- Compresión de Prompts: Reduce los Costes de Tokens Sin Perder Calidad
- Estrategias de Caché para LLM: Caché de Prompts, Caché Semántico y Cuándo Usar Cada Uno
- Reducción de Costes de LLM: 12 Estrategias para Bajar los Costes de Inferencia de IA
- Optimización Ventana de Contexto: 6 Estrategias para LLMs (2026)
- Enrutamiento de Modelos LLM: Envía Consultas al Modelo Correcto Automáticamente
- Monitorización del Uso de Tokens: Rastrea, Atribuye y Optimiza el Gasto en IA
- Control de Longitud de Salida: Cómo Evitar que los LLMs Generen Tokens de Más
Acerca del autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde lidera la estrategia de búsqueda de la empresa en SEO, AEO, GEO y optimización para LLMs. Especializado en búsqueda potenciada por IA, estrategia de contenidos, desarrollo de enlaces y SEM. Conecta en LinkedIn.
NeuralTrust es una plataforma de seguridad para agentes de IA, reconocida en la Guía de Mercado de Gartner 2025 para AI Gateways y Guardian Agents, el Gartner Hype Cycle for Application Security 2026 y el KuppingerCole Leadership Compass 2025 para Generative AI Defense. Certificada ISO 27001. Sede central en Barcelona.