Zum Inhalt springen

OpenClaw: Lokale KI-Modelle effizient einrichten

Kennst du das? Du willst volle Kontrolle über deine Daten, aber die Cloud-Kosten steigen oder die Latenz nervt. Lokale Modelle sind eine starke Lösung, aber sie brauchen ordentlich Power, damit sie bei komplexen Aufgaben nicht einknicken oder Sicherheitslücken durch Prompt Injection aufreißen.

Lokal ist machbar, aber OpenClaw erwartet einen großen Context und starken Schutz gegen Prompt Injection. Kleine Modelle kürzen den Context oft eigenmächtig und vernachlässigen die Sicherheit. Setz auf Qualität: Mindestens zwei voll ausgestattete Mac Studios oder ein vergleichbares GPU-Rig (~30k $+). Eine einzelne 24 GB GPU reicht nur für leichtere Prompts mit höherer Latenz. Nutze die größte verfügbare Modell-Variante, die du ausführen kannst; stark quantisierte oder kleine Checkpoints erhöhen das Risiko für Prompt Injection (siehe Security).

Wenn du den einfachsten Einstieg suchst, starte mit Ollama und openclaw onboard. Diese Seite ist der Leitfaden für High-End-Setups und eigene OpenAI-kompatible lokale Server.

Empfohlen: LM Studio + großes lokales Modell (Responses API)

Abschnitt betitelt „Empfohlen: LM Studio + großes lokales Modell (Responses API)“

Der aktuell beste lokale Stack. Lade ein großes Modell in LM Studio (zum Beispiel ein Full-Size Qwen, DeepSeek oder Llama Build), aktiviere den lokalen Server (Standard http://127.0.0.1:1234) und nutze die Responses API, um Reasoning vom finalen Text zu trennen.

{
agents: {
defaults: {
model: { primary: “lmstudio/my-local-model” },
models: {
“anthropic/claude-opus-4-6”: { alias: “Opus” },
“lmstudio/my-local-model”: { alias: “Local” },
},
},
},
models: {
mode: “merge”,
providers: {
lmstudio: {
baseUrl: “http://127.0.0.1:1234/v1”,
apiKey: “lmstudio”,
api: “openai-responses”,
models: [
{
id: “my-local-model”,
name: “Local Model”,
reasoning: false,
input: [“text”],
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
contextWindow: 196608,
maxTokens: 8192,
},
],
},
},
},
}

Checkliste für das Setup

  • Installiere LM Studio: https://lmstudio.ai
  • Lade in LM Studio den größten verfügbaren Modell-Build (vermeide “kleine” oder stark quantisierte Varianten), starte den Server und bestätige, dass http://127.0.0.1:1234/v1/models das Modell auflistet.
  • Ersetze my-local-model mit der tatsächlichen Modell-ID, die in LM Studio angezeigt wird.
  • Lass das Modell geladen; ein Cold-Load verursacht Latenz beim Start.
  • Passe contextWindow/maxTokens an, falls dein LM Studio Build abweicht.
  • Nutze für WhatsApp die Responses API, damit nur der finale Text gesendet wird.

Behalte gehostete Modelle konfiguriert, auch wenn du lokal arbeitest; nutze models.mode: "merge", damit Fallbacks verfügbar bleiben.

Hybride Konfiguration: Gehostet als Primary, lokal als Fallback

Abschnitt betitelt „Hybride Konfiguration: Gehostet als Primary, lokal als Fallback“
{
agents: {
defaults: {
model: {
primary: "anthropic/claude-sonnet-4-6",
fallbacks: ["lmstudio/my-local-model", "anthropic/claude-opus-4-6"],
},
models: {
"anthropic/claude-sonnet-4-6": { alias: "Sonnet" },
"lmstudio/my-local-model": { alias: "Local" },
"anthropic/claude-opus-4-6": { alias: "Opus" },
},
},
},
models: {
mode: "merge",
providers: {
lmstudio: {
baseUrl: "http://127.0.0.1:1234/v1",
apiKey: "lmstudio",
api: "openai-responses",
models: [
{
id: "my-local-model",
name: "Local Model",
reasoning: false,
input: ["text"],
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
contextWindow: 196608,
maxTokens: 8192,
},
],
},
},
},
}

Tausche die Reihenfolge von Primary und Fallback; nutze denselben Provider-Block und models.mode: "merge", um auf Sonnet oder Opus auszuweichen, falls der lokale Rechner offline ist.

  • Gehostete MiniMax/Kimi/GLM Varianten gibt es auch auf OpenRouter mit regionalen Endpoints (z. B. US-hosted). Wähle dort die regionale Variante, um den Traffic in deiner Jurisdiktion zu halten, während du weiterhin models.mode: "merge" für Anthropic/OpenAI Fallbacks nutzt.
  • Nur lokal bleibt der sicherste Weg für den Datenschutz; gehostetes regionales Routing ist der Mittelweg, wenn du Provider-Features brauchst, aber die Kontrolle über den Datenfluss behalten willst.

vLLM, LiteLLM, OAI-proxy oder eigene Gateways funktionieren, wenn sie einen OpenAI-style /v1 Endpoint bereitstellen. Ersetze den Provider-Block oben durch deinen Endpoint und deine Modell-ID:

{
models: {
mode: "merge",
providers: {
local: {
baseUrl: "http://127.0.0.1:8000/v1",
apiKey: "sk-local",
api: "openai-responses",
models: [
{
id: "my-local-model",
name: "Local Model",
reasoning: false,
input: ["text"],
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
contextWindow: 120000,
maxTokens: 8192,
},
],
},
},
},
}

Lass models.mode: "merge" aktiv, damit gehostete Modelle als Fallback bereitstehen.

  • Kann das Gateway den Proxy erreichen? Teste es mit curl http://127.0.0.1:1234/v1/models.
  • Modell in LM Studio nicht geladen? Lade es neu; ein Cold Start ist eine häufige Ursache für Hänger.
  • Context-Fehler? Verringere contextWindow oder erhöhe das Limit deines Servers.
  • Sicherheit: Lokale Modelle überspringen oft Provider-Filter; halte Agents spezialisiert und die Compaction aktiv, um die Auswirkungen von Prompt Injection zu begrenzen.

AI Setup Assistant

OpenClaw

OpenClaw Expert

Noch festgefahren?

Wenn diese Seite nicht hilft, frage OpenClaw Expert nach Schritt-fuer-Schritt-Loesungen.