Servir requests a un LLM uno por uno desperdicia la mayor parte de la GPU. Batching bien hecho es la diferencia entre pagar por capacidad ociosa y aprovecharla al máximo.
La inferencia de un LLM es dominada por lectura de memoria (mover los pesos del modelo desde la memoria de la GPU hacia las unidades de cómputo), no por el cómputo en sí — es "memory-bound". Procesar un solo request a la vez significa que la GPU carga los pesos completos del modelo para generar un solo token de una sola secuencia, dejando la mayor parte de su capacidad de cómputo paralelo sin usar. Agrupar varios requests en el mismo paso de cómputo (un "batch") permite reutilizar esa misma carga de pesos para generar tokens de múltiples secuencias simultáneamente — el costo de mover los pesos se amortiza entre todos los requests del batch.
El batching estático clásico agrupa un conjunto fijo de requests, espera a que todos terminen de generar (incluyendo el más largo) y solo entonces libera el batch completo para aceptar nuevos requests — si un request termina rápido pero otro genera 500 tokens, el slot del primero queda ocioso hasta que el batch completo cierre. El continuous batching (también llamado batching dinámico), popularizado por motores como vLLM y TGI, resuelve esto a nivel de scheduler: en cuanto un request termina, su slot se libera inmediatamente para que entre un request nuevo de la cola, sin esperar a que el resto del batch termine.
La diferencia entre batching estático y continuous batching puede significar varias veces más throughput en el mismo hardware para cargas con longitud de respuesta variable — que es la norma en producción, donde algunas preguntas se responden en 20 tokens y otras en 500. Esto se traduce directamente en costo: si puedes atender 5 veces más requests por segundo con la misma GPU, el costo por request cae proporcionalmente, sin cambiar el modelo ni degradar la latencia individual de forma significativa.
Batching no es gratis: agregar más requests a un batch en curso puede aumentar el tiempo que tarda cualquier request individual en recibir su primer token, porque el scheduler tiene que repartir el cómputo disponible entre más secuencias simultáneas. Motores de producción exponen parámetros para poner un techo al tamaño del batch o priorizar ciertos requests, y encontrar el punto correcto depende de si tu aplicación tolera más latencia a cambio de más throughput (un batch job nocturno) o necesita respuesta rápida garantizada (un chat en vivo).
Si consumes LLMs vía API de un proveedor (OpenAI, Anthropic, Bedrock), el proveedor ya aplica batching internamente en su infraestructura compartida — no es algo que configures tú directamente. Donde sí tienes control es en cómo estructuras tus propias llamadas: usar los endpoints de batch que varios proveedores ofrecen para trabajos no interactivos (procesar miles de documentos sin necesidad de respuesta inmediata) suele venir con descuentos significativos sobre el precio de la API síncrona, precisamente porque el proveedor puede agruparlos con mayor libertad al no tener restricción de latencia en tiempo real.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel