Ollama auf VPS installieren und absichern

Was Sie aufbauen

Ein einzelnes Open-Weight-Sprachmodell, das auf einem eigenen Server läuft. Die Antworten erfolgen über eine HTTP-API und optional über eine Chat-Seite in Ihrem Browser. Ollama ist die Komponente, die das Modell herunterlädt, in den Speicher lädt und Anfragen auf http://127.0.0.1:11434 bereitstellt. Die Installation erfolgt mit einem Befehl. Die komplexen Aspekte liegen an anderer Stelle: Die Auswahl eines Modells, das der RAM Ihres VPS tatsächlich bewältigen kann, und die Vermeidung der versehentlichen Veröffentlichung eines unauthentifizierten Inference-Servers im Internet.

Zwei wichtige Warnungen vorab. Ein VPS ohne GPU führt kleine Modelle langsam aus. Die API verfügt über keinerlei integrierte Authentifizierung. Beide Punkte werden unten detailliert behandelt, da sie die häufigsten Fehlerquellen darstellen.

Der Realitätscheck für die Dimensionierung in einfachen Zahlen

Der Speicherbedarf eines Modells entspricht etwa der Dateigröße, plus etwa einem Gigabyte für den Runtime-Overhead, plus zusätzliche Kapazität für das Context Window. Die Standardmodelle von Ollama sind 4-bit quantisiert (gekennzeichnet als Q4). Dies benötigt etwa ein halbes Gigabyte RAM pro Milliarde Parameter. Die Berechnung ist daher einfach und entscheidend.

Ein 3B-Modell wie llama3.2:3b hat eine Download-Größe von ca. 2 GB und benötigt etwa 4 GB freien RAM zur Ausführung. Ein 7B- oder 8B-Modell wie mistral:7b oder llama3.1:8b belegt ca. 5 GB auf der Festplatte und benötigt etwa 8 GB RAM; für einen reibungslosen Betrieb sind 16 GB ratsam. Ein 13B- oder 14B-Modell benötigt etwa 16 GB. Modelle im Bereich von 30B bis 70B erfordern einen Server mit viel RAM oder realistischerweise eine GPU. Auf einem CPU-basierten VPS passt das Modell entweder nicht in den Speicher oder die Antwort erfolgt so langsam, dass es unbrauchbar ist.

Zur Geschwindigkeit: Dieser Aspekt wird oft unterschätzt. Die CPU-Inferenz ist durch die Speicherbandbreite begrenzt, nicht durch die Taktrate. Ein Shared-vCPU-VPS verfügt über eine geringe Bandbreite. Rechnen Sie mit einstelligen bis niedrigen zweistelligen Tokens pro Sekunde: Ein 7-8B Q4-Modell erreicht etwa 4 bis 10 Tokens pro Sekunde, ein 3B-Modell 10 bis 25 Tokens. Eine GPU ist etwa eine Größenordnung schneller. Dies sind grobe Schätzwerte. Die sicherste Methode ist die Messung auf dem eigenen System, wie im folgenden Schritt zum Ausführen gezeigt. Vertrauen Sie Ihrem eval rate und nicht einer Zahl aus einem Artikel, auch nicht diesem hier.

Das praktische Fazit: Kleine quantisierte Modelle auf der CPU sind für Entwürfe, Zusammenfassungen und Klassifizierungen nützlich, sofern die Geschwindigkeit akzeptabel ist. Für größere oder schnellere Anforderungen ist eine GPU-Instanz einzuplanen.

Um ein spezifisches Modell mit einem spezifischen System zu vergleichen, schätzen Sie dessen Speicherbedarf hier:

Ollama installieren

Es gibt zwei saubere Methoden. Das offizielle Skript ist auf einem nackten VPS am einfachsten:

curl -fsSL https://ollama.com/install.sh | sh

Dadurch wird ein Systembenutzer namens ollama erstellt, die Binary wird unter /usr/local/bin/ollama installiert und ein systemd-Service namens ollama.service registriert. Dieser startet beim Booten und bindet 127.0.0.1:11434. Überprüfen Sie den Status mit:

systemctl status ollama
ollama --version

Wenn Sie bereits Docker nutzen, verwenden Sie stattdessen den Container:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

Beachten Sie das 127.0.0.1:-Präfix bei der Port-Zuweisung. Dies bindet den Port nur an localhost. Die Verwendung von -p 11434:11434 veröffentlicht den Port auf allen Schnittstellen, was der Fehler ist, vor dem der Abschnitt zur Sicherheit warnt. Wählen Sie eine Installationsmethode; führen Sie das Skript und den Container nicht gleichzeitig aus, da sich sonst zwei Prozesse um den Port streiten.

Laden und Ausführen Ihres ersten Modells

ollama pull llama3.2:3b
ollama run llama3.2:3b

pull lädt die Modellschichten auf die Festplatte (bei diesem Modell etwa 2 GB). run lädt diese in den Arbeitsspeicher und öffnet eine >>>-Eingabeaufforderung. Geben Sie eine Frage ein. Das erste Token kann mehrere Sekunden dauern, während die Gewichte von der Festplatte in den RAM geladen werden; danach wird die Antwort gestreamt. Geben Sie /bye ein, um den Chat zu verlassen; Ollama läuft im Hintergrund weiter.

Prüfen Sie, was geladen wurde und wie es genutzt wird:

ollama ps

Die Spalte PROCESSOR zeigt die tatsächliche Auslastung. 100% CPU bedeutet, dass keine GPU verwendet wird, was die langsame Geschwindigkeit verursacht. Messen Sie die tatsächliche Geschwindigkeit mit dem flag --verbose:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

Die am Ende ausgegebene Zeile eval rate zeigt die Tokens pro Sekunde auf dieser Hardware an. Dies ist der Wert, der für die Planung relevant ist.

Speicherort der Modelle und benötigter Festplattenspeicher

Modelle, die durch das Script installiert wurden und als Service laufen, liegen im Home-Verzeichnis des Benutzers ollama:

sudo du -sh /usr/share/ollama/.ollama/models

Wenn Sie die Modelle interaktiv mit Ihrem eigenen Benutzer ausführen, liegen sie in ~/.ollama/models. Innerhalb des Containers liegen sie im benannten Volume ollama. Dies ist wichtig, da quantisierte Gewichte schnell an Speicherplatz beanspruchen: Ein 3B-Modell benötigt ~2 GB, ein 7-8B-Modell ~5 GB und ein 14B-Modell ~9 GB. Wenn Sie vier Modelle zum Vergleich herunterladen, sind bereits 20 GB verbraucht. Planen Sie die Festplattengröße basierend auf der Anzahl der Modelle, die Sie dauerhaft behalten möchten. Löschen Sie alle anderen Modelle mit ollama rm <model>.

Als verwalteter Dienst ausführen

Das Installationsskript hat ollama.service bereits registriert, sodass der Dienst nach einem Neustart ohne weitere Maßnahmen automatisch startet. Die Einstellung, die geändert werden sollte, ist die Verweildauer eines Modells im Speicher sowie bei einigen Konfigurationen die Bind-Address. Beide Einstellungen werden in einer systemd drop-in Datei gespeichert, damit ein Ollama-Upgrade diese nicht überschreibt:

sudo systemctl edit ollama.service

Fügen Sie dies unter der [Service] Header-Zeile ein, die der Editor anzeigt:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE definiert, wie lange ein Modell nach der letzten Anfrage im Speicher bleibt (Standardwert: 5 Minuten). Erhöhen Sie diesen Wert auf Systemen, die durchgehend abgefragt werden, um das Neuladen der Weights zu vermeiden. Setzen Sie den Wert auf 0 bei Systemen mit begrenzten Ressourcen, um den RAM sofort nach Abschluss einer Anfrage freizugeben. systemctl edit lädt die Unit-Files neu; führen Sie einen Neustart aus, um die Änderungen zu übernehmen:

sudo systemctl restart ollama

Der wichtigste Sicherheitsaspekt

Standardmäßig bindet Ollama an 127.0.0.1:11434, sodass nur Prozesse auf dem VPS selbst darauf zugreifen können. Diese Standardeinstellung ist korrekt. Behalten Sie diese bei.

Die API verfügt über keine Authentifizierung. Keine. Es gibt keinen API-Key, keinen Login, kein Rate-Limiting und keine Allow-List. Jeder, der den Port 11434 erreichen kann, kann jedes von Ihnen geladene Modell ausführen, neue Modelle laden, diese löschen und Ihre CPU oder GPU dauerhaft unter Volllast setzen. Scanner wie Shodan indexieren tausende offene Ollama-Instanzen; eine exponierte Instanz wird innerhalb von Stunden gefunden und missbraucht.

Vermeiden Sie daher diesen einen Fehler: Setzen Sie OLLAMA_HOST=0.0.0.0 nicht und öffnen Sie den Port 11434 nicht in Ihrer Firewall. Dies veröffentlicht einen unauthentifizierten Inference-Server im gesamten Internet. Keine Konfiguration macht einen offenen Port 11434 auf 0.0.0.0 sicher, da Ollama keine entsprechenden Einstellungen bietet – eine Authentifizierung existiert schlichtweg nicht.

Es gibt drei sichere Wege, das Modell von außerhalb des Servers aus zu erreichen:

• Behalten Sie die lokale Bindung bei. Wenn der einzige Aufrufer ein anderes Programm auf demselben VPS ist – ein Cron-Skript, ein Bot oder ein MCP-Server, der Ihre Tools mit dem Modell verbindet – lassen Sie die Bindung bei 127.0.0.1 und lassen Sie dieses Programm http://127.0.0.1:11434 aufrufen. Es wird nichts exponiert und es ist nichts Weiteres erforderlich.
• Nutzen Sie einen privaten Tunnel. Verbinden Sie den VPS mit einem selbst gehosteten WireGuard VPN, setzen Sie OLLAMA_HOST auf die Tunnel-Adresse (zum Beispiel 10.8.0.1, nicht 0.0.0.0), und nur VPN-Peers können eine Verbindung herstellen. Das öffentliche Internet sieht auf Port 11434 weiterhin nichts.
• Schalten Sie einen authentifizierenden Reverse-Proxy vor. Beenden Sie TLS und fordern Sie ein Passwort oder einen Token bei nginx, Traefik oder Caddy an und leiten Sie die Anfragen dann an 127.0.0.1:11434 weiter. Ollama behält seine Localhost-Bindung bei; der Proxy ist das einzige Element, das auf dem öffentlichen Port lauscht. Dies entspricht dem Vorgehen, ein Let's Encrypt-Zertifikat für nginx vor einen lokalen Dienst zu schalten.

Die Reverse-Proxy-Option entspricht genau dem, was Ihnen die Chat-UI als Nächstes mit einem echten Login bietet.

Eine Chat-UI mit Open WebUI hinter TLS hinzufügen

Open WebUI ist eine selbst gehostete Chat-Schnittstelle. Führen Sie diese in Docker aus und verbinden Sie sie mit dem lokalen Ollama:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Die Flag --network=host ist bei einem Linux-VPS entscheidend. Sie versetzt den Container in den Network Namespace des Hosts. Dadurch ist 127.0.0.1 innerhalb des Containers der Loopback-Adapter des Hosts. Der Container erreicht Ollama unter 127.0.0.1:11434, ohne dass Ollama auf einer anderen Schnittstelle lauschen muss. Die Bridge-Network-Methode, die an anderer Stelle beschrieben wird — --add-host=host.docker.internal:host-gateway mit OLLAMA_BASE_URL=http://host.docker.internal:11434 — funktioniert hier nicht: Dieser Name löst auf das Docker-Bridge-Gateway auf. Ein Dienst, der auf 127.0.0.1 am Host gebunden ist, ist über die Bridge nicht erreichbar. Open WebUI bricht daher mit einer Fehlermeldung zur Verbindung zu Ollama ab.

Der Nachteil von Host-Networking ist, dass Open WebUI nun auf dem Port 8080 des Hosts auf jeder Schnittstelle lauscht. Jegliches -p-Mapping wird ignoriert; Docker gibt dazu eine Warnung aus. Schließen Sie daher 8080 sowohl in der Host- als auch in der Provider-Firewall. Der TLS-Reverse-Proxy soll der einzige öffentliche Zugang sein. Beim ersten Aufruf fordert Open WebUI zur Erstellung eines Admin-Kontos auf. Dieses Konto dient als Authentifizierungsebene; wählen Sie daher ein starkes Passwort.

Um den Chat von Ihrem Laptop über HTTPS zu öffnen, schalten Sie einen TLS-Reverse-Proxy vor 127.0.0.1:8080. Wenn Sie bereits mehrere Docker-Apps auf dem System ausrichten, ist Traefik mit automatischem TLS für viele Apps die sauberste Lösung: Ein Label-Block stellt das Zertifikat aus und leitet chat.example.com an Open WebUI weiter. Die Regel aus dem Sicherheitsabschnitt bleibt bestehen: Der Proxy verwaltet den öffentlichen Port und den Login, während Ollama auf localhost bleibt und der eigene 8080 von Open WebUI durch die Firewall geschützt bleibt.

Verwenden Sie den OpenAI-kompatiblen Endpoint in Ihrem Code

Ollama unterstützt eine Teilmenge der OpenAI Chat-API unter /v1. Daher funktionieren die meisten OpenAI-Client-Bibliotheken, wenn Sie zwei Parameter anpassen: die Base URL und einen Platzhalter-Key.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

Die api_key wird von der Client-Bibliothek benötigt, aber von Ollama ignoriert; jeder beliebige String ist gültig. model muss ein Modellname sein, den Sie bereits per pull geladen haben; ein unbekannter Name führt zu model "x" not found, try pulling it first. Ein einfacher curl-Aufruf funktioniert nach demselben Prinzip:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

Dies ist auch die Methode, um das Modell in Agent- und Editor-Tools einzubinden. Wenn Sie direkt auf dem Server entwickeln, kann ein lokales Modell Skripte und Plugins unterstützen, zusätzlich zu Claude Code, das in tmux auf dem VPS läuft. So werden einfache Entwürfe kostengünstig und privat lokal erstellt, während komplexe Logik-Aufgaben an ein gehostetes Modell ausgelagert werden.

Fehlerzustände und die exakten Fehlermeldungen

Der Prozess wird während der Generierung mit "Killed" abgebrochen. Sie starten ein großes Modell und das Terminal gibt Killed aus, oder das Server-Log zeigt llama runner process has terminated: signal: killed. Der Linux OOM-Killer hat den Prozess gestoppt, weil das Modell mehr RAM benötigt als das System besitzt. Bestätigen Sie die Ursache mit sudo dmesg | grep -i oom; dort sehen Sie eine Zeile wie Out of memory: Killed process ... (ollama). Die Lösung ist ein kleineres oder stärker quantisiertes Modell — llama3.2:3b anstelle von 13B — oder das Hinzufügen von Swap. Mit Swap überlebt eine Last, die den physischen RAM knapp überschreitet, durch langsames Arbeiten, anstatt abzustürzen. Swap verwandelt einen sofortigen Absturz in eine langsame Antwort; er macht ein 70B-Modell auf 4 GB RAM jedoch nicht praktikabel.

"Error: model requires more system memory". Ollama verweigert den Start des Modells und gibt Error: model requires more system memory (X GiB) than is available (Y GiB) aus. Dies ist die höfliche Version des oben genannten Absturzes: Ollama hat die Berechnung durchgeführt und den Vorgang gestoppt, anstatt den OOM-Killer agieren zu lassen. Das Programm gibt sogar beide Zahlen an. Wählen Sie ein Modell, dessen Anforderungen unter Ihrem freien RAM liegen (prüfen Sie dies mit free -h), verringern Sie die Context Length oder wechseln Sie zu einem größeren VPS. Kein Flag lässt das Modell in den Speicher passen — der Speicherbedarf ist real.

Das erste Token benötigt sehr lange, danach läuft es normal. Ein neu geladenes Modell gibt fünf bis dreißig Sekunden lang nichts aus und streamt dann normal. Diese Pause entsteht, weil die Weights zum ersten Mal von der Festplatte in den RAM geladen werden; langsamer Speicher verschlechtert dies. Sobald das Modell geladen ist, bleibt es für die Dauer von OLLAMA_KEEP_ALIVE im Speicher, sodass die zweite Anfrage sofort beantwortet wird. Erhöhen Sie diesen Wert, falls Sie die Pausen stören, und nutzen Sie ollama ps, um zu sehen, ob ein Modell aktuell geladen ist.

Alles ist einfach langsam. Zehn Tokens pro Sekunde oder weniger, ohne Fehlermeldung. Das ist CPU-Inferenz, die genau das tut, was CPU-Inferenz tut. ollama ps zeigt 100% CPU an, was bedeutet, dass keine GPU vorhanden ist. Dies ist kein Fehler und keine Einstellung kann dies beheben, da die Begrenzung die Speicherbandbreite ist und keine Fehlkonfiguration. Verwenden Sie ein kleineres Modell, akzeptieren Sie die Geschwindigkeit oder wechseln Sie zu einer GPU-Instanz — und messen Sie Ihre tatsächliche Rate mit --verbose, bevor Sie annehmen, dass etwas defekt ist.

Connection refused von einem anderen Rechner. Von Ihrem Laptop aus erhalten Sie curl: (7) Failed to connect to <ip> port 11434: Connection refused. Dies entspricht dem Design: Ollama bindet sich nur an localhost. "Beheben" Sie dies nicht durch das Binden an 0.0.0.0, da dies genau der oben genannte Sicherheitsfehler ist. Greifen Sie stattdessen über das VPN oder über einen authentifizierenden Proxy auf das Modell zu.

Sie haben 11434 für das Internet freigegeben. Wenn Sie OLLAMA_HOST=0.0.0.0 gesetzt und die Firewall geöffnet haben und nun Modell-Downloads sehen, die Sie nie gestartet haben, oder die CPU durch unbekannte Clients bei 100% Last liegt, wurden Sie entdeckt und ausgenutzt. Dies ist der Hauptfehler und kein Sonderfall. Binden Sie den Dienst an 127.0.0.1 oder die VPN-Adresse um, schließen Sie 11434 in der Firewall und schalten Sie eine Authentifizierung davor. Gehen Sie davon aus, dass alles, was unter dieser Adresse erreichbar war, während sie offen war, von Fremden abgefragt wurde.

Backups und Upgrades

Es gibt nur wenige Zustände, die verloren gehen können. Die Modelle können erneut heruntergeladen werden. Daher sind nur das Data Volume von Open WebUI — Accounts, Chat-Verlauf, Einstellungen — und alle selbst erstellten systemd drop-in Dateien sicherungswürdig. Sichern Sie das Volume mit einem temporären Container:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

Aktualisieren Sie Ollama durch erneutes Ausführen des Install-Scripts; aktualisieren Sie Open WebUI mit docker pull ghcr.io/open-webui/open-webui:main und erstellen Sie anschließend den Container neu. Fixieren Sie keine Versionen langfristig: Sowohl die Modellqualität als auch die Laufzeit entwickeln sich schnell. Lesen Sie daher die Release Notes und führen Sie neue Benchmarks auf Ihrem eigenen System durch, anstatt den Werten aus dem letzten Quartal zu vertrauen.

FAQ

Kann ich ein LLM wirklich auf einem reinen CPU-VPS ausführen?

Ja, jedoch mit Einschränkungen. Kleine quantisierte Modelle im Bereich von 3B bis 8B laufen auf der CPU und sind für Entwürfe, Zusammenfassungen und Klassifizierungen nützlich. Die Geschwindigkeit ist jedoch gering; auf einer gemeinsam genutzten vCPU liegt sie bei einstelligen bis niedrigen zweistelligen Tokens pro Sekunde. Alles ab 13B ist extrem langsam oder passt nicht in den RAM. Für hohe Geschwindigkeit oder größere Modelle ist eine GPU-Instanz erforderlich.

Wie viel RAM benötigt jedes Modell?

Eine grobe Faustregel für die standardmäßigen 4-bit quantisierten Modelle: etwa 0,5 GB RAM pro Milliarde Parameter für die Gewichte, plus ca. 1 GB Overhead und etwas mehr für den Kontext. Ein 3B-Modell benötigt also etwa 4 GB freien Speicher, ein 7-8B-Modell etwa 8 GB und ein 14B-Modell etwa 16 GB. Prüfen Sie Ihren verfügbaren Speicher mit free -h und lassen Sie Platz für das Betriebssystem und andere Prozesse auf dem System.

Ist die Ollama API authentifiziert?

Nein. Ollama verfügt über keine integrierte Authentifizierung, keinen API-Key und kein Rate-Limiting. Jeder, der den Port 11434 erreichen kann, hat die volle Kontrolle. Deshalb bindet Ollama standardmäßig an 127.0.0.1 und Sie dürfen den Port 11434 niemals über 0.0.0.0 für das Internet öffnen. Greifen Sie lokal, über ein privates VPN oder über einen Reverse Proxy mit Login darauf zu.

Wie füge ich eine Web-Chat-Oberfläche hinzu?

Führen Sie Open WebUI in Docker mit --network=host aus, damit es den Loopback des Hosts teilt und das native Ollama unter http://127.0.0.1:11434 erreicht. Schalten Sie anschließend einen TLS-Reverse-Proxy vor den Port 8080, um den Zugriff von Ihrem Laptop aus zu ermöglichen. Halten Sie 8080 in der Firewall geschlossen, sodass der Proxy der einzige öffentliche Zugang ist. Das Admin-Konto von Open WebUI stellt die Anmeldung bereit; das Passwort wird beim ersten Start festgelegt.

Wie rufe ich es aus meiner eigenen Anwendung auf?

Verwenden Sie den OpenAI-kompatiblen Endpunkt unter http://127.0.0.1:11434/v1. Zeigen Sie jedes OpenAI SDK auf diese Base-URL, übergeben Sie einen beliebigen String als API-Key (da dieser ignoriert wird) und setzen Sie model auf einen bereits heruntergeladenen Modellnamen. Bestehender OpenAI-Code läuft in der Regel unverändert, außer dass die Base-URL und der Key angepasst werden müssen.