OpenClaw mit Ollama: lokale Modelle einrichten, Limits prüfen, Stalls vermeiden

Ollama bringt Modelle auf den eigenen Rechner, OpenClaw verbindet sie mit deinen Chats, Tools und Automationen. Das spart bei passenden Aufgaben externe Inferenzkosten und hält die Modellanfrage auf deinem System. Kontextgröße, Tool-Verhalten, Arbeitsspeicher und die vergebenen Rechte bleiben dabei entscheidend.

Dieser Guide behandelt den lokalen Betrieb. Dafür nutzt OpenClaw den Provider ollama mit der nativen Ollama-Schnittstelle. Die übliche lokale Basis-URL lautet:

http://127.0.0.1:11434

Hänge hier kein /v1 an. Das wäre ein OpenAI-kompatibler Pfad und nicht die für den OpenClaw-Ollama-Provider erwartete Basis-URL.

Wann ein lokales Modell passt

Ein lokales Modell ist sinnvoll für überschaubare Aufgaben, deren Datenpfad auf deinem Rechner bleiben soll, etwa Entwürfe, Klassifikation oder klar begrenzte Recherche im vorhandenen Workspace. Plane vor dem produktiven Einsatz einen echten Test mit deinem Prompt, deinen Tools und deinem verfügbaren Speicher ein.

Für lange Arbeitsverläufe, komplexe Tool-Auswahl oder weitreichende Aktionen ist ein lokales Modell keine Sicherheits- oder Qualitätsgarantie. Ein Modell kann technisch antworten und trotzdem Tool-Calls übersehen, falsche Argumente erzeugen oder Anweisungen aus untrusted Inhalt schlecht einordnen.

OpenClaw unterscheidet drei Ollama-Betriebsarten:

• ollama für lokale Modelle und, je nach Konfiguration, den kombinierten Zugriff auf lokale und Cloud-Modelle.
• ollama-cloud für Ollama Cloud ohne lokale Runtime.
• einen lokalen-only Betrieb, bei dem Ollama auf dem eigenen Rechner oder einem privaten Host läuft.

Die folgenden Schritte beziehen sich auf lokal-only.

Voraussetzungen prüfen

Du brauchst eine funktionierende OpenClaw-Installation, einen laufenden Ollama-Dienst und mindestens ein lokal verfügbares Modell. Installiere Ollama über den offiziellen Download für dein Betriebssystem. Anschließend ziehst du ein Modell aus der Ollama Library.

ollama pull <modellname>
ollama list

Ersetze <modellname> durch ein Modell, das für deinen Zweck geeignet ist. Prüfe Tool-Unterstützung, verfügbares Kontextfenster und den Speicherbedarf auf deiner Hardware. Die Parameterzahl allein reicht als Auswahlkriterium nicht aus.

ollama list muss das gezogene Modell anzeigen. Falls das nicht gelingt, liegt der Fehler noch vor OpenClaw.

Prüfe danach die lokale Runtime:

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

Erwartetes Ergebnis: JSON mit einer Modellliste. Kommt keine Antwort, starte Ollama über die für dein Betriebssystem vorgesehene Methode und prüfe, ob ein anderer Dienst den Port belegt.

Ollama in OpenClaw einrichten

Bei einer bestehenden OpenClaw-Installation öffnest du den Modellbereich:

openclaw configure --section model

Für eine neue Installation führt auch der Onboarding-Flow durch die Modellauswahl:

openclaw onboard

Wähle den lokalen Ollama-Provider und trage diese Basis-URL ein:

http://127.0.0.1:11434

Der Assistent speichert die funktionierende Modellroute und pflegt die zulässige Modellauswahl. Ein lokal vorhandenes Ollama-Modell ist nicht automatisch als OpenClaw-Modell sichtbar oder als Standard ausgewählt.

Wenn du die Konfigurationsdatei später gezielt lesen oder pflegen willst, erklärt Gateway-Konfiguration: openclaw.json verständlich erklärt die relevanten Grundlagen.

Modellroute statt Vermutung prüfen

Lass dir nach dem Setup nur lokale Ollama-Modelle anzeigen:

openclaw models list --provider ollama --local

Danach prüfst du die aktuell aufgelöste Modellkonfiguration:

openclaw models status

Ein lokaler Model-Ref hat üblicherweise dieses Format:

ollama/<modellname>

Setze ihn für einen kontrollierten Test explizit als Standardmodell:

openclaw models set ollama/<modellname>
openclaw models status

Erwartetes Ergebnis: models status zeigt den gewünschten Model-Ref als Standardroute. Erscheint dein Modell nicht in der lokalen Providerliste, überprüfe zuerst Ollama mit ollama list und anschließend die Provider-Einrichtung im Konfigurationsassistenten. Wechsle nicht blind den Modellnamen, solange nicht klar ist, ob OpenClaw die lokale Runtime überhaupt erreicht.

Zwei Tests, zwei unterschiedliche Aussagen

Ein Agentenlauf prüft mehr als die Modellinferenz: Workspace-Kontext, Tools, Berechtigungen und Session-Verhalten können das Ergebnis beeinflussen. Teste deshalb zuerst die reine Inferenz:

openclaw infer model run --local --model ollama/<modellname> --json

Der Lauf sollte eine erfolgreiche Modellantwort liefern. Scheitert dieser Test, suche bei Ollama, der Modellroute oder den Ressourcen des Rechners.

Erst wenn die Inferenz funktioniert, folgt ein Agententest. Die verfügbaren Flags können sich zwischen OpenClaw-Versionen unterscheiden. Prüfe deshalb zuerst die Hilfe deiner installierten Version:

openclaw agent exec --help

Führe danach einen kleinen, ungefährlichen Auftrag ohne schreibende Tools aus. Erfolg bedeutet hier mehr als Textausgabe: Der Agent soll den Auftrag beenden, das erwartete Ergebnis liefern und keine unbeabsichtigte Tool-Aktion auslösen.

Danach testest du denselben Ablauf mit realistischem Kontext und genau den Tools, die später genutzt werden. So erkennst du, ob der Engpass beim Modell selbst, beim Kontext oder beim Tool-Handling liegt.

Wenn Läufe langsam werden oder hängen bleiben

Arbeite die Diagnose in dieser Reihenfolge ab:

1. Prüfe mit ollama list und /api/tags, ob Ollama erreichbar ist und das Modell vorhanden bleibt.
2. Prüfe mit openclaw models list --provider ollama --local, ob OpenClaw das Modell erkennt.
3. Prüfe mit openclaw models status, welche Route tatsächlich aktiv ist.
4. Wiederhole den reinen Inferenztest mit dem exakten Model-Ref.
5. Vergleiche einen kurzen Agententest mit einem realistischen Lauf inklusive Kontext und Tool-Schemas.

Antwortet die reine Inferenz schnell, während der Agententest stockt, liegt die Ursache oft im Umfang des Kontextes, in Tool-Schemas oder in der Modellentscheidung während des Laufs. Wird schon die reine Inferenz langsam, prüfe Modellgröße, freien RAM beziehungsweise VRAM und parallele Last auf dem Rechner.

Ein Neustart kann einen festgefahrenen lokalen Dienst wieder erreichbar machen. Er ersetzt keinen Hardware- oder Kontexttest. Wenn derselbe realistische Auftrag wiederholt an derselben Grenze scheitert, reduziere den Kontext, wähle ein passenderes Modell oder teile den Workflow auf.

Fallbacks korrekt einsetzen

OpenClaw versucht zuerst das primäre Modell und arbeitet anschließend konfigurierte Fallbacks ab. Ein Fallback ist technische Wiederherstellung für passende Fehlerfälle. Er springt nicht automatisch ein, weil ein lokales Modell zwar erfolgreich, aber qualitativ schwach geantwortet hat.

Triff die Modellwahl für anspruchsvolle Aufgaben deshalb bewusst, bevor der Lauf startet. Nutze einen Fallback zusätzlich für technische Ausfälle. Prüfe die genaue Konfiguration und Reihenfolge mit openclaw models status sowie der OpenClaw-Dokumentation zu Modell-Failover.

Eine ausführlichere Einordnung von Provider-Routen, Modellwahl und Fallbacks findest du in OpenClaw Tutorial Teil 3: Modelle konfigurieren.

Sicherheit: lokal ist nur eine Eigenschaft des Datenpfads

Ein lokales Modell kann verhindern, dass die Inferenzanfrage an einen externen Modellanbieter geht. Daraus folgt nicht, dass der gesamte Agentenlauf sicher ist.

• Begrenze Ollama nach Möglichkeit auf 127.0.0.1.
• Ein Ollama-Host im Netzwerk braucht Zugriffsschutz, etwa VPN oder restriktive Firewall-Regeln. Stelle einen nativen Ollama-Endpoint nicht offen ins Internet.
• Gib einem Testagenten nur die Tools und Rechte, die der Test wirklich benötigt.
• Behandle Web-Inhalte, Dokumente und eingehende Nachrichten weiterhin als potenziell untrusted. Kleinere oder stark quantisierte Modelle können Anweisungen in solchen Inhalten schlechter abgrenzen.

Für einen lokalen oder privaten nativen Ollama-Host ist kein künstlicher Bearer-Token erforderlich. Bei einem öffentlich erreichbaren Host ist Zugriffskontrolle Pflicht. Wie du Tool-Ausführung und Freigaben begrenzt, zeigt OpenClaw Approvals erklärt: /approve, Sandboxing und Host-Exec ohne Blindflug.

Wichtigste Punkte

Die zuverlässige Reihenfolge lautet: Ollama lokal erreichbar machen, das Modell in OpenClaw sichtbar prüfen, den exakten Model-Ref verifizieren und Inferenz von Agenten- und Tool-Test trennen.

Ein kurzer Antworttest reicht nicht für eine Produktionsentscheidung. Teste denselben Workflow mit dem späteren 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 Antwort.

Weiterführende Links

• OpenClaw: Ollama Provider
• OpenClaw: lokale Modelle
• OpenClaw: Modellkonfiguration
• OpenClaw: openclaw models
• OpenClaw: Agent CLI
• OpenClaw: Modell-Failover
• Ollama Library

Dieser Guide ist Teil der OpenClaw-Praxis-Serie (Teil 4 von 6).