El batching continuo permite que un servidor vLLM admita una nueva solicitud mientras otras solicitudes siguen generando tokens. Un lote fijo espera a que todos sus miembros terminen antes de poder formar el siguiente lote; el batching continuo revisa el conjunto activo en cada paso de planificación. Esa distinción importa cuando los prompts y las salidas tienen longitudes diferentes. Las solicitudes cortas pueden incorporarse al trabajo de la GPU sin esperar la respuesta más larga de un grupo anterior.
Para un equipo de inferencia, la pregunta útil no es si el batching continuo está habilitado en una lista de funcionalidades. Es si su combinación real de solicitudes obtiene más respuestas completadas por segundo sin llevar el tiempo hasta el primer token, el tiempo en cola o la tasa de errores más allá del objetivo de servicio. Esta guía explica el mecanismo, los límites que importan y un benchmark que puede ejecutar antes de elegir la capacidad de GPU.
Cómo funciona el batching continuo de vLLM
En la arquitectura V1 actual de vLLM, el planificador llena un presupuesto de tokens en cada paso a partir de solicitudes en ejecución y en espera. Una solicitud registra cuántos tokens se han calculado; el planificador asigna trabajo para cerrar esa brecha. El mismo bucle gestiona el prefill fragmentado, la caché de prefijos y la decodificación especulativa. Este es un modelo mental más preciso que un diagrama de un lote estático que se ejecuta hasta completarse. Consulte la descripción general de la arquitectura de vLLM para ver la descripción del planificador.
Imagine tres llegadas: una respuesta corta de chat, un prompt de documento largo y otro chat corto. Con un lote fijo, el segundo chat corto podría esperar el límite del lote de la solicitud larga. Con el batching continuo, puede considerarse en un paso de planificación posterior mientras las primeras solicitudes permanecen activas. La admisión sigue estando limitada por el presupuesto de tokens, los límites de secuencias y el espacio disponible de caché KV. El batching continuo no garantiza ausencia de colas ni un resultado más rápido para cada solicitud.
PagedAttention aborda una parte diferente del problema: almacenar y gestionar la caché KV de atención en bloques. Ayuda al motor a usar la memoria de forma más flexible, mientras que el planificador decide qué solicitudes reciben cómputo. Mantener esas funciones separadas ayuda a diagnosticar si el bajo rendimiento se debe a la planificación, la presión de la caché KV, los prompts largos o un cuello de botella ascendente. El diseño de PagedAttention de vLLM describe el mecanismo de memoria.
Los controles que dan forma a un lote
| Control | Qué limita | Qué vigilar al modificarlo |
|---|---|---|
max_num_batched_tokens |
Tokens procesados en una iteración del planificador | Rendimiento, tiempo hasta el primer token, latencia entre tokens y progreso de prompts largos |
max_num_seqs |
Secuencias procesadas en una iteración | Solicitudes en ejecución, margen de memoria y latencia de cola |
| Prefill fragmentado | Divide un prefill largo entre pasos de planificación | Latencia de prompts largos e interferencia con solicitudes de decodificación |
| Límite de cola o admisión | Solicitudes que pueden esperar o ejecutarse | Tiempo en cola, tasa de rechazo y si la sobrecarga llega a los llamadores |
| Capacidad de caché KV | Contexto activo que cabe en la GPU | Preempción, recálculo y fallos por falta de memoria |
Estos ajustes interactúan. Aumentar un presupuesto de tokens puede mejorar el rendimiento para una carga de trabajo y empeorar la latencia interactiva para otra. Incrementar el número de secuencias admitidas puede elevar la concurrencia, pero también consumir más caché KV. La versión, la arquitectura del modelo, las longitudes de contexto y el hardware afectan al resultado. Lea la referencia de configuración del planificador para conocer el comportamiento de la versión instalada de vLLM y, después, cambie un control a la vez.
Cuando la caché KV no puede alojar trabajo nuevo, vLLM puede preemptar una solicitud en ejecución y recalcular posteriormente su progreso. Un aumento en el recuento de preempciones advierte de que simplemente agregar más llegadas al lote no es gratis. La descripción general de la arquitectura explica las reglas de planificación y preempción.
Un benchmark que coincide con el tráfico de producción
No compare configuraciones de batching continuo con un único prompt corto enviado tan rápido como el cliente pueda hacerlo. Cree tres grupos de solicitudes a partir de sus propios registros o de una traza segura para la privacidad:
- Chats interactivos cortos con prompts y respuestas breves.
- Solicitudes de contexto largo con prefills grandes y longitudes de salida moderadas.
- Solicitudes de agentes o RAG con prefijos repetidos, longitudes de salida variables, cancelaciones y ráfagas.
Mantenga fijos entre ejecuciones la revisión del modelo, el tokenizador, el tipo de GPU, la versión de vLLM y la traza de solicitudes. Varíe la tasa de solicitudes ofrecida desde un nivel inferior a la carga esperada hasta el punto en que el tiempo en cola o los errores se vuelvan inaceptables. La guía oficial de vllm bench serve documenta los controles de tasa de solicitudes y conjunto de datos. Registre el comando exacto, la configuración y la versión de la traza para que la comparación pueda repetirse.
Para cada ejecución, registre solicitudes completadas por segundo, tokens de salida por segundo, p50 y p95 del tiempo hasta el primer token, latencia p95 entre tokens, latencia p95 de extremo a extremo, tiempo en cola, fallos y la marca máxima de uso de memoria de la GPU. La referencia de métricas de producción de vLLM incluye medidores de solicitudes en ejecución y en espera, e histogramas de tiempo en cola, tiempo hasta el primer token y preempciones. Un cuadro de mando útil es:
| Ejecución | Solicitudes ofrecidas/s | Solicitudes completadas/s | p95 del primer token | p95 de cola | p95 de extremo a extremo | Tasa de errores | Preempciones |
|---|---|---|---|---|---|---|---|
| Línea de base | medido | medido | medido | medido | medido | medido | medido |
| Cambio de presupuesto de tokens | medido | medido | medido | medido | medido | medido | medido |
| Cambio de límite de secuencias | medido | medido | medido | medido | medido | medido | medido |
Complete esta tabla con mediciones; no existe una ganancia porcentual universal que pueda copiarse de otro modelo o proveedor. Elija la configuración que cumpla los objetivos de latencia y fiabilidad al menor coste por respuesta aceptada, no la que tenga el mayor rendimiento de tokens de forma aislada.
Diagnostique un resultado decepcionante
Si el batching continuo parece ineficaz, busque la restricción antes de cambiar otro indicador.
Las solicitudes en espera aumentan mientras la memoria de la GPU sigue siendo suficiente. Compruebe los límites de admisión, un límite de secuencias pequeño, la tokenización de la CPU y la concurrencia del lado del cliente. Un planificador no puede llenar una GPU con solicitudes que nunca la alcanzan.
El tiempo hasta el primer token aumenta con prompts largos. Separe el tráfico con prefill intensivo del tráfico con decode intensivo en el benchmark. Revise el prefill por fragmentos y la configuración del presupuesto de tokens, y compare la distribución de prompts largos en lugar de solo el promedio.
El rendimiento mejora, pero la latencia p95 empeora. Es posible que el servidor esté aceptando más trabajo simultáneo del que permite el objetivo de su servicio interactivo. Limite la admisión, use un tiempo de espera de cola o un grupo de servicio independiente, y vuelva a realizar la prueba con la misma carga ofrecida.
Aumentan las preempciones o los eventos de falta de memoria. Es posible que los contextos activos no quepan en la caché KV de la GPU. Reduzca los límites de concurrencia o de contexto, seleccione una GPU con memoria suficiente o reconsidere las opciones de modelo y precisión. Evite tratar una solicitud preemptada como un evento de planificación gratuito.
La utilización de la GPU es baja incluso cuando las solicitudes esperan. Inspeccione la CPU, la red, el almacenamiento, la carga del modelo y el ritmo del cliente antes de atribuir el cuello de botella al batching continuo. Nuestra guía de implementación de vLLM cubre el manual operativo de serving más amplio; este artículo se centra en el comportamiento del planificador y la medición.
Dónde interviene la elección de la GPU en la decisión
El batching continuo puede mejorar cómo utiliza una GPU, pero no puede hacer que un modelo quepa en una memoria de la que no dispone. Estime los pesos, la caché KV con la concurrencia y longitud de contexto esperadas, la sobrecarga de tiempo de ejecución y un margen de seguridad. Después, ejecute benchmarks en la configuración de GPU que pretende alquilar. Una GPU de 80 GB y una GPU con más memoria pueden producir comportamientos de admisión y preempción diferentes para el mismo modelo y traza de solicitudes.
GPU Compute de Flatkey ofrece opciones de alquiler que incluyen H100 SXM, H200, B200, B300, A100 80GB y RTX 5090. La configuración, región, disponibilidad y precio deben confirmarse para el alquiler seleccionado. Lleve una traza de benchmark, la latencia objetivo, la revisión del modelo y la estimación de memoria al comparar opciones. Esto hace que la conversación sobre capacidad trate del trabajo completado en lugar de una especificación destacada de la GPU.
Lista de comprobación práctica para la decisión
Antes de comprometerse con una configuración de batching continuo de vLLM, responda estas preguntas:
- ¿El escenario de mayor tráfico cumple los objetivos de latencia p95 del primer token y de extremo a extremo?
- ¿Qué ocurre ante un pico por encima de la tasa normal de solicitudes: cola limitada, rechazo o un gran aumento de la latencia?
- ¿Las preempciones y la presión sobre la caché KV son estables con la longitud de contexto prevista?
- ¿El resultado es repetible con la revisión exacta del modelo y la configuración de GPU que planea ejecutar?
- ¿El coste por respuesta aceptada supera al de la alternativa después de contabilizar los reintentos y la capacidad inactiva?
Preguntas frecuentes
¿El batching continuo de vLLM significa que cada solicitud se ejecuta inmediatamente?
No. Una nueva llegada puede considerarse en un paso de planificación, pero aun así puede esperar por presupuesto de tokens, una ranura de secuencia o capacidad de caché KV. Observe los indicadores de ejecución y espera junto con los histogramas de tiempo en cola antes de prometer un objetivo de latencia interactiva.
¿El batching continuo de vLLM es lo mismo que el prefill por fragmentos?
No. El batching continuo describe cómo las solicitudes se unen y abandonan el trabajo planificado a lo largo del tiempo. El prefill por fragmentos divide el trabajo de prefill de un prompt largo para que pueda compartir el presupuesto de tokens entre pasos. Funcionan juntos en el planificador actual, pero ajustar uno de ellos no sustituye la medición del otro.
¿Debo maximizar el tamaño del batch?
No necesariamente. Un batch más grande puede mejorar el rendimiento al tiempo que aumenta el tiempo en cola, el tiempo hasta el primer token o la presión de preempción. Ejecute la misma traza con la misma carga ofrecida y compare el objetivo de servicio completo, incluidos los fallos y el coste por respuesta aceptada.
El batching continuo de vLLM es un método de planificación, no un resultado de benchmark. La configuración más sólida es aquella cuyo rendimiento, latencia, comportamiento de memoria y modo de fallo puede explicar con sus propias mediciones.
