El motor de inferencia constituye la infraestructura crítica que soporta servicios de LLM como OpenAI o Claude, dictando la eficiencia con la que los modelos procesan las solicitudes de los usuarios. Comprender sus mecanismos internos, desde el procesamiento de *prompts* hasta la gestión de recursos de GPU, es fundamental para el diseño de sistemas robustos. El análisis se centra en Nano-vLLM, una implementación concisa que encapsula las funcionalidades esenciales de vLLM, según se detalla en un informe reciente de neutree.ai.
Nano-vLLM, desarrollado por un colaborador de DeepSeek, logra un rendimiento comparable al motor completo vLLM a pesar de su base de código reducida, implementando características clave como el *prefix caching* y optimizaciones de compilación de *torch*. La primera parte de esta exploración se enfoca en la arquitectura de ingeniería: cómo se organizan los componentes, el flujo de las solicitudes y las decisiones de programación que optimizan el rendimiento.
El flujo principal comienza cuando el método *generate* recibe *prompts* de texto, los cuales son transformados en secuencias internas mediante un *tokenizer* específico del modelo. Estas secuencias se convierten en la unidad de trabajo principal que navega por el sistema, un proceso que precede a la computación real del modelo.
El diseño central sigue un patrón productor-consumidor, con el *Scheduler* (programador) como eje central, desacoplando la recepción de solicitudes de su procesamiento. El método *addrequest* actúa como productor, añadiendo secuencias a la cola del *Scheduler*, mientras que un bucle de consumo extrae lotes de secuencias para su procesamiento eficiente en la GPU.
Este agrupamiento (*batching*) es crucial para amortizar la sobrecarga fija de la computación en GPU, como la inicialización de *kernels* CUDA y las transferencias de datos, mejorando drásticamente el rendimiento general (*throughput*). Sin embargo, esto introduce una tensión inherente en el diseño: lotes más grandes aumentan el rendimiento a costa de una latencia potencialmente mayor para solicitudes individuales.
La inferencia se divide en dos fases computacionales distintas: el *Prefill*, donde se procesan todos los *tokens* de entrada para establecer el estado interno del modelo, y el *Decode*, donde se generan *tokens* de salida secuencialmente. El *Scheduler* debe gestionar estas fases de manera diferente debido a sus características computacionales contrastantes, priorizando el procesamiento masivo en *Prefill* y el paso a paso en *Decode*.
El *Scheduler* mantiene colas de Espera y Ejecución, y utiliza el *Block Manager* para la asignación de recursos, específicamente para el caché KV. Si la memoria de la GPU se agota, el *Scheduler* puede desalojar (*preempt*) secuencias activas y devolverlas a la cola de espera, asegurando la reanudación una vez que los recursos del caché KV se liberen.
El *Block Manager* implementa una gestión de memoria innovadora al dividir las secuencias en bloques de tamaño fijo, gestionando metadatos en la CPU y utilizando *hashing* para reutilizar bloques de caché idénticos, un mecanismo poderoso para escenarios con prefijos comunes en aplicaciones de *chat*.
