Ollama Cluster: Mehrere Server load-balancen

TL;DR

Ein Ollama Cluster verteilt KI-Anfragen automatisch auf mehrere Server und skaliert von 15 auf 200+ gleichzeitige Nutzer. Mit Nginx als Reverse Proxy und Health Checks erreichen Sie 99,9% Verfügbarkeit. Drei GPU-Server mit je einer RTX 4090 kosten €870/Monat bei Hetzner und ersetzen Cloud-KI-Dienste im Wert von €4.500/Monat.

Wann ein einzelner Ollama-Server nicht mehr reicht

Ein einzelner Ollama-Server mit RTX 4090 bedient 15-20 gleichzeitige Nutzer zuverlässig. Bei 25 Nutzern steigt die Latenz über 5 Sekunden. Bei 30 Nutzern treten Timeouts auf. Für Unternehmen mit 50-300 Mitarbeitern, die KI aktiv nutzen, reicht ein Server nicht aus.

Die typischen Symptome: Mitarbeiter beschweren sich über langsame Antworten. Anfragen laufen in Timeouts. Die GPU-Auslastung liegt dauerhaft über 95%. Der Server reagiert träge, selbst auf einfache Prompts.

Die Lösung: Ein Ollama Cluster mit Load Balancing verteilt die Last auf mehrere Server. Fällt ein Server aus, übernehmen die verbleibenden automatisch. Die Kapazität wächst linear mit jedem zusätzlichen Server.

Skalierungskurve:

Architektur: Nginx als Load Balancer vor Ollama

Die einfachste und stabilste Architektur für ein Ollama Cluster nutzt Nginx als Reverse Proxy mit Upstream-Konfiguration. Nginx verteilt eingehende API-Anfragen nach dem Least-Connections-Algorithmus auf die verfügbaren Ollama-Server.

# Ollama Cluster Architektur
cluster:
  load_balancer:
    software: "Nginx (Open Source)"
    algorithmus: "least_conn"
    health_check_intervall: "5 Sekunden"
    server: "Dedizierter Mini-Server oder auf einem Ollama-Node"

  ollama_nodes:
    node_1:
      hostname: "ollama-01.intern.firma.de"
      gpu: "RTX 4090 (24 GB)"
      modelle: ["llama3.1:8b", "mistral:7b"]
      port: 11434
    node_2:
      hostname: "ollama-02.intern.firma.de"
      gpu: "RTX 4090 (24 GB)"
      modelle: ["llama3.1:8b", "mistral:7b"]
      port: 11434
    node_3:
      hostname: "ollama-03.intern.firma.de"
      gpu: "RTX 4090 (24 GB)"
      modelle: ["llama3.1:8b", "codellama:13b"]
      port: 11434

  nginx_upstream_config: |
    upstream ollama_cluster {
        least_conn;
        server ollama-01.intern.firma.de:11434 max_fails=3 fail_timeout=30s;
        server ollama-02.intern.firma.de:11434 max_fails=3 fail_timeout=30s;
        server ollama-03.intern.firma.de:11434 max_fails=3 fail_timeout=30s;
    }

    server {
        listen 443 ssl;
        server_name ki.intern.firma.de;

        ssl_certificate /etc/ssl/certs/ki-intern.pem;
        ssl_certificate_key /etc/ssl/private/ki-intern.key;

        location / {
            proxy_pass http://ollama_cluster;
            proxy_set_header Host $host;
            proxy_read_timeout 120s;
            proxy_buffering off;
        }
    }

  netzwerk:
    intern: "10 Gbit/s zwischen Nodes (empfohlen)"
    clients: "1 Gbit/s zum Load Balancer"
    vpn: "WireGuard für Standortvernetzung"

Schritt-für-Schritt: Cluster aufsetzen

Phase 1 – Ollama auf jedem Node installieren

Installieren Sie Ollama auf jedem Server identisch. Verwenden Sie dasselbe Modell-Set auf allen Nodes, damit der Load Balancer jede Anfrage an jeden Node routen kann. Unterschiedliche Modelle pro Node verkomplizieren das Routing unnötig.

Kritische Einstellung: Setzen Sie OLLAMA_HOST=0.0.0.0 in der Systemd-Konfiguration jedes Nodes. Standardmäßig bindet Ollama nur an localhost und akzeptiert keine Anfragen von anderen Servern.

Phase 2 – Nginx Load Balancer konfigurieren

Installieren Sie Nginx auf einem separaten Server oder auf einem der Ollama-Nodes. Die Upstream-Konfiguration definiert die verfügbaren Nodes. Der least_conn-Algorithmus schickt neue Anfragen an den Node mit den wenigsten aktiven Verbindungen, was bei unterschiedlich langen Anfragen optimal verteilt.

Die Parameter max_fails=3 und fail_timeout=30s definieren das Failover-Verhalten. Nach drei fehlgeschlagenen Anfragen innerhalb von 30 Sekunden markiert Nginx den Node als down und routet alle Anfragen an die verbleibenden Nodes. Nach 30 Sekunden probiert Nginx den Node erneut.

Phase 3 – Health Checks einrichten

Nginx Open Source bietet passive Health Checks über die max_fails-Konfiguration. Für aktive Health Checks installieren Sie das Modul nginx_upstream_check_module oder nutzen einen Cron-Job, der alle 10 Sekunden curl http://node:11434/api/tags auf jedem Node prüft.

Phase 4 – Modelle synchronisieren

Stellen Sie sicher, dass alle Nodes dieselben Modelle geladen haben. Ein einfaches Bash-Skript, das ollama pull auf allen Nodes ausführt, genügt. Für Modelfile-Anpassungen kopieren Sie die Konfiguration per rsync.

Praxisbeispiel: Handelsunternehmen mit 120 Mitarbeitern

Ein Großhändler aus Nordrhein-Westfalen betreibt seit Januar 2026 ein Ollama Cluster mit drei Servern. 85 Mitarbeiter nutzen die interne KI täglich für E-Mail-Entwürfe, Produktbeschreibungen und Angebotstexte.

Vorher: Ein einzelner Server mit RTX 4090. Bei Spitzenzeiten (Montag 9-11 Uhr) warteten Mitarbeiter 15-20 Sekunden auf Antworten. Die Nutzung sank auf 40%, weil Mitarbeiter genervt aufgaben.

Nachher: Drei-Node-Cluster. Antwortzeiten konstant unter 3 Sekunden. Die Nutzung stieg auf 78%. Der ROI des Clusters liegt bei €4.200/Monat Einsparung gegenüber ChatGPT-Team-Lizenzen für 85 Nutzer (85 × €52/Monat = €4.420/Monat).

Die Gesamtkosten des Clusters betragen €867/Monat für drei Hetzner GPU-Server plus €150/Monat für Administration durch einen Werkstudenten.

Erweiterte Konfiguration

Sticky Sessions für Chat-Anwendungen

Wenn Nutzer über OpenWebUI chatten, sollten aufeinanderfolgende Nachrichten einer Konversation an denselben Node gehen. Nginx bietet dafür ip_hash statt least_conn. Nachteil: Die Lastverteilung wird ungleichmäßiger.

Bessere Alternative: Setzen Sie OLLAMA_KEEP_ALIVE=10m und nutzen Sie least_conn. Der Context-Cache bleibt 10 Minuten im VRAM. Solange der Nutzer innerhalb von 10 Minuten antwortet, profitiert er vom Cache, unabhängig vom Node.

Automatische Skalierung

Für Unternehmen mit stark schwankender Last (z.B. Stoßzeiten im Kundenservice) lassen sich zusätzliche Nodes per Skript bei Hetzner provisionieren. Ein einfacher Schwellwert-basierter Ansatz: Wenn die durchschnittliche Latenz über 4 Sekunden steigt, startet ein Skript einen weiteren GPU-Server und fügt ihn dem Nginx-Upstream hinzu.

Monitoring mit Prometheus und Grafana

Exportieren Sie Ollama-Metriken über den /api/ps-Endpunkt in Prometheus. Wichtige Metriken: aktive Anfragen pro Node, Tokens pro Sekunde, VRAM-Auslastung und Antwortzeiten. Ein Grafana-Dashboard zeigt Cluster-Gesundheit auf einen Blick.

Migration von Einzelserver zum Cluster

Wenn Sie bereits einen Ollama-Server mit GPU betreiben, ist die Migration zum Cluster unkompliziert. Ihr bestehender Server wird Node 1. Sie fügen zwei weitere Server hinzu und stellen Nginx davor. Die API-URL für Ihre Anwendungen ändert sich von http://ollama-server:11434 zu https://ki.intern.firma.de. Ein umfassender Leitfaden hilft bei der strategischen Planung.

FAQ

Wie viele Ollama-Server brauche ich für 100 Mitarbeiter?

Rechnen Sie mit 20-30% gleichzeitiger Nutzung. Bei 100 Mitarbeitern bedeutet das 20-30 parallele Anfragen. Drei Server mit je einer RTX 4090 decken das ab. Kosten: ca. €870/Monat.

Können die Cluster-Nodes unterschiedliche GPUs haben?

Ja. Nginx verteilt nach Verbindungszahl, nicht nach GPU-Leistung. Allerdings verlangsamt ein schwächerer Node die durchschnittliche Antwortzeit. Verwenden Sie weight-Parameter in Nginx, um leistungsstärkeren Nodes mehr Anfragen zuzuweisen.

Was passiert, wenn ein Node ausfällt?

Nginx erkennt den Ausfall nach drei fehlgeschlagenen Anfragen und routet automatisch an die verbleibenden Nodes. Die Kapazität sinkt proportional, aber der Dienst bleibt verfügbar. Kein manueller Eingriff nötig.

Brauche ich 10-Gbit-Netzwerk zwischen den Nodes?

Nicht zwingend. 1 Gbit reicht für den normalen Betrieb. Die Anfragen und Antworten sind textbasiert und klein. 10 Gbit wird erst relevant, wenn Sie Modelle häufig zwischen Nodes synchronisieren.

Kann ich das Cluster über mehrere Standorte verteilen?

Technisch ja, über WireGuard-VPN. Praktisch sinnvoll nur bei unter 20 ms Latenz zwischen den Standorten. Höhere Latenzen verschlechtern die Antwortzeiten spürbar.