Cómo vLLM resuelve la ineficiencia de la GPU mediante batching continuo y PagedAttention

Los modelos de lenguaje grandes son motores de predicción, no servidores, lo que crea una discrepancia fundamental al manejar altos volúmenes de solicitudes. Ejecutar estos modelos una solicitud a la vez deja ocioso la mayor parte del poder computacional de la GPU, aumentando los costos y limitando la escalabilidad para los desarrolladores que construyen productos de IA.

Qué ocurrió

El desafío de servir modelos de pesos abiertos a gran escala ha llevado a los ingenieros a adoptar vLLM, un servidor de inferencia y framework diseñado específicamente para entornos de alto rendimiento. Originario del Sky Computing Lab de la UC Berkeley en 2023, vLLM aborda las ineficiencias centrales del despliegue estándar de LLM repensando cómo se agrupan las solicitudes y cómo se gestiona la memoria en las GPUs.

Los métodos tradicionales de inferencia tienen dificultades porque procesan las solicitudes secuencialmente o utilizan batching estático, donde grupos de solicitudes comienzan y terminan juntos. Este enfoque no tiene en cuenta la longitud variable de las respuestas de los LLM, lo que lleva a un desperdicio significativo de ciclos de cómputo mientras las solicitudes más rápidas esperan a que las más lentas se completen. vLLM introduce el batching continuo y una técnica novedosa de gestión de memoria llamada PagedAttention para mantener las GPUs totalmente utilizadas.

Este framework se ha convertido en la solución preferida para entornos de producción donde la eficiencia de costos y el rendimiento son críticos. Al desacoplar la finalización de la solicitud de la ejecución del lote, vLLM asegura que cada paso hacia adelante realice trabajo útil, aumentando drásticamente el número de tokens generados por segundo sin requerir hardware adicional.

Cómo funciona

La inferencia de LLM consta de dos fases: prefill, donde el modelo procesa el prompt de entrada, y decode, donde genera los tokens de salida uno por uno. En configuraciones estándar, la fase de decode es ineficiente porque la GPU debe cargar todos los pesos del modelo para generar cada token individual. El batching estático mejora esto ligeramente al procesar múltiples solicitudes simultáneamente, pero sufre de efectos de rezago (straggler effects) donde las respuestas cortas bloquean el inicio de nuevos lotes con respuestas más largas.

vLLM reemplaza el batching estático con batching continuo. En lugar de esperar a que todas las solicitudes de un lote terminen, el programador inserta inmediatamente nuevas solicitudes en el siguiente paso hacia adelante tan pronto como cualquier solicitud existente se completa. Esto mantiene la GPU ocupada todo el tiempo, maximizando el rendimiento. Sin embargo, el batching continuo requiere una gestión de memoria eficiente porque cada solicitud activa mantiene una caché Key-Value (KV) que crece con cada token generado.

Para resolver el problema de fragmentación de memoria, vLLM utiliza PagedAttention. Los frameworks tradicionales reservan memoria para el peor caso posible para la caché KV de cada solicitud, lo que conduce a un desperdicio masivo. PagedAttention trata la caché KV como memoria virtual en un sistema operativo, almacenándola en bloques no contiguos. Esto permite al sistema asignar memoria dinámicamente y compartir bloques entre solicitudes cuando es posible, asegurando que la memoria de la GPU se utilice solo para datos activos y no para potencial reservado.

Detalles clave

• vLLM fue introducido en un paper de 2023 por investigadores del Sky Computing Lab de la UC Berkeley.
• El framework utiliza batching continuo para añadir nuevas solicitudes a los pasos hacia adelante tan pronto como las anteriores finalizan.
• PagedAttention gestiona la memoria de la caché KV en bloques no contiguos, similar a la paginación de memoria virtual del SO.
• El batching estático estándar desperdicia cómputo al forzar a las solicitudes rápidas a esperar por las lentas dentro del mismo lote.
• La caché KV almacena pares de clave y valor para cada token, creciendo con cada paso de generación.
• vLLM expone un endpoint de API compatible con OpenAI para facilitar la integración en aplicaciones existentes.

Por qué importa

Para ingenieros de software y fundadores técnicos, la utilización de la GPU está directamente ligada a los costos de infraestructura. Cuando un modelo ejecuta una solicitud a la vez, el costoso hardware permanece mayormente ocioso durante la fase de decode. Al adoptar vLLM, los equipos pueden atender significativamente más usuarios con el mismo presupuesto de hardware, haciendo viables los modelos de pesos abiertos para aplicaciones de producción que requieren baja latencia y alta concurrencia.

El cambio de batching estático a continuo también mejora la experiencia de usuario al reducir los tiempos de espera. En sistemas estáticos, un usuario que envía una consulta corta podría ser retrasado por un lote anterior que contiene una solicitud larga y compleja. El batching continuo asegura que ninguna solicitud quede ociosa mientras otras se completan, llevando a un rendimiento de API más predecible y receptivo. Esta confiabilidad es esencial para funciones de IA orientadas al consumidor donde la velocidad percibida impacta el engagement.

Además, la eficiencia de memoria proporcionada por PagedAttention elimina una barrera importante para escalar. Sin ella, los ingenieros deben sobreaprovisionar memoria para manejar longitudes del peor caso posible, lo que limita el número de solicitudes concurrentes que una sola GPU puede manejar. La asignación dinámica de vLLM permite despliegues de mayor densidad, simplificando la planificación de capacidad y reduciendo la necesidad de optimización manual compleja de tamaños de lote.

Qué puedes hacer

• Reemplaza los pipelines estándar de Hugging Face con vLLM para cualquier despliegue de modelo de pesos abiertos que requiera alto rendimiento.
• Configura tu servidor de inferencia para usar batching continuo en lugar de batching estático para reducir el tiempo ocioso de la GPU.
• Monitorea el uso de la caché KV para entender la presión de memoria y ajusta las configuraciones de longitud máxima del modelo en consecuencia.
• Utiliza el endpoint de API compatible con OpenAI proporcionado por vLLM para minimizar los cambios en tu código del lado cliente.
• Realiza benchmarks de tu configuración actual de batching estático contra vLLM para cuantificar las mejoras en tokens por segundo.
• Asegúrate de que tu aplicación maneje tiempos de respuesta variables de manera elegante, ya que el batching continuo puede cambiar los perfiles de latencia.