Batching continuo: cómo atender más solicitudes con un LLM

El batching continuo (continuous batching) permite que una GPU compartida admita nuevas solicitudes entre los pasos de generación. Así, las tareas cortas ya no dejan capacidad sin aprovechar a la espera de que terminen las largas. El artículo fundacional de Orca, publicado por Yu y sus colaboradores en OSDI en 2022, explica este cambio en la planificación. Con solicitudes concurrentes, puede aumentar la producción total de tokens por segundo, aunque un servidor más ocupado no garantiza respuestas más rápidas para cada usuario.

En un servidor de modelos compartido, el objetivo útil es completar más trabajo dentro de los límites de tiempo de respuesta. Una gráfica de rendimiento sin un objetivo de latencia no permite saber a cuántos clientes puede atender el servidor con una experiencia satisfactoria.

La compatibilidad y los controles de los servidores que se describen a continuación se verificaron en la documentación oficial disponible el 25 de octubre de 2026. El ejemplo de planificación es ilustrativo; no es una prueba de rendimiento de hardware.

¿Cómo funciona el batching continuo?

El batching continuo, o procesamiento continuo por lotes, modifica el grupo de solicitudes activas mientras la generación sigue en marcha. Cuando una solicitud termina, sale del grupo; si el planificador dispone de capacidad, puede incorporar otra que esté en espera. Esta técnica también se conoce como in-flight batching o iteration-level batching.

Un modelo de lenguaje de gran tamaño, o LLM, primero procesa el prompt en la fase de prefill y luego genera la continuación en la fase de decode. En la decodificación autorregresiva habitual, cada solicitud activa produce su siguiente token, un fragmento de texto, durante un paso de generación. El planificador decide qué solicitudes participan en el siguiente paso. La guía de inferencia de LLM explica estas fases con más detalle.

Imagina una mesa compartida. Si los turnos son fijos, el siguiente grupo solo puede sentarse cuando todos los comensales del grupo anterior han terminado. Con una asignación continua, una persona puede ocupar una silla libre mientras otra sigue comiendo. Comparten la mesa, pero cada una conserva su propia comida.

La analogía tiene un límite: el planificador de una GPU también debe hacer espacio para el procesamiento de los prompts y la asignación de memoria. Que haya una silla libre no significa que cualquier solicitud en espera pueda entrar de inmediato.

¿Qué aportó el artículo de Orca?

Con Orca, la planificación pasó a decidirse en cada iteración, en lugar de hacerlo para una solicitud completa. El artículo de OSDI 2022, de Gyeong-In Yu y sus colaboradores, describe cómo invocar el motor de ejecución para una sola iteración del modelo y después revisar la composición del lote.

La técnica complementaria, denominada agrupación selectiva, reúne en lotes determinadas operaciones del modelo y permite manejar los distintos historiales que necesita la atención, la operación que conecta un token con su contexto previo. Juntas, estas técnicas permiten que el sistema de inferencia intercale solicitudes de distinta longitud. El artículo también considera el tamaño del lote y la memoria disponible para claves y valores como restricciones de la planificación. Leer el artículo de Orca.

El cambio se produce en el sistema que sirve el modelo. No hace falta entrenar al modelo para que responda a varias personas dentro de una misma conversación.

Batching estático, dinámico y continuo: ¿qué cambia?

La pregunta clave es en qué momento puede incorporarse una nueva solicitud al trabajo que ya está en marcha. Aceptar conexiones HTTP concurrentes, por sí solo, no demuestra que la ejecución del modelo use batching continuo.

La documentación de NVIDIA sobre batching en Triton describe el batching dinámico convencional, incluidos los controles de tamaño de lote y tiempo de espera en cola. Esa decisión de planificación es distinta de sustituir solicitudes durante la generación de un LLM.

Batching dinámico en vLLM: importa cuándo se admite trabajo nuevo

vLLM, un motor para servir LLM, documenta el uso de batching continuo. «Batching dinámico» es una etiqueta menos precisa. Hugging Face también habla de planificación dinámica o batching dinámico para describir la sustitución de prompts ya completados durante la generación en su explicación del batching continuo. Conviene comprobar si el motor admite trabajo nuevo entre pasos de generación, en lugar de sacar conclusiones solo por el nombre.

El streaming es otra cuestión. Un servidor puede transmitir tokens al cliente a medida que los genera y mantener fija la composición del lote de ejecución. La ventaja que nos ocupa aquí es que el trabajo entrante pueda aprovechar la capacidad que liberan las solicitudes completadas.

Un ejemplo de planificación

Una tarea corta puede liberar capacidad útil mientras otra más larga sigue ejecutándose. Pensemos en un servidor ilustrativo con dos posiciones de decodificación. A la solicitud A le faltan 2 pasos; a B, 4; y C está esperando con 2 pasos de trabajo pendientes. Para este ejemplo, dejamos de lado el prefill, el costo de la planificación y las variaciones en la duración de cada paso.

Con una composición fija, A y B empiezan juntas. A termina, pero C debe esperar a que B finalice para que empiece el siguiente grupo. Con batching continuo, C puede ocupar la posición de A en cuanto esta termina y avanzar al mismo tiempo que B.

El ejemplo muestra una admisión más temprana, no una aceleración medida. Un chatbot de soporte que combina respuestas cortas con resúmenes largos tiene la misma oportunidad de planificación; la mejora real depende de las solicitudes, el hardware y la configuración del servidor.

Por qué aumenta el rendimiento y dónde lo limita la caché KV

El batching permite aprovechar una misma transferencia de los pesos del modelo para realizar más trabajo útil. Los pesos son los parámetros numéricos aprendidos que se utilizan para calcular una respuesta. Varias solicitudes que usan el mismo modelo pueden compartir el trabajo de transferir esos pesos por la memoria de la GPU, lo que permite aprovechar mejor la capacidad de cómputo disponible. La planificación continua ayuda a mantener ese lote útil a medida que terminan las solicitudes individuales. NVIDIA explica la relación entre batching, movimiento de memoria y uso de la GPU.

La GPU puede mantenerse ocupada incluso con un lote ineficiente. Lo que importa es cuánto trabajo útil para las solicitudes produce esa actividad, no que la gráfica de utilización esté al máximo.

Pero cada solicitud activa también necesita memoria de trabajo. Su caché KV, o caché de claves y valores, almacena el estado de atención de los tokens ya procesados. Una mayor concurrencia y unos historiales más largos aumentan la presión sobre esa memoria. La explicación de la caché KV distingue este estado del almacenamiento de prompts en caché para su reutilización.

PagedAttention aprovecha mejor la memoria

El batching continuo decide qué se ejecuta; PagedAttention cambia cómo se almacena el estado de atención. El artículo de vLLM de 2023, de Woosuk Kwon y sus colaboradores, describe cómo dividir el estado KV en bloques de tamaño fijo que no necesitan ocupar posiciones contiguas en la memoria física. Un mapa de bloques conserva el orden lógico de la secuencia.

Esto reduce la memoria que se pierde por fragmentación y duplicación innecesaria. Una distribución más eficiente permite alojar los conjuntos de datos de trabajo de más solicitudes, de modo que el planificador dispone de más trabajo útil entre el que elegir. El artículo presenta expresamente este enfoque de gestión de memoria como complementario al enfoque de planificación de Orca.

El límite sigue siendo la capacidad física. Distribuir mejor la memoria no permite alojar un número ilimitado de conversaciones largas. En vLLM, la falta de espacio KV puede provocar desalojo o preemption: se pausa una solicitud y después se vuelve a calcular su estado, lo que puede aumentar la latencia hasta completarla. La documentación de optimización explica este comportamiento.

¿Qué ocurre con la latencia?

El batching continuo puede acortar la espera en cola, pero los lotes más grandes o más cargados pueden ralentizar la experiencia una vez admitida la solicitud. Conviene medir cada etapa por separado:

• Tiempo hasta el primer token, o TTFT: cuánto espera el usuario antes de que empiece la respuesta.
• Latencia entre tokens: los intervalos entre tokens una vez iniciado el streaming.
• Latencia de extremo a extremo: cuánto tarda en completarse la solicitud.

Una solicitud recién llegada puede evitar la espera hasta que se vacíe un lote fijo entero. Sin embargo, procesar un prompt nuevo y extenso puede competir por recursos con las solicitudes que ya están decodificando. El prefill por fragmentos, o chunked prefill, divide el procesamiento del prompt en partes más pequeñas para que el planificador pueda intercalarlo con la generación en curso.

Por ejemplo, vLLM documenta un equilibrio en su presupuesto de tokens por iteración: los valores más bajos pueden proteger la latencia entre tokens, mientras que los más altos permiten procesar más prefill y mejorar el TTFT. Por eso, el presupuesto debe ajustarse a la carga de trabajo; no es un parámetro que convenga llevar al máximo sin más. Guía de ajuste de vLLM.

Batching continuo en LLM con poca carga y con mucha demanda

Con poca carga puede haber pocas solicitudes que agrupar; bajo una sobrecarga sostenida seguirá habiendo cola. Quien desarrolla y envía una sola solicitud cada vez no debería esperar el mismo beneficio que un servicio de atención a clientes con solicitudes que se solapan. En el otro extremo, admitir más trabajo del que la GPU puede sostener acaba empeorando los tiempos de espera.

En una aplicación interactiva, hay que observar tanto la mediana como el p95, el percentil 95. Un buen promedio puede ocultar una minoría de sesiones lentas. Define el TTFT y los intervalos de streaming aceptables según la experiencia que debe ofrecer el producto; después, mide la capacidad dentro de esos límites.

Servidores LLM con batching continuo: compatibilidad y límites

Los cuatro servidores siguientes documentan compatibilidad con batching continuo o in-flight batching. Compartir esa función no significa que sus planificadores, presupuestos de memoria o compatibilidad con modelos sean intercambiables.

Batching continuo en vLLM

vLLM combina la planificación continua de solicitudes con la gestión paginada de la caché KV. Su documentación enumera expresamente ambas funciones. Para quienes operan el servidor, los controles útiles son el máximo de secuencias y los tokens planificados por iteración, no simplemente un número deseado de conexiones simultáneas a la API.

El límite es la presión sobre la memoria: aumentar la concurrencia puede provocar desalojos y recálculos en lugar de aportar más capacidad útil. Ajusta la configuración según la combinación de solicitudes y el objetivo de latencia, y mantén el mismo modelo y hardware al comparar los ajustes.

SGLang

SGLang admite batching continuo y ofrece controles explícitos de admisión. Su documentación de argumentos del servidor define --max-running-requests, --chunked-prefill-size y el presupuesto para los pesos del modelo y el espacio de memoria KV que controla --mem-fraction-static.

Estos controles responden a preguntas distintas: cuántas solicitudes pueden ejecutarse, cuánto procesamiento de prompts cabe en un fragmento y cómo se asigna la memoria. Elevar el límite de solicitudes no elimina los demás límites. Para elegir el motor en un contexto más amplio, consulta la comparativa de vLLM y SGLang y después evalúa el modelo y la combinación de solicitudes concretos que necesitas atender.

NVIDIA TensorRT-LLM

NVIDIA TensorRT-LLM equipara expresamente in-flight batching con batching continuo y batching por iteración. La documentación de esta función describe el procesamiento conjunto de secuencias en fase de contexto y en fase de generación, con tensores de entrada empaquetados en la implementación documentada.

El límite de solicitudes y el presupuesto de tokens son restricciones distintas. La documentación del planificador de PyTorch también distingue entre reservar recursos, incluida la capacidad KV, y elegir cuáles de las solicitudes que caben se ejecutan. Un planificador in-flight no puede admitir trabajo que no supere esas comprobaciones de capacidad.

Hugging Face Text Generation Inference

Hugging Face Text Generation Inference admite batching continuo, pero su estado de mantenimiento cambia la decisión ante un nuevo despliegue. Según su documentación, el proyecto acepta ahora correcciones menores, mejoras de documentación y tareas ligeras de mantenimiento, y recomienda recurrir en adelante a otros motores, entre ellos vLLM y SGLang.

Una instalación existente de TGI no pierde el batching por ese cambio de estado. Para una nueva infraestructura de servicio de modelos, yo empezaría por evaluar alternativas en desarrollo activo. Si un despliegue ya cumple sus objetivos, conviene planificar la migración en función de una necesidad concreta de soporte o de nuevas capacidades.

Qué promesas conviene tomar con cautela

El batching continuo no ofrece un multiplicador de velocidad aplicable a cualquier entorno. Los artículos de Orca y PagedAttention evalúan sistemas y cargas de trabajo concretos. Sus resultados no aíslan una mejora universal que pueda trasladarse a cualquier modelo, GPU o endpoint de un proveedor.

Tampoco elimina la espera. Una solicitud en cola sigue necesitando procesamiento del prompt, memoria y un turno según la política del planificador. Los prompts largos, la demanda concurrente elevada y la presión sobre la caché siguen marcando límites.

Por último, una mayor tasa total de tokens no demuestra que un producto de chat haya mejorado. Si los usuarios esperan más hasta el primer token o sufren pausas molestas durante el streaming, ese rendimiento adicional del servidor puede quedar fuera del margen operativo aceptable para el producto.

Qué cambiar en la práctica a partir del lunes

Quienes desarrollan deberían evaluar un servidor compartido cuando las solicitudes se solapan; quienes lo operan deberían ajustar la configuración dentro de los límites de latencia; quienes comparan proveedores deberían pedir mediciones con competencia por los recursos. Una herramienta de uso individual con solicitudes ocasionales puede esperar. Un servicio con clientes en cola y respuestas de distintas longitudes tiene un motivo concreto para actuar. La comparativa de Ollama y vLLM explica la transición del uso local a un servidor compartido.

1. 1

   Define la experiencia antes de aumentar la concurrencia

   Anota el tiempo aceptable hasta el primer token, los intervalos de streaming y el tiempo de finalización para el flujo de trabajo real. Un sistema que resume en segundo plano y un asistente de soporte en vivo necesitan límites de aceptación distintos.

2. 2

   Reproduce una combinación representativa de solicitudes

   Mantén comparables el modelo, el hardware, las longitudes de los prompts, los límites de salida y las condiciones de la caché. Incluye respuestas cortas, prompts largos y generaciones extensas. Conserva patrones de llegada realistas para que una prueba tranquila de un solo usuario no se tome como representativa de un servicio con mucha actividad.

3. 3

   Registra el rendimiento junto con la cola y la latencia

   Mide los tokens de salida por segundo de todo el servidor, las solicitudes completadas, las solicitudes en espera, los fallos, el TTFT y los intervalos entre tokens. vLLM expone métricas correspondientes, como vllm:num_requests_waiting, vllm:time_to_first_token_seconds y vllm:inter_token_latency_seconds, en su documentación de métricas de producción.

4. 4

   Quédate con la mayor carga que aún cumpla los objetivos

   Cambia un solo control de planificación o memoria cada vez. Deja de aumentar la concurrencia cuando se incumplan los límites de latencia o la presión sobre la memoria provoque recálculos repetidos. Pide al proveedor la misma visión conjunta de rendimiento y latencia con la concurrencia que esperas, además de aclarar si la capacidad es compartida o reservada.

El resultado debe ser un límite operativo medido: la carga de trabajo que puede sostener el endpoint sin dejar de ofrecer la experiencia de usuario prevista. Eso es lo que convierte una función de batching en un criterio para decidir un despliegue.

Para entender la infraestructura de IA con explicaciones prácticas y saber qué cambiar en tu sistema, suscríbete al boletín.