Ollama sicher auf einem VPS selbst hosten

Was Sie erstellen

Ein einzelnes Open-Weight-Sprachmodell läuft auf einem Server, den Sie selbst verwalten. Sie greifen über eine HTTP-API darauf zu. Optional können Sie zusätzlich eine Chat-Seite im Browser bereitstellen. Ollama lädt das Modell herunter, lädt es in den Arbeitsspeicher und nimmt Anfragen auf http://127.0.0.1:11434 entgegen. Die Installation erfolgt mit einem Befehl. Die eigentlichen Herausforderungen liegen an anderer Stelle: Sie müssen ein Modell auswählen, das Ihr VPS tatsächlich im Arbeitsspeicher halten kann. Außerdem dürfen Sie nicht versehentlich einen nicht authentifizierten Inferenzserver im gesamten Internet veröffentlichen.

Zwei wichtige Warnungen vorab. Ein VPS ohne GPU führt kleine Modelle nur langsam aus. Die API verfügt überhaupt nicht über eine integrierte Authentifizierung. Beide Punkte werden weiter unten ausführlich behandelt. Genau hier entstehen die größten Probleme.

Die Größenordnung in klaren Zahlen

Der Speicherbedarf eines Modells entspricht grob seiner Dateigröße, zuzüglich etwa eines Gigabytes Laufzeit-Overhead und eines weiteren Anteils für das Kontextfenster. Die Standard-Tags der meisten verbreiteten Ollama-Modelle, darunter llama3.2:3b, llama3.1:8b und mistral:7b, sind mit 4 Bit quantisiert (als Q4_K_M bezeichnet). Dafür wird etwa ein halbes Gigabyte RAM pro Milliarde Parameter benötigt. Nicht jeder Standard ist Q4: Kleine Modelle wie smollm2:135m werden mit 16 Bit ausgeliefert. Prüfen Sie daher die Quantisierungszeile auf der Library-Seite des Modells, bevor Sie die Werte berechnen. Die Rechnung ist einfach und entscheidet über alles. Den letzten Anteil legen Sie selbst fest: Wenn Sie num_ctx über den kleinen Ollama-Standard erhöhen, stehen längere Prompts zur Verfügung. Gleichzeitig wächst der KV-Cache im RAM. Legen Sie daher eine Kontextlänge fest, bevor Sie beurteilen, ob ein Modell passt.

Ein 3B-Modell wie llama3.2:3b ist ein Download von etwa 2 GB und benötigt zum Ausführen rund 4 GB freien RAM. Ein 7B- oder 8B-Modell wie mistral:7b oder llama3.1:8b belegt etwa 5 GB auf dem Datenträger und benötigt ungefähr 8 GB RAM, mit 16 GB läuft es komfortabler. Ein 13B- oder 14B-Modell benötigt ungefähr 16 GB. Alles im Bereich von 30B bis 70B erfordert ein System mit viel RAM oder realistisch betrachtet eine GPU. Auf einer CPU-VPS passt es entweder nicht in den Speicher oder antwortet so langsam, dass es unbrauchbar ist.

Nun zur Geschwindigkeit, denn diesen Punkt unterschätzen viele. Die CPU-Inferenz wird durch die Speicherbandbreite begrenzt, nicht durch die Taktfrequenz. Eine VPS mit gemeinsam genutzter vCPU bietet nur eine moderate Bandbreite. Rechnen Sie mit einstelligen bis niedrigen zweistelligen Tokenraten: Ein 7-8B-Q4-Modell erreicht möglicherweise 4 bis 10 Token pro Sekunde, ein 3B-Modell 10 bis 25. Eine GPU ist ungefähr eine Größenordnung schneller. Diese Werte sind bewusst grob gehalten. Messen Sie am besten Ihr eigenes System. Der folgende Ausführungsschritt zeigt, wie das geht. Vertrauen Sie auf eval rate und nicht auf eine Zahl in irgendeinem Artikel, auch nicht in diesem.

Die praktische Schlussfolgerung: Kleine quantisierte Modelle auf einer CPU sind für Entwürfe, Zusammenfassungen und Klassifizierung tatsächlich nützlich, wenn Sie die Geschwindigkeit akzeptieren können. Für größere oder schnellere Modelle sollten Sie ein GPU-Instanz einplanen. Wenn Sie diese Rechnung für ein bestimmtes Modell vollständig nachvollziehen möchten, behandelt Nemotron 3.5 Lightning auf einer VPS auszuführen, welchen Tag Sie laden sollten, wie viel RAM tatsächlich benötigt wird und ob die reine CPU-Ausführung ausreichend schnell ist.

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

Ollama installieren

Es gibt zwei saubere Möglichkeiten. Auf einem unkonfigurierten VPS ist das offizielle Script am einfachsten:

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

Dabei wird ein Systembenutzer namens ollama angelegt, die Binärdatei nach /usr/local/bin/ollama installiert und ein systemd-Dienst namens ollama.service eingerichtet. Dieser startet beim Booten und bindet an 127.0.0.1:11434. Prüfen Sie, ob der Dienst läuft:

systemctl status ollama
ollama --version

Wenn Sie bereits Docker verwenden, nutzen 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 Präfix 127.0.0.1: bei der Portzuordnung. Dadurch wird der Port nur an localhost gebunden. Wenn Sie stattdessen -p 11434:11434 schreiben, wird er auf jeder Schnittstelle veröffentlicht. Genau davor warnt der Sicherheitsabschnitt. Wählen Sie eine Installationsmethode. Führen Sie nicht gleichzeitig das Script aus und starten Sie den Container nicht parallel. Andernfalls konkurrieren zwei Prozesse um den Port.

Erstes Modell herunterladen und ausführen

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

pull lädt die Modell-Layer auf die Festplatte herunter (bei diesem Modell etwa 2 GB). run lädt sie in den Arbeitsspeicher und zeigt eine >>>-Eingabeaufforderung an. Geben Sie eine Frage ein. Das erste Token kann mehrere Sekunden dauern, während die Gewichte von der Festplatte in den Arbeitsspeicher geladen werden. Danach wird die Antwort fortlaufend ausgegeben. Geben Sie /bye ein, um den Chat zu beenden. Ollama läuft im Hintergrund weiter.

Prüfen Sie, was geladen ist und wie es verwendet wird:

ollama ps

Die Spalte PROCESSOR zeigt den tatsächlichen Zustand. 100% CPU bedeutet, dass keine GPU verwendet wird. Das ist die Ursache für die geringe Geschwindigkeit. Messen Sie die tatsächliche Geschwindigkeit mit dem Verbose-Flag:

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 diesem Wert sollten Sie Ihre Planung ausrichten.

Wo Modelle gespeichert werden und wie viel Speicherplatz Sie einplanen sollten

Modelle, die das Skript installiert und der Dienst ausführt, werden im Home-Verzeichnis des Benutzers ollama gespeichert:

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

Wenn Sie sie interaktiv als eigener Benutzer ausführen, liegen sie in ~/.ollama/models. Im Container werden sie im benannten Volume ollama gespeichert. Das ist wichtig, weil sich quantisierte Gewichte schnell summieren: Ein 3B-Modell benötigt etwa 2 GB, ein 7-8B-Modell etwa 5 GB und ein 14B-Modell etwa 9 GB. Wenn Sie vier Modelle zum Vergleichen herunterladen, sind unbemerkt 20 GB belegt. Planen Sie den Speicherplatz für die Modelle ein, die Sie behalten möchten, und löschen Sie die übrigen mit ollama rm <model>. Wenn auf demselben VPS bereits etwas mit hohem eigenem Speicherbedarf läuft, beispielsweise PhotoPrism oder Immich mit einer Fotobibliothek, ziehen Sie diesen Speicherbedarf zunächst vom freien Speicherplatz ab. Behandeln Sie den verbleibenden Speicherplatz als Ihr tatsächliches Modellbudget.

Führen Sie den Dienst unter Ihrer Kontrolle aus

Das Installationsskript hat ollama.service bereits registriert. Der Dienst wird daher ohne weitere Maßnahmen beim Booten neu gestartet. Eine sinnvolle Anpassung betrifft die Dauer, für die ein Modell im Speicher bleibt. Je nach Setup kann außerdem die Bind-Adresse geändert werden. Beide Einstellungen gehören in einen systemd-Drop-in, damit ein Ollama-Upgrade sie nicht überschreibt:

sudo systemctl edit ollama.service

Fügen Sie dies unter dem vom Editor angezeigten Header [Service] ein:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE legt fest, wie lange ein Modell nach der letzten Anfrage im Speicher bleibt. Der Standardwert beträgt 5 Minuten. Erhöhen Sie den Wert auf einem System, das Sie den ganzen Tag abfragen, damit die Gewichte nicht bei jeder Anfrage erneut geladen werden. Setzen Sie den Wert auf 0, wenn der Arbeitsspeicher knapp ist und nach Abschluss einer Anfrage sofort freigegeben werden soll. Wenn ein Modell dauerhaft statt für ein festgelegtes Zeitfenster im Speicher bleiben soll, beschreibt ein dauerhaft geladenes Ollama-Modell das Anfragefeld keep_alive und wie die Gewichte nach einem Reboot erneut vorgewärmt werden, statt erst bei der ersten langsamen Anfrage geladen zu werden. systemctl edit lädt die Unit-Dateien neu. Starten Sie den Dienst daher neu, damit die Änderung wirksam wird:

sudo systemctl restart ollama

Der wichtigste Sicherheitsaspekt

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

Die API hat keine Authentifizierung. Keine. Es gibt keinen API-Schlüssel, keine Anmeldung und keine Ratenbegrenzung. Die einzige Allowlist, die sie besitzt, OLLAMA_ORIGINS, steuert nur, welche Browser-Origin-Quellen sie aufrufen dürfen (CORS). Sie verhindert nicht, dass curl oder ein Skript auf einem anderen Rechner darauf zugreift. Jeder, der Port 11434 erreichen kann, kann jedes von Ihnen geladene Modell ausführen, neue Modelle laden, Modelle löschen und Ihre CPU oder GPU dauerhaft mit voller Auslastung betreiben. Scanner wie Shodan erfassen offene Ollama-Instanzen zu Tausenden. Eine exponierte Instanz wird innerhalb weniger Stunden gefunden und missbraucht.

Begehen Sie daher niemals diesen einen Fehler: Setzen Sie nicht OLLAMA_HOST=0.0.0.0 und öffnen Sie Port 11434 nicht in Ihrer Firewall. Dadurch veröffentlichen Sie einen nicht authentifizierten Inferenzserver im gesamten Internet. Keine Konfiguration macht eine direkte Veröffentlichung von Port 11434 auf 0.0.0.0 sicher, weil keine der dokumentierten Ollama-Einstellungen die lokale API um Authentifizierung erweitert. Eine Origin-Allowlist ist keine Anmeldung. Das ist eine Regel für diesen speziellen Dienst und kein generelles Verbot, jemals einen Port zu öffnen: ein selbst gehostetes RustDesk-Relay für Remote-Desktops muss öffentlichen Datenverkehr akzeptieren, damit es überhaupt funktioniert. Es verwendet dafür eine eigene schlüsselbasierte Authentifizierung und eine kurze, dokumentierte Liste von Ports. Genau das bietet Ollama nicht.

Es gibt drei sichere Möglichkeiten, von einem anderen System als dem VPS auf das Modell zuzugreifen:

• Lassen Sie den Dienst lokal. Wenn nur ein anderes Programm auf demselben VPS, ein Cron-Skript, ein Bot oder ein MCP-Server, der Ihre Tools mit dem Modell verbindet, darauf zugreift, lassen Sie die Bind-Adresse auf 127.0.0.1 und lassen Sie dieses Programm http://127.0.0.1:11434 aufrufen. Nichts wird veröffentlicht. Weitere Maßnahmen sind nicht erforderlich.
• Greifen Sie über einen privaten Tunnel darauf zu. Binden Sie den VPS in ein selbst gehostetes WireGuard-VPN ein, setzen Sie OLLAMA_HOST auf die Tunneladresse, zum Beispiel 10.8.0.1 und nicht 0.0.0.0, und erlauben Sie nur VPN-Peers den Zugriff. Das öffentliche Internet sieht weiterhin nichts auf Port 11434.
• Schalten Sie einen authentifizierenden Reverse Proxy davor. Terminieren Sie TLS und verlangen Sie in nginx, Traefik oder Caddy ein Passwort oder Token. Leiten Sie die Anfragen anschließend an 127.0.0.1:11434 weiter. Ollama behält seine Bind-Adresse auf localhost. Nur der Proxy lauscht am öffentlichen Port. Das entspricht dem Vorgehen, ein Let’s-Encrypt-Zertifikat auf nginx vor jedem lokalen Dienst einzurichten.

Die Option mit dem Reverse Proxy verwendet die Chat-Oberfläche im nächsten Schritt. Sie ergänzt sie um eine echte Anmeldung.

Chat-Oberfläche mit Open WebUI hinter TLS hinzufügen

Open WebUI ist eine selbst gehostete Chat-Oberfläche. Führen Sie sie 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

Das Flag --network=host ist auf einem Linux-VPS entscheidend. Der Container verwendet dadurch den Netzwerk-Namespace des Hosts. Deshalb verweist 127.0.0.1 innerhalb des Containers auf den Loopback des Hosts, und der Container erreicht Ollama über 127.0.0.1:11434, ohne dass Ollama an einer anderen Schnittstelle lauschen muss. Die Bridge-Netzwerk-Konfiguration, die Sie an anderer Stelle mit --add-host=host.docker.internal:host-gateway und OLLAMA_BASE_URL=http://host.docker.internal:11434 sehen werden, funktioniert hier nicht: Dieser Name wird zur Docker-Bridge-Gateway-Adresse aufgelöst. Ein Dienst, der auf dem Host an 127.0.0.1 gebunden ist, ist über die Bridge nicht erreichbar. Open WebUI bleibt dann einfach mit der Meldung stehen, dass keine Verbindung zu Ollama hergestellt werden kann.

Der Nachteil des Host-Netzwerks besteht darin, dass Open WebUI jetzt am Host-Port 8080 auf allen Schnittstellen lauscht. Jede -p-Zuordnung wird verworfen, und Docker gibt dazu eine Warnung aus. Sperren Sie daher 8080 sowohl auf dem Host als auch in der Provider-Firewall. Der TLS-Reverse-Proxy soll der einzige öffentlich erreichbare Zugang sein. Beim allerersten Aufruf fordert Open WebUI Sie auf, ein Administratorkonto anzulegen. Dieses Konto dient als Authentifizierungsschicht. Wählen Sie daher ein starkes Passwort.

Damit Sie den Chat von Ihrem Laptop über HTTPS öffnen können, schalten Sie einen TLS-Reverse-Proxy vor 127.0.0.1:8080. Wenn Sie auf dem Server bereits mehrere Docker-Anwendungen weiterleiten, passt Traefik mit automatischem TLS für viele Anwendungen am besten: Ein einziger Label-Block stellt das Zertifikat aus und leitet chat.example.com an Open WebUI weiter. Diese Weiterleitung pro Anwendung über Labels verwenden auch alle anderen Browser-Oberflächen auf dem Server, unabhängig davon, ob es sich um ein Status-Dashboard oder um etwas Ungewöhnlicheres wie Halcyon, das eine Jellyfin-Bibliothek als Videothek aus den 90er-Jahren darstellt handelt. Jede Anwendung erhält ihren eigenen Hostnamen und ihren eigenen Login. Die Regel aus dem Sicherheitsabschnitt gilt weiterhin: Der Proxy verwaltet den öffentlichen Port und den Login, während Ollama auf localhost bleibt und Open WebUI's eigener 8080 durch die Firewall geschützt bleibt.

Verwenden Sie den OpenAI-kompatiblen Endpunkt aus Ihrem Code

Ollama stellt unter /v1 eine Teilmenge der OpenAI-Chat-API bereit. Die meisten OpenAI-Clientbibliotheken funktionieren daher, wenn Sie zwei Dinge ändern: die Basis-URL und einen beliebigen Schlüssel.

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)

api_key ist für die Clientbibliothek erforderlich, wird von Ollama aber ignoriert. Sie können daher eine beliebige Zeichenfolge verwenden. model muss der Name eines Modells sein, das Sie bereits heruntergeladen haben. Ein unbekannter Name führt mit model 'x' not found zu einer 404-Antwort. Ein einfacher curl-Aufruf verwendet dasselbe 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"}]}'

Auf diese Weise binden Sie das Modell auch in Agenten- und Editor-Tools ein. Wenn Sie bereits auf dem Server entwickeln, kann ein lokales Modell neben Claude Code, das auf dem VPS innerhalb von tmux läuft, Skripte und Plugins unterstützen. So bleiben kostengünstige, private Entwurfsaufgaben von einer kostenpflichtigen API getrennt, während das anspruchsvolle Schlussfolgern bei einem gehosteten Modell verbleibt.

Fehlerbilder mit den exakt angezeigten Meldungen

Der Prozess wird während der Generierung „Killed“. Sie starten ein großes Modell, und das Terminal gibt Killed aus. Alternativ zeigt das Server-Log (journalctl -u ollama) eine Zeile, die mit llama-server process has terminated beginnt. Das ist die Meldung in Ollama 0.40.7, geprüft am 21. Oktober 2026. Ältere Releases meldeten llama runner process has terminated: signal: killed. Der Linux-OOM-Killer hat den Prozess beendet, weil das Modell mehr RAM benötigte, als auf dem System verfügbar ist. Bestätigen Sie die Ursache mit sudo dmesg | grep -i oom. Dort sehen Sie eine Zeile wie Out of memory: Killed process .... Abhilfe schafft ein kleineres oder stärker quantisiertes Modell, llama3.2:3b statt eines 13B-Modells, oder zusätzlicher Swap. Damit übersteht ein Vorgang, der den physischen RAM nur knapp überschreitet, die Last langsam statt abzubrechen. Swap macht aus einem sofortigen Absturz eine langsame Antwort. Ein 70B-Modell wird dadurch auf 4 GB nicht praktikabel. Die Beendigung bleibt unbemerkt, sofern Sie nicht gerade das Terminal überwachen. Auf einem System, das Sie von einem anderen Rechner aus abfragen, informiert Sie eine OnFailure=-Unit für ollama.service, die einen von Ihnen betriebenen ntfy-Server für Push-Benachrichtigungen verwendet, sobald der Prozess beendet wurde. Sie müssen das Problem dann nicht erst bei der nächsten Anfrage feststellen.

Ollama verweigert das Laden des Modells. Die Anfrage schlägt sofort mit einem Fehler fehl, statt dass der Prozess abstürzt. Das Server-Log enthält model is too large for system memory (Ollama 0.40.7, geprüft am 21. Oktober 2026). Ältere Releases gaben direkt an der Eingabeaufforderung Error: model requires more system memory (X GiB) than is available (Y GiB) aus. Das ist die kontrollierte Variante des obigen Absturzes: Ollama hat den Speicherbedarf berechnet und den Vorgang beendet, statt den OOM-Killer auslösen zu lassen. Wählen Sie ein Modell, dessen Speicherbedarf unter dem freien RAM liegt (prüfen Sie diesen mit free -h), verkleinern Sie die Kontextlänge oder wechseln Sie zu einem größeren VPS. Kein Flag sorgt dafür, dass ein nicht passendes Modell in den Speicher passt. Der benötigte Speicher ist tatsächlich erforderlich.

Das erste Token benötigt sehr lange, danach funktioniert alles normal. Ein nicht geladenes Modell gibt fünf bis dreißig Sekunden lang nichts aus und streamt danach normal. In dieser Pause werden die Gewichte erstmals vom Datenträger in den RAM geladen. Langsamer Speicher verlängert die Wartezeit. Nach dem Laden bleibt das Modell für die Dauer von OLLAMA_KEEP_ALIVE im Speicher. Die zweite Anfrage wird daher sofort beantwortet. Dauert das erste Laden länger als ein Timeout in der Aufrufkette, erhalten Sie statt einer langsamen Antwort einen Fehler. Ermitteln Sie, welche Ebene context deadline exceeded gemeldet hat, um festzustellen, ob der Client, der Proxy oder der Ladevorgang die Wartezeit überschritten hat. Erhöhen Sie diesen Wert, wenn die Wartezeiten stören. Mit ollama ps sehen Sie, ob derzeit ein Modell geladen ist.

Alles ist einfach langsam. Sie erhalten höchstens zehn Tokens pro Sekunde, aber keinen Fehler. Das ist CPU-Inferenz und entspricht dem erwartbaren Verhalten einer CPU-Inferenz. ollama ps zeigt 100% CPU. Das bedeutet, dass keine GPU vorhanden ist. Das ist kein Fehler. Keine Einstellung macht aus einer CPU eine GPU, weil die Hauptbegrenzung die Speicherbandbreite ist. Eine Einstellung sollten Sie auf einer VM dennoch testen: Ollama ermittelt die Thread-Anzahl anhand der erkannten physischen Kerne, und ein Hypervisor kann diese falsch melden. Verwenden Sie in einer ollama run --verbose-Sitzung /set parameter num_thread 4 (oder die Anzahl Ihrer vCPUs), führen Sie dieselbe Anfrage erneut aus und behalten Sie den Wert mit dem besten eval rate bei. Verwenden Sie ansonsten ein kleineres Modell, akzeptieren Sie die Geschwindigkeit oder wechseln Sie zu einer GPU-Instanz. Messen Sie Ihre tatsächliche Rate mit --verbose, bevor Sie von einem Fehler ausgehen. Wenn die Wartezeit durch die Länge der Antwort und nicht durch die Ausgabegeschwindigkeit entsteht, begrenzt num_predict die Antwortlänge. Dadurch verbringt ein ausschweifendes Modell nicht mehrere Minuten mit Tokens, die Sie ohnehin nicht lesen werden.

Von einem anderen Rechner wird die Verbindung abgelehnt. Auf Ihrem Laptop gibt ein aktuelles curl (8.23.0, geprüft am 21. Oktober 2026) curl: (7) Failed to connect to <ip>:11434 after <n> ms: Could not connect to server aus. Das mit Ubuntu 24.04 ausgelieferte curl 8.5.0 gibt curl: (7) Failed to connect to <ip> port 11434 after <n> ms: Couldn't connect to server aus. Die Wörter „Connection refused“ erscheinen nur, wenn Sie -v hinzufügen. Die betreffende Zeile lautet connect to <ip> port 11434 from ... failed: Connection refused. Das Verhalten ist korrekt: Ollama lauscht nur auf localhost. Beheben Sie das Problem nicht, indem Sie an 0.0.0.0 binden. Das wäre genau der oben beschriebene Fehler, durch den der Dienst offengelegt wird. Greifen Sie stattdessen über das VPN oder den authentifizierenden Proxy auf das Modell zu.

Sie haben Port 11434 im Internet veröffentlicht. Wenn Sie OLLAMA_HOST=0.0.0.0 gesetzt, die Firewall geöffnet haben und nun nicht gestartete Modelldownloads oder eine durch unbekannte Clients dauerhaft auf 100 % ausgelastete CPU sehen, wurde Ihr System gefunden und verwendet. Das ist ein grundlegender Fehler und kein Sonderfall. Binden Sie den Dienst wieder an 127.0.0.1 oder an die VPN-Adresse, schließen Sie Port 11434 in der Firewall und schalten Sie eine Authentifizierung davor. Gehen Sie davon aus, dass alles, was während der Offenlegung unter dieser Adresse erreichbar war, von Unbekannten abgefragt wurde.

Backups und Upgrades

Es gibt nur wenige Zustandsdaten, die verloren gehen können. Die Modelle lassen sich erneut herunterladen. Daher lohnt es sich nur, das Daten-Volume von Open WebUI, Benutzerkonten, den Chatverlauf, Einstellungen und eventuell erstellte systemd-Drop-ins zu sichern. 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, indem Sie das Installationsskript erneut ausführen. Aktualisieren Sie Open WebUI mit docker pull ghcr.io/open-webui/open-webui:main und erstellen Sie anschließend den Container neu. Ein Hinweis zum Speicherplatz bei der Version-0.40-Reihe: Ollama 0.40.2 begann damit, mit früheren Versionen heruntergeladene Modelle im Hintergrund zu aktualisieren, und behielt die ursprünglichen Kopien als Backups. Dadurch wird zusätzlicher Speicherplatz belegt, bis diese Kopien entfernt werden. 0.40.3 (11 October 2026) pausierte dieses Hintergrund-Upgrade. Prüfen Sie nach einem Upgrade df -h und lesen Sie die Release Notes zum Befehl, mit dem sich diese Backups löschen lassen. Fixieren Sie langfristig keine Version: Sowohl die Modellqualität als auch die Laufzeitumgebung ändern sich schnell. Lesen Sie daher die Release Notes und führen Sie auf Ihrem eigenen System neue Benchmarks durch, statt den Zahlen aus dem letzten Quartal zu vertrauen.

FAQ

Kann ich ein LLM wirklich auf einem VPS nur mit CPU ausführen?

Ja, innerhalb bestimmter Grenzen. Kleine quantisierte Modelle im Bereich von 3B bis 8B laufen auf der CPU und sind für Entwürfe, Zusammenfassungen und Klassifizierung tatsächlich nützlich, allerdings langsam: Auf einer gemeinsam genutzten vCPU erreichen sie nur eine einstellige bis niedrige zweistellige Anzahl an Tokens pro Sekunde. Modelle ab 13B laufen quälend langsam oder passen überhaupt nicht in den RAM. Für eine höhere Geschwindigkeit oder größere Modelle benötigen Sie eine GPU-Instanz.

Wie viel RAM benötigt jedes Modell?

Als grobe Regel für die 4-Bit-Tags (Q4), die die meisten populären Modelle standardmäßig verwenden, gilt: etwa 0.5 GB RAM pro Milliarde Parameter für die Gewichte, zusätzlich etwa 1 GB Overhead und etwas mehr für den Kontext. Ein 3B-Modell benötigt daher 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 alle anderen Anwendungen auf dem Server.

Ist die Ollama-API authentifiziert?

Nein. Ollama verfügt über keine integrierte Authentifizierung, keinen API-Schlüssel und kein Rate-Limit. Jeder, der Port 11434 erreichen kann, hat die vollständige Kontrolle darüber. Die Einstellung OLLAMA_ORIGINS beschränkt nur, welche Browser-Ursprünge darauf zugreifen dürfen, nicht aber, wer eine Verbindung herstellen kann. Genau deshalb bindet Ollama standardmäßig an 127.0.0.1. Sie dürfen Port 11434 auf 0.0.0.0 niemals im Internet veröffentlichen. Greifen Sie lokal, über ein privates VPN oder über einen Reverse Proxy zu, der eine Anmeldung ergänzt.

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

Führen Sie Open WebUI in Docker mit --network=host aus. Dadurch verwendet es die Loopback-Schnittstelle des Hosts und erreicht das native Ollama unter http://127.0.0.1:11434. Schalten Sie anschließend einen TLS-Reverse-Proxy vor den Port 8080, damit Sie von Ihrem Laptop aus darauf zugreifen können. Halten Sie 8080 in der Firewall geschlossen, damit der Proxy der einzige öffentlich erreichbare Zugang bleibt. Das Administratorkonto von Open WebUI stellt die Anmeldung bereit. Das Passwort legen Sie beim ersten Start fest.

Wie rufe ich es aus meiner eigenen Anwendung auf?

Verwenden Sie den OpenAI-kompatiblen Endpunkt unter http://127.0.0.1:11434/v1. Konfigurieren Sie jedes OpenAI-SDK mit dieser Basis-URL. Übergeben Sie einen beliebigen String als API-Schlüssel, da dieser ignoriert wird, und setzen Sie model auf den Namen eines Modells, das Sie heruntergeladen haben. Vorhandener OpenAI-Code läuft normalerweise unverändert, abgesehen von der Basis-URL und dem Schlüssel.