Inhaltsverzeichnis
Einleitung: Warum Hybrid?
KI-Assistenten im Local-First-Betrieb haben ein grundsätzliches Dilemma: Leistungsfähige Sprachmodelle brauchen Rechenleistung, die ein Raspberry Pi auch mit NVMe-SSD und 8 GB RAM nicht liefern kann. Die Alternative – vollständige Cloud-Abhängigkeit – bedeutet, dass sämtliche Anfragen und Daten einen externen Server passieren.
Meine Lösung ist ein hybrider Ansatz: Ein Raspberry Pi 5 übernimmt die lokale Steuerung und rechenarme Aufgaben wie Embeddings. Ein günstiger VPS stellt über einen Ollama-Container den Zugriff auf leistungsfähige Cloud-Modelle bereit. Dazwischen vermittelt OpenClaw als Docker-basierte Gateway-Instanz.
Dieser Artikel ist der erste einer dreiteiligen Serie. Er beschreibt die Architektur-Entscheidung, die Hardware-Wahl und die grundlegende Aufteilung zwischen lokalem Pi, VPS und Cloud-Modellen. Teil 2 widmet sich dem OpenClaw Gateway im Detail – Vault, Skills und Scheduling. Teil 3 fasst Betriebserfahrung, Update-Strategie und ein ehrliches Fazit zusammen.
1. Die Grundidee: Drei Schichten
Die Architektur besteht aus drei klar getrennten Schichten mit eigenen Verantwortlichkeiten:
Lokale Basis (Raspberry Pi 5)
- Host-System mit Debian
- Docker-Isolation für OpenClaw
- Lokale Embedding-Berechnung (nomic-embed-text)
- Kein direkter Chat-Modell-Zugriff von außen
Vermittlungsebene (VPS)
- Ollama-Container als Service-Endpunkt
- Stellt Cloud-Modelle über die Ollama-API bereit
- Keine eigene GPU: Die Inferenz läuft in der Ollama-Cloud-Infrastruktur
- Kostengünstig: etwa 4–6 €/Monat
Cloud-Modelle (Ollama Cloud)
- Sprachmodelle: DeepSeek, Qwen, Kimi, Nemotron
- Embedding-Modelle laufen lokal (keine Cloud-Latenz)
- Zugriff ausschließlich über den VPS-Endpunkt
Diese Dreiteilung hat einen entscheidenden Vorteil: Jede Schicht macht nur das, was sie am besten kann. Der Pi spart Rechenleistung durch lokale Embeddings, der VPS vermittelt ohne eigene GPU-Investition, und die Cloud liefert Rechenleistung ohne Fixkosten für Hardware.
2. Der Raspberry Pi 5 als Basisstation
2.1 Hardware-Grundlagen
Ein Raspberry Pi 5 mit 8 GB RAM ist die Mindestvoraussetzung. Entscheidend ist der Verzicht auf SD-Karten als Systemlaufwerk: Eine NVMe-SSD über den PCIe-Anschluss ist nicht optional, sondern zwingend, sobald Docker-Container mit persistenten States laufen. SD-Karten degradieren bei regelmäßigen Schreibzugriffen innerhalb von Monaten.
Empfehlung: NVMe-SSD mit 256 GB oder mehr über ein HAT+ Interface, aktiver Kühlkörper oder Lüfter, stabiles Netzteil (offizielles 27W Pi 5 Netzteil oder vergleichbar).
2.2 Debian als Betriebssystem
Der Pi läuft mit Raspberry Pi OS (Debian-Basis) oder Debian direkt. Der OpenClaw-Docker-Container selbst verwendet Debian Bookworm als Basis – der Host kann auch eine aktuellere Version einsetzen.
Wichtiger Unterschied: Der OpenClaw-Container hat keinen direkten Zugriff auf den Host. Alle persistenten Daten werden über Docker-Volumes bereitgestellt. Das bedeutet: Selbst wenn der Container kompromittiert wird, bleibt das Host-System isoliert.
2.3 Docker als Schutzschicht
OpenClaw läuft in einem Docker-Container, gestartet über Docker Compose. Die Konfiguration ist bewusst einfach gehalten:
- Code: Getrennt vom State (Git-Repository für Updates)
- State: Persistente Daten auf dem Host gemountet
- Secrets: Separates Volume für Tokens und Keys
- Workspace: Skills, Dokumentation, eigene Skripte
Diese Trennung ist das zentrale Sicherheitsmerkmal der Architektur. Ein docker compose down && docker compose up -d mit aktualisiertem Image ersetzt den gesamten Container-Code, ohne einen einzigen State-Datenpunkt zu verlieren.
2.4 Lokale Embeddings
Embeddings – also die Umwandlung von Text in numerische Vektoren für die Ähnlichkeitssuche – laufen auf dem Pi selbst. Ein dedizierter lokaler Ollama-Service stellt das Modell nomic-embed-text bereit. Das ist rechenarm genug für den Pi 5, spart die Netzwerklatenz zum VPS und reduziert die Abhängigkeit von externen Diensten.
Der Kompromiss: Text-Embeddings sind langsamer als auf einem x86-Server, aber für die typischen Workloads eines persönlichen Assistents völlig ausreichend (wenige Sekunden pro Vorgang).
3. Der VPS als Cloud-Endpunkt
3.1 Was der VPS tatsächlich leistet
Der VPS ist kein „Vermittler“ im Sinne eines simplen Proxys. Er betreibt einen eigenen Ollama-Container, der als API-Endpunkt für Cloud-Modelle dient. Die Konfiguration ist simpel: Ollama per docker run oder Docker Compose im Container starten, Modelle mit ollama pull beziehen, den Endpunkt per Firewall auf bekannte Quellen beschränken.
Der entscheidende Punkt: Der VPS selbst hat keine dedizierte GPU und keine besondere Rechenleistung für KI. Die rechenintensive Arbeit – das eigentliche Ausführen der Sprachmodelle – findet auf den Servern von Ollama Cloud statt. Der VPS ist der technische Zugangspunkt, nicht die Recheneinheit.
Warum nicht direkt auf die Ollama-Cloud-API zugreifen, sondern den Umweg über den VPS nehmen? Zwei Gründe:
- Einheitlicher Endpunkt: OpenClaw spricht immer denselben Ollama-API-Endpunkt an – egal ob das Modell lokal oder extern läuft. Der Wechsel zwischen lokalen und Cloud-Modellen ist konfigurationsbasiert.
- Sicherheit und Kontrolle: Der VPS-Endpunkt lässt sich über Firewall-Regeln auf bekannte Quellen beschränken. Direkter Zugriff auf eine öffentliche API erhöht die Angriffsfläche.
3.2 Modellauswahl
Die genutzten Cloud-Modelle sind:
- DeepSeek v4 (Flash): Standard-Modell für den täglichen Betrieb – schnell, ausreichend für die meisten Aufgaben
- Qwen 3.5: Für komplexere Reasoning-Aufgaben
- Kimi K2.6: Content-Erstellung und redaktionelle Arbeit
- Nemotron 3 Super: Hochwertige Reasoning-Qualität, aber langsamer
Die Auswahl folgt einem einfachen Prinzip: Für schnelle, häufige Aufgaben ein leichtes Modell, für anspruchsvolle Aufgaben schwerere Modelle bei Bedarf. Der VPS-Endpunkt macht alle Modelle über dieselbe API erreichbar.
3.3 Alternativen und Kosten
Der hier beschriebene VPS kostet etwa 5 €/Monat für ein ausreichend dimensioniertes Modell (2 vCores, 4 GB RAM, 50 GB SSD). Das ist günstiger als die meisten Cloud-KI-Abonnements und bietet gleichzeitig mehr Kontrolle.
Alternativen wären:
- Eigenbau mit GPU (teurer, höherer Stromverbrauch, lauter)
- Reine Cloud-API-Nutzung (bequemer, aber Abhängigkeit von Drittanbieter-APIs)
- Stärkerer lokaler Rechner (Intel NUC, Mini-PC) – höhere Anschaffungskosten (300–600 €), aber bei intensiver Nutzung auf lange Sicht günstiger als Cloud-APIs
Der Hybrid-Ansatz ist der Kompromiss zwischen Kosten, Kontrolle und Leistung.
4. Zusammenspiel der Komponenten
Im täglichen Betrieb läuft ein typischer Vorgang so ab:
- Der Nutzer stellt eine Anfrage an OpenClaw (über Telegram, Signal, Web-UI)
- OpenClaw sucht im lokalen Memory-Kontext (Embeddings via lokalen Pi-Ollama)
- Bei Bedarf ergänzt OpenClaw den Kontext durch Websuche (Skill-gesteuert)
- Die Anfrage + Kontext geht an den konfigurierten Sprachmodell-Endpunkt (VPS/Ollama Cloud)
- Das Modell liefert die Antwort zurück
- OpenClaw speichert relevante Kontext-Informationen lokal
Der Nutzer bekommt von der Aufteilung nichts mit. Die Anfrage fühlt sich an wie ein einheitlicher, lokaler Assistent – nur dass die Rechenarbeit extern erledigt wird.
5. Sicherheitsbetrachtung
Die kritische Frage bei Cloud-Anbindung: Welche Daten verlassen das lokale System?
- Sprachmodell-Anfragen: Die eigentlichen Prompts und Inhalte werden an die Cloud gesendet. Das ist der architekturbedingte Kompromiss.
- Memory und Vault: Bleiben lokal. OpenClaw extrahiert relevante Kontextinformationen und sendet nur diese als Prompt-Kontext.
- Secrets und Credentials: Verlassen niemals den lokalen Container.
- Embeddings: Werden lokal berechnet und bleiben im lokalen Memory-Core.
Für sensible Daten, die niemals die lokale Umgebung verlassen dürfen, gibt es zwei Optionen:
- Nutzung lokaler Modelle auf dem Pi (kleinere Modelle, geringere Qualität)
- Auslagerung des gesamten Betriebs auf einen stärkeren lokalen Rechner
Fazit und Ausblick auf Teil 2
Die Hybrid-Architektur aus Raspberry Pi 5, VPS und Cloud-Modellen ist ein tragfähiger Kompromiss für alle, die KI-Assistenten lokal betreiben wollen, ohne auf moderne Sprachmodelle zu verzichten. Die Kosten sind überschaubar, die Sicherheitslage kontrollierbar, und die Aufteilung folgt klaren fachlichen Grenzen.
Teil 2 dieser Serie widmet sich dem OpenClaw Gateway als Steuerzentrale: Wie Vault und Workspace die deterministische Arbeitsweise ermöglichen, wie Skills die Funktionalität erweitern, und wie das Scheduling den Betrieb automatisiert.
Teil 3 fasst Betriebserfahrung, Update-Strategie und ein ehrliches Fazit nach mehreren Monaten Produktivbetrieb zusammen.
Erschienen auf alleswasbewegt.de – Technik für Selbstbauer, die mehr wissen wollen.