In diesem realen Ubuntu-24.04.4-LTS-VPS-Test lief Ollama in Docker, qwen3:4b wurde mit ungefähr 2,5 GB geladen, ein echter /api/chat-Inferenztest durchgeführt und die Ollama-API nur an 127.0.0.1:11434 gebunden.
Ubuntu 24.04.4 LTS
↓ Docker / eka-ai
Ollama :11434
↓
qwen3:4b
↓
Echter /api/chat Test
↓
127.0.0.1 lokale APIDiese Anleitung dokumentiert eine reale Docker-basierte Ollama-Installation unter Ubuntu 24.04.4 LTS. Ziel ist, qwen3:4b vollständig auf dem VPS auszuführen und die API nicht direkt auf öffentlichen Interfaces bereitzustellen.
Im finalen Aufbau hängt Ollama im Docker-Netzwerk eka-ai, Modelle liegen dauerhaft im Named Volume ollama_data und die Host-API ist nur über 127.0.0.1:11434 erreichbar.
Ubuntu 24.04.4 LTS
↓
Docker / eka-ai
↓
Ollama :11434
↓
qwen3:4b
↓
127.0.0.1 lokale APIDer 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 || trueDa 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 dockerWir 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_datadocker network inspect eka-ai --format 'Netz={{.Name}} Driver={{.Driver}} Scope={{.Scope}}'
docker volume inspect ollama_dataIm 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:latestdocker run -d --name ollama --restart unless-stopped --network eka-ai -p 127.0.0.1:11434:11434 -v ollama_data:/root/.ollama ollama/ollama:latestdocker ps --filter name='^/ollama$'
curl -sS http://127.0.0.1:11434/api/tagsNachdem 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:4bdocker exec ollama ollama list
curl -sS http://127.0.0.1:11434/api/tagsEin 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 ollamaNach der echten Inferenz war qwen3:4b auf der CPU geladen und der Ollama-Container nutzte im Test ungefähr 3 GiB RAM. Der reale Verbrauch hängt von Modell, Kontext und Parallelität ab.
Der wichtigste Abschlusscheck ist, dass Port 11434 nur auf 127.0.0.1 lauscht und die Standard-Ollama-API damit nicht direkt auf öffentlichen Interfaces veröffentlicht wird.
docker exec ollama ollama ps
docker stats --no-stream ollamass -lntp | grep ':11434'
docker network inspect eka-ai --format '{{range .Containers}}Netz={{$.Name}} IP={{.IPv4Address}}{{end}}'Ja. Im realen Test lief Ollama unter Ubuntu 24.04.4 LTS mit dem Docker-Image ollama/ollama.
Nein. Der Test-VPS hatte kein Compute-GPU-Passthrough und qwen3:4b lief im CPU-Modus.
Die reale ollama-list-Ausgabe zeigte ungefähr 2,5 GB.
Die reale API-Metadaten meldeten parameter_size 4.0B und Q4_K_M-Quantisierung.
Der Standard-API-Port ist 11434. In diesem Setup wird er hostseitig nur an 127.0.0.1:11434 gebunden.
Besser sind ein privates Netz, ein authentifizierter Reverse Proxy oder eine andere Zugriffskontrolle.
Mit docker exec ollama ollama pull qwen3:4b im laufenden Container.
Mit docker exec ollama ollama list oder über http://127.0.0.1:11434/api/tags.
Ein POST-Request an /api/chat lieferte mit qwen3:4b den erwarteten Text EKA-OLLAMA-TEST-BASARILI.
Mit geladenem Modell nutzte der getestete Ollama-Container ungefähr 3,06 GiB RAM.
Ja, solange das Named Volume ollama_data erhalten bleibt.
Beide Container in dasselbe benutzerdefinierte Netzwerk hängen und http://ollama:11434 verwenden.
Ja, wenn genügend RAM, Datenträger und idealerweise eine geeignete GPU vorhanden sind.
Port-Bindings, Volume-Backups, Restart-Policy, Ressourcenverbrauch und API-Zugriffsregeln.
Qwen3, Ollama, Open WebUI, n8n und weitere Self-Hosted-AI-Dienste auf einem eigenen EKA-Sunucu-Linux-VPS betreiben.
Aktualisiert: 10.08.2026