OpenClaw mit Ollama: lokale Modelle einrichten, Limits prüfen, Stalls vermeiden
Wie du Ollama lokal in OpenClaw einrichtest, Modellrouten prüfst und langsame oder instabile Läufe systematisch eingrenzt.
Ollama bringt Modelle auf den eigenen Rechner, OpenClaw verbindet sie mit deinen Chats, Tools und Automationen. Das kann externe Inferenzkosten vermeiden und hält die Modellanfrage bei einem lokalen Modell auf deinem System. Kontextgröße, Tool-Verhalten, verfügbarer Speicher und die vergebenen Rechte bleiben trotzdem entscheidend.
Dieser Guide behandelt ausschließlich lokale Modelle. OpenClaw nutzt dafür den Provider ollama und dessen native Schnittstelle. Die übliche lokale Basis-URL lautet:
http://127.0.0.1:11434
Hänge kein /v1 an. OpenClaw spricht mit Ollama über die native API, insbesondere /api/chat, und nicht über den OpenAI-kompatiblen /v1-Pfad. Laut aktueller OpenClaw-Dokumentation kann /v1 das Tool-Calling beschädigen und rohe Tool-Call-Daten als Text ausgeben.
Wann ein lokales Modell passt
Ein lokales Modell eignet sich für überschaubare Aufgaben, deren Modellanfrage auf deinem Rechner bleiben soll: etwa Entwürfe, Klassifikation oder klar begrenzte Arbeit mit vorhandenen Dateien. Teste vor dem produktiven Einsatz deinen tatsächlichen Prompt, die vorgesehenen Tools und einen realistischen Kontext auf deiner Hardware.
Ein technisch erfolgreicher Lauf ist noch kein Qualitäts- oder Sicherheitsnachweis. Das Modell kann Tool-Calls übersehen, falsche Argumente erzeugen oder Anweisungen aus nicht vertrauenswürdigen Inhalten schlecht einordnen.
OpenClaw unterstützt über Ollama unterschiedliche Routen:
ollamaverbindet OpenClaw mit einem erreichbaren Ollama-Host. Dieser kann lokale Modelle und bei entsprechender Anmeldung auch Ollama-Cloud-Modelle bereitstellen.ollama-cloudhält den direkten Zugriff auf Ollama Cloud von der lokalen Providerroute getrennt.- Für den hier beschriebenen lokalen Betrieb zeigt
ollamaauf einen Ollama-Dienst auf demselben Rechner oder in einem privaten Netz.
Die folgenden Schritte verwenden http://127.0.0.1:11434 und damit einen Dienst auf demselben Rechner.
Voraussetzungen prüfen
Du brauchst eine funktionierende OpenClaw-Installation, einen laufenden Ollama-Dienst und mindestens ein lokal geladenes Modell. Installiere Ollama über den offiziellen Download für dein Betriebssystem und wähle ein Modell aus der Ollama Library.
ollama pull <modellname>
ollama list
Ersetze <modellname> in allen folgenden Befehlen durch denselben Modellnamen. Wähle das Modell nicht allein nach seiner Parameterzahl aus. Relevant sind außerdem Tool-Unterstützung, Kontextfenster, Quantisierung und der Speicherbedarf auf deinem Rechner.
ollama list muss das geladene Modell anzeigen. Fehlt es dort, liegt der Fehler noch vor OpenClaw.
Prüfe anschließend, ob die lokale API erreichbar ist:
curl --fail --show-error http://127.0.0.1:11434/api/tags
Erwartetes Ergebnis ist ein JSON-Dokument mit einer Modellliste. Ein Verbindungsfehler bedeutet, dass der Ollama-Dienst nicht erreichbar ist. Starte ihn über die für dein Betriebssystem vorgesehene Methode und prüfe außerdem, ob ein anderer Prozess Port 11434 belegt.
Ollama in OpenClaw einrichten
Öffne bei einer bestehenden OpenClaw-Installation den Modellbereich:
openclaw configure --section model
Für eine neue Installation führt auch der vollständige Onboarding-Flow durch die Modellauswahl:
openclaw onboard
Beide Befehle benötigen ein interaktives Terminal. Wähle die lokale Ollama-Einrichtung und verwende diese Basis-URL:
http://127.0.0.1:11434
Der Modellbereich aktualisiert die Provider- und Modellauswahl. Er übernimmt dabei nicht automatisch die Rolle eines vollständigen Laufzeittests. Prüfe die gespeicherte Route deshalb anschließend mit den CLI-Befehlen im nächsten Abschnitt.
Wenn du die Konfigurationsdatei gezielt lesen oder pflegen willst, erklärt Gateway-Konfiguration: openclaw.json verständlich erklärt die Grundlagen.
Modellroute prüfen
Lass dir zunächst die lokalen Modelle des Ollama-Providers anzeigen:
openclaw models list --provider ollama --local
Das gewünschte Modell muss in der Ausgabe erscheinen. Prüfe danach die aufgelöste Standard- und Fallback-Konfiguration:
openclaw models status
Ein lokaler Model-Ref hat üblicherweise dieses Format:
ollama/<modellname>
Notiere vor einer Änderung das bisherige Standardmodell aus openclaw models status. Der folgende Befehl ändert die Standardroute und kann damit auch andere nachfolgende Läufe betreffen:
openclaw models set ollama/<modellname>
openclaw models status
Erwartetes Ergebnis: openclaw models status zeigt ollama/<modellname> als primäre Route. Erscheint das Modell nicht in der lokalen Providerliste, prüfe zuerst ollama list, danach /api/tags und zuletzt die Provider-Einrichtung. Wechsle nicht auf Verdacht den Modellnamen, solange unklar ist, ob OpenClaw den Ollama-Dienst erreicht.
Inferenz und Agentenlauf getrennt testen
Ein Agentenlauf umfasst mehr als Modellinferenz. Workspace-Kontext, Tools, Berechtigungen und Laufzeitkonfiguration können das Ergebnis beeinflussen. Prüfe deshalb zuerst Ollamas native Chat-Inferenz direkt:
curl --fail --show-error http://127.0.0.1:11434/api/chat \
-H 'Content-Type: application/json' \
-d '{"model":"<modellname>","messages":[{"role":"user","content":"Antworte nur mit OK."}],"stream":false}'
Erwartetes Ergebnis ist ein JSON-Dokument mit einer Assistant-Nachricht. Deren Inhalt sollte OK oder eine erkennbare Antwort auf den Testprompt enthalten. Scheitert bereits dieser Aufruf, liegt die Ursache bei Ollama, dem Modellnamen oder den verfügbaren Ressourcen und noch nicht beim OpenClaw-Agentenlauf.
Prüfe für den zweiten Test zunächst die Optionen deiner installierten OpenClaw-Version:
openclaw agent exec --help
Die aktuelle Dokumentation beschreibt openclaw agent exec als isolierten eingebetteten Agentenlauf ohne Gateway-Verbindung. Er überspringt die Workspace-Bootstrap-Dateien und beschränkt laut Dokumentation Dateisystem-Tools auf das übergebene --cwd. Das ist eine reale, aber nur teilweise technische Einschränkung: Sie begrenzt den Dateizugriff, sperrt aber nicht automatisch andere konfigurierte Tools wie Netzwerk- oder Shell-Zugriffe. Die Anweisung “Verwende keine Tools” im folgenden Testprompt ist keine technische Grenze. Ein zu testendes lokales Modell kann sie ignorieren oder falsch umsetzen.
Führe diesen Test deshalb nur in einer isolierten, wegwerfbaren Umgebung aus, etwa einer Wegwerf-VM, einem Container oder einem separaten Benutzerkonto ohne Zugriff auf produktive Daten oder Zugangsdaten. Lege zusätzlich ein leeres temporäres Arbeitsverzeichnis an, damit der Zugriff durch Dateisystem-Tools auf dieses Verzeichnis begrenzt bleibt:
TEST_DIR="$(mktemp -d)"
openclaw agent exec --json --cwd "$TEST_DIR" "Antworte nur mit: OK. Verwende keine Tools."
Erwartetes Ergebnis ist ein erfolgreich beendeter JSON-Lauf mit der Antwort OK. Das bestätigt, dass Inferenz und Agentenlaufzeit zusammenspielen. Es bestätigt nicht, dass das Modell Tool-Anweisungen zuverlässig respektiert. Taucht in der JSON-Ausgabe dennoch eine Tool-Aktion auf, hat das Modell die Anweisung missachtet; werte das als Sicherheitsbefund für dieses Modell. Schlägt der Lauf komplett fehl, obwohl der direkte /api/chat-Aufruf funktioniert, prüfe openclaw models status, die Agentenlaufzeit und die ausgegebenen Fehlerdetails.
Räume das leere Testverzeichnis anschließend auf:
rmdir "$TEST_DIR"
Schlägt rmdir fehl, hat der Lauf Dateien erzeugt. Prüfe deren Inhalt, bevor du sie entfernst. Das ist zugleich ein Hinweis darauf, dass der Agent die Anweisung im Testprompt nicht eingehalten hat.
Erst danach folgt ein Test mit realistischem Kontext und genau den Tools, die später verwendet werden. So lässt sich unterscheiden, ob der Engpass beim Modell, beim Kontextumfang oder beim Tool-Handling liegt.
Wenn Läufe langsam werden oder hängen bleiben
Arbeite die Diagnose in dieser Reihenfolge ab:
ollama listbestätigt, dass das Modell lokal vorhanden ist./api/tagsbestätigt, dass der Ollama-Dienst erreichbar ist./api/chatprüft die native Modellinferenz ohne OpenClaw-Agentenlauf.openclaw models list --provider ollama --localbestätigt die Erkennung durch OpenClaw.openclaw models statuszeigt, welche primäre Route und welche Fallbacks tatsächlich aufgelöst werden.- Der kleine
agent exec-Test in der isolierten Umgebung prüft OpenClaws Agentenlauf ohne Workspace-Bootstrap. - Ein realistischer Lauf ergänzt den späteren Kontext und die benötigten Tool-Schemas.
Ist bereits /api/chat langsam, prüfe Modellgröße, freien RAM beziehungsweise VRAM und parallele Last. Antwortet /api/chat schnell, während agent exec stockt, liegt die Ursache eher in OpenClaws Laufzeitkonfiguration. Wird erst der realistische Test langsam, reduziere den Kontext, die Zahl der Tools oder die Größe ihrer Schemas und wiederhole denselben Auftrag.
Ein Neustart kann einen festgefahrenen Ollama-Dienst wieder erreichbar machen. Er ersetzt aber keinen Ressourcen- oder Kontexttest. Scheitert derselbe realistische Auftrag wiederholt an derselben Grenze, teile den Workflow auf oder wähle vor dem Start ein geeigneteres Modell.
Fallbacks korrekt einsetzen
OpenClaw versucht zuerst das primäre Modell und arbeitet danach die konfigurierten Fallbacks ab. Ein Fallback dient der technischen Wiederherstellung bei geeigneten Fehlern. Er wird nicht allein deshalb aktiv, weil ein Modell erfolgreich antwortet, die Antwort aber inhaltlich schwach ist.
Wähle für einen anspruchsvollen Auftrag deshalb vor dem Lauf eine passende Modellroute. Nutze Fallbacks zusätzlich für technische Ausfälle und kontrolliere ihre Reihenfolge mit:
openclaw models status
Eine ausführlichere Einordnung von Provider-Routen, Modellwahl und Fallbacks findest du in OpenClaw Tutorial Teil 3: Modelle konfigurieren.
Vorheriges Standardmodell wiederherstellen
Wenn Ollama nur für diesen Test als Standardmodell gesetzt wurde, stelle anschließend die zuvor notierte Route wieder her:
openclaw models set <vorheriger-model-ref>
openclaw models status
Die Statusausgabe muss wieder den vorherigen Model-Ref als primäre Route zeigen. Dieser Schritt ist nicht nötig, wenn Ollama dauerhaft dein Standardmodell bleiben soll.
Sicherheit: Lokal beschreibt nur den Datenpfad
Ein lokales Modell kann verhindern, dass die Modellanfrage an einen externen Modellanbieter gesendet wird. Daraus folgt nicht, dass der gesamte Agentenlauf lokal oder sicher ist: Tools können weiterhin Netzwerkzugriffe ausführen, Dateien verändern oder externe Dienste ansprechen.
- Binde Ollama nach Möglichkeit nur an
127.0.0.1. - Schütze einen Ollama-Host im privaten Netz durch VPN oder restriktive Firewall-Regeln. Stelle den nativen Endpoint nicht offen ins Internet.
- Gib einem Testagenten nur die Tools und Rechte, die der Test benötigt, und teste ein neues oder ungeprüftes Modell zuerst in einer isolierten, wegwerfbaren Umgebung statt auf einem produktiven System.
- Behandle Web-Inhalte, Dokumente und eingehende Nachrichten weiterhin als nicht vertrauenswürdig. Kleinere oder stark quantisierte Modelle können eingebettete Anweisungen schlechter abgrenzen.
Für Loopback-, private Netzwerk- und andere von OpenClaw als lokal erkannte Ollama-Hosts ist laut Provider-Dokumentation kein echter Bearer-Token nötig. Öffentliche Remote-Hosts und https://ollama.com benötigen dagegen echte Zugangsdaten. Für direkten Cloud-Zugriff ist der getrennte Provider ollama-cloud vorgesehen.
Wie du Tool-Ausführung und Freigaben begrenzt, zeigt OpenClaw Approvals erklärt: /approve, Sandboxing und Host-Exec ohne Blindflug.
Wichtigste Punkte
Die belastbare Reihenfolge lautet: Ollama erreichbar machen, das Modell direkt über /api/chat prüfen, seine OpenClaw-Route verifizieren und erst danach einen Agentenlauf in einer isolierten Umgebung starten.
Ein kurzer Antworttest reicht nicht für eine Produktionsentscheidung. Wiederhole deinen späteren Workflow mit realistischem Kontext und den vorgesehenen Tools. Wähle für anspruchsvolle Aufgaben bewusst eine passende Modellroute; Fallbacks helfen bei technischen Fehlern, nicht bei einer inhaltlich schwachen erfolgreichen Antwort.
Weiterführende Links
- OpenClaw: Ollama Provider
- OpenClaw: lokale Modelle
- OpenClaw: Modellkonfiguration
- OpenClaw:
openclaw models - OpenClaw: Agent CLI
- OpenClaw: Modell-Failover
- Ollama herunterladen
- Ollama Library
Dieser Guide ist Teil der OpenClaw-Praxis-Serie (Teil 4 von 6).
Transparenz
agentenlog.de nutzt KI-Assistenz für Recherche, Struktur und Entwurf. Inhaltliche Auswahl, Einordnung und Veröffentlichung liegen redaktionell bei agentenlog.de; Quellen und Fakten werden vor Veröffentlichung automatisiert geprüft.
Quellen
- https://docs.openclaw.ai/providers/ollama
- https://docs.openclaw.ai/cli/configure.md
- https://docs.openclaw.ai/cli/models.md
- https://docs.openclaw.ai/cli/agent
- https://docs.openclaw.ai/concepts/model-failover
- https://docs.openclaw.ai/gateway/local-models
- https://ollama.com/download
- https://ollama.com/library
Serie: OpenClaw Praxis-Serie
Das könnte dich auch interessieren
OpenClaw sicher updaten: Backup, Verify und Recovery ohne Blindflug
Wie du OpenClaw vor Updates sauber sicherst, Update-Pfade prüfst und typische Recovery-Fallen rund um Config, Workspaces und Plugins vermeidest.
OpenClaw Remote Nodes sicher einrichten: Tailscale, Pairing und Fehlersuche
Wie du OpenClaw Remote Nodes über Gateway, Tailscale oder SSH sauber betreibst: mit Pairing, Diagnoseleiter, Fehlerbildern und Sicherheitsgrenzen.
OpenClaw Approvals erklärt: /approve, Sandboxing und Host-Exec ohne Blindflug
Wenn OpenClaw plötzlich /approve verlangt oder Host-Exec trotz Freigaben blockiert: So prüfst du Sandbox, Policy und sichere Recovery ohne YOLO-Modus.