Ollama API unter Ubuntu 24.04: curl /api/tags, /api/chat und qwen3:4b Testanleitung

Diese Anleitung konzentriert sich auf die HTTP-API des bereits funktionierenden Ollama- und qwen3:4b-Stacks. Host-Anwendungen verwenden http://127.0.0.1:11434, Dienste im gemeinsamen Docker-Netzwerk eka-ai können http://ollama:11434 verwenden.

localhost in einem Container bezeichnet den Container selbst. Separate n8n- oder Open-WebUI-Container erreichen Ollama deshalb über den Docker-DNS-Namen ollama, während der Host-Port nur an Loopback gebunden bleibt.

Host API:   http://127.0.0.1:11434
Docker API: http://ollama:11434

Vor dem Modelldownload lieferte die reale /api/tags-Anfrage HTTP 200 mit einem leeren models-Array. Damit war die HTTP-Runtime gesund, obwohl noch kein Modell installiert war.

Beim Troubleshooting diesen Test vor Modellproblemen ausführen. Antwortet der Endpunkt nicht, zuerst Container, Port-Binding und Ollama-Logs prüfen.

curl -sS -w "\nHTTP %{http_code}\n" http://127.0.0.1:11434/api/tags

docker logs --tail 80 ollama

Nach erfolgreichem API-Test wurde qwen3:4b im Container geladen. Die reale Modellliste zeigte ungefähr 2,5 GB.

Die aufgezeichneten API-Metadaten meldeten parameter_size 4.0B, Q4_K_M-Quantisierung sowie completion-, tools- und thinking-Fähigkeiten.

docker exec ollama ollama pull qwen3:4b

docker exec ollama ollama list

Die CLI-Liste ist für Menschen praktisch, /api/tags liefert dagegen eine JSON-Modellliste für Integrationen. Im realen Test erschien qwen3:4b dort mit Name, Größe und Modelldetails.

Wenn Open WebUI oder n8n keine Modelle sieht, denselben Endpunkt vom Host und bei Bedarf aus dem jeweiligen Container aufrufen, um Ollama- von Docker-Netzwerkproblemen zu trennen.

curl -sS http://127.0.0.1:11434/api/tags

docker exec ollama ollama list

Ein Modell in der Liste beweist noch keine funktionierende Inferenz. Deshalb wurde eine echte Benutzeranfrage an /api/chat gesendet und mit stream:false eine einzelne JSON-Antwort angefordert.

Der reale assistant-Inhalt lautete EKA-OLLAMA-TEST-BASARILI und die Anfrage endete mit done:true. Der CPU-Test dauerte ungefähr 18 Sekunden.

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

Für den End-to-End-Test wurden model=qwen3:4b, message.role=assistant, der erwartete message.content und done:true kontrolliert.

Die aufgezeichnete Qwen3-Antwort enthielt auch ein thinking-Feld. Wenn die Anwendung nur die sichtbare Benutzerantwort benötigt, ist message.content das sauberere Ausgabefeld.

Wichtige Felder:
model
message.role
message.content
done
done_reason
total_duration

Nach der echten Chat-Anfrage zeigte ollama ps qwen3:4b auf der CPU geladen. Zum aufgenommenen Zeitpunkt waren Context 4096 und Processor 100% CPU sichtbar.

Docker stats zeigte ungefähr 3.059 GiB für den Ollama-Container. Diese Werte beschreiben nur den Testmoment und variieren mit Prompt, Kontext, Modell und Parallelität.

docker exec ollama ollama ps

docker stats --no-stream ollama

127.0.0.1 ist auf dem Host korrekt, localhost in einem anderen Container zeigt aber nicht auf Ollama. Im gemeinsamen benutzerdefinierten Netzwerk löst Docker den Hostnamen ollama auf.

Unsere finale Testzusammenfassung bestätigte http://127.0.0.1:11434 für den Host und http://ollama:11434 innerhalb von Docker. Dieses Muster wurde später für Open WebUI und n8n verwendet.

docker network inspect eka-ai

docker exec n8n node -e "fetch('http://ollama:11434/api/tags').then(r=>r.text()).then(console.log)"

Die reale Bereitstellung veröffentlichte Ollama nicht direkt im Internet, sondern verwendete 127.0.0.1:11434:11434. Die ss-Ausgabe bestätigte das Loopback-Binding.

Für entfernten Zugriff TLS, Authentifizierung, Reverse Proxy, VPN oder privates Netz planen statt einfach 0.0.0.0:11434 zu öffnen.

ss -lntp | grep ':11434'

docker ps --filter name='^/ollama$'

Kann curl keine Verbindung aufbauen, zuerst Container und 127.0.0.1:11434-Binding prüfen. Liefert /api/tags HTTP 200, aber models ist leer, läuft die Runtime, möglicherweise ohne installiertes Modell.

Ist das Modell vorhanden, aber Chat schlägt fehl, docker logs ollama prüfen. Ist Chat nur langsam, mit ollama ps und docker stats CPU/RAM kontrollieren; CPU-only-Inferenz kann zusätzliche Ladezeit haben.

docker ps --filter name='^/ollama$'

curl -sS http://127.0.0.1:11434/api/tags

docker logs --tail 150 ollama

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

Modellliste und echte Chat-Anfrage sind die zwei schnellsten Integrationstests. Mit laufendem Modell, Containerlog und Socket-Prüfung lässt sich die fehlerhafte Schicht schnell eingrenzen.

Die folgenden Befehle fassen das Host- und Docker-Zugriffsmuster unseres realen Ubuntu-24.04-Tests zusammen.

curl -sS http://127.0.0.1:11434/api/tags

curl -sS http://127.0.0.1:11434/api/chat -H 'Content-Type: application/json' -d '{"model":"qwen3:4b","messages":[{"role":"user","content":"Hallo"}],"stream":false}'

docker exec ollama ollama ps

ss -lntp | grep ':11434'

Das Volume ollama_data hält Modelldateien unabhängig vom Container persistent. Vor Image-Updates oder Container-Neuerstellung eine Volume-Backup- und VPS-Snapshot-Strategie definieren.

Nach Reboot oder Upgrade Container, /api/tags, echte /api/chat-Anfrage und 11434-Binding erneut prüfen. So wird die reale Inferenzkette statt nur eines laufenden Prozesses validiert.

docker ps --filter name='^/ollama$'

curl -sS http://127.0.0.1:11434/api/tags

docker exec ollama ollama list

ss -lntp | grep ':11434'