En los entornos corporativos modernos de 2026, la transición de los modelos de inteligencia artificial desde fases preliminares de investigación hasta su puesta en servicio comercial a gran escala plantea uno de los desafíos de ingeniería de infraestructura más exigentes de la década. Servir un modelo de lenguaje de 70.000 millones de parámetros no se asemeja en nada a desplegar un contenedor web tradicional en Node.js o Python: la gestión de la memoria de la GPU, el particionado de tensores entre aceleradores físicos y la volatilidad del tráfico exigen una arquitectura de orquestación industrial.

Para resolver la ecuación de alto rendimiento y costes sostenibles, los ingenieros de infraestructura combinan la potencia de Kubernetes con el motor de inferencia de código abierto vLLM (desarrollado por UC Berkeley) y el compilador de bajo nivel TensorRT-LLM de NVIDIA. Al aprovechar la innovadora gestión de memoria de PagedAttention —que trata la memoria caché de claves y valores (KV Cache) del transformador como si fuera la memoria virtual paginada de un sistema operativo—, vLLM logra multiplicar el rendimiento de procesamiento (throughput) hasta por 24 veces frente a servidores ingenuos basados en Hugging Face Transformers.

De acuerdo con mediciones estandarizadas de la industria publicadas por el consorcio MLCommons (MLPerf Inference Benchmarks) y directrices de orquestación de la Cloud Native Computing Foundation (CNCF), la integración de vLLM con Kubernetes y auto-escalado basado en colas (KEDA) reduce el coste por token servido en más de un 68% en nubes públicas y privadas. Como hemos analizado al evaluar servidores locales con Ollama y el monitoreo de observabilidad distribuida con Langfuse, el despliegue a escala es la culminación de la madurez tecnológica de cualquier plataforma de IA.

1. El Cuello de Botella de la Inferencia: Por Qué Falla el Batching Tradicional

La inferencia en modelos de lenguaje opera en dos fases computacionales muy diferentes: la fase de Prefill (procesamiento paralelo de los tokens de entrada) y la fase de Decode (generación autorregresiva token a token). Durante la fase de decodificación, el cálculo está estrictamente limitado por el ancho de banda de la memoria de la tarjeta gráfica (Memory Bandwidth Bound): la GPU debe leer gigabytes de parámetros de pesos únicamente para emitir una sola palabra.

En los servidores convencionales, el procesamiento por lotes estático (Static Batching) agrupaba varias peticiones obligando a rellenar con ceros (padding) las secuencias más cortas hasta igualar la longitud de la más larga. Peor aún: si una petición requería generar solo 10 tokens y otra necesitaba 500 tokens, la primera petición permanecía bloqueada en la GPU desperdiciando ciclos de computación hasta que la última secuencia finalizaba su generación.

Este desperdicio masivo de recursos computacionales provocaba que las tarjetas gráficas operaran a menos del 20% de su capacidad teórica, encareciendo desorbitadamente el coste de la infraestructura.

La inferencia a gran escala exige coordinar clústeres de GPUs optimizando el tráfico concurrente de tokens.

2. PagedAttention y Continuous Batching: Los Fundamentos Matemáticos de vLLM

La solución arquitectónica concebida por el equipo de UC Berkeley en vLLM revolucionó la industria mediante dos conceptos:

PagedAttention: En lugar de reservar un bloque de memoria contiguo y estático en la VRAM para cada sesión de usuario (lo que provocaba una fragmentación interna y externa de más del 60%), PagedAttention divide la memoria caché de claves y valores (KV Cache) en bloques no contiguos de tamaño fijo (por ejemplo, 16 tokens). La GPU utiliza una tabla de páginas para acceder a los bloques dispersos en memoria física, reduciendo el desperdicio de VRAM a menos del 4% y permitiendo alojar hasta 5 veces más usuarios simultáneos en la misma tarjeta gráfica.

Agrupamiento Continuo (Continuous Batching / Iteration-level Scheduling): En lugar de esperar a que termine un lote completo, vLLM programa la inferencia a nivel de iteración individual de token. Tan pronto como una petición finaliza su generación, se desaloja de la GPU y una nueva petición en cola entra a ocupar su lugar de inmediato en el siguiente paso de decodificación, maximizando la utilización de los núcleos de cálculo en un 95% continuo.

3. Contenedorización Optimizada: Construcción de Imágenes Docker con CUDA y FlashAttention

Para empaquetar nuestro motor de inferencia, utilizamos la imagen base optimizada de vLLM, compilada con soporte nativo para los kernels acelerados de FlashAttention-2 y Cutlass:

# Dockerfile optimizado para producción
FROM vllm/vllm-openai:latest

# Variables de entorno para optimización de memoria CUDA
ENV CUDA_VISIBLE_DEVICES=0,1
ENV NCCL_DEBUG=WARN
ENV VLLM_LOGGING_LEVEL=INFO

# Puerto expuesto para la API REST compatible con OpenAI
EXPOSE 8000

# Punto de entrada con paralelismo de tensores (2 GPUs)
ENTRYPOINT ["python3", "-m", "vllm.entrypoints.openai.api_server", \
            "--model", "/modelos/Meta-Llama-3.1-70B-Instruct", \
            "--tensor-parallel-size", "2", \
            "--max-model-len", "8192", \
            "--gpu-memory-utilization", "0.95", \
            "--port", "8000"]

Esta configuración arranca automáticamente un servidor web ASGI de alto rendimiento que expone los endpoints estándar /v1/completions y /v1/chat/completions, permitiendo consumir el clúster con cualquier cliente o librería existente.

Las imágenes de vLLM integran FlashAttention-2 para exprimir al máximo el ancho de banda de la GPU.

4. NVIDIA GPU Operator en Kubernetes: Asignación de Recursos y Time-Slicing

Para que Kubernetes pueda programar pods en nodos equipados con tarjetas gráficas, instalamos el NVIDIA GPU Operator mediante Helm. Este operador gestiona de forma automatizada los controladores del kernel de Linux, el toolkit de contenedores de NVIDIA y el plugin de dispositivos para K8s:

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
helm install --wait --generate-name \
     -n gpu-operator --create-namespace \
     nvidia/gpu-operator

Una vez activo, los pods pueden solicitar aceleradores físicos de forma nativa en su especificación de recursos utilizando la directiva resources.limits.nvidia.com/gpu: "2", garantizando que el planificador de Kubernetes solo asigne el pod a máquinas que dispongan de la cantidad exacta de GPUs requerida para el paralelismo de tensores.

5. Manifiestos de Kubernetes: Deployment de vLLM, Health Checks y Model Cache en PV

Descargar un modelo de 70GB desde Hugging Face cada vez que un pod se reinicia retrasaría los arranques en más de 20 minutos. La práctica canónica consiste en pre-descargar los pesos del modelo en un volumen persistente (PersistentVolume) compartido mediante NFS o almacenamiento de bloques en la nube:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-llama3-deployment
  namespace: ai-production
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm-llama3
  template:
    metadata:
      labels:
        app: vllm-llama3
    spec:
      containers:
      - name: vllm-server
        image: vllm/vllm-openai:latest
        args:
        - "--model=/models/llama-3.1-8b-instruct"
        - "--gpu-memory-utilization=0.92"
        - "--max-model-len=4096"
        resources:
          limits:
            nvidia.com/gpu: "1"
            memory: 32Gi
            cpu: "8"
        ports:
        - containerPort: 8000
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 40
          periodSeconds: 10
        volumeMounts:
        - name: model-storage
          mountPath: /models
      volumes:
      - name: model-storage
        persistentVolumeClaim:
          claimName: llm-models-pvc

El sondeo de disponibilidad (Readiness Probe) consulta el endpoint /health del servidor vLLM, impidiendo que el balanceador de tráfico envíe peticiones al pod mientras el modelo se está cargando en la memoria gráfica.

Kubernetes orquesta el ciclo de vida de los pods de inferencia garantizando alta disponibilidad.

6. Tabla Comparativa: Motores de Producción: vLLM vs. NVIDIA TensorRT-LLM vs. TGI

Comparamos los tres motores dominantes para inferencia a gran escala en centros de datos:

7. Escalado Elástico con KEDA: Autoescalado según Peticiones Pendientes en Cola

El escalado automático estándar de Kubernetes basado en porcentaje de CPU o memoria (HPA clásico) fracasa estrepitosamente con los LLMs: la memoria VRAM de la GPU permanece ocupada casi al 95% de forma continua debido a la reserva estática de la KV Cache, engañando al planificador y provocando escalados infinitos o inútiles.

La arquitectura profesional implementa KEDA (Kubernetes Event-driven Autoscaling) basándose en la longitud de la cola de peticiones en espera expuesta por las métricas Prometheus de vLLM (vllm:num_requests_waiting):

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-queue-autoscaler
  namespace: ai-production
spec:
  scaleTargetRef:
    name: vllm-llama3-deployment
  minReplicaCount: 1
  maxReplicaCount: 8
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus-k8s.monitoring.svc:9090
      metricName: vllm_num_requests_waiting
      threshold: '5'  # Si hay más de 5 peticiones esperando en cola, levantar nuevo pod
      query: sum(vllm:num_requests_waiting{app="vllm-llama3"})

Cuando el tráfico nocturno cae a cero, el clúster mantiene una sola réplica caliente. Si un pico repentino de tráfico acumula más de 10 peticiones en espera, KEDA aprovisiona de forma inmediata nuevos nodos con GPUs, garantizando latencias p99 impecables sin incurrir en costes ociosos durante horas de baja actividad.

8. Preguntas Frecuentes sobre Inferencia a Escala con vLLM y Kubernetes