Visión general de la arquitectura de vLLM
En una frase
vLLM es un motor de inferencia LLM de alto throughput,y v0.25 ya ha migrado a la arquitectura v1: LLMEngine es una cáscara fina,y el núcleo real es EngineCore (que puede correr como proceso en background por ZMQ dentro de EngineCoreProc),expuesto a través de EngineCoreClient (Inproc/MP/AsyncMP);en runtime el Scheduler gestiona las colas waiting/running con batching continuo (continuous batching) y preempting,GPUModelRunner.execute_model ejecuta el forward sobre el Worker,KVCacheManager + BlockPool implementan PagedAttention + prefix caching,y AttentionBackend abstrae la atención con múltiples backends.
Capas
Una frase por capa
- Arranque y configuración: EngineArgs parsea todos los parámetros de inicio y deriva VllmConfig;LLM es la clase offline y AsyncLLM la entrada asíncrona.
- Línea principal del motor v1: LLMEngine es la cáscara fina,y el núcleo real es EngineCore (que combina scheduler+worker);EngineCoreProc lo envuelve como proceso en background por ZMQ.
- EngineCoreClient: InprocClient (en proceso) / MPClient (multiproceso) / AsyncMPClient;unifican para arriba la interfaz add_request/abort etc.
- Planificador: el Scheduler mantiene las colas waiting/running,schedule decide qué peticiones corren en este paso,y soporta preemption y prefill throttle.
- Executor: abstrae el backend de ejecución;UniProc/Multiproc/Ray tres opciones,encargado de levantar el Worker y el entorno distribuido.
- Worker y ModelRunner: el Worker posee el modelo y la KV cache,GPUModelRunner.execute_model ejecuta un forward,ubatch hace el micro-batching y cudagraph acelera.
- Carga del modelo: DefaultModelLoader carga los pesos,las capas lineales de TP (ColumnParallel/QKVParallel/RowParallel) hacen el sharding,y la capa quant maneja la cuantización.
- KV Cache: KVCacheManager gestiona el ciclo de vida de los blocks,KVCacheCoordinator (Hybrid/Unitary/NoPrefix) define la política,y BlockPool hace la asignación + el índice de prefix cache.
- Backend de Attention: abstracción AttentionBackend,conmuta entre FlashAttention/FlashInfer/Triton/MLA/Mamba.
- Sampling: el forward/sample del Sampler convierte logits en tokens,y LogitsProcessor hace el preproceso.
- Prefix Cache y distribuido: prefix cache reutiliza KV blocks en coincidencias,GroupCoordinator gestiona la comunicación TP/PP,y OpenAI serving expone el API HTTP.
Motivación de las capas
vLLM desacopla por completo «cómo configurar» (engine args), «cómo planificar» (scheduler), «cómo ejecutar» (executor+worker), «cómo gestionar la memoria de GPU» (KV cache), «cómo calcular la atención» (attention backend), «cómo comunicar» (distributed) y «cómo exponer hacia afuera» (serving). Así,cambiar el backend de attention no afecta a la planificación,cambiar el backend de ejecución (single GPU/Ray) no afecta a la lógica de KV cache,y añadir prefix cache no modifica el código del modelo. EngineCore es el único núcleo:todas las peticiones fluyen a través de él.
Lecturas equivocadas habituales
- «El núcleo de vLLM es PagedAttention» — PagedAttention es la técnica clave para la gestión de la KV cache,pero el núcleo de la arquitectura v1 es el trío EngineCore + Scheduler + batching continuo (continuous batching);PagedAttention es solo la implementación de la capa de KV cache.
- «LLMEngine es el motor» — en v1,LLMEngine es una cáscara fina;quien realmente trabaja es EngineCore,y LLMEngine se ocupa sobre todo de validar parámetros y reenviar peticiones.
- «continuous batching y PagedAttention son lo mismo» — no lo son. continuous batching es la estrategia de planificación (puede añadir/quitar peticiones en cada paso),y PagedAttention es la gestión de memoria (KV cache en bloques);cooperan pero son independientes.
Orden de lectura recomendado
Empieza por Arranque y configuración,luego LLMEngine y EngineCore,y después sigue el orden Planificador → Executor → Worker y ModelRunner → KV Cache → Attention → Sampling → Distribuido y serving.