Ollama mit rootless Podman auf einem VPS betreiben

Ollama in rootless Podman auf einem VPS ausführen

Damit Ollama in rootless Podman auf einem Server läuft, müssen fünf Voraussetzungen erfüllt sein, die eine Desktop-Anleitung auslassen kann. Ein dedizierter Benutzer ohne privilegierte Rechte besitzt den Container. Für diesen Benutzer ist Lingering aktiviert, damit der Container nach dem Abmelden weiterläuft. Eine Quadlet-Datei übergibt den Container an systemd, damit er nach einem Reboot wieder gestartet wird. Das Modellverzeichnis hat auf Distributionen mit aktiviertem SELinux das erforderliche SELinux-Label. Die API lauscht nur auf dem Loopback-Interface. Der Zugriff erfolgt über einen SSH-(Secure-Shell-)Tunnel.

Ollama ist ein Server für Large Language Models (LLM). Die Modelldateien werden auf der Festplatte gespeichert, in den Arbeitsspeicher geladen und über HTTP-Anfragen auf Port 11434 verarbeitet. Ollama verfügt weder über eine Anmeldung noch über einen API-Schlüssel oder Benutzerkonten. Daher ist das Netzwerk die einzige Zugriffskontrolle. Podman führt Container ohne Daemon und ohne root aus. Alles, was aus dem Container ausbricht, läuft daher zunächst als normaler Benutzer ohne privilegierte Rechte. Wenn Sie zuerst den Laufzeitvergleich lesen möchten, lesen Sie wie sich Podman und Docker auf einem VPS unterscheiden. Wenn Sie vollständig auf Container verzichten möchten, ist Ollama direkt auf einem VPS installieren der kürzere Weg.

SSD Nodes stellt Fedora unter seinen Images bereit. Fedora liefert Podman und SELinux (Security-Enhanced Linux) standardmäßig mit. Jeder folgende Befehl funktioniert auf jeder Distribution mit Podman 5 oder neuer.

Warum die Laptop-Version auf einem Server angepasst werden muss

Das Fedora Magazine veröffentlichte am 5. August 2026 eine klare Anleitung für diesen Stack: Ollama lokal mit Podman unter Fedora Linux ausführen, von Yazan Monshed. Sie bietet einen guten Einstieg in die Werkzeuge. Sie richtet sich jedoch an einen Laptop. Vier ihrer Entscheidungen verhalten sich auf einem Rechner mit öffentlicher IP-Adresse anders.

• Der Container wird mit einem einfachen podman run -d gestartet. Ein manuell gestarteter Container wird nach einem Reboot nicht erneut gestartet, weil kein automatischer Start konfiguriert wurde.
• Verwendet wird der veränderliche Tag ollama/ollama. Auf einem Laptop bemerken Sie den Tag, an dem sich das Verhalten ändert. Auf einem Server zeigt sich das Problem möglicherweise zuerst durch ein Skript, das über Nacht nicht mehr funktioniert.
• Die Veröffentlichung erfolgt mit -p 11434:11434. Dadurch wird an alle Interfaces gebunden. Hinter einem Heimrouter ist der Dienst aus dem Internet nicht erreichbar. Auf einem VPS handelt es sich dagegen um eine öffentliche Inference-API ohne Passwortschutz.
• Der Container läuft unter Ihrem eigenen Login-Benutzer. Auf einem Server sollte das Konto, dem der Container gehört, keine anderen Daten besitzen. Bei einem Ausbruch aus dem Container landet der Angreifer dann in einem leeren Home-Verzeichnis.

Keine dieser Entscheidungen ist für den Rechner, für den die Anleitung geschrieben wurde, falsch. Sie müssen lediglich jede davon erneut prüfen, wenn der Server von überall erreichbar ist und niemand davor sitzt.

Unprivilegierten Benutzer anlegen und subuid prüfen

Rootless Podman ordnet die internen Benutzer-IDs (UID) des Containers einem Block nicht verwendeter IDs auf dem Host zu. Dieser Block ist in /etc/subuid und /etc/subgid festgelegt. Ohne diesen Block können Rootless-Container überhaupt nicht gestartet werden.

sudo dnf install -y podman        # or: sudo apt install -y podman
sudo useradd --create-home --shell /bin/bash --comment "Ollama container owner" ollama
sudo passwd --lock ollama
grep ollama /etc/subuid /etc/subgid

grep sollte zwei Zeilen ausgeben, eine aus jeder Datei. Jede Zeile muss einen Bereich mit 65536 IDs angeben:

/etc/subuid:ollama:100000:65536
/etc/subgid:ollama:100000:65536

Die Startnummer ist bei Ihnen möglicherweise anders. Das ist unproblematisch. Wenn grep keine Ausgabe liefert, hat useradd keinen Bereich zugewiesen. Der erste podman-Befehl als dieser Benutzer schlägt dann wie folgt fehl:

Error: cannot find UID/GID for user ollama: no subuid ranges found for user "ollama" in /etc/subuid

Weisen Sie einen Bereich zu, den kein anderer Benutzer verwendet, und teilen Sie Podman mit, dass seine alte Zuordnung veraltet ist:

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 ollama
sudo -iu ollama podman system migrate

Durch das Sperren des Passworts kann sich niemand direkt als ollama anmelden. Sie wechseln von Ihrem Administratorkonto mit sudo -iu ollama zu diesem Konto.

Aktivieren Sie Lingering, damit der Dienst nach dem Abmelden weiterläuft

Die systemd-Instanz eines Benutzers wird normalerweise bei der Anmeldung gestartet und beim Abmelden beendet. /run/user/<uid> wird dabei ebenfalls entfernt. Jeder Rootless-Container dieses Benutzers wird im selben Moment beendet. Lingering hält die Benutzerinstanz ohne zugeordnete Sitzung aktiv.

sudo loginctl enable-linger ollama
loginctl show-user ollama --property=Linger

Die Ausgabe sollte Linger=yes enthalten. Aktivieren Sie Lingering, bevor Sie die Unit erstellen. Das für die Unit benötigte Verzeichnis /run/user/<uid> ist erst vorhanden, wenn Lingering aktiviert ist.

Es gibt noch einen weiteren Schritt, den niemand erwartet. sudo -iu ollama stellt zwar eine Shell bereit, aber keinen Sitzungsbus. Deshalb schlägt systemctl --user sofort fehl:

Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined

systemd sucht den Benutzerbus unter $XDG_RUNTIME_DIR/bus. sudo -i setzt diese Variable jedoch nicht. Setzen Sie sie daher in jeder Administrations-Shell, in der Sie diesen Dienst verwalten, manuell:

sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user status

Wo die Modellblobs gespeichert werden und wie viel Speicherplatz einzuplanen ist

Ollama schreibt die Gewichte im Container nach /root/.ollama/models. Binden Sie ein Verzeichnis aus dem Home-Verzeichnis des Benutzers in diesen Pfad ein. Dann werden die Dateien an einem messbaren Ort gespeichert: /home/ollama/ollama-data/models. Die Blobs liegen in models/blobs als inhaltsadressierte Dateien. models/manifests enthält den kleinen Index, der diese Dateien benennt. Wenn Sie stattdessen ein benanntes Volume verwenden, wie im Beitrag des Fedora Magazine, liegt derselbe Verzeichnisbaum unter /home/ollama/.local/share/containers/storage/volumes/<volume>/_data. In beiden Fällen schreiben ollama pull und ollama run die Gewichte in denselben Verzeichnisbaum. Die beiden Befehle unterscheiden sich nur darin, ob nach Abschluss des Downloads einmal eine Chatsitzung geöffnet wird.

Ermitteln Sie den benötigten Speicherplatz, bevor Sie Modelle herunterladen. Die veröffentlichten Downloadgrößen geben den Mindestbedarf an.

[
  {
    "label": "gemma3:4b",
    "download_gb": 3.3
  },
  {
    "label": "mistral:7b",
    "download_gb": 4.4
  },
  {
    "label": "qwen3:8b",
    "download_gb": 5.2
  },
  {
    "label": "gemma3:12b",
    "download_gb": 8.1
  },
  {
    "label": "qwen3:14b",
    "download_gb": 9.3
  },
  {
    "label": "gemma3:27b",
    "download_gb": 17
  },
  {
    "label": "qwen3:30b",
    "download_gb": 19
  }
]

Alle 7 Zeilen enthalten Angaben, die auf ollama.com/library veröffentlicht wurden. Es handelt sich nicht um auf einem Datenträger gemessene Größen. Das kleinste Tag in dieser Übersicht, gemma3:4b, benötigt beim Download 3.3 GB. Das größte Tag, qwen3:30b, benötigt beim Download 19 GB. Das Container-Image wird zusätzlich im eigenen Speicher von Podman abgelegt. Prüfen Sie daher beide Werte zusammen mit podman system df und df -h /home. Ein Modell benötigt während des Ladens außerdem ungefähr so viel RAM wie seine Dateigröße sowie zusätzlichen Speicher für das Kontextfenster. Ein Modell mit 19 GB läuft daher nicht auf einem VPS mit 16 GB RAM.

Taggenauigkeit sicherstellen und den vollständigen Registry-Namen verwenden

sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
mkdir -p ~/ollama-data ~/.config/containers/systemd
podman pull docker.io/ollama/ollama:0.32.9

Verwenden Sie ein veröffentlichtes Versionstag, 0.32.9 (Stand: August 2026), und nicht latest. Mit einem festgelegten Tag liefert ein Neustart um 04:00 dasselbe Binary, das Sie getestet haben. Jede Verhaltensänderung geht damit auf eine von Ihnen vorgenommene Änderung zurück. Docker Hub veröffentlicht für dieselben Versionen außerdem die Tags -rc und -rocm. Verwenden Sie das einfache Tag, außer Sie haben eine AMD-GPU.

Geben Sie auch den Registry-Host an. Unter Fedora verfügt eine systemd-Unit bei einem kurzen Namen über kein Terminal, an dem sie eine Eingabe anfordern kann. Die Unit schlägt dann mit folgendem Fehler fehl:

Error: short-name "ollama/ollama" did not resolve to an alias and no unqualified-search registries are defined

Das Image zunächst manuell zu beziehen, ist optional, aber sinnvoll. Dadurch wird der mehrere Gigabyte große Download aus dem Start-Timeout der Unit herausgehalten.

Die Quadlet-Unit, die einen Reboot übersteht

Quadlet ist der systemd-Generator von Podman. Sie erstellen eine .container-Datei, systemd wandelt sie beim Booten in einen Dienst um, und podman generate systemd ist nicht mehr erforderlich. Speichern Sie diese Datei als /home/ollama/.config/containers/systemd/ollama.container. Der Besitzer muss der Benutzer ollama sein.

[Unit]
Description=Ollama API (rootless)
After=network-online.target
Wants=network-online.target

[Container]
Image=docker.io/ollama/ollama:0.32.9
ContainerName=ollama
PublishPort=127.0.0.1:11434:11434
Volume=/home/ollama/ollama-data:/root/.ollama:Z
Environment=OLLAMA_KEEP_ALIVE=30m
Environment=OLLAMA_MAX_LOADED_MODELS=1

[Service]
Restart=always
TimeoutStartSec=900

[Install]
WantedBy=default.target

Der Dateiname legt den Namen des Dienstes fest. Daher wird ollama.container zu ollama.service.

systemctl --user daemon-reload
systemctl --user start ollama.service
systemctl --user status ollama.service

status sollte active (running) anzeigen. Führen Sie systemctl --user enable ollama.service nicht aus. Die Unit ist keine Datei auf der Festplatte. Daher lehnt systemd den Befehl ab:

Failed to enable unit: Unit file /run/user/1001/systemd/generator/ollama.service is transient or generated.

Der Abschnitt [Install] übernimmt diese Aufgabe bereits. Quadlet erstellt den Link für den Start beim Booten während daemon-reload selbst. Deshalb ist dieser Befehl erforderlich. TimeoutStartSec=900 deckt einen ersten Start ab, bei dem das Image noch heruntergeladen werden muss. Die standardmäßigen 90 Sekunden reichen für einen Download von zwei Gigabyte nicht aus. systemd beendet den Start dann mit einem Fehler. OLLAMA_KEEP_ALIVE=30m hält ein Modell zwischen Anfragen im Arbeitsspeicher, statt es nach fünf Minuten zu entladen. Die Abwägungen werden unter ein Ollama-Modell im Arbeitsspeicher behalten erläutert. Falls ein Begriff aus der systemd-Terminologie hier neu für Sie ist, erklärt wie systemd-Dienste und Timer auf einem VPS funktionieren die Units selbst.

Warum das Modellverzeichnis unter SELinux den Zugriff verweigert

Auf Fedora, RHEL, Rocky und AlmaLinux ist SELinux standardmäßig im Enforcing-Modus aktiv. Ein Containerprozess läuft in der Domäne container_t, während ein Verzeichnis im Home-Verzeichnis eines Benutzers mit user_home_t gekennzeichnet ist. Die Richtlinie erlaubt diesen Zugriff nicht. Daher kann Ollama seine Modellstruktur nicht erstellen, und der Container wird beendet. getenforce gibt auf diesen Systemen Enforcing aus. Die Zugriffsverweigerung wird protokolliert:

sudo ausearch -m avc -ts recent

Sie sehen eine Zeile, in der die Domäne und das Label des Ziels genannt werden:

avc:  denied  { write } for  pid=1842 comm="ollama" name="models" dev="vda1" ino=131077 scontext=system_u:system_r:container_t:s0:c214,c827 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir permlisted=0

Das :Z am Ende der Volume=-Zeile behebt das Problem. Es versieht das Hostverzeichnis mit dem Label container_file_t und weist ihm eine private MCS-Kategorie (Multi-Category Security) zu, die nur dieser Container trägt. Das kleingeschriebene :z verwendet stattdessen ein gemeinsam genutztes Label. Das ist die richtige Wahl, wenn zwei Container dasselbe Verzeichnis lesen.

Beachten Sie :Z, da der Befehl destruktiv und ohne Ausgabe arbeitet. Die Neuzuordnung der Labels erfolgt rekursiv. Wenn Sie den Befehl auf /home/ollama anwenden, wird jede Datei in diesem Home-Verzeichnis neu gekennzeichnet. Dadurch funktioniert der Zugriff dieses Benutzers auf seine SSH-Schlüssel nicht mehr. Übergeben Sie :Z immer ein eigenes Unterverzeichnis, das keine anderen Dateien enthält. Benannte Volumes benötigen den Befehl nicht, da Podman sie beim Erstellen korrekt kennzeichnet. Einen umfassenderen Überblick bietet SELinux-Grundlagen für einen Server mit Erläuterungen zu Kontexten und Booleans. Unter Ubuntu und Debian wird stattdessen AppArmor verwendet. :Z hat dort keine Wirkung. Wenn der Befehl in der Unit bleibt, ist das unproblematisch.

Port 11434 schließen und über SSH auf die API zugreifen

PublishPort=127.0.0.1:11434:11434 bindet die Host-Seite an Loopback. Prüfen Sie das:

ss -ltnp | grep 11434
curl http://127.0.0.1:11434

Die Ausgabe von ss muss 127.0.0.1:11434 anzeigen. 0.0.0.0:11434 oder *:11434 bedeutet, dass der Port aus dem Internet erreichbar ist, und curl muss auf Ollama is running antworten.

Achten Sie genau darauf, an welche Seite Sie binden. Die Adresse in PublishPort ist die Host-Adresse. Im Container muss Ollama weiterhin auf allen Schnittstellen lauschen. Das ist die Standardeinstellung des Images. Wenn Sie Environment=OLLAMA_HOST=127.0.0.1 setzen, bindet Ollama an das Loopback-Interface des Containers. Podman leitet veröffentlichten Datenverkehr dann stattdessen an die Netzwerkadresse des Containers weiter. Deshalb wird jede Anfrage abgewiesen, auch vom Host.

Ein offener Port 11434 verursacht zwei Probleme. Ollama bietet keine Authentifizierung. Jeder, der den Port erreicht, kann über /api/tags Ihre Modelle auflisten, über /api/generate Inferenz auf Ihrer CPU ausführen und Ihr verfügbares Datenvolumen verbrauchen, neue Modelle auf Ihre Festplatte laden und vorhandene Modelle löschen. Außerdem werden Prompts und Ausgaben bei unverschlüsseltem HTTP zu einem entfernten Port im Klartext übertragen. Jede Maschine entlang des Pfads kann sie lesen. Beide Probleme verschwinden, wenn der Port den Host nicht verlässt.

Leiten Sie den Port von Ihrer Workstation über SSH weiter:

ssh -N -L 11434:127.0.0.1:11434 you@vps.example.com

Nun ist http://127.0.0.1:11434 auf Ihrem Laptop der Ollama-Server. Die Verbindung läuft innerhalb der Verschlüsselung der SSH-Sitzung. Wenn auf Ihrem Laptop bereits Ollama läuft, schlägt das lokale Binden mit bind [127.0.0.1]:11434: Address already in use fehl. Verwenden Sie -L 11435:127.0.0.1:11434 und richten Sie Ihren Client auf Port 11435.

Wenn ein Browser-Client benötigt wird, setzen Sie stattdessen einen Reverse Proxy mit Passwort davor. Ein Caddy-Site-Block umfasst vier Zeilen, und caddy hash-password gibt den benötigten bcrypt-Hash aus:

ollama.example.com {
  basic_auth {
    you $2a$14$replace_with_the_generated_hash
  }
  reverse_proxy 127.0.0.1:11434
}

Caddy bezieht selbstständig ein Zertifikat über TLS (Transport Layer Security), sodass der Datenverkehr verschlüsselt ist. Testen Sie zuerst Ihren Client. Viele Tools, die mit Ollama kommunizieren, haben kein Feld für einen Authorization-Header und schlagen bei Basic Auth mit einem einfachen 401 Unauthorized fehl. Der SSH-Tunnel hat dieses Problem nicht. Deshalb wird er hier standardmäßig empfohlen.

Ein Modell abrufen und den gesamten Pfad prüfen

podman exec -it ollama ollama pull gemma3:4b
curl -s http://127.0.0.1:11434/api/tags
curl -s http://127.0.0.1:11434/api/generate -d '{"model":"gemma3:4b","prompt":"Reply with the single word: ready","stream":false}'
du -sh ~/ollama-data/models

/api/tags gibt JSON mit einer Auflistung von gemma3:4b zurück. /api/generate gibt nach einer kurzen Pause, während die Gewichte von der Festplatte geladen werden, ein JSON-Objekt mit einem Feld response zurück. du sollte eine Zahl melden, die nahe an der veröffentlichten Downloadgröße liegt. Beweisen Sie anschließend den Teil, um den es in diesem gesamten Leitfaden geht:

sudo reboot
# reconnect, then:
sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user is-active ollama.service

active bedeutet, dass der Prozess weiterhin vorhanden ist. Der Abschnitt [Install] und daemon-reload haben ihre Aufgaben erfüllt. inactive bedeutet, dass einer der drei Bestandteile fehlt.

Fehlerbilder und die dabei angezeigten Meldungen

Container ist nach einem Reboot verschwunden. Prüfen Sie zuerst loginctl show-user ollama --property=Linger, da die systemd-Instanz des Benutzers ohne Linger=yes beim Booten nicht gestartet wird. Wenn Lingering aktiviert ist, der Abschnitt [Install] in der Datei .container fehlt oder Sie die Datei bearbeitet und systemctl --user daemon-reload nicht ausgeführt haben, tritt dieses Problem auf.

Error: statfs /home/ollama/ollama-data: no such file or directory. Die Quelle des Bind-Mounts muss vorhanden sein, bevor der Container gestartet wird. Podman erstellt keine Verzeichnisse auf dem Host. Führen Sie mkdir -p ~/ollama-data als Benutzer ollama aus.

Start schlägt nach 90 Sekunden fehl. journalctl --user -u ollama.service zeigt Start operation timed out. Terminating. an, weil der Image-Pull noch lief. Führen Sie den Pull manuell aus oder behalten Sie TimeoutStartSec=900 bei.

Container wird gestartet und beendet sich wieder. podman logs ollama und sudo ausearch -m avc -ts recent zeigen zusammen, ob das Problem mit dem SELinux-Label zusammenhängt. Ein AVC, in dem container_t und user_home_t genannt werden, bedeutet, dass :Z fehlt.

Anfragen vom Host werden abgewiesen. curl: (7) Failed to connect to 127.0.0.1 port 11434: Connection refused mit dem Dienst active bedeutet normalerweise, dass OLLAMA_HOST im Container auf eine Loopback-Adresse gesetzt wurde. Entfernen Sie diese Zeile.

Generierung ist sehr langsam oder der Container wird beendet. Ohne GPU läuft die Inferenz auf der CPU und ein großes Modell ist naturgemäß langsam. Wenn ein Container während einer Anfrage beendet wird und in den Logs signal: killed erscheint, war der Out-of-Memory-Killer des Kernels aktiv. Wählen Sie daher einen kleineren Tag aus der obigen Tabelle.

Ein festgelegtes Image aktualisieren

Durch das Festlegen einer Version bestimmen Sie selbst, wann Updates erfolgen. Bearbeiten Sie Image= in ollama.container, und laden Sie die Konfiguration anschließend neu und starten Sie den Dienst neu:

systemctl --user daemon-reload
systemctl --user restart ollama.service
podman exec ollama ollama --version

Die Modelle liegen im Bind-Mount und bleiben beim Image-Wechsel unverändert erhalten. AutoUpdate=registry im Abschnitt [Container] ist für den Betrieb mit einem veränderlichen Tag vorgesehen. Neben einem festen Versionstag hat es keinen Nutzen, da sich der Inhalt dieses Tags nicht ändert. Sichern Sie /home/ollama/ollama-data/models/manifests und die Datei .container. Die Blobs können Sie auslassen: Sie sind groß, und ollama pull lädt sie auf einem neuen System erneut herunter.

FAQ

Warum wird mein rootless Podman-Container beendet, wenn ich mich abmelde?

Die systemd-Instanz eines Benutzers und sein Verzeichnis /run/user/<uid> werden beendet, sobald die letzte Sitzung dieses Benutzers endet. Damit werden auch alle rootless Container beendet. Führen Sie sudo loginctl enable-linger ollama aus und prüfen Sie, ob loginctl show-user ollama --property=Linger den Wert Linger=yes ausgibt. Aktivieren Sie Lingering, bevor Sie die Quadlet-Unit erstellen. Das von der Unit benötigte Laufzeitverzeichnis existiert erst, wenn Lingering aktiviert ist.

Benötige ich SELinux-Labels für das Ollama-Modellverzeichnis?

Unter Fedora, RHEL, Rocky und AlmaLinux ist das erforderlich, wenn Sie ein Verzeichnis des Hosts per Bind-Mount einbinden. Der Container läuft in der Domäne container_t. Ein Verzeichnis im Home-Verzeichnis ist jedoch mit user_home_t gekennzeichnet. Dadurch wird der Schreibzugriff verweigert und Ollama beendet sich. Ergänzen Sie :Z in der Zeile Volume= und verwenden Sie dafür ein eigenes Unterverzeichnis. Die Umkennzeichnung wird rekursiv durchgeführt. Wenn Sie :Z auf ein gesamtes Home-Verzeichnis setzen, funktioniert der Zugriff dieses Benutzers auf SSH-Schlüssel nicht mehr. Named Volumes erhalten von Podman die korrekten Labels und benötigen keine zusätzlichen Einstellungen.

Wie viel Speicherplatz benötigt ein Ollama-Modell?

Orientieren Sie sich zunächst an der veröffentlichten Downloadgröße auf ollama.com/library. Sie reicht von 3.3 GB für gemma3:4b bis zu 19 GB für qwen3:30b. Rechnen Sie zusätzlich das Podman-Image ein. Lassen Sie außerdem Speicherplatz frei, weil ein zweites Modell das erste nicht vom Datenträger entfernt. Prüfen Sie df -h /home vor dem Abruf und du -sh ~/ollama-data/models danach. Planen Sie den RAM auf die gleiche Weise: Ein geladenes Modell benötigt ungefähr seine Dateigröße im Arbeitsspeicher, zusätzlich zum Kontextfenster.

Ist es sicher, Port 11434 auf einem VPS zu veröffentlichen?

Nein. Ollama wird ohne Authentifizierung ausgeliefert. Jeder, der den Port erreicht, kann Ihre Modelle auflisten, löschen und neue Modelle auf Ihren Datenträger herunterladen. Außerdem kann er Inferenz auf Kosten Ihrer CPU und Ihres verfügbaren Bandbreitenkontingents ausführen. Unverschlüsseltes HTTP über das Internet überträgt zudem jeden Prompt und jede Vervollständigung im Klartext. Binden Sie die Host-Seite mit PublishPort=127.0.0.1:11434:11434 an 127.0.0.1, prüfen Sie dies mit ss -ltnp | grep 11434 und greifen Sie über einen SSH-Tunnel oder einen Reverse Proxy mit Passwortschutz darauf zu.