Qué pasó. Aleksa Gordić publicó un análisis técnico que desmenuzza vLLM componente a componente: desde el gestor de KV cache con paged attention, pasando por el scheduler con continuous batching, hasta el serving layer multinodo. El post sigue el código del motor V1 (commit de agosto de 2025) y parte de lo básico para añadir capas una a una.

Por qué te importa. Si sirves modelos open-weight en producción, vLLM probablemente está bajo tu stack. Entender cómo gestiona la memoria de vídeo, el scheduling de solicitudes y el batching continuo te ayuda a diagnosticar cuellos de botella y configurarlo mejor, en lugar de tratarlo como una caja negra. Cuando el throughput se desmorona o la latencia se vuelve loca, saber qué hace el scheduler bajo el capó marca la diferencia entre un tuning acertado y un disparo al aire.

Si quieres intentarlo. El artículo es gratuito, parte de un ejemplo en Python con una sola GPU y va subiendo. Nivel a nivel: scheduler, paged attention, continuous batching, prefix caching, speculative decoding, multi-GPU, serving layer.

En detalle

vLLM es el motor de inference que la mayoría de quienes sirven modelos open-weight en producción llevan bajo el capó. El proyecto introdujo la idea de paged attention: en lugar de reservar un bloque contiguo de memoria de vídeo para cada solicitud, el KV cache se divide en páginas de tamaño fijo, asignadas y liberadas bajo demanda. La memoria se reutiliza sin fragmentación, y el throughput crece significativamente comparado con una asignación ingenua. Piensa en una oficina donde cada persona tiene un archivador dedicado, medio vacío: desperdicias espacio. Con páginas, asignas solo los compartimentos que necesitas, cuando los necesitas, y los liberas en cuanto terminas.

El artículo de Gordić sigue el código del motor V1 y lo explica de abajo hacia arriba. Parte del ejemplo más simple: una instancia offline, single-GPU, síncrona. Desde ahí suma capas. El scheduler con su política FCFS o prioritaria decide quién entra en el batch y quién espera, según la memoria disponible. El gestor de KV cache con su free_block_queue mantiene un registro de bloques libres y ocupados, como una lista de habitaciones vacías en un hotel. El model executor ejecuta los forward pass, es decir, los verdaderos pasos de cálculo del modelo en la GPU.

Luego sube de nivel. Continuous batching: vLLM no espera a que un batch de solicitudes termine completamente antes de cargar unas nuevas. En cada paso de decoding, el scheduler reorganiza las solicitudes activas, insertando las nuevas donde hay espacio. Una solicitud corta no espera a una larga para liberar el batch. En un sistema tradicional, si metes diez solicitudes juntas y una es mucho más larga que las otras, las nueve cortas quedan bloqueadas esperando a la décima. Con batching continuo, cada vez que una solicitud termina, su lugar en el batch lo ocupa inmediatamente otra de la cola.

Prefix caching reconoce cuándo múltiples solicitudes comparten el mismo prefijo (system prompt, contexto compartido) y cachea el resultado, ahorrando cálculo. Si cien usuarios envían el mismo prompt del sistema, vLLM calcula los tokens de ese prefijo una sola vez. Speculative decoding usa un modelo pequeño para generar borradores de tokens que el modelo grande verifica en un solo forward pass, intercambiando throughput por latencia. El modelo pequeño sugiere, por ejemplo, cinco tokens; el modelo grande chequea de una vez cuántos son correctos y los acepta, regenerando solo los restantes.

Los dos últimos niveles cubren el salto de una GPU a varias GPUs y múltiples nodos: data parallelism, tensor parallelism, pipeline parallelism, expert parallelism. El tensor parallelism divide los pesos del modelo entre varias GPUs, así un modelo demasiado grande para una sola tarjeta cabe dividido. El pipeline parallelism asigna capas diferentes a GPUs diferentes, pasando resultados de una a otra por turnos. Y el serving layer lo pone todo detrás de una API asíncrona, capaz de manejar miles de solicitudes simultáneas sin bloquearse.

El límite de este writeup es que vLLM se mueve rápido: el motor V0 ya está deprecado, el V1 evoluciona semana a semana. El artículo está anclado a un commit específico, y algunas interfaces podrían haber cambiado. Los conceptos de base se mantienen estables: quien los entiende sabe diagnosticar problemas de throughput, configurar mejor los parámetros de memoria, y elegir cuándo vLLM es la herramienta correcta frente a alternativas como SGLang o TensorRT-LLM.