Las mismas 16 GPU, el doble de usuarios: Enrutamiento con reconocimiento de inferencias para clústeres de LLM

TL;DR: Las mismas 16 GPU, el doble de usuarios. Tu factura de GPU se mantiene estable mientras la capacidad se duplica. Un clúster que manejaba 20 usuarios simultáneos ahora gestiona 200. Estos números son posibles gracias al programador de inferencias de llm-d. Se diseñó para enrutar cada solicitud a través de un clúster distribuido con visibilidad de cada nodo, cola y caché. Las solicitudes de modelos de lenguaje de gran tamaño (LLM) son lentas, no uniformes y costosas; el programador de inferencias se diseñó precisamente para eso.

El patrón que funciona en todos los demás entornos

Cada hora de GPU tiene un precio; la pregunta es cuánto trabajo obtienes de ella.

Kubernetes es la forma en que se crean, implementan y operan los servicios distribuidos a escala. En una configuración estándar de Kubernetes, defines una implementación, estableces una cantidad de réplicas y un servicio de Kubernetes te ofrece un punto de acceso con equilibrio de carga round-robin en todos tus pods. Para las API REST, los servicios web y los microservicios, este patrón es prácticamente perfecto. Las solicitudes son rápidas y uniformes, y cada una tarda aproximadamente la misma fracción de segundo en completarse.

Pero en el momento en que empiezas a ofrecer modelos generativos de gran tamaño a escala, como los modelos open source de clase Llama, Mistral o GPT, esa suposición deja de ser válida.

Donde el round-robin alcanza sus límites

Las solicitudes de inferencia de LLM no son como las solicitudes HTTP normales, y las diferencias son las que interrumpen el equilibrio de carga estándar:

• Variabilidad temporal: Una solicitud puede tardar menos de un segundo o más de un minuto, según lo que se le pida al modelo. El round-robin distribuye las solicitudes, no el trabajo. Si una réplica recibe una secuencia de solicitudes largas y costosas, se convierte en un cuello de botella mientras otra permanece prácticamente inactiva.
• Variabilidad de la forma: Las peticiones cortas con respuestas generadas largas se comportan de manera diferente a las peticiones largas con respuestas cortas. El perfil de cómputo, la presión de la memoria y el tiempo de finalización son todos diferentes.
• Variabilidad de las fases: Cada solicitud de inferencia tiene dos fases internas: prefill, que procesa toda la petición de entrada en un solo barrido paralelo, y decode, que genera la respuesta token a token. Estas dos fases tienen distintos perfiles de recursos, duraciones y sensibilidad a la carga. Un sistema que no puede diferenciarlas no puede optimizar ninguna de las dos.

El round-robin se diseñó para cargas de trabajo en las que las solicitudes son efímeras, uniformes y económicas. Un programador que no puede ver el interior de la solicitud las trata como si fueran lo mismo.

Figura 1: El round-robin distribuye el recuento de solicitudes, no el trabajo. Las mismas 5 solicitudes (que varían en tamaño y costo de cómputo) llegan de forma desigual a los pods. Un pod queda sepultado bajo 2 solicitudes largas mientras otro permanece casi inactivo. El enrutamiento con reconocimiento de inferencias detecta la forma, el tamaño y la carga, y en su lugar equilibra el trabajo real.

Un acierto de caché en el pod equivocado es un error de caché

vLLM es el motor de inferencia estándar de facto para los LLM; todos los principales aceleradores de hardware están optimizados para él y los nuevos modelos se lanzan con soporte para vLLM desde el día 0. Gestiona excepcionalmente bien la mecánica de la inferencia en un solo nodo.

vLLM introdujo el almacenamiento en caché de prefijos para abordar una de las partes más costosas de la inferencia: volver a procesar los mismos prefijos de peticiones una y otra vez. Cuando varias solicitudes comparten un prefijo común (una petición del sistema, un documento o un historial de conversaciones), vLLM puede almacenar en caché el estado de clave-valor (KV) del primer cálculo y reutilizarlo para las solicitudes posteriores. En un acierto de caché, se omite por completo el paso de prefill: el tiempo hasta el primer token (TTFT) disminuye proporcionalmente a la parte de la petición que ya estaba almacenada, pero solo si la solicitud llega a la réplica específica que contiene esa caché.

Una solicitud que sería casi gratuita en una réplica se enruta a otra donde comienza desde cero. La optimización existe, pero el enrutamiento round-robin la ignora.

Con poco tráfico, esto es una oportunidad perdida. A escala, pagas el doble por el mismo cálculo.

Del nodo al clúster

Cada pod solo se ve a sí mismo, aunque cada pod de vLLM gestiona bien su parte de las solicitudes: administra la memoria, procesa lotes de forma eficiente y entrega tokens tan rápido como el hardware lo permite. No sabe qué están procesando sus pares, qué réplicas están bajo carga ni dónde se encuentra el estado de la caché de prefijos en el clúster. 

El problema de coordinación ocurre por encima del nodo. Kubernetes es la plataforma preferida para la infraestructura distribuida y la orquestación a escala, por lo que llm-d se diseñó para ser nativo de Kubernetes desde cero. 

Inference Gateway (IGW) es como se manifiesta en la práctica: una capa de tráfico basada en Envoy y la Kubernetes Gateway API que entiende las cargas de trabajo de LLM, no solo HTTP. Detrás de ella, el Inference Scheduler supervisa cada pod del InferencePool en tiempo real (profundidad de la cola, estado de la caché KV, carga) y enruta cada solicitud a la instancia correcta en lugar de a la siguiente en rotación.

Figura 2: Inference Gateway (IGW) recibe cada solicitud y consulta al Inference Scheduler (EPP) a través de ext_proc. El programador califica todos los pods del InferencePool basándose en dos señales en tiempo real (el estado de la caché KV y la carga), devuelve el endpoint seleccionado a IGW y esta reenvía la solicitud. En un acierto de caché, se reutiliza la parte de prefill almacenada y la decodificación comienza de inmediato. En un fallo de caché, prefill se ejecuta por completo.

Programación de inferencias a escala: Mismo hardware, el doble de capacidad

El programador de inferencias (Inference Scheduler o EPP de llm-d) es lo que materializa la coordinación a nivel de clúster. En lugar de tratar a todos los pods como intercambiables, enruta cada solicitud basándose en señales en tiempo real: Estado de la caché KV, profundidad de la cola y carga. Todas las solicitudes van a la instancia correcta, siempre.

Los resultados de las pruebas de rendimiento de llm-d v0.5 muestran lo que esto ofrece en la práctica.

Programación de inferencias (Qwen3-32B, 8 pods de vLLM, 16 NVIDIA H100):

• Hasta un 109% más de rendimiento frente a un servicio de Kubernetes básico. Las mismas 16 GPU atienden aproximadamente al doble de usuarios simultáneos en su objetivo de nivel de servicio (SLO).
• Hasta un 99% menos de tiempo hasta el primer token (TTFT) bajo una carga equivalente. La prueba de rendimiento muestra que el TTFT básico sube hasta unos dolorosos ~80 segundos bajo carga alta. La programación inteligente lo mantiene en ~150 ms. Esa es la diferencia entre un producto que parece defectuoso y uno que parece instantáneo.
  • La prueba de rendimiento mantiene ~11000 tokens de salida/s en 16 GPU. Suponiendo ~1000 tokens por respuesta y ~3 solicitudes por minuto por usuario activo, eso se traduce en unos 200 usuarios simultáneos en SLO, en un hardware donde el servicio de Kubernetes básico deja de ser utilizable después de los 20.

Cada resultado tiene control de versiones y está vinculado a una guía reproducible específica.

Figura 3: Programación de inferencias de llm-d frente a Kubernetes básico: TTFT medio y rendimiento total frente a QPS. Topología: 8 pods de vLLM, 16 NVIDIA H100 (TP=2). Carga de trabajo: prefijo compartido sintético, 150 grupos × 5 prompts, longitud de 6000/1200/1000 para sistema/pregunta/salida. Resultados: P50 TTFT 136-157 ms, 4,5-11k tok de salida/s, hasta un 109% más de rendimiento y un 99% menos de TTFT frente al nivel básico. Fuente: llm-d v0.5.

vLLM optimiza el nodo, llm-d optimiza el clúster

vLLM y llm-d están diseñados para trabajar juntos, y la brecha de rendimiento entre ejecutar uno sin el otro es medible: El doble de usuarios en el mismo hardware, un 99% mejor latencia bajo carga, un clúster que resiste con 250 usuarios simultáneos tan bien como lo hacía con 20.

Si ejecutas 2 o más réplicas, la programación de inferencia inteligente se aplica a tu carga de trabajo hoy mismo. La brecha de rendimiento no es incremental: es la diferencia entre un clúster que escala y uno que tiene dificultades. 

Aquí es donde comienza la inferencia distribuida.

Experimenta la escala por ti mismo

Las guías de llm-d y las configuraciones de las pruebas de rendimiento que respaldan cada cifra de esta publicación del blog son públicas y reproducibles. Un buen punto de partida es el lanzamiento de llm-d v0.5.

Red Hat AI Enterprise incluye una versión de llm-d con soporte empresarial con una prueba gratuita de 60 días de Red Hat AI Enterprise. Este es un buen lugar para comenzar si quieres ejecutar esto en tu propia infraestructura.

Si quieres ver primero el programador en acción, la Introduction to llm-d Interactive Demo explica cómo se enrutan las solicitudes.

Nota del autor: Datos de las pruebas de rendimiento obtenidos del lanzamiento de llm-d v0.5. Todos los resultados son reproducibles utilizando las configuraciones con control de versiones publicadas en las guías de llm-d.