Ollama + Qwen3 4B + Open WebUI unter Ubuntu 24.04 installieren: Vollständiger bebilderter Local-AI-Ratgeber

Dieser Ratgeber dokumentiert den lokalen KI-Stack, den wir auf einem echten Ubuntu-24.04.4-LTS-VPS aufgebaut haben. Ollama übernimmt die Modell-Inferenz, qwen3:4b ist das lokale Sprachmodell und Open WebUI stellt die Browseroberfläche bereit; beide Anwendungscontainer teilen sich ein Docker-Netzwerk.

Im finalen Aufbau ist die Ollama-API an 127.0.0.1:11434 und Open WebUI an 127.0.0.1:3000 gebunden. Nginx auf HTTPS 443 ist der einzige öffentliche Web-Einstieg, während Open WebUI Ollama privat über http://ollama:11434 im Docker-Netzwerk eka-ai erreicht.

Internet :443
     ↓
Nginx + Let's Encrypt
     ↓
127.0.0.1:3000 → Open WebUI :8080
     ↓ eka-ai Docker-Netzwerk
ollama:11434 → qwen3:4b

Der Test-VPS lief mit Ubuntu 24.04.4 LTS, 8 vCPUs und rund 31 GiB RAM. Als Prozessor wurde eine AMD-Ryzen-9-7950X-Basis angezeigt. Weder NVIDIA-Treiber noch ein nutzbares ROCm-Compute-Gerät waren vorhanden, daher wurde der erste Aufbau im CPU-Modus verifiziert.

Lokale Modelle benötigen RAM und Speicherplatz. Planen Sie nicht nur nach Parameterzahl, sondern auch nach Quantisierung, Kontextfenster, gleichzeitigen Benutzern und Betriebssystemreserve.

cat /etc/os-release | grep -E 'PRETTY_NAME|VERSION_ID|VERSION_CODENAME'
uname -r
free -h
df -h /

lscpu | grep -E 'Architecture|CPU\(s\)|Model name'
nvidia-smi 2>/dev/null || true
ls -la /dev/dri 2>/dev/null || true

Da Ollama und Open WebUI in Docker laufen, wurden zuerst Docker-Daemon und Compose-Plugin geprüft. Im realen Test liefen Docker Engine 29.7.2 und Docker Compose v5.4.0.

Falls Docker noch fehlt, führen Sie zuerst den Ubuntu-24.04-Docker-und-Portainer-Ratgeber mit dem offiziellen Docker-Repository aus.

docker --version
docker compose version
systemctl is-active docker

Wir erstellten das Bridge-Netzwerk eka-ai, damit Open WebUI den Ollama-Container über seinen Namen auflösen kann. Das Named Volume ollama_data speichert die heruntergeladenen Modelle unabhängig vom Container-Lebenszyklus.

Container können bei Updates neu erstellt werden, während die Modelldaten im Volume erhalten bleiben. Löschen Sie das Volume nicht ohne verifiziertes Backup.

docker network inspect eka-ai >/dev/null 2>&1 || docker network create eka-ai
docker volume create ollama_data

docker network inspect eka-ai --format 'Netz={{.Name}} Driver={{.Driver}} Scope={{.Scope}}'
docker volume inspect ollama_data

Im Test wurde kein GPU-Passthrough erkannt, daher lief das offizielle Ollama-Docker-Image im CPU-Modus. Host-Port 11434 wurde an 127.0.0.1 statt 0.0.0.0 gebunden, sodass die Ollama-API nicht direkt im Internet veröffentlicht wurde.

Der Container trat zugleich dem Netzwerk eka-ai bei. Open WebUI kann Ollama damit als ollama:11434 erreichen, ohne den privaten Dienst öffentlich zu machen.

docker pull ollama/ollama:latest

docker run -d --name ollama --restart unless-stopped --network eka-ai -p 127.0.0.1:11434:11434 -v ollama_data:/root/.ollama ollama/ollama:latest

docker ps --filter name='^/ollama$'
curl -sS http://127.0.0.1:11434/api/tags

Nachdem Ollama erreichbar war, luden wir qwen3:4b in den Container. Die reale API-Ausgabe zeigte ungefähr 2,5 GB Speicherbedarf, parameter_size 4.0B und die Quantisierung Q4_K_M.

Die Downloadzeit hängt von Netzwerk und Datenträger ab. Warten Sie den Pull vollständig ab, bevor Sie das Modell in Open WebUI erwarten.

docker exec ollama ollama pull qwen3:4b

docker exec ollama ollama list
curl -sS http://127.0.0.1:11434/api/tags

Ein Modell in der Liste beweist noch keine funktionierende Inferenz. Deshalb sendeten wir eine echte Anfrage an /api/chat und qwen3:4b lieferte die erwartete Testphrase zurück.

Im CPU-Test belegte Ollama bei geladenem Modell ungefähr 3 GiB RAM; ollama ps zeigte 100% CPU. Diese Werte gelten nur für den aufgenommenen Testzeitpunkt und ändern sich mit Kontext und Parallelität.

curl -sS http://127.0.0.1:11434/api/chat -d '{"model":"qwen3:4b","messages":[{"role":"user","content":"Schreibe nur EKA-OLLAMA-TEST-BASARILI."}],"stream":false}'

docker exec ollama ollama ps
docker stats --no-stream ollama

Der finale Aufbau verwendete vom Host http://127.0.0.1:11434 und im Docker-Netzwerk http://ollama:11434. Port 11434 lauschte nur auf Loopback.

Damit kann Open WebUI Ollama privat erreichen, während Internet-Clients keinen direkten Zugriff auf die rohe Ollama-API erhalten.

ss -lntp | grep ':11434'

docker network inspect eka-ai --format '{{range .Containers}}{{.Name}} {{.IPv4Address}}{{println}}{{end}}'

docker exec ollama ollama list

Wir richteten openwebui.ekasunucu.com auf den Test-VPS und prüften die DNS-Auflösung. Für Anwendungsdaten wurde das Named Volume openwebui_data erstellt.

Zusätzlich wurde ein WEBUI_SECRET_KEY erzeugt. In Produktion sollte dieser Wert sicher in einer geschützten Datei oder einem Secret Manager gespeichert und bei Container-Neuerstellung wiederverwendet werden.

dig +short openwebui.ekasunucu.com @1.1.1.1
dig +short openwebui.ekasunucu.com @8.8.8.8

docker volume create openwebui_data

umask 077
[ -s /root/.openwebui_secret_key ] || openssl rand -hex 32 > /root/.openwebui_secret_key
WEBUI_SECRET_KEY="$(cat /root/.openwebui_secret_key)"

Im realen Test kam ghcr.io/open-webui/open-webui:main zum Einsatz. Host-Port 3000 wurde auf 127.0.0.1 begrenzt, intern blieb Port 8080 und openwebui_data wurde nach /app/backend/data gemountet.

Da Ollama dasselbe Netzwerk eka-ai nutzt, setzten wir OLLAMA_BASE_URL auf http://ollama:11434. Docker-DNS löst den Containernamen auf, ohne Ollama öffentlich zu veröffentlichen.

docker pull ghcr.io/open-webui/open-webui:main

WEBUI_SECRET_KEY="$(cat /root/.openwebui_secret_key)"
docker run -d --name open-webui --restart unless-stopped --network eka-ai -p 127.0.0.1:3000:8080 -e OLLAMA_BASE_URL=http://ollama:11434 -e WEBUI_SECRET_KEY="$WEBUI_SECRET_KEY" -v openwebui_data:/app/backend/data ghcr.io/open-webui/open-webui:main

docker ps --filter name='^/open-webui$'

Beim ersten Start kann Open WebUI Datenbankmigrationen ausführen und lokale Hilfsmodelle vorbereiten. In unserem Test erschienen zunächst connection reset und HTTP 000, obwohl der Container-Prozess bereits lief.

Nach Abschluss der Migrationen und dem Laden des Embedding-Modells lieferte /health HTTP 200 mit {"status":true}. Während dieser Initialisierung ist Log-Beobachtung sinnvoller als wiederholtes Löschen und Neuerstellen des Containers.

docker logs -f --tail 150 open-webui

until [ "$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:3000/health || true)" = "200" ]; do sleep 5; done
curl -sS http://127.0.0.1:3000/health

docker inspect open-webui --format 'Status={{.State.Status}} Health={{if .State.Health}}{{.State.Health.Status}}{{else}}none{{end}}'

Ein erfolgreicher Ollama-Test auf dem Host reicht nicht; auch der Open-WebUI-Container muss die API erreichen. Im gemeinsamen Docker-Netzwerk lautet das Ziel ollama:11434.

Open WebUI bezieht die Modellliste über diese Verbindung. Fehlt qwen3:4b, prüfen Sie zuerst /api/tags in Ollama, dann die Connection-Einstellung und die Mitgliedschaft beider Container in eka-ai.

docker exec open-webui python -c "import urllib.request; print(urllib.request.urlopen('http://ollama:11434/api/tags').read().decode())"

docker network inspect eka-ai --format '{{range .Containers}}{{.Name}} {{.IPv4Address}}{{println}}{{end}}'

Statt den Open-WebUI-Hostport ins Internet zu veröffentlichen, wurde Nginx zum öffentlichen Einstieg. Nginx lauscht auf 80/443, leitet an 127.0.0.1:3000 weiter und erhält die WebSocket-Upgrade-Header.

Verwenden Sie den korrekten server_name und führen Sie vor jedem Reload nginx -t aus.

cat >/etc/nginx/sites-available/openwebui.ekasunucu.com <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name openwebui.ekasunucu.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 3600;
    }
}
EOF
ln -sfn /etc/nginx/sites-available/openwebui.ekasunucu.com /etc/nginx/sites-enabled/openwebui.ekasunucu.com
nginx -t
systemctl reload nginx

Nachdem der Nginx-Reverse-Proxy bereit war, stellte Certbot erfolgreich ein Let's-Encrypt-Zertifikat für openwebui.ekasunucu.com aus und integrierte es in Nginx.

Sowohl Origin-HTTPS als auch die öffentliche Domain lieferten im finalen Test HTTP 200. Benutzer greifen damit über den sicheren Hostnamen statt über einen Docker-Port zu.

certbot --nginx -d openwebui.ekasunucu.com

curl -I https://openwebui.ekasunucu.com

certbot certificates

Am Ende lauschte Ollama auf 127.0.0.1:11434 und Open WebUI auf 127.0.0.1:3000; Nginx war öffentlich auf 80 und 443 erreichbar. Dadurch wird die rohe Ollama-API nicht direkt ins Internet gestellt.

Docker-Portpublishing kann Firewall-Regeln beeinflussen. Prüfen Sie daher tatsächliche Sockets mit ss und veröffentlichte Containerports zusätzlich mit docker ps.

ss -lntp | grep -E ':80 |:443 |:3000 |:11434' || true

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'

Wir führten certbot renew --dry-run aus, statt automatische Erneuerung nur anzunehmen. Die simulierten Renewals für Open WebUI und Portainer waren erfolgreich.

Im finalen Zustand war Open WebUI healthy, Ollama lief, die HTTPS-Domain antwortete mit 200 und systemctl --failed meldete keine fehlgeschlagenen Units.

certbot renew --dry-run

curl -sS -o /dev/null -w '%{http_code}\n' https://openwebui.ekasunucu.com

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'
systemctl --failed

Nach Abschluss der Infrastruktur öffneten wir https://openwebui.ekasunucu.com und erreichten die Open-WebUI-Willkommensseite. Über den Start-Button ging es zur Kontoeinrichtung.

Der Browser sollte direkt den Hostnamen verwenden. Öffentlicher Zugriff auf Port 3000 ist nicht erforderlich, da Nginx und TLS den Benutzerverkehr übernehmen.

Auf der ersten Registrierungsseite legten wir den Administrator mit Name, E-Mail und starkem Kennwort an. Das erste Konto erhält Zugriff auf die Administration.

Verwenden Sie in Produktion ein eindeutiges Kennwort und prüfen Sie die Registrierungs- und Freigaberichtlinie, bevor weitere Benutzer zugelassen werden.

Nach der Kontoeinrichtung stand qwen3:4b in der Modellauswahl von Open WebUI bereit. Damit war die Kette Browser → Open WebUI → Ollama → qwen3:4b vollständig funktionsfähig.

Die Inferenz läuft auf der Ollama-Seite des Servers; Open WebUI stellt Oberfläche, Benutzer- und Gesprächsebene bereit. Für größere Modelle oder mehr parallele Nutzer müssen CPU/RAM/GPU erneut dimensioniert werden.

Ollama-Modelldaten liegen in ollama_data, Open-WebUI-Anwendungsdaten in openwebui_data. VPS-Snapshot und Volume-Backups vor Updates erleichtern ein Rollback.

Der reale Test nutzte :main. Dokumentieren oder pinnen Sie für Produktion die Image-Version, sichern Sie Daten, erstellen Sie Container bewusst neu und prüfen Sie danach /health, Ollama /api/tags, HTTPS, lokale Port-Bindings und Autostart nach einem Reboot.

docker run --rm -v ollama_data:/quelle -v /root:/backup alpine sh -c 'tar czf /backup/ollama_data-$(date +%F).tar.gz -C /quelle .'

docker run --rm -v openwebui_data:/quelle -v /root:/backup alpine sh -c 'tar czf /backup/openwebui_data-$(date +%F).tar.gz -C /quelle .'

docker restart ollama open-webui
curl -sS http://127.0.0.1:3000/health
curl -sS http://127.0.0.1:11434/api/tags