Zum Inhalt springen
tutorials · 8 min Lesezeit

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.

openclaw ollama lokale-modelle tutorials

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:

  • ollama verbindet OpenClaw mit einem erreichbaren Ollama-Host. Dieser kann lokale Modelle und bei entsprechender Anmeldung auch Ollama-Cloud-Modelle bereitstellen.
  • ollama-cloud hält den direkten Zugriff auf Ollama Cloud von der lokalen Providerroute getrennt.
  • Für den hier beschriebenen lokalen Betrieb zeigt ollama auf 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:

  1. ollama list bestätigt, dass das Modell lokal vorhanden ist.
  2. /api/tags bestätigt, dass der Ollama-Dienst erreichbar ist.
  3. /api/chat prüft die native Modellinferenz ohne OpenClaw-Agentenlauf.
  4. openclaw models list --provider ollama --local bestätigt die Erkennung durch OpenClaw.
  5. openclaw models status zeigt, welche primäre Route und welche Fallbacks tatsächlich aufgelöst werden.
  6. Der kleine agent exec-Test in der isolierten Umgebung prüft OpenClaws Agentenlauf ohne Workspace-Bootstrap.
  7. 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.


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.