Desplegar vLLM Kubernetes: Arquitectura y Setup

Parte 1 de 6. Esta serie cubre el despliegue de vLLM en producción con Kubernetes en seis partes. Parte 2 → Despliegue Paso a Paso en Kubernetes

Desplegar vLLM en producción exige GPU scheduling, tensor parallelism, cuantización y observabilidad para servir LLMs a escala. Esta guía te entrega manifiestos hardened para producción, datos de benchmark reales y el checklist de 10 puntos que ejecuto en cada cluster antes de salir a producción.

¿Qué es vLLM y por qué usarlo para inferencia en producción?

vLLM es un motor de inferencia open-source diseñado para serving de LLM de alto rendimiento en GPUs NVIDIA. Tres innovaciones arquitectónicas lo diferencian de cualquier alternativa:

• PagedAttention: Un algoritmo de gestión de memoria que divide el KV cache en bloques no contiguos, mejorando la utilización de memoria GPU por 2-4× comparado con la asignación estática.
• Continuous batching: Agrega dinámicamente nuevas requests a los batches en ejecución a medida que se liberan slots de secuencia, entregando 3-5× mayor throughput versus el batching estático.
• Tensor parallelism: Divide las capas del modelo entre múltiples GPUs vía NCCL all-reduce, permitiendo que modelos que exceden la VRAM de una sola GPU corran en nodos multi-GPU.

En tokens-por-segundo-por-dólar, los despliegues de vLLM production aplastan a los servidores de propósito general. La documentación oficial de vLLM profundiza en estos mecanismos.

Prerrequisitos para ejecutar vLLM en Kubernetes

Tu cluster necesita estar GPU-ready: drivers correctos, operators adecuados, red configurada. Un GPU operator faltante o una versión incorrecta de CUDA es la razón #1 de fallos en producción.

Requisitos de hardware y cluster

Verificación de software

# Verifica que el GPU operator y el device plugin estén corriendo
kubectl get pods -n gpu-operator

# Confirma que la capacidad de GPU se anuncia en los nodos
kubectl get nodes -o json | jq '.items[].status.capacity | select(has("nvidia.com/gpu"))'

También necesitarás Prometheus Adapter para HPA (cubierto en la Parte 2).

Almacenamiento de modelos

vLLM trae modelos de Hugging Face por defecto. En producción eso no sirve. Siempre precarga los pesos en un PersistentVolume local. Un modelo 70B en FP16 consume ~140 GB. Descargar eso en cada arranque destruirá tus SLOs.

Matriz de compatibilidad de versiones

Versiones desalineadas de vLLM, CUDA y Kubernetes producen errores crípticos en runtime. Consulta esta matriz para cada upgrade:

Regla de hierro: Actualiza vLLM y CUDA siempre juntos. Ejecutar vLLM 0.8.x con CUDA 12.1 provoca fallos de kernels FP8 en GPUs H100.

Visión general de la arquitectura para LLM Serving

La arquitectura es directa: Ingress enruta requests hacia Pods con GPU, Prometheus recolecta métricas, HPA escala según la cola de inferencia.

graph LR
    A[Client] --> B[Ingress / NGINX]
    B --> C[vLLM Service]
    C --> D[vLLM Pod]
    D --> E[GPU 0]
    D --> F[GPU 1]
    D --> G[GPU 2]
    D --> H[GPU 3]
    D --> I[Model PVC]
    J[Prometheus] --> D
    K[Grafana] --> J
    L[HPA Controller] --> D

Flujo de datos:

1. Un cliente envía una request chat/completions compatible con OpenAI a través de Ingress.
2. El Service de Kubernetes la reenvía al Pod de vLLM.
3. PagedAttention inserta la request en el batch activo.
4. Tensor parallelism distribuye el cómputo entre GPUs mediante NCCL.
5. Prometheus consulta /metrics para rastrear SLIs.
6. HPA crea réplicas cuando vllm_num_requests_running cruza el umbral.

Continúa en Parte 2: Despliegue Paso a Paso en Kubernetes donde configurarás el namespace, los ConfigMaps, los Secrets y desplegarás vLLM en producción.