Cómo realmente despliego Ollama en Kubernetes (y los dolores de GPU que arreglé)

Ejecutar Ollama en Kubernetes no es difícil. Mantenerlo útil a escala es donde empiezan las opiniones. Hacer que vea tu GPU es donde desaparece el fin de semana.

Ejecuto Ollama en mi cluster de Kubernetes de homelab. Es una configuración de K3s de tres nodos. Un nodo tiene una GTX 1080 para cargas de GPU. Hacer que Ollama realmente use esa GPU tomó más tiempo del que esperaba.

Este post es lo que realmente desplegué y lo que realmente se rompió.

Lo que realmente desplegué

Mi Deployment de Ollama se ve así:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ollama
  namespace: ollama
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: ollama
  template:
    metadata:
      labels:
        app: ollama
    spec:
      runtimeClassName: nvidia
      nodeSelector:
        gpu-type: nvidia
      containers:
        - name: ollama
          image: ollama/ollama:latest
          ports:
            - containerPort: 11434
          env:
            - name: OLLAMA_KEEP_ALIVE
              value: "30m"
            - name: OLLAMA_MAX_LOADED_MODELS
              value: "2"
          resources:
            limits:
              nvidia.com/gpu: "1"
              memory: 16Gi
              cpu: "4"
          volumeMounts:
            - name: models
              mountPath: /root/.ollama
      volumes:
        - name: models
          persistentVolumeClaim:
            claimName: ollama-models

Notas importantes:

• Recreate strategy porque el PVC es ReadWriteOnce. Dos pods no pueden montarlo.
• runtimeClassName: nvidia porque sin esto, la GPU es invisible.
• OLLAMA_KEEP_ALIVE: 30m porque me cansé de esperar la recarga del modelo en cada petición.
• OLLAMA_MAX_LOADED_MODELS: 2 porque mi GTX 1080 puede caber cómodamente un modelo de 8B, o dos más pequeños.

Lo que realmente observo

Rastreo tres cosas en Grafana:

• Utilización de GPU durante la inferencia. Debería subir a casi 100% cuando una petición está activa. Si se queda en 0%, el modelo está corriendo en CPU. Reviso esto cada vez que despliego un nuevo modelo.
• Conjunto de trabajo de memoria contra el límite. Tuve un OOMKill cuando intenté cargar un modelo de 13B. El pod se reinició, el modelo se perdió, y tuve que volver a descargarlo. Eso tomó 20 minutos.
• Latencia de API desde el ingress. Expongo Ollama a través de un ingress interno con autenticación básica. La latencia debería estar bajo 2 segundos para un prompt corto. Si es más alta, reviso si el modelo todavía está cargado o si la GPU está ocupada.

Lo que no haría (porque lo intenté)

• Compartir el PVC entre réplicas. No funciona con ReadWriteOnce. Aprendí esto cuando intenté escalar a 2 réplicas y el segundo pod se quedó atascado en Pending.
• Ejecutar Ollama en CPU. Lo intenté una vez cuando el GPU Operator se rompió. Un prompt que tomaba 2 segundos en GPU tomó 45 segundos en CPU. No es usable.
• Servir de producción con SLAs. Ollama no está construido para eso.
• Alta concurrencia. Un usuario a la vez está bien. Dos usuarios empieza a ponerse lento.
• Modelos mayores a 8B en mi GTX 1080. Podría caber, pero la generación es lenta y hay riesgo de OOM.

Conclusión

Desplegar Ollama en Kubernetes es técnicamente viable y operacionalmente exigente. La parte difícil no es el YAML. Es hacer que la GPU sea visible, mantener los modelos cargados, y no quedarte sin memoria.

Si tu cluster no tiene GPU, no empieces con Ollama. Empieza por entender si tu organización está lista para operar GPU. Si tienes GPU, el YAML es lo fácil. El resto es monitoreo, límites, y paciencia.

Mi GTX 1080 no es una GPU de producción. Es una GPU de aprendizaje. Sé la diferencia.