Batch API o llamadas en tiempo real: cómo elegir el canal correcto para cada carga de trabajo

Primero, distingue las dos escalas de tiempo

La sensibilidad al tiempo de las llamadas a LLM varía enormemente. Un usuario que espera una respuesta en un chat tolera segundos; una tarea de generación de informes diarios de un equipo puede tolerar horas. El canal batch está diseñado precisamente para lo segundo: encola las solicitudes, las procesa de forma agrupada y cambia un tiempo de finalización más largo por un precio por token más bajo.

La [documentación de batch processing](https://platform.claude.com/docs/en/build-with-claude/batch-processing) de Anthropic y su [página de precios](https://claude.com/pricing) listan por separado el precio del nivel batch; en el lado de OpenAI también existe el batch correspondiente y descuentos por procesamiento por lotes. Lo común es el descuento sobre el precio estándar; la diferencia está en la forma de envío y la ventana de finalización.

Marco de decisión: cuatro preguntas

1. ¿Hay alguien esperando este resultado de forma síncrona? Sí → tiempo real. No → continuar.
2. ¿El resultado puede llegar unas horas más tarde? Sí → candidato a batch. Debe ser en minutos → tiempo real.
3. ¿Las solicitudes son un conjunto enumerable offline? Sí (un lote de documentos, un lote de tickets, un lote de muestras de evaluación) → batch es muy adecuado.
4. ¿Es alto el coste de reintentar tras un fallo? Alto → tiempo real para obtener retroalimentación inmediata; bajo → el reintento masivo por batch es más rentable.

Lista de escenarios batch típicos

• Clasificación y etiquetado de contenido: un sistema unificado de etiquetas para cientos de miles de productos, reseñas y tickets.
• Limpieza de datos offline: extraer en lote campos estructurados a partir de texto no estructurado.
• Evaluación de regresión: antes de cambiar un prompt, ejecutar un conjunto de evaluación fijo para comparar.
• Resumen / traducción masivos: organización offline de bibliotecas de documentos, registros de atención al cliente y actas de reuniones.
• Generación de datos sintéticos: generar muestras en lote para entrenamiento o evaluación.

Los escollos de batch: éxito parcial y reintentos

Un trabajo batch no es 'todo o nada'. En un trabajo de cientos de solicitudes, normalmente algunas fallan por errores de parámetros, entradas demasiado largas o políticas de contenido. A nivel de ingeniería hay que lograr:

• Registrar el resultado de cada elemento, no tratar el éxito o fracaso de todo el lote como un valor booleano.
• Distinguir lo reintentable de lo no reintentable: 429 / 5xx son reintentables; reintentar un error de parámetros 400 no sirve de nada.
• Claves de idempotencia: el reenvío repetido de la misma información de negocio no debe provocar facturación duplicada ni escrituras duplicadas.
• Simulación previa de costes: estimar un límite superior por tokens antes de enviar, para evitar facturas inesperadas por un solo trabajo.

Gestionar ambos canales con una sola pasarela

Separar tiempo real y batch en dos conjuntos independientes de cuentas, claves y facturación es la deuda arquitectónica más común: cuando cambia un precio hay que actualizar dos sitios, y para investigar un fallo hay que revisar dos paneles.

El enfoque de Admesh es una sola Base URL, un solo conjunto de claves y una sola factura: en el lado del negocio, el tipo de tarea decide por qué canal ir, mientras que el catálogo de modelos y el precio unitario provienen siempre de la misma configuración de backend, y el margen y el uso se consultan en el mismo lugar.

Ver límites de tasa y concurrencia →