Lokale Modelle sind machbar. Sie erhöhen jedoch auch die Anforderungen an Hardware, Kontextgröße und Prompt-Injection-Abwehr: kleine oder stark quantisierte Karten kürzen den Kontext und schwächen die Sicherheit. Diese Seite ist der meinungsstarke Leitfaden für höherwertige lokale Stacks und benutzerdefinierte OpenAI-kompatible lokale Server. Für Onboarding mit möglichst wenig Reibung starten Sie mit LM Studio oder Ollama undDocumentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
openclaw onboard.
Für lokale Server, die nur starten sollen, wenn ein ausgewähltes Modell sie benötigt, siehe
Lokale Modelldienste.
Hardware-Mindestanforderungen
Zielen Sie hoch: ≥2 voll ausgestattete Mac Studios oder ein vergleichbares GPU-System (~30.000 USD+) für einen komfortablen Agent-Loop. Eine einzelne 24-GB-GPU funktioniert nur für leichtere Prompts bei höherer Latenz. Führen Sie immer die größte / vollständige Variante aus, die Sie hosten können; kleine oder stark quantisierte Checkpoints erhöhen das Prompt-Injection-Risiko (siehe Sicherheit).Backend auswählen
| Backend | Verwenden, wenn |
|---|---|
| LM Studio | Ersteinrichtung lokal, GUI-Loader, native Responses API |
| Ollama | CLI-Workflow, Modellbibliothek, systemd-Dienst ohne manuelle Betreuung |
| MLX / vLLM / SGLang | Selbstgehostetes Serving mit hohem Durchsatz und OpenAI-kompatiblem HTTP-Endpunkt |
| LiteLLM / OAI-proxy / benutzerdefinierter OpenAI-kompatibler Proxy | Sie eine andere Modell-API davor schalten und OpenClaw sie wie OpenAI behandeln soll |
api: "openai-responses"), wenn das Backend sie unterstützt (LM Studio tut dies). Andernfalls bleiben Sie bei Chat Completions (api: "openai-completions").
Empfohlen: LM Studio + großes lokales Modell (Responses API)
Der derzeit beste lokale Stack. Laden Sie ein großes Modell in LM Studio (zum Beispiel einen vollständigen Qwen-, DeepSeek- oder Llama-Build), aktivieren Sie den lokalen Server (Standardhttp://127.0.0.1:1234) und verwenden Sie Responses API, um Reasoning vom finalen Text getrennt zu halten.
- Installieren Sie LM Studio: https://lmstudio.ai
- Laden Sie in LM Studio den größten verfügbaren Modell-Build herunter (vermeiden Sie „small“/stark quantisierte Varianten), starten Sie den Server und bestätigen Sie, dass
http://127.0.0.1:1234/v1/modelsihn auflistet. - Ersetzen Sie
my-local-modeldurch die tatsächliche Modell-ID, die in LM Studio angezeigt wird. - Halten Sie das Modell geladen; Kaltstarts erhöhen die Startlatenz.
- Passen Sie
contextWindow/maxTokensan, falls Ihr LM-Studio-Build abweicht. - Bleiben Sie für WhatsApp bei Responses API, damit nur finaler Text gesendet wird.
models.mode: "merge", damit Fallbacks verfügbar bleiben.
Hybridkonfiguration: gehostetes Primärmodell, lokaler Fallback
Lokal zuerst mit gehostetem Sicherheitsnetz
Tauschen Sie die Reihenfolge von Primärmodell und Fallback; behalten Sie denselben Provider-Block undmodels.mode: "merge" bei, damit Sie auf Sonnet oder Opus zurückfallen können, wenn die lokale Maschine nicht verfügbar ist.
Regionales Hosting / Datenrouting
- Gehostete MiniMax/Kimi/GLM-Varianten gibt es auch auf OpenRouter mit regional gebundenen Endpunkten (z. B. in den USA gehostet). Wählen Sie dort die regionale Variante, um Traffic in Ihrer gewählten Jurisdiktion zu halten und dennoch
models.mode: "merge"für Anthropic/OpenAI-Fallbacks zu verwenden. - Rein lokal bleibt der stärkste Datenschutzpfad; gehostetes regionales Routing ist der Mittelweg, wenn Sie Provider-Funktionen benötigen, aber Kontrolle über den Datenfluss wünschen.
Andere OpenAI-kompatible lokale Proxys
MLX (mlx_lm.server), vLLM, SGLang, LiteLLM, OAI-proxy oder benutzerdefinierte
Gateways funktionieren, wenn sie einen OpenAI-artigen /v1/chat/completions-
Endpunkt bereitstellen. Verwenden Sie den Chat-Completions-Adapter, sofern das
Backend nicht ausdrücklich Unterstützung für /v1/responses dokumentiert.
Ersetzen Sie den obigen Provider-Block durch Ihren Endpunkt und Ihre Modell-ID:
api bei einem benutzerdefinierten Provider mit baseUrl ausgelassen wird,
verwendet OpenClaw standardmäßig openai-completions. Loopback-Endpunkte wie
127.0.0.1 werden automatisch als vertrauenswürdig behandelt; LAN-, Tailnet-
und private DNS-Endpunkte benötigen weiterhin request.allowPrivateNetwork: true.
Der Wert models.providers.<id>.models[].id ist Provider-lokal. Fügen Sie dort
nicht das Provider-Präfix ein. Ein MLX-Server, der zum Beispiel mit
mlx_lm.server --model mlx-community/Qwen3-30B-A3B-6bit gestartet wurde, sollte
diese Katalog-ID und Modellreferenz verwenden:
models.providers.mlx.models[].id: "mlx-community/Qwen3-30B-A3B-6bit"agents.defaults.model.primary: "mlx/mlx-community/Qwen3-30B-A3B-6bit"
input: ["text", "image"] bei lokalen oder per Proxy angebundenen
Vision-Modellen, damit Bildanhänge in Agent-Turns injiziert werden. Interaktives
Onboarding für benutzerdefinierte Provider erkennt gängige Vision-Modell-IDs und
fragt nur bei unbekannten Namen nach. Nicht interaktives Onboarding verwendet
dieselbe Erkennung; nutzen Sie --custom-image-input für unbekannte Vision-IDs
oder --custom-text-input, wenn ein bekannt wirkendes Modell hinter Ihrem
Endpunkt nur Text unterstützt.
Behalten Sie models.mode: "merge" bei, damit gehostete Modelle als Fallbacks
verfügbar bleiben. Verwenden Sie models.providers.<id>.timeoutSeconds für
langsame lokale oder entfernte Modellserver, bevor Sie
agents.defaults.timeoutSeconds erhöhen. Das Provider-Timeout gilt nur für
Modell-HTTP-Anfragen, einschließlich Verbindung, Header, Body-Streaming und den
gesamten durch guarded-fetch abgesicherten Abbruch.
Für benutzerdefinierte OpenAI-kompatible Provider wird das Speichern eines nicht geheimen lokalen Markers wie
apiKey: "ollama-local" akzeptiert, wenn baseUrl auf Loopback, ein privates LAN, .local oder einen einfachen Hostnamen auflöst. OpenClaw behandelt ihn als gültige lokale Anmeldedaten, statt einen fehlenden Schlüssel zu melden. Verwenden Sie einen echten Wert für jeden Provider, der einen öffentlichen Hostnamen akzeptiert./v1-Backends:
- OpenClaw behandelt diese als Proxy-artige OpenAI-kompatible Routen, nicht als native OpenAI-Endpunkte
- rein native OpenAI-Anfrageformung gilt hier nicht: kein
service_tier, kein Responsesstore, keine OpenAI-Reasoning-Kompatibilitäts-Payload- Formung und keine Prompt-Cache-Hinweise - versteckte OpenClaw-Attributionsheader (
originator,version,User-Agent) werden bei diesen benutzerdefinierten Proxy-URLs nicht injiziert
-
Manche Server akzeptieren bei Chat Completions nur String-
messages[].content, keine strukturierten Content-Part-Arrays. Setzen Siemodels.providers.<provider>.models[].compat.requiresStringContent: truefür diese Endpunkte. -
Manche lokalen Modelle geben eigenständige eingeklammerte Tool-Anfragen als Text aus, zum Beispiel
[tool_name], gefolgt von JSON und[END_TOOL_REQUEST]. OpenClaw hebt diese nur dann zu echten Tool-Aufrufen hoch, wenn der Name exakt einem für den Turn registrierten Tool entspricht; andernfalls wird der Block als nicht unterstützter Text behandelt und vor nutzersichtbaren Antworten verborgen. - Wenn ein Modell JSON, XML oder ReAct-artigen Text ausgibt, der wie ein Tool-Aufruf aussieht, der Provider aber keinen strukturierten Aufruf ausgegeben hat, lässt OpenClaw ihn als Text stehen und protokolliert eine Warnung mit der Run-ID, Provider/Modell, erkanntem Muster und Tool-Namen, sofern verfügbar. Behandeln Sie dies als Tool-Call- Inkompatibilität von Provider/Modell, nicht als abgeschlossenen Tool-Lauf.
-
Wenn Tools als Assistant-Text erscheinen, statt ausgeführt zu werden, zum Beispiel rohes JSON,
XML, ReAct-Syntax oder ein leeres
tool_calls-Array in der Provider-Antwort, prüfen Sie zuerst, ob der Server ein Tool-Call-fähiges Chat-Template bzw. einen entsprechenden Parser verwendet. Für OpenAI-kompatible Chat-Completions-Backends, deren Parser nur funktioniert, wenn Tool-Nutzung erzwungen wird, setzen Sie eine anfragebezogene Überschreibung pro Modell, statt sich auf Text- Parsing zu verlassen:Verwenden Sie dies nur für Modelle/Sitzungen, bei denen jeder normale Turn ein Tool aufrufen soll. Es überschreibt den OpenClaw-Standard-Proxywerttool_choice: "auto". Ersetzen Sielocal/my-local-modeldurch die exakte Provider/Modell-Referenz, die vonopenclaw models listangezeigt wird. -
Wenn ein benutzerdefiniertes OpenAI-kompatibles Modell OpenAI-Reasoning-Efforts jenseits
des eingebauten Profils akzeptiert, deklarieren Sie diese im Modell-Compat-Block. Wenn Sie hier
"xhigh"hinzufügen, machen/think xhigh, Sitzungsauswahlen, Gateway-Validierung undllm-task- Validierung die Stufe für diese konfigurierte Provider/Modell-Referenz verfügbar:
Kleinere oder strengere Backends
Wenn das Modell sauber geladen wird, aber vollständige Agent-Durchläufe sich fehlerhaft verhalten, arbeiten Sie von oben nach unten – bestätigen Sie zuerst den Transport und grenzen Sie dann die Oberfläche ein.-
Bestätigen Sie, dass das lokale Modell selbst antwortet. Keine Tools, kein Agent-Kontext:
-
Bestätigen Sie das Gateway-Routing. Sendet nur den angegebenen Prompt – überspringt Transkript, AGENTS-Bootstrap, Zusammenbau der Kontext-Engine, Tools und mitgelieferte MCP-Server, prüft aber weiterhin Gateway-Routing, Authentifizierung und Provider-Auswahl:
-
Probieren Sie den Lean-Modus. Wenn beide Prüfungen bestehen, reale Agent-Durchläufe aber mit fehlerhaften Tool-Aufrufen oder übergroßen Prompts scheitern, aktivieren Sie
agents.defaults.experimental.localModelLean: true. Dadurch werden die drei schwergewichtigsten Standard-Tools (browser,cron,message) entfernt, sodass die Prompt-Form kleiner und weniger brüchig ist. Siehe Experimentelle Funktionen → Lean-Modus für lokale Modelle für die vollständige Erklärung, wann Sie ihn verwenden sollten und wie Sie bestätigen, dass er aktiv ist. -
Deaktivieren Sie Tools als letzten Ausweg vollständig. Wenn der Lean-Modus nicht ausreicht, setzen Sie
models.providers.<provider>.models[].compat.supportsTools: falsefür diesen Modelleintrag. Der Agent arbeitet dann auf diesem Modell ohne Tool-Aufrufe. -
Darüber hinaus liegt der Engpass upstream. Wenn das Backend nach Lean-Modus und
supportsTools: falseweiterhin nur bei größeren OpenClaw-Läufen scheitert, ist das verbleibende Problem normalerweise die Kapazität des upstream Modells oder Servers – Kontextfenster, GPU-Speicher, kv-cache-Verdrängung oder ein Backend-Fehler. An diesem Punkt ist es nicht mehr die Transportschicht von OpenClaw.
Fehlerbehebung
- Kann Gateway den Proxy erreichen?
curl http://127.0.0.1:1234/v1/models. - LM Studio-Modell entladen? Laden Sie es erneut; Kaltstart ist eine häufige Ursache für „Hängenbleiben“.
- Meldet der lokale Server
terminated,ECONNRESEToder schließt er den Stream mitten im Durchlauf? OpenClaw zeichnet in der Diagnose ein niedrig-kardinalesmodel.call.error.failureKindplus einen RSS-/Heap-Snapshot des OpenClaw-Prozesses auf. Bei Speicherdruck in LM Studio/Ollama gleichen Sie diesen Zeitstempel mit dem Serverlog oder macOS-Crash-/ Jetsam-Log ab, um zu bestätigen, ob der Modellserver beendet wurde. - OpenClaw leitet die Preflight-Schwellenwerte für Kontextfenster aus dem erkannten Modellfenster ab oder aus dem nicht gedeckelten Modellfenster, wenn
agents.defaults.contextTokensdas effektive Fenster reduziert. Unter 20 % wird mit einer Untergrenze von 8k gewarnt. Harte Sperren verwenden den 10-%-Schwellenwert mit einer Untergrenze von 4k, begrenzt auf das effektive Kontextfenster, damit übergroße Modellmetadaten ein ansonsten gültiges Benutzerlimit nicht ablehnen können. Wenn Sie diese Preflight-Prüfung auslösen, erhöhen Sie das Kontextlimit des Servers/Modells oder wählen Sie ein größeres Modell. - Kontextfehler? Senken Sie
contextWindowoder erhöhen Sie Ihr Serverlimit. - OpenAI-kompatibler Server gibt
messages[].content ... expected a stringzurück? Fügen Siecompat.requiresStringContent: truezu diesem Modelleintrag hinzu. - OpenAI-kompatibler Server gibt
validation.keyszurück oder sagt, dass Nachrichteneinträge nurroleundcontenterlauben? Fügen Siecompat.strictMessageKeys: truezu diesem Modelleintrag hinzu. - Direkte kleine
/v1/chat/completions-Aufrufe funktionieren, aberopenclaw infer model run --localscheitert bei Gemma oder einem anderen lokalen Modell? Prüfen Sie zuerst die Provider-URL, Modellreferenz, Authentifizierungsmarkierung und Serverlogs; lokalesmodel runenthält keine Agent-Tools. Wenn lokalesmodel runerfolgreich ist, größere Agent-Durchläufe aber scheitern, reduzieren Sie die Tool-Oberfläche des Agent mitlocalModelLeanodercompat.supportsTools: false. - Tool-Aufrufe erscheinen als roher JSON-/XML-/ReAct-Text, oder der Provider gibt ein
leeres
tool_calls-Array zurück? Fügen Sie keinen Proxy hinzu, der Assistant-Text blind in Tool-Ausführung umwandelt. Beheben Sie zuerst das Chat-Template/den Parser des Servers. Wenn das Modell nur funktioniert, wenn Tool-Nutzung erzwungen wird, fügen Sie die obige modellbezogene Überschreibungparams.extra_body.tool_choice: "required"hinzu und verwenden Sie diesen Modelleintrag nur für Sitzungen, in denen in jedem Durchlauf ein Tool-Aufruf erwartet wird. - Sicherheit: Lokale Modelle überspringen Provider-seitige Filter; halten Sie Agents eng begrenzt und Compaction aktiviert, um den Wirkungsradius von Prompt Injection zu begrenzen.