Ollama im eigenen lokalen Netzwerk teilen (Familie, Team)

#Warum ein Ollama-Server im lokalen Netzwerk?

Standardmäßig lauscht Ollama nur auf 127.0.0.1:11434 – daher kann nur der Rechner darauf zugreifen, auf dem es läuft. Das ist sicher, lässt aber das Potenzial einer GPU ungenutzt. Eine RTX 4090 oder ein Mac Studio M4 Max bedient mit 7B–14B-Modellen in Q4 problemlos 3 bis 5 Benutzer gleichzeitig.

Die VRAM teilen

Ein einziges in den Speicher geladenes Modell für den ganzen Haushalt oder das gesamte Team — keine redundanten Kopien.

Modelle zentralisieren

150 GB an GGUF-Dateien, einmal auf dem Server gespeichert, niemals auf den Laptops.

Versionen standardisieren

Alle nutzen dasselbe Qwen 3.5 9B Q4 — damit sind Qualitätsunterschiede zwischen den Arbeitsplätzen passé.

Akkuladung sparen

Die Laptops führen keine Berechnungen durch – sie senden eine HTTP-POST-Anfrage an den stationären Server.

#Voraussetzungen

Ollama installiert

Auf dem Rechner, der den Server hosten wird (Linux, macOS oder Windows). Idealerweise auf dem Rechner mit der besten GPU.

Feste IP-Adresse oder lokaler DNS

Der Server muss dieselbe IP-Adresse behalten. DHCP-Reservierung am Router oder statische IP-Adresse. Alternativ hostname.local über mDNS.

Vertrauenswürdiges Netzwerk

Heim-WLAN mit WPA2/3 oder ein VLAN für das Team. Kein gemeinsam genutztes öffentliches WLAN.

Administratorrechte

Um die Firewall und den Systemdienst zu ändern (systemd, launchd, services.msc).

#1. Ollama mit OLLAMA_HOST=0.0.0.0 im Netzwerk zugänglich machen

Ollama liest zwei zentrale Umgebungsvariablen aus: OLLAMA_HOST legt die Netzwerkschnittstelle fest, auf der Ollama lauscht, OLLAMA_ORIGINS legt die zulässigen CORS-Origins fest. Um in den Servermodus zu wechseln, setzt man OLLAMA_HOST von 127.0.0.1 auf 0.0.0.0 (alle Netzwerkschnittstellen).

#Linux (systemd)

Auf modernen Distributionen läuft Ollama über systemd. Anstatt die Basisdatei zu bearbeiten, wird der Service-Override bearbeitet — dieser bleibt bei Paketupdates erhalten.

sudo systemctl edit ollama.service

Fügen Sie im Editor, der sich öffnet, diesen Block zwischen den auskommentierten Zeilen ein:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=*"

sudo systemctl daemon-reload
sudo systemctl restart ollama.service
sudo systemctl status ollama.service

Prüfen Sie, ob ss -tlnp Ollama tatsächlich auf 0.0.0.0:11434 und nicht mehr nur auf 127.0.0.1:11434 anzeigt.

#Windows

Unter Windows liest Ollama beim Start die Benutzerumgebungsvariablen. Die saubere Vorgehensweise: OLLAMA_HOST zu den Benutzerumgebungsvariablen hinzufügen und anschließend den Dienst über die Taskleiste neu starten (Rechtsklick auf das Symbol → Quit Ollama, dann erneut starten).

[Environment]::SetEnvironmentVariable('OLLAMA_HOST', '0.0.0.0:11434', 'User')
[Environment]::SetEnvironmentVariable('OLLAMA_ORIGINS', '*', 'User')

#2. Firewall für das LAN öffnen

Sobald Ollama auf 0.0.0.0 lauscht, muss die Firewall Zugriffe auf Port 11434 erlauben – allerdings nur aus dem lokalen Netzwerk. Port 11434 niemals für Zugriffe aus dem Internet öffnen: Ollama hat keine native Authentifizierung.

#UFW (Ubuntu, Debian)

# Autoriser le port 11434 depuis le LAN seulement
sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp
sudo ufw reload
sudo ufw status

Passen Sie 192.168.1.0/24 an Ihr tatsächliches Subnetz an (mit ip a überprüfen). Wenn Sie ufw allow 11434 ohne Einschränkung der Quelle belassen und der Rechner über eine Portweiterleitung von außen erreichbar ist, stellen Sie Ollama der ganzen Welt zur Verfügung – für anonymen Zugriff.

#iptables (ohne UFW)

sudo iptables -A INPUT -p tcp -s 192.168.1.0/24 --dport 11434 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 11434 -j DROP
# Sauvegarder selon la distrib (iptables-persistent, netfilter-persistent)
sudo netfilter-persistent save

#Windows Defender Firewall

New-NetFirewallRule `
  -DisplayName 'Ollama LAN' `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 11434 `
  -RemoteAddress 192.168.1.0/24 `
  -Action Allow

#3. Besonderheiten von macOS

Unter macOS läuft Ollama als GUI-Anwendung (Symbol in der Menüleiste), die den Daemon im Hintergrund startet. In der Shell definierte Umgebungsvariablen sind für die GUI-Anwendung nicht sichtbar – dafür muss man launchctl verwenden oder die Anwendung ändern.

1. 01
   Ollama vollständig beenden

   Klicken Sie auf das Llama-Icon in der Menüleiste → Quit Ollama. Überprüfen Sie mit ps aux | grep ollama, dass nichts mehr läuft.
2. 02
   Die Variable auf launchctl-Ebene definieren

   In einem Terminal: launchctl setenv OLLAMA_HOST "0.0.0.0:11434" und anschließend launchctl setenv OLLAMA_ORIGINS "*". Alle anschließend gestarteten GUI-Anwendungen erben diese Variablen.
3. 03
   Ollama.app erneut starten

   Öffnen Sie Applications → Ollama.app. Die App liest die Umgebung erneut ein und lauscht auf 0.0.0.0.
4. 04
   Die Einstellungen über einen Neustart hinweg beibehalten

   Die mit launchctl setenv gesetzten Einstellungen bleiben nach einem Neustart nicht erhalten. Um sie dauerhaft zu speichern, erstellen Sie einen LaunchAgent unter ~/Library/LaunchAgents/com.ollama.env.plist (siehe Apple-Dokumentation) oder führen Sie die setenv-Befehle über ein Startskript erneut aus.

#4. Clients verbinden

Von einem anderen Rechner im LAN aus ersetzt die IP-Adresse des Servers localhost in allen Befehlen und Konfigurationen.

# Remplacer 192.168.1.42 par l'IP réelle du serveur
curl http://192.168.1.42:11434/api/tags

# Génération directe
curl http://192.168.1.42:11434/api/generate -d '{
  "model": "qwen3.5:9b",
  "prompt": "Bonjour",
  "stream": false
}'

Für die CLI von Ollama selbst wird OLLAMA_HOST auf der Clientseite exportiert — der Befehl ollama run pointe wird dann an den entfernten Server gesendet.

export OLLAMA_HOST=http://192.168.1.42:11434
ollama list           # liste les modèles du serveur
ollama run qwen3.5:9b # tourne en remote, affichage local

Open WebUI

Fügen Sie unter Settings → Connections die URL http://192.168.1.42:11434 als Ollama API URL hinzu. Die Benutzeroberfläche läuft auf jedem beliebigen Rechner im LAN.

Continue.dev (VS Code)

In config.json verweist das Feld apiBase des Providers ollama auf http://192.168.1.42:11434.

LangChain Python

Ollama(base_url="http://192.168.1.42:11434", model="qwen3.5:9b") — genauso wie bei der lokalen Nutzung über localhost.

#5. Nginx-Reverse-Proxy + HTTP-Basic-Authentifizierung

Ollama ohne zusätzliche Absicherung im LAN bereitzustellen, ist für die Familie in Ordnung. Für ein Team sollten Sie jedoch mindestens eine HTTP-Basic-Authentifizierung und etwas Logging hinzufügen. Nginx erledigt das in 20 Zeilen.

sudo apt install nginx apache2-utils
# Créer le fichier htpasswd avec un premier utilisateur
sudo htpasswd -c /etc/nginx/.htpasswd alice
# Ajouter d'autres utilisateurs (sans -c pour ne pas écraser)
sudo htpasswd /etc/nginx/.htpasswd bob

server {
    listen 8080;
    server_name ollama.local;

    # Limite par IP source : LAN seulement
    allow 192.168.1.0/24;
    deny all;

    location / {
        auth_basic "Ollama LAN";
        auth_basic_user_file /etc/nginx/.htpasswd;

        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # Streaming SSE : désactiver le buffering Nginx
        proxy_buffering off;
        proxy_cache off;
        proxy_read_timeout 600s;
        chunked_transfer_encoding on;
    }
}

sudo ln -s /etc/nginx/sites-available/ollama /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Wichtig: Mit dieser Konfiguration muss Ollama wieder auf 127.0.0.1:11434 lauschen (nicht auf 0.0.0.0). Nginx lauscht öffentlich auf Port 8080, prüft die IP-Adresse und das Passwort und leitet anschließend an das lokal laufende Ollama weiter. Die Clients greifen nun auf http://alice:motdepasse@192.168.1.42:8080 zu.

#Bewährte Sicherheitspraktiken

Den Zugriff in der Firewall anhand der Quell-IP einschränken

Doppelt hält besser: Behalten Sie auch mit Nginx die UFW/iptables-Regel bei. Ein Nginx-Bug oder eine falsche Bind-Adresse kann Port 11434 direkt zugänglich machen.

Zugriff auf /api/create von außen deaktivieren

Über diesen Endpunkt lässt sich ein beliebiges Modelfile hochladen. Fügen Sie bei Nginx location /api/create { return 403; } hinzu.

Anfragen protokollieren

Das access_log von Nginx zeigt, wer was aufruft. Nützlich, um eine offengelegte Server-IP-Adresse oder einen falsch konfigurierten Client zu erkennen, der massenhaft Anfragen sendet.

Benutzerbezogene Quoten

Ollama unterstützt dies nicht nativ. Um Bob einzuschränken, der um 3 Uhr morgens einen großen Generierungsauftrag startet, kommen LiteLLM oder Open WebUI als Middleware-Schicht infrage.

~/.ollama sichern

Der zentrale Server wird zu einem Single Point of Failure. Der Modellordner kann 100 GB oder mehr belegen – mindestens ein rsync-Skript zum Sichern auf ein externes Laufwerk vorsehen.

#Fehlerbehebung

„Connection refused“ beim Zugriff von einem Client

Ollama lauscht weiterhin auf 127.0.0.1. Prüfen Sie auf dem Server die Ausgabe von ss -tlnp | grep 11434 — wenn dort 127.0.0.1:11434 steht, wird die Variable OLLAMA_HOST vom Dienst nicht erkannt. Prüfen Sie erneut die Ausgabe von systemctl show ollama | grep Environment.

Connection timed out

Die Firewall blockiert die Verbindung. Testen Sie nc -zv 192.168.1.42 11434 vom Client aus: Bei timeout liegt es an der Firewall. Bei refused nimmt Ollama keine Verbindungen an.

CORS-Fehler in Open WebUI

OLLAMA_ORIGINS=* fehlt oder wird nicht angewendet. Zum Debuggen: curl -H "Origin: http://autre-machine" -I http://192.168.1.42:11434 — die Antwort muss Access-Control-Allow-Origin enthalten.

macOS: Variable wird nach Neustart ignoriert

launchctl setenv bleibt nicht dauerhaft wirksam. Dafür ist ein LaunchAgent erforderlich. Pragmatische Alternative: ein Skript ~/start-ollama.sh, das launchctl setenv und open Ollama.app ausführt und nach jedem Neustart manuell zu starten ist.

Plötzliche Verlangsamung bei mehreren Benutzern

Ollama verarbeitet die Anfragen in der Warteschlange pro Modell. Bei 3 gleichzeitigen Benutzern auf einem 14B wartet der 3. Benutzer. OLLAMA_NUM_PARALLEL=2 (Umgebungsvariable) ermöglicht 2 parallele Anfragen mit einem höheren VRAM-Aufwand.

Das Modell wird zwischen den Anfragen aus dem Speicher entladen

Standardmäßig entlädt Ollama ein Modell 5 Minuten nach der letzten Anfrage. OLLAMA_KEEP_ALIVE=24h erzwingt, dass es im VRAM bleibt – entscheidend für einen gemeinsam genutzten Server.

#Weiterführende Informationen

Der gemeinsam genutzte Ollama-Server bildet die Grundlage einer Mehrbenutzerumgebung. Darauf aufbauend bieten sich drei weitere Schritte an:

Eine gemeinsam genutzte Chat-Oberfläche hinzufügen

Der Leitfaden „Open WebUI mit Ollama: der umfassende Leitfaden“ beschreibt ausführlich, wie Sie ein ChatGPT-ähnliches Frontend für mehrere Benutzer einrichten, das an diesen Server angebunden wird.

Im Produktionsumfeld mit Docker bereitstellen

Die Anleitung „Ein LLM mit Docker Compose produktiv bereitstellen“ zeigt dieselbe Architektur in containerisierter Form mit Traefik und HTTPS.

Zu einem Intranet-Chatbot erweitern

Der Leitfaden „Einen KI-Chatbot für das eigene Team im Intranet bereitstellen“ ergänzt SSO-Authentifizierung, Monitoring und die Sicherung der Gespräche.