La transición desde entornos locales basados en Ollama hacia una infraestructura de inferencia robusta con vLLM representa un salto arquitectónico fundamental. Ollama opera como un envoltorio de procesos en una máquina individual, limitado por un modelo de ejecución secuencial y bloqueante. Esto se manifiesta en una incapacidad para manejar la concurrencia, una asignación rígida de memoria de video (VRAM) y tiempos de respuesta degradados bajo carga. En contraste, vLLM está diseñado como un motor de inferencia distribuido, optimizado para la utilización densa de la GPU mediante tecnologías clave como PagedAttention para una gestión dinámica de la memoria KV Cache y Continuous Batching para el procesamiento eficiente de lotes.

La migración no es un simple reemplazo de contenedores, sino una reestructuración completa de la pila de servicio. Implica adaptar capas de solicitud y respuesta, rediseñar los mecanismos de despliegue y observabilidad, e integrarse con las primitivas orquestación de entornos de producción como Kubernetes. A continuación, se detalla un camino de ejecución basado en pruebas prácticas para realizar esta transición de manera controlada.

Evaluación Comparativa de Línea Base

Antes de cualquier cambio, es imprescindible establecer métricas comparativas idénticas. En un servidor con una GPU A10G (24GB VRAM), se ejecutaron pruebas de carga con el mismo conjunto de consultas.

# Prueba de línea base con Ollama
docker run --gpus all -d --name ollama_test ollama/ollama
docker exec ollama_test ollama run llama3:70b

# Solicitud de ejemplo
curl -s http://localhost:11434/api/chat \
  -d '{"model":"llama3:70b", "stream": false, "messages":[{"role":"user","content":"Explica el teorema central del límite en tres párrafos."}]}' | jq '.message.content'

# Prueba de línea base con vLLM
docker run --gpus all -d -v /ruta/modelos:/modelos \
  -p 8000:8000 --name vllm_test vllm/vllm-openai \
  --model /modelos/Meta-Llama-3-70B-Instruct \
  --gpu-memory-utilization 0.9

# Solicitud de ejemplo (formato OpenAI-compatible)
curl -s http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"Meta-Llama-3-70B-Instruct", "messages":[{"role":"user","content":"Explica el teorema central del límite en tres párrafos."}]}' | jq '.choices[0].message.content'

Los resultados típicos muestran una reducción dramática en la latencia del primer token (de ~1100ms a ~280ms) y un aumento significativo en las consultas por segundo (QPS) bajo carga concurrente para vLLM. Sin embargo, el tiempo de carga inicial del modelo en vLLM es considerablemente mayor.

Adaptación del Formato del Modelo y la API

Los modelos optimizados para Ollama suelen estar en formato GGUF. Si bien vLLM puede cargar modelos en formato Hugging Face (HF) nativo, que suele ofrecer mejor soporte para cuantización avanzada como AWQ, también soporta GGUF a través de parámetros específicos. Para una migración sin reentrenamiento, se puede usar el mismo archivo GGUF.

La capa de API requiere adaptaciones sustanciales. Ollama expone un endpoint /api/chat con un formato de respuesta propietario. vLLM ofrece compatibilidad con la API de OpenAI. Un servicio proxy o capa de adaptación debe traducir las solicitudes y respuestas.

# Ejemplo de adaptación en un servidor proxy (pseudocódigo)
app.post('/v1/chat/completions', async (req, res) => {
  // Extraer parámetros de la solicitud entrante
  const userQuery = req.body.messages;

  // Llamar al endpoint nativo de vLLM con formato OpenAI
  const vllmResponse = await fetch('http://vllm-server:8000/v1/chat/completions', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      model: "mi-modelo-local",
      messages: userQuery,
      max_tokens: req.body.max_tokens || 2048
    })
  });

  const data = await vllmResponse.json();

  // Reestructurar la respuesta al formato esperado por clientes legacy (si es necesario)
  const adaptedResponse = {
    id: data.id,
    object: "chat.completion",
    created: data.created,
    model: data.model,
    choices: data.choices,
    usage: data.usage
  };

  res.json(adaptedResponse);
});

Despliegue y Orquestación en Producción

Para el despliegue en un clúster de Kubernetes, se utilizan manifiestos que configuran la carga de recursos, los límites de concurrencia y el escalado automático. La configuración de vLLM a través de variables de entorno es crucial para el rendimiento.

# Fragmento de un Deployment de Kubernetes para vLLM
apiVersion: apps/v1
kind: Deployment
metadata:
  name: servicio-inferencia-vllm
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
      - name: vllm-container
        image: vllm/vllm-openai:latest
        args:
        - "--model"
        - "/modelos/llama3-70b-instruct"
        - "--tensor-parallel-size"
        - "1"
        - "--gpu-memory-utilization"
        - "0.85"
        - "--max-num-seqs"
        - "64"
        - "--disable-log-stats"
        - "false"
        env:
        - name: HUGGING_FACE_HUB_TOKEN
          valueFrom:
            secretKeyRef:
              name: hf-token-secret
              key: token
        resources:
          limits:
            nvidia.com/gpu: 1
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 120
          periodSeconds: 10

Parámetros como --max-num-seqs controlan la concurrencia máxima por réplica, y --gpu-memory-utilization define el porcentaje de VRAM reservado para el caché KV y los tensores del modelo. Su valor óptimo se determina mediante pruebas de carga controladas en el hardware objetivo.

Observabilidad y Solución de Problemas Comunes

vLLM expone métricas detalladas en formato Prometheus en el endpoint /metrics. Las métricas clave incluyen vllm:gpu_cache_usage_ratio, vllm:time_in_queue_seconds y vllm:generation_throughput_tokens_per_second. Estas métricas alimentan paneles de Grafana y alertas para monitorear la salud del servicio.

Los problemas frecuentes durante la migración suelen ser:

1. Latencia alta en respuestas streaming: A menudo causada por proxies (como Nginx) que almacenan en búfer las respuestas SSE. La solución es desactivar explícitamente el búfer.
2. Errores de OOM (Out-of-Memory) durante picos de carga: Requiere ajustar --max-num-seqs y posiblemente --block-size (tamaño de página del caché KV) para un uso más eficiente de la VRAM.
3. Salida incorrecta o formato de respuesta inesperado: Verificar que el modelo cargado en vLLM incluya la plantilla de chat (chat_template) corrrecta, la cual puede faltar si se migra desde un formato simplificado.
4. Tiempos de inicio proolngados del pod: Solucionable implementando sondeos de preparación (readinessProbe) con tiempos de espera generosos y considerando mecanismos de precalentamiento de modelos.

Una estrategia de migración gradual, utilizando una malla de servicios como Istio para enrutar un pequeño porcentaje del tráfico a la nueva implementación de vLLM, permite una validación controlada del rendimiento y la funcionalidad antes del corte completo.