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 plus etwa einem Gigabyte Laufzeit-Overhead und einem weiteren Anteil für das Kontextfenster. Ollamas Standardmodelle sind mit 4 Bit quantisiert (als Q4 bezeichnet). Das benötigt pro Milliarde Parameter etwa ein halbes Gigabyte RAM. Die Rechnung ist daher einfach und entscheidend. Den letzten Anteil legen Sie selbst fest: Wenn Sie num_ctx über Ollamas kleinen Standardwert erhöhen, stehen längere Prompts zur Verfügung. Gleichzeitig wächst jedoch 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 etwa 2 GB groß 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 der Festplatte und benötigt ungefähr 8 GB RAM, mit 16 GB läuft es komfortabel. 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 realistischerweise eine GPU. Auf einem 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. CPU-Inferenz wird durch die Speicherbandbreite begrenzt, nicht durch die Taktfrequenz. Ein 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 nur grobe Richtwerte. Messen Sie am besten Ihr eigenes System. Der folgende Ausführungsschritt zeigt, wie das geht. Vertrauen Sie auf eval rate, nicht auf eine Zahl in irgendeinem Artikel, auch nicht in diesem.

Die praktische Schlussfolgerung: Kleine quantisierte Modelle sind auf der CPU für Entwürfe, Zusammenfassungen und Klassifizierungen tatsächlich nützlich, wenn Sie die Geschwindigkeit akzeptieren können. Für größere oder schnellere Modelle sollten Sie ein GPU-Instance einplanen. Wenn Sie diese Rechnung lieber vollständig anhand eines bestimmten Modells nachvollziehen möchten, beschreibt Nemotron 3.5 Lightning auf einem VPS auszuführen, welches Tag Sie herunterladen müssen, wie viel RAM das Modell tatsächlich benötigt und ob die CPU-Leistung ausreicht.

Um ein bestimmtes Modell mit einem bestimmten System zu vergleichen, schätzen Sie hier seinen 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

Ollama bindet standardmäßig 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. Überhaupt keine. Es gibt keinen API-Schlüssel, keine Anmeldung, kein Rate-Limit und keine Allowlist. Jeder, der Port 11434 erreichen kann, kann jedes von Ihnen heruntergeladene Modell ausführen, neue Modelle herunterladen, Modelle löschen und Ihre CPU oder GPU dauerhaft vollständig auslasten. Scanner wie Shodan erfassen offene Ollama-Instanzen zu Tausenden. Eine exponierte Instanz wird innerhalb weniger Stunden gefunden und missbraucht.

Der eine Fehler, den Sie niemals machen dürfen, ist folgender: Setzen Sie OLLAMA_HOST=0.0.0.0 nicht und öffnen Sie Port 11434 nicht in der Firewall. Dadurch veröffentlichen Sie einen nicht authentifizierten Inferenzserver im gesamten Internet. Keine Konfiguration macht einen direkt auf 0.0.0.0 gebundenen Port 11434 sicher, weil es in Ollama nichts zu konfigurieren gibt und die Authentifizierung schlicht nicht vorhanden ist. Das ist eine Regel für diesen konkreten Dienst und kein generelles Verbot, jemals einen Port zu öffnen: ein selbst gehostetes RustDesk-Relay für Remote-Desktop muss öffentlichen Netzwerkverkehr akzeptieren, damit es seine Aufgabe überhaupt erfüllen kann. Dafür verfügt es über eine eigene schlüsselbasierte Authentifizierung und eine kurze, dokumentierte Liste von Ports. Genau das fehlt Ollama.

Es gibt drei sichere Möglichkeiten, von außerhalb des Servers auf das Modell zuzugreifen:

• Lokal darauf zugreifen. Wenn der einzige Client ein anderes Programm auf demselben VPS, ein Cron-Skript, ein Bot oder ein MCP-Server zur Verbindung Ihrer Tools mit dem Modell ist, lassen Sie das Binding auf 127.0.0.1 und lassen Sie das Programm http://127.0.0.1:11434 aufrufen. Nichts wird veröffentlicht, und es ist nichts Weiteres erforderlich.
• Über einen privaten Tunnel darauf zugreifen. Binden Sie den VPS in ein selbst betriebenes WireGuard-VPN ein, setzen Sie OLLAMA_HOST auf die Tunneladresse, beispielsweise 10.8.0.1 und nicht 0.0.0.0, und erlauben Sie nur Verbindungen von VPN-Peers. Im öffentlichen Internet ist Port 11434 weiterhin nicht sichtbar.
• Einen authentifizierenden Reverse Proxy davorschalten. Terminieren Sie TLS und verlangen Sie bei nginx, Traefik oder Caddy ein Passwort oder Token. Leiten Sie die Anfragen anschließend an 127.0.0.1:11434 weiter. Ollama behält sein localhost-Binding. Nur der Proxy lauscht am öffentlichen Port. Das entspricht dem Vorgehen, bei dem Sie ein Let's-Encrypt-Zertifikat für nginx vor jedem lokalen Dienst verwenden.

Die Reverse-Proxy-Option stellt Ihnen die Chat-Oberfläche im nächsten Schritt bereit, einschließlich einer echten 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.

OpenAI-kompatiblen Endpunkt aus Ihrem Code verwenden

Ollama stellt unter /v1 eine Teilmenge der OpenAI-Chat-API bereit. Daher funktionieren die meisten OpenAI-Clientbibliotheken, 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 jedoch ignoriert. Daher funktioniert jede Zeichenfolge. model muss ein Name sein, den Sie bereits abgerufen haben. Ein unbekannter Name gibt model "x" not found, try pulling it first zurück. Ein einfacher curl-Aufruf verfolgt 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 System entwickeln, kann ein lokales Modell Skripte und Plugins ergänzen, ebenso wie Claude Code, das auf dem VPS innerhalb von tmux läuft. So bleiben günstige, private Entwurfsaufgaben außerhalb einer kostenpflichtigen API, während ein gehostetes Modell die aufwendige Analyse übernimmt.

Fehlerbilder mit den exakt angezeigten Zeichenfolgen

Der Prozess wird während der Generierung „Killed“. 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 beendet, weil das Modell mehr RAM benötigte, als auf dem Server vorhanden ist. Bestätigen Sie die Ursache mit sudo dmesg | grep -i oom. Dort sehen Sie eine Zeile wie Out of memory: Killed process ... (ollama). Verwenden Sie ein kleineres oder stärker quantisiertes Modell, beispielsweise llama3.2:3b statt eines 13B-Modells, oder fügen Sie Swap hinzu. Dadurch überlebt ein Ladevorgang, der den physischen RAM nur knapp überschreitet, langsam statt abzubrechen. Swap macht aus einem sofortigen Absturz eine langsame Antwort. Ein 70B-Modell wird dadurch auf 4 GB jedoch nicht praktikabel. Der Prozess wird still beendet, sofern Sie nicht gerade das Terminal beobachten. Auf einem Server, den Sie von einem anderen System aus abfragen, informiert Sie eine an ollama.service angehängte OnFailure=-Unit über einen von Ihnen betriebenen ntfy-Server für Push-Benachrichtigungen sofort über den Abbruch, statt dass Sie ihn erst bei der nächsten Anfrage feststellen.

„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. Das ist die kontrollierte Variante des vorherigen Absturzes: Ollama hat den Speicherbedarf berechnet und den Start abgebrochen, statt den OOM-Killer eingreifen zu lassen. Die beiden Werte werden dabei direkt ausgegeben. Wählen Sie ein Modell, dessen Speicherbedarf unter Ihrem freien RAM liegt. Prüfen Sie diesen mit free -h. Alternativ können Sie die Context-Länge verkleinern oder auf einen größeren VPS wechseln. Kein Flag kann das Modell passend machen, wenn der benötigte Speicher tatsächlich fehlt.

Das erste Token lässt lange auf sich warten, danach geht es normal weiter. Ein nicht geladener Cold-Start des Modells erzeugt für fünf bis dreißig Sekunden keine Ausgabe und streamt anschließend normal. In dieser Pause werden die Gewichte zum ersten Mal von der Festplatte in den Arbeitsspeicher geladen. Langsamer Speicher verlängert die Pause. Nach dem Laden bleibt das Modell für die Dauer von OLLAMA_KEEP_ALIVE im Speicher resident. Daher beantwortet es die zweite Anfrage sofort. Wenn dieser erste Ladevorgang ein Timeout irgendwo im Aufrufpfad überschreitet, erhalten Sie statt einer langsamen Antwort einen Fehler. Wenn Sie ermitteln, welche Ebene den Fehler context deadline exceeded gemeldet hat, können Sie feststellen, ob der Client, der Proxy oder der Ladevorgang selbst das Timeout überschritten hat. Erhöhen Sie diesen Wert, wenn Sie 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 und keine Fehlermeldung. Das ist CPU-Inferenz, die sich genau wie CPU-Inferenz verhält. ollama ps zeigt 100% CPU. Das bedeutet, dass keine GPU vorhanden ist. Dies ist kein Fehler, und keine Einstellung kann das beheben, weil die Grenze durch die Speicherbandbreite und nicht durch eine Fehlkonfiguration entsteht. Verwenden Sie ein kleineres Modell, akzeptieren Sie die Geschwindigkeit oder wechseln Sie zu einer GPU-Instanz. Messen Sie mit --verbose die tatsächliche Rate, bevor Sie von einem Fehler ausgehen. Wenn die Wartezeit durch die Länge der Antwort und nicht durch die Rate entsteht, verhindert eine Begrenzung der Antwort mit num_predict, dass ein ausuferndes Modell minutenlang Tokens generiert, die Sie ohnehin nicht lesen werden.

Verbindung von einem anderen Rechner abgelehnt. Von Ihrem Laptop erhalten Sie curl: (7) Failed to connect to <ip> port 11434: Connection refused. Das entspricht dem vorgesehenen Verhalten: Ollama bindet standardmäßig nur an localhost. Beheben Sie das nicht, indem Sie an 0.0.0.0 binden. Genau das wäre der zuvor beschriebene Fehler bei der Freigabe. Greifen Sie stattdessen über das VPN oder über 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 Modell-Downloads sehen, die Sie nicht gestartet haben, oder die CPU durch unbekannte Clients dauerhaft zu 100 % ausgelastet ist, wurde Ihr Server entdeckt und verwendet. Das ist der zentrale Fehler und kein seltener Sonderfall. Binden Sie erneut 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 Freigabe 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, Konten, den Chatverlauf, Einstellungen und jedes von Ihnen erstellte systemd-Drop-in 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. Verwenden Sie langfristig keine festen Versionen: 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 erneut Benchmarks durch, statt den Zahlen des letzten Quartals 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. Auf einer gemeinsam genutzten vCPU arbeiten sie jedoch langsam, mit einstelligen bis niedrigen zweistelligen Tokenraten pro Sekunde. Alles ab 13B ist quälend langsam oder passt überhaupt nicht in den RAM. Für höhere Geschwindigkeit oder größere Modelle benötigen Sie eine GPU-Instanz.

Wie viel RAM benötigt jedes Modell?

Als grobe Regel gilt für die standardmäßigen quantisierten 4-Bit-Modelle: etwa 0.5 GB RAM pro Milliarde Parameter für die Gewichte, zuzüglich ungefähr 1 GB Overhead und etwas zusätzlichem Speicher 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 Arbeitsspeicher mit free -h und lassen Sie Platz für das Betriebssystem und alle anderen Dienste 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. Genau deshalb bindet Ollama standardmäßig an 127.0.0.1, und deshalb dürfen Sie 11434 unter 0.0.0.0 niemals im Internet veröffentlichen. Greifen Sie lokal, über ein privates VPN oder über einen Reverse Proxy darauf 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 das Loopback-Interface des Hosts und erreicht die native Ollama-Instanz unter http://127.0.0.1:11434. Schalten Sie anschließend einen TLS-Reverse-Proxy vor dessen Port 8080, damit Sie von Ihrem Laptop aus darauf zugreifen können. Lassen 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. Richten Sie ein beliebiges OpenAI-SDK auf diese Basis-URL, übergeben Sie einen beliebigen Text als API-Schlüssel, da er ignoriert wird, und setzen Sie model auf einen Namen, den Sie heruntergeladen haben. Vorhandener OpenAI-Code läuft normalerweise unverändert, abgesehen von der Basis-URL und dem Schlüssel.