OpenClaw mit lokalen Modellen: Qwen + Ollama, null API-Kosten
Die Erkenntnis, die gerade viral geht
Diese Woche macht ein Setup-Tweet die Runde: OpenClaw + Qwen 3.5 über Ollama — lokale KI-Agenten auf Claude-Niveau, ohne API-Rechnung, ohne Cloud, ohne dass ein einziges Zeichen deine Hardware verlässt.
166 Retweets in wenigen Stunden. Der Grund? Die Frage, die sich viele stellen: *"Muss ich für jeden Agenten-Aufruf wirklich Anthropic oder OpenAI bezahlen?"*
Die Antwort lautet: Nein.
Dieser Artikel zeigt genau, wie das funktioniert — und was du in einem Multi-Agenten-Setup beachten musst.
---
Warum überhaupt lokale Modelle?
Drei Gründe, die für die meisten Setups relevant sind:
1. Kosten. Bei einem 6-Agenten-Team mit Heartbeats alle 30 Minuten, täglichen Cron-Jobs und aktivem Betrieb summieren sich API-Kosten schnell auf 200–500 € im Monat. Ein lokales Modell kostet: einmalig Strom.
2. Datenschutz. Wenn deine Agenten Zugriff auf E-Mails, Geschäftsdaten und interne Dokumente haben — möchtest du nicht, dass diese Daten durch einen Cloud-Anbieter fließen. Bei sensiblen Setups ist das kein Nice-to-have, sondern Pflicht.
3. Latenz. Für einfache Aufgaben (Datei lesen, Task-Status prüfen, kurze Antwort formulieren) ist ein lokales 7B-Modell schneller als ein Cloud-API-Call mit Netzwerklatenz.
---
Was du brauchst
---
Schritt 1: Ollama installieren und Modell laden
```bash
# Ollama installieren (macOS)
brew install ollama
# Ollama installieren (Linux)
curl -fsSL https://ollama.com/install.sh | sh
# Qwen 3.5 7B laden (~4.7 GB Download)
ollama pull qwen2.5:7b
# Für anspruchsvollere Aufgaben: 14B
ollama pull qwen2.5:14b
# Test: Modell direkt ansprechen
ollama run qwen2.5:7b "Hallo, was kannst du?"
```
Wenn du eine Antwort siehst: Ollama läuft. Das Modell ist bereit.
Ollama stellt lokal eine API bereit: `http://localhost:11434`. Das ist der Endpunkt, den OpenClaw später nutzt.
---
Schritt 2: OpenClaw für lokales Modell konfigurieren
OpenClaw unterstützt verschiedene Modell-Provider — darunter die OpenAI-kompatible API, die Ollama bereitstellt.
Öffne oder erstelle deine OpenClaw-Konfiguration:
```bash
openclaw config show
```
Um das Modell auf Ollama/Qwen umzustellen:
```bash
# Provider auf Ollama-kompatible API setzen
openclaw config set model.provider openai-compatible
openclaw config set model.baseUrl http://localhost:11434/v1
openclaw config set model.name qwen2.5:7b
openclaw config set model.apiKey ollama
```
Wichtig: Ollama erwartet keinen echten API-Key, aber das Feld darf nicht leer sein. Ein Platzhalter wie `ollama` reicht.
Danach Gateway neu starten:
```bash
openclaw gateway restart
```
---
Schritt 3: Testen, ob der Agent das Modell nutzt
```bash
# Prüfen ob der Agent antwortet
openclaw sessions list
# Direkte Test-Session
openclaw sessions test
```
Alternativ: Schick eine Nachricht an den konfigurierten Kanal (z.B. Telegram) und schau, ob der Agent antwortet. Wenn ja — läuft alles lokal.
Zur Kontrolle kannst du in Ollama's Logs schauen:
```bash
# Ollama-Logs (Linux)
journalctl -u ollama -f
# macOS: Ollama läuft im Hintergrund, Logs unter
tail -f ~/.ollama/logs/server.log
```
Wenn du dort Einträge siehst, wenn der Agent antwortet: bestätigt, alles lokal.
---
Welches Modell für welche Aufgabe?
Nicht jedes Modell ist für jeden Einsatz gleich gut. Das ist unsere Erfahrung aus dem 6-Agenten-Setup:
Qwen 2.5 7B — geeignet für:
Schwach bei: langen, mehrstufigen Reasoning-Ketten; komplexem Code schreiben; ambigen Anweisungen.
Qwen 2.5 14B — geeignet für:
Schwach bei: sehr langen Kontext-Fenstern (>32k Token), subtilen Reasoning-Aufgaben, die GPT-4 oder Claude benötigen.
Qwen 2.5 Coder 32B — für Power-User:
Braucht jedoch mindestens 64 GB RAM. Für die meisten Setups überdimensioniert.
---
Multi-Agenten-Setup: Verschiedene Modelle pro Agent
Das ist das Killer-Feature lokaler Modelle in einem Multi-Agenten-System: jeder Agent kann ein anderes Modell nutzen.
In unserem Setup:
| Agent | Aufgabe | Modell |
|-------|---------|--------|
| Sam (Teamleitung) | Delegation, Koordination | Claude Sonnet (Cloud) |
| Peter (Coding) | Code-Review, Debugging | Qwen 2.5 Coder 7B (lokal) |
| Maya (Marketing) | Blog-Posts, Texte | Qwen 2.5 14B (lokal) |
| Alex (Alltagsaufgaben) | E-Mails, Kalender | Qwen 2.5 7B (lokal) |
| Iris (Research) | Web-Suche, Zusammenfassungen | Qwen 2.5 14B (lokal) |
| Atlas (CEO) | Direktassistenz | Claude Sonnet (Cloud) |
Das Ergebnis: Cloud-Kosten auf 2 Agenten reduziert, die wirklich komplexes Reasoning brauchen. Der Rest läuft lokal.
So konfigurierst du verschiedene Modelle pro Agent:
Jeder Agent hat seinen eigenen Workspace. In der OpenClaw-Konfiguration dieses Workspaces kannst du das Modell überschreiben:
```bash
# Im Workspace eines spezifischen Agenten
openclaw config set model.name qwen2.5:7b
openclaw config set model.baseUrl http://localhost:11434/v1
```
Alternativ: Modell direkt im System-Prompt referenzieren oder über Environment-Variablen pro Container setzen (wenn du Docker nutzt).
---
Praktische Limitierungen und wie wir damit umgehen
Kontext-Fenster
Ollama-Modelle haben standardmäßig ein kleineres Kontext-Fenster als Cloud-APIs. Bei langen Conversations oder großen Dateien kann das zum Problem werden.
Lösung: In Ollama das Kontext-Fenster explizit erhöhen:
```bash
# Modell mit größerem Kontext starten
OLLAMA_NUM_CTX=32768 ollama serve
```
Oder in der Modelfile definieren:
```
FROM qwen2.5:7b
PARAMETER num_ctx 32768
```
Tool-Calling
Nicht alle Ollama-Modelle unterstützen zuverlässiges Tool-Calling. Qwen 2.5 ist hier besser als die meisten, aber schlechter als Claude oder GPT-4.
Praktische Regel: Wenn ein Cron-Job mehrere Tools parallel aufrufen muss (z.B. E-Mail + Kalender + ClickUp gleichzeitig), nutze ein stärkeres Modell. Für sequentielle Single-Tool-Calls reicht Qwen.
Kaltstart-Latenz
Das erste Request nach dem Systemstart lädt das Modell in den RAM — kann 10–30 Sekunden dauern. Danach: schnell.
Lösung: Ollama beim Systemstart automatisch laden:
```bash
# Modell vorladen (einmalig beim Start)
ollama run qwen2.5:7b "" &
```
---
Docker + Ollama: Das produktive Setup
Wenn du mehrere Agenten in Docker-Containern betreibst (wie wir), läuft Ollama idealerweise auf dem Host — nicht in jedem Container.
```yaml
# docker-compose.yml (Ausschnitt)
services:
agent-maya:
image: openclaw/agent:latest
environment:
- OPENCLAW_MODEL_PROVIDER=openai-compatible
- OPENCLAW_MODEL_BASE_URL=http://host.docker.internal:11434/v1
- OPENCLAW_MODEL_NAME=qwen2.5:14b
- OPENCLAW_MODEL_API_KEY=ollama
volumes:
- ./workspaces/maya:/workspace
agent-alex:
image: openclaw/agent:latest
environment:
- OPENCLAW_MODEL_PROVIDER=openai-compatible
- OPENCLAW_MODEL_BASE_URL=http://host.docker.internal:11434/v1
- OPENCLAW_MODEL_NAME=qwen2.5:7b
- OPENCLAW_MODEL_API_KEY=ollama
volumes:
- ./workspaces/alex:/workspace
```
`host.docker.internal` ist der Hostname, über den Container den Host erreichen können. Auf Linux manchmal anders — prüfe mit `docker network inspect bridge`.
---
Wann Cloud-API doch sinnvoll ist
Ehrlichkeit: Lokale Modelle sind nicht in jedem Fall die bessere Wahl.
Bleib bei Cloud wenn:
Wechsel zu lokal wenn:
Der pragmatische Ansatz: Hybrid. Cloud für die Denkarbeit, lokal für die Routinearbeit. Das ist genau, was unser 6-Agenten-Team macht.
---
Das vollständige Setup
Das gesamte Bild — Docker-Konfiguration, Multi-Modell-Setup, Tailscale-Sicherheit und die genauen System-Prompts für jeden Agenten — ist im OpenClaw Setup Playbook dokumentiert.
18 Kapitel, basierend auf echten Produktionserfahrungen. Kein theoretisches Framework, sondern das, was wir tatsächlich betreiben.
Komplett auf Deutsch verfügbar. 🇩🇪