Ollama auf Kubernetes deployen: GPU-LLMs in Produktion

Phillip Pham, Geschäftsführer bei Pexon Consulting | 10 Min. Lesezeit | 04.08.2026

TL;DR

Ollama auf Kubernetes bringt lokale LLMs vom Einzelserver in den produktiven, skalierbaren Betrieb: GPU-Scheduling, persistenter Modellspeicher, Autoscaling und Ingress. Diese Anleitung zeigt das Deployment über das Helm-Chart, den NVIDIA GPU Operator und ein StatefulSet Schritt für Schritt, inklusive der häufigsten Stolpersteine bei GPU-Nodes und Modellspeicher.

Warum Ollama auf Kubernetes, nicht auf einem Einzelserver

Ollama auf einem Ubuntu-Server zu installieren ist in zehn Minuten erledigt, und für einen Proof of Concept ist das genau richtig. Für den Produktivbetrieb reicht es nicht. Ein Einzelserver hat keinen Failover, kein Autoscaling und keine saubere Trennung zwischen teurer GPU-Hardware und dem Rest Ihrer Workloads.

Kubernetes löst genau diese drei Punkte. GPU-Nodes lassen sich gezielt für die LLM-Last reservieren, das Modell überlebt einen Pod-Neustart dank persistentem Speicher, und bei Lastspitzen skalieren Sie horizontal. Wer schon einen Cluster betreibt, bekommt Monitoring, Ingress und Zugriffskontrolle gratis dazu.

Wenn Sie noch beim Einzelserver stehen, ist das der richtige Startpunkt: unsere Anleitung zu Ollama und Open WebUI auf Ubuntu. Dieser Beitrag ist der nächste Schritt, vom POC in die Produktion.

Was Sie für dieses Tutorial brauchen

• Einen Kubernetes-Cluster (verwaltet oder self-hosted) mit mindestens einem GPU-Node, idealerweise NVIDIA.
• kubectl und helm (v3) lokal konfiguriert und mit dem Cluster verbunden.
• Cluster-Admin-Rechte, um den NVIDIA GPU Operator und Namespaces anzulegen.
• Eine grobe Vorstellung, welches Modell Sie fahren wollen, denn davon hängt der GPU-Speicherbedarf ab. Ein 8B-Modell läuft auf einer kleinen GPU, ein 70B-Modell braucht deutlich mehr.

Schritt 1: GPU-Nodes vorbereiten

Kubernetes sieht GPUs nicht von allein. Sie brauchen den NVIDIA GPU Operator, der Treiber, Device-Plugin und Monitoring ausrollt. Installiert wird er per Helm:

# NVIDIA GPU Operator installieren, macht GPUs im Cluster nutzbar
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
helm install gpu-operator nvidia/gpu-operator 
  --namespace gpu-operator --create-namespace

Danach prüfen Sie, ob die GPUs als zuweisbare Ressource auftauchen:

# Zeigt die Zahl der nvidia.com/gpu Ressourcen pro Node
kubectl get nodes -o json | grep -i "nvidia.com/gpu"

Ein Praxishinweis: Reservieren Sie die GPU-Nodes ausschließlich für die LLM-Last. Setzen Sie einen Taint, damit gewöhnliche Pods die teure Hardware nicht belegen und Ollama CPU oder RAM wegnehmen:

kubectl taint nodes <gpu-node-name> nvidia.com/gpu=true:NoSchedule

Schritt 2: Ollama per Helm deployen

Für Ollama gibt es ein community-gepflegtes Helm-Chart (otwld/ollama-helm), das GPU-Unterstützung, persistenten Speicher und Modell-Preload mitbringt. Zuerst das Repo hinzufügen:

helm repo add ollama-helm https://otwld.github.io/ollama-helm/
helm repo update

Die Konfiguration legen Sie in einer values.yaml ab. Hier die produktionsnahen Kernwerte: GPU aktiviert, persistenter Speicher für die Modelle und eine Toleration für den oben gesetzten Taint.

# values.yaml: Ollama auf Kubernetes mit GPU und persistentem Speicher
ollama:
  gpu:
    enabled: true
    type: nvidia
    number: 1
  models:
    pull:
      - llama3.1        # Modell beim Start vorladen
persistentVolume:
  enabled: true         # Modelle bleiben nach Pod-Neustarts erhalten
  size: 50Gi
tolerations:
  - key: nvidia.com/gpu
    operator: Exists
    effect: NoSchedule

Dann das Deployment ausrollen:

helm install ollama ollama-helm/ollama 
  --namespace ollama --create-namespace 
  --values values.yaml

Da sich Chart-Optionen zwischen Versionen ändern, gleichen Sie die Werte im Zweifel mit der aktuellen Chart-Dokumentation ab. Welche Inferenz-Engine überhaupt zu Ihrem Anwendungsfall passt, Ollama, vLLM oder TGI, klärt unser Vergleich der Inference Engines.

Schritt 3: Modellspeicher und StatefulSet

Der häufigste Anfängerfehler ist, den Modellspeicher zu vergessen. Ohne persistentes Volume lädt Ollama nach jedem Pod-Neustart alle Modelle neu herunter, das dauert bei einem 70B-Modell zig Minuten und kostet bei jeder Neuplanung Zeit und Bandbreite. Das persistentVolume.enabled: true aus Schritt zwei legt diesen Speicher an.

Für den Betrieb mit Modellzustand ist ein StatefulSet die sauberere Wahl als ein Deployment, weil es dem Pod eine stabile Identität und ein festes Volume zuordnet. Prüfen Sie nach dem Rollout, ob der Pod läuft und die GPU sieht:

kubectl -n ollama get pods
kubectl -n ollama exec -it <ollama-pod> -- ollama list

Schritt 4: Service, Ingress und Test

Ollama läuft jetzt, ist aber nur clusterintern erreichbar. Für den Zugriff durch Anwendungen legen Sie einen Service (ClusterIP) an, für den Zugriff von außen einen Ingress mit TLS. Danach testen Sie die API:

# Test gegen die Ollama-API im Cluster
kubectl -n ollama port-forward svc/ollama 11434:11434 &
curl http://localhost:11434/api/generate 
  -d '{"model": "llama3.1", "prompt": "Sag Hallo auf Deutsch."}'

Kommt eine sinnvolle Antwort zurück, steht die Basis. Von hier binden Sie ein Frontend wie Open WebUI oder ein Gateway wie LiteLLM an, das die OpenAI-kompatible Schnittstelle bereitstellt.

Troubleshooting: die häufigsten Fehler

• Pod bleibt in Pending: Kein GPU-Node verfügbar oder der Taint hat keine passende Toleration. Prüfen Sie kubectl describe pod auf die Ursache im Scheduling.
• GPU wird nicht erkannt: Der NVIDIA GPU Operator ist nicht vollständig ausgerollt. Prüfen Sie die Pods im Namespace gpu-operator, besonders das Device-Plugin.
• Modell lädt bei jedem Neustart neu: Das persistente Volume fehlt oder ist nicht gemountet. Ohne persistentVolume.enabled: true gibt es keinen dauerhaften Modellspeicher.
• Out of Memory beim Modellstart: Das Modell ist zu groß für den GPU-Speicher. Wählen Sie ein kleineres Modell oder eine GPU mit mehr VRAM.

Produktions-Checkliste

Bevor Sie den Cluster für echte Last freigeben, gehen Sie diese Punkte durch.

1. GPU-Nodes per Taint reserviert, Ollama mit passender Toleration.
2. Persistentes Volume für den Modellspeicher aktiviert und ausreichend dimensioniert.
3. Ressourcen-Limits (GPU, RAM) gesetzt, damit ein Pod den Node nicht überlastet.
4. Ingress mit TLS, nicht ungesicherter Zugriff auf Port 11434.
5. Monitoring der GPU-Auslastung, um teure Leerlaufzeiten zu erkennen.
6. Zugriff über ein Gateway oder Frontend mit Authentifizierung, nicht die offene API.
7. Backup oder Reproduzierbarkeit des Modellstands dokumentiert.

Häufig gestellte Fragen

Warum Ollama auf Kubernetes statt auf einem einzelnen Server?

Ein Einzelserver eignet sich für den POC, hat aber keinen Failover, kein Autoscaling und keine saubere Ressourcentrennung. Kubernetes reserviert GPU-Nodes gezielt, hält den Modellstand über Neustarts hinweg und skaliert bei Last. Wer bereits einen Cluster betreibt, bekommt Monitoring, Ingress und Zugriffskontrolle ohne Zusatzaufwand.

Brauche ich zwingend NVIDIA-GPUs?

Für ernsthaften LLM-Betrieb praktisch ja. Ollama läuft zwar auch auf CPU, aber die Antwortzeiten sind für produktive Nutzung meist zu langsam. Der NVIDIA GPU Operator ist der Standardweg, GPUs in Kubernetes nutzbar zu machen. Andere Beschleuniger sind möglich, aber deutlich weniger verbreitet und schlechter dokumentiert.

Welches Modell passt auf welche GPU?

Als grobe Orientierung: Ein 8B-Modell läuft auf einer GPU mit 16 GB VRAM komfortabel, ein 70B-Modell braucht deutlich mehr, oft mehrere GPUs oder Quantisierung. Wählen Sie das Modell nach Anwendungsfall und rechnen Sie den VRAM-Bedarf vor dem Kauf der Hardware durch.

Wie binde ich ein Chat-Frontend an?

Über den ClusterIP-Service. Open WebUI oder ein LiteLLM-Gateway sprechen die OpenAI-kompatible Ollama-Schnittstelle an. Das Gateway davor gibt Ihnen zusätzlich zentrale Zugriffskontrolle und Kostentracking über mehrere Modelle hinweg.

Lohnt sich der Aufwand gegenüber einer Cloud-API?

Das hängt vom Volumen und vom Schutzbedarf ab. Bei moderater Nutzung ist eine verwaltete API meist günstiger. Self-hosted auf Kubernetes lohnt sich bei hohem, dauerhaftem Volumen oder wenn die Daten das Rechenzentrum nicht verlassen dürfen.

Nächster Schritt

Das Deployment ist der Anfang. Der Dauerbetrieb, GPU-Auslastung im Griff, Modelle aktuell, Frontends abgesichert, ist die eigentliche Arbeit. Wenn Sie einen KI-Cluster produktiv und wirtschaftlich betreiben wollen, sprechen wir darüber.

Verwandte Themen