Optimiza el procesamiento por lotes en las API de IA serverless

Si tus trabajos de IA no necesitan respuestas instantáneas, el procesamiento por lotes suele ser el mejor camino. Yo lo usaría para reducir el coste de API en aproximadamente un 50%, mantener el trabajo en segundo plano alejado del tráfico en vivo y procesar grandes cargas de texto, imagen, audio o vídeo sin meter todo dentro de una sola función serverless.

Aquí va la versión corta:

• Yo usaría colas, workers sin estado y almacenamiento de objetos en lugar de una única función de ejecución prolongada.

• Yo empezaría con 100 a 500 elementos por lote para muchos trabajos de LLM, y luego reduciría el tamaño del lote para trabajos con mucho contenido multimedia.

• Yo limitaría la concurrencia dentro de la función a alrededor de 5 a 10 solicitudes por worker y vigilaría los tokens por minuto, no solo el número de solicitudes.

• Yo añadiría checkpoints cada 10 a 50 elementos, 3 a 5 reintentos, backoff exponencial y una cola de mensajes fallidos (dead-letter queue).

• Yo haría cada elemento idempotente con una clave estable como job_id:item_id y usaría rutas de salida deterministas.

• Yo haría seguimiento de elementos por minuto, duración del lote, tasa de reintentos, tasa de errores y coste por lote en USD.

• Yo probaría los nuevos trabajos con un piloto de 10 a 50 elementos antes de escalar.

La idea principal es simple: los pipelines de IA por lotes funcionan mejor cuando los diseño pensando primero en los límites. Los timeouts serverless, los límites de memoria, los límites de payload y el throttling del proveedor moldean el tamaño del lote, el fan-out, los reintentos y los patrones de almacenamiento.

Para flujos de trabajo con múltiples modelos, yo también mantendría simple la capa de API. Un servicio unificado como APIMart puede ayudar cuando un pipeline necesita enrutar entre más de 500 modelos para tareas de texto, imagen y vídeo sin lógica de proveedor separada en cada worker.

Lo que más importa no es la velocidad bruta. Es el rendimiento, la seguridad de los reintentos y el control de costes por ejecución.

Serverless AI Inference: Scalable, Cost-Efficient Model Serving Explained | Uplatz

Cómo diseñar un pipeline por lotes serverless escalable

Esos límites te empujan hacia una configuración respaldada por colas.

Componentes centrales del pipeline y flujo de datos

Un pipeline por lotes escalable tiene cuatro partes: un productor, una cola de mensajes duradera, un pool de workers y un almacén de resultados.

Aquí está el flujo básico: el productor sube los payloads grandes al almacenamiento de objetos y luego coloca un trabajo ligero en la cola. Los workers toman ese trabajo, obtienen el payload, llaman a la API de IA, guardan el resultado y solo entonces confirman el mensaje. Ese último paso importa. Si un worker se cae en mitad de un trabajo, el mensaje sin confirmar vuelve a aparecer para que otro worker pueda reintentarlo ^[6][7].

Si un trabajo es demasiado grande para terminar dentro del timeout de una función, divide el conjunto de datos en lotes más pequeños y reparte el trabajo entre workers paralelos a través de un orquestador de larga duración.

Una vez que ese flujo base funciona, el siguiente paso es enrutar los trabajos por modalidad y runtime.

Cuándo dividir los flujos de trabajo por modalidad

Usa colas separadas cuando el tamaño del payload o el tiempo de procesamiento cambien de forma significativa. No toda tarea de IA debería vivir en el mismo pool de workers. La clasificación de texto puede tardar unos pocos segundos por elemento. Los trabajos multimedia pesados pueden ejecutarse durante minutos. Pon ambos en un mismo pool y el comportamiento de los timeouts se vuelve un lío rápidamente ^[4][7].

Un mejor enfoque es dividir las colas por runtime y tamaño de payload, no solo por tipo de archivo. Enruta los trabajos por tipo de evento. Por ejemplo, envía PDF, imágenes, audio y vídeo a colas y pools de workers separados con filtros de eventos. Eso mantiene los reintentos aislados y evita que una carga de trabajo atasque a otra ^[8].

Usar APIMart como capa de API de IA unificada

Cuando un pipeline maneja tareas de texto, imagen y vídeo, hacer malabares con integraciones de proveedores separadas puede convertirse en un quebradero de cabeza de mantenimiento ^[2][6]. APIMart te da una sola API para más de 500 modelos de IA, incluidos modelos de lenguaje como GPT-5 y Claude, modelos de imagen y modelos de vídeo como Sora y Kling V3.

Eso significa que las funciones worker pueden mantenerse sin estado y consistentes entre distintos tipos de trabajo. También ayuda cuando diferentes etapas del pipeline necesitan diferentes modelos, porque la autenticación, los límites de tasa y la lógica de reintentos quedan todos detrás de un único punto de integración.

Cómo elegir el tamaño de lote y el modelo de paralelismo adecuados

Una vez definida la arquitectura de tu pipeline, la siguiente decisión es simple en teoría pero fácil de arruinar en la práctica: ¿cuánto trabajo debería manejar cada worker a la vez y cuántas solicitudes deberían ejecutarse en paralelo?

Si los lotes son demasiado pequeños, malgastas cómputo en sobrecarga. Si son demasiado grandes, los fallos salen caros porque los reintentos ocurren tarde y rehacen demasiado trabajo. El punto óptimo suele salir de equilibrar el runtime, el uso de memoria y el coste de los reintentos.

Equilibra el tamaño del lote frente al runtime, la memoria y los reintentos

Para la mayoría de las cargas de trabajo de LLM, 100–500 elementos por lote es un buen rango inicial. Es lo bastante grande para repartir la sobrecarga de orquestación entre más trabajo, pero aún lo bastante pequeño como para que un fallo no te obligue a reejecutar un fragmento enorme.

Los reintentos hacen que esto sea fácil de visualizar. Si un worker se cae cerca del final de un lote enorme, puede que tengas que rehacer todo ese trabajo. Por eso ayuda hacer un checkpoint cada 10–50 finalizaciones, de modo que una caída solo rehaga una pequeña porción de trabajo ^[2][11].

Los trabajos con mucho contenido multimedia normalmente necesitan lotes más pequeños que los trabajos solo de texto, porque cada respuesta es más grande ^[1].

Usa el batching dinámico para cargas de trabajo desiguales

Los tamaños de lote fijos suenan pulcros sobre el papel. En producción, a menudo se desmoronan.

El tráfico cambia. Una ejecución masiva nocturna podría empujar miles de elementos por minuto, mientras que el tráfico diurno puede llegar lentamente. Un único tamaño de lote fijo no manejará bien ambos casos.

El batching dinámico resuelve eso enviando un lote cuando ocurre cualquiera de estas cosas:

• El lote alcanza un tamaño establecido

• Vence una ventana de espera establecida

Una configuración común es un tamaño máximo de lote más un tiempo máximo de espera, como 5 segundos ^[9][1]. Durante los periodos de mucha actividad, el límite de tamaño se alcanza una y otra vez, lo que mantiene alto el rendimiento. Durante los periodos más lentos, el temporizador entra en acción para que los elementos no se queden sin más esperando en la cola.

También puedes empaquetar varios elementos en un solo prompt para repartir la sobrecarga del prompt de sistema entre más trabajo ^[10].

Ejecuta las llamadas a la API de forma concurrente dentro de cada función

Una vez fijado el tamaño del lote, el siguiente paso es controlar las llamadas paralelas dentro de cada función.

La mayor parte del retraso normalmente proviene de esperar respuestas de red, no del cómputo local. Así que la concurrencia asíncrona suele ser la opción adecuada. Envía varias solicitudes a la vez y luego deja que el event loop gestione la espera.

La parte importante es el límite. Usa un semáforo para mantener acotada la concurrencia dentro de la función. Un pool de 5–10 solicitudes concurrentes es un punto de partida sensato ^[9][11]. Súbelo mucho más y puede que te topes con los límites de tasa del proveedor.

Con las API de LLM, el límite principal suele ser tokens por minuto, no el número bruto de solicitudes. Así que haz seguimiento del uso de tokens en una ventana móvil de 60 segundos y aplica throttling antes de que lo haga el proveedor por ti ^[10]. Esa protección importa porque, de otro modo, un solo worker puede consumir toda la memoria o provocar throttling para todo el pipeline.

Usa la configuración más simple que alcance tu objetivo de rendimiento sin disparar el coste de los reintentos.

Cómo mantener los flujos de trabajo por lotes fiables y observables a escala

Acertar con el tamaño del lote y la concurrencia es solo la mitad del trabajo. A medida que crece el volumen, la parte más dura es mantener los trabajos a salvo cuando algo se rompe y detectar los problemas rápido.

Gestiona los fallos parciales sin reprocesar todo

Un solo registro defectuoso nunca debería matar el lote entero. Si una entrada está mal formada o una solicitud sufre timeout, ese fallo debería quedar contenido.

En la práctica, la lógica de procesamiento de cada elemento necesita su propio manejo de errores. Escribe un checkpoint atómico tras cada fragmento y luego reanuda desde el último checkpoint en lugar de empezar de cero. Si un elemento sigue fallando tras 3 a 5 reintentos, envíalo a una cola de mensajes fallidos (DLQ) para revisión manual en vez de reintentar para siempre. Usa backoff exponencial antes de cada intento de reintento —por ejemplo, espera 1s, luego 2s, luego 4s— para evitar martillear un endpoint de API con límite de tasa ^[12][1][13].

Una vez que la recuperación es segura, haz seguimiento de con qué frecuencia ocurre y cuánto cuesta.

Haz idempotente cada trabajo por lotes

Los reintentos solo son seguros cuando una ejecución repetida produce el mismo resultado.

Eso importa aún más en las plataformas serverless, donde los errores transitorios a menudo disparan reintentos automáticos. Sin idempotencia, esos reintentos pueden provocar escrituras duplicadas u otros efectos secundarios repetidos.

La solución es simple: construye una clave de idempotencia estable como job_id:item_id en lugar de usar una marca de tiempo en tiempo de ejecución ^[14][15]. Luego usa upserts para que reprocesar un elemento reemplace el registro existente en lugar de crear un segundo. Para almacenamiento basado en archivos como S3, usa rutas de salida deterministas ligadas a los parámetros del elemento de trabajo, de modo que las reejecuciones sobrescriban la misma salida en vez de crear duplicados ^[2][13].

También deberías fijar el timeout de visibilidad de la cola en al menos 3x el tiempo de procesamiento p99 esperado. Eso evita que un segundo worker tome un trabajo que todavía se está ejecutando en el primero ^[2][13].

Haz seguimiento del rendimiento, la latencia y el coste por lote

Necesitas métricas que muestren si el batching sigue teniendo sentido bajo carga. A nivel de lote, haz seguimiento de:

• Elementos procesados por minuto

• Duración media del lote

• Número de reintentos por elemento

• Tasa de errores

• Coste por lote en USD, basado en el total de tokens de entrada y salida ^[12][1][2]

Configura una alerta si la tasa de éxito cae por debajo del 95% ^[1].

Reintenta solo los elementos fallidos. Usa la estrategia de saltar y registrar únicamente para trabajos de enriquecimiento no críticos.

Cómo reducir costes y mejorar el rendimiento para cargas de trabajo en producción

Identifica los principales generadores de coste

Antes de reducir costes, necesitas ver a dónde va el dinero.

En un pipeline de IA por lotes serverless, el uso de tokens de la API de IA suele ser el mayor gasto. El modo por lotes ayuda en dos frentes: reduce el gasto en tokens y baja la sobrecarga de las solicitudes. En la práctica, las API de lotes ofrecen costes de tokens aproximadamente un 50% más bajos que las llamadas síncronas ^[5][18].

Después de los tokens, la duración del cómputo serverless suele ser el siguiente gran generador de coste, especialmente para trabajos de vídeo e imagen facturados por runtime de GPU ^[17]. El almacenamiento y la transferencia de datos también pueden colarse sin que te des cuenta. Si mueves archivos grandes entre regiones, esos cargos se acumulan rápido. Y en flujos de trabajo de alto riesgo, la revisión humana de salidas de baja confianza puede convertirse por sí sola en un importante centro de coste ^[16].

Los patrones de coste también cambian según la modalidad. Las cargas de trabajo de texto se basan en tokens, así que normalmente son más fáciles de predecir. La generación de vídeo funciona de forma distinta: se te factura por segundo de salida, lo que significa que la duración del clip tiene un efecto directo en el gasto. Un clip de 10 segundos simplemente cuesta más que uno de 5 segundos. Por eso el ajuste de la ejecución importa tanto aquí.

Ajusta la memoria, los timeouts, el tamaño del paquete y los patrones de escritura

Muchos de los mejores ahorros vienen del ajuste llano de la ejecución, no de trucos elaborados.

Fija los timeouts del cliente en 60 segundos o más. Transmite la entrada y la salida en JSONL en lugar de cargar lotes grandes en memoria de una sola vez. Ese solo cambio puede reducir la presión de memoria y hacer los trabajos por lotes menos frágiles. Usa la cuantización solo cuando la VRAM sea el cuello de botella ^[5][18].

Son pequeños ajustes, pero pueden recortar el desperdicio sin cambiar el trabajo en sí.

Una vez que el uso de memoria y la E/S están en buena forma, la siguiente gran palanca es la selección del modelo.

Ajusta la elección del modelo y la estrategia de lotes a los objetivos de negocio

La mayor palanca de coste es elegir el modelo adecuado para el trabajo.

Los modelos de frontera como GPT-5 o Claude Opus tienen sentido para el razonamiento complejo. Pero para clasificación o extracción, pueden ser excesivos. Un modelo más ligero suele bastar. En muchos pipelines, usar modelos más ligeros para aproximadamente el 80% de las tareas y reservar los modelos más pesados para el otro 20% puede reducir los costes medios entre un 70% y un 90% ^[18][19].

Una división simple suele funcionar bien:

• Usa modelos más ligeros para la extracción y la clasificación

• Reserva los modelos más pesados para el razonamiento

• Escala el tamaño del lote según la complejidad de la tarea

Si necesitas enrutar distintos tipos de trabajo a distintos modelos, APIMart te da una única API para más de 500 modelos.

Antes de escalar, ejecuta un piloto de 10 a 50 elementos para medir el coste por elemento. Eso te da una lectura clara de lo que probablemente costará cada trabajo antes de que aumente el volumen.

Conclusión: la forma más simple de mejorar los flujos de trabajo de IA por lotes

Una vez definidos tu pipeline, el tamaño del lote, las comprobaciones de fiabilidad y las protecciones de coste, escalar se vuelve mucho más simple. El paralelismo por fan-out, los lotes de tamaño adecuado y el manejo estricto de reintentos son las principales palancas que convierten un trabajo lento y secuencial en algo que puedes ejecutar en producción.

Mantén los fallos contenidos. Haz los reintentos idempotentes. Concilia los resultados esperados frente a las salidas reales. Esa es la parte que evita que el sistema se descarrile cuando algo se rompe. Después de eso, el coste suele convertirse en el siguiente límite.

Haz seguimiento del gasto en USD por ejecución de lote para poder atar los costes a cada trabajo y detectar los valores atípicos caros ^[2]. Empieza las nuevas cargas de trabajo con un piloto de 10 a 50 elementos, verifica tu coste por elemento y luego escala una vez que los números cuadren ^[1][3].

Para la mayoría de las tareas, los modelos más pequeños deberían llevar el peso principal. Reserva los modelos más grandes para el trabajo de generación más complejo. Y si un pipeline por lotes se ejecuta a través de múltiples modalidades y tipos de modelo, una única capa como APIMart puede mantener el enrutamiento simple a través de una sola API. Esa combinación es lo que hace que los flujos de trabajo de IA por lotes sean más predecibles a escala de producción.

Preguntas frecuentes

¿Cuándo debería usar el procesamiento por lotes en lugar de llamadas de IA en tiempo real?

Usa el procesamiento por lotes para trabajo que no está en la ruta crítica del usuario y que puede esperar desde unos pocos minutos hasta unas pocas horas.

Es una buena opción para trabajos offline como:

• enriquecimiento de datos a gran escala

• análisis de documentos

• creación de índices vectoriales

• informes programados

Usa endpoints en tiempo real solo cuando alguien está esperando activamente al otro lado, como en un chat interactivo o preguntas y respuestas en vivo.

¿Cómo elijo el tamaño de lote adecuado para mi carga de trabajo?

Para el batching a nivel de aplicación, empieza con 50 a 100 elementos. En muchos casos, el punto óptimo cae entre 100 y 500. Si usas API de lotes nativas del proveedor, puedes ir mucho más alto, a veces hasta 50.000 solicitudes en un solo lote.

El objetivo es encontrar un tamaño de lote que te dé un buen equilibrio entre eficiencia y aislamiento de fallos. Lo quieres lo bastante pequeño como para que los reintentos no salgan demasiado caros, pero lo bastante grande como para reducir la sobrecarga de orquestación.

Para la inferencia dinámica, ajusta el tamaño del lote según los límites de VRAM y tus objetivos de latencia.

¿Cómo puedo evitar el procesamiento duplicado durante los reintentos?

Haz tu pipeline idempotente para que procesar el mismo elemento de nuevo lleve al mismo resultado cada vez.

Usa una clave de idempotencia estable e inmutable. Antes de ejecutar cualquier trabajo, comprueba si esa clave ya ha sido reclamada o procesada. Luego usa upserts más restricciones únicas para evitar escrituras duplicadas.

También ayuda mantener un registro de los IDs de documentos procesados. Eso te da una forma simple de saltar los elementos que ya están hechos durante los reintentos o las ejecuciones reanudadas.