OpenClaw selbst hosten: Local AI in zwei Stufen

Warum überhaupt eine KI selbst hosten?

Die meisten Teams, die in die AI-Werkzeugwelt einsteigen, starten mit einer SaaS-API: Key einfügen, Request absetzen, fertig. Für Prototypen ist das in Ordnung. Für produktive Nutzung in einem Unternehmen ist es das oft nicht.

Das Kernproblem sind die Daten. Jeder Prompt, der an einen externen Anbieter geht, verlässt den Perimeter. Für interne Dokumentationsabfragen, Code-Reviews, Log-Analysen oder alles, was Kundendaten berührt, ist das ein Compliance- und Vertraulichkeitsrisiko, das viele Organisationen nicht akzeptieren können. NIS2 und DSGVO machen das konkreter – nicht weniger.

Selbst-Hosting löst das. Das Modell läuft auf Ihrer Hardware, die Daten verlassen Ihr Netzwerk nie, und Sie kontrollieren Version, Konfiguration und Zugriff.

Die Architektur: zwei Stufen

Das Setup, das ich betreibe, kombiniert zwei Auslieferungsebenen:

Tier 1 – Rechenzentrums-Server (ständig erreichbarer Inferenz-Endpoint)

Ein dedizierter Server in einem Colocation-Rechenzentrum, der OpenClaw als primäres Inferenz-Backend betreibt. Diese Maschine ist immer erreichbar, bearbeitet gleichzeitige Anfragen mehrerer Nutzer oder Dienste und läuft mit Modellen, die in ihren VRAM passen oder in quantisierter Form in den System-RAM.

Tier 2 – GPU-Arbeitsplatz im Büro (lokaler Hochleistungs-Knoten)

Ein Arbeitsplatzrechner mit Consumer- oder Prosumer-GPU im Büro. Mehr Rechenleistung als der Rechenzentrums-Server für große Modelle oder Batch-Jobs. Verbunden mit dem Rechenzentrums-Server über WireGuard-VPN. Nicht permanent online, aber während der Arbeitszeit und für geplante Nachtjobs verfügbar.

Beide Stufen sprechen dieselbe API. Clients müssen nicht wissen, welches Backend eine Anfrage bearbeitet.

Aufbau des Rechenzentrums-Servers

Die Hardware-Anforderungen hängen stark davon ab, welche Modelle Sie betreiben wollen. Ein praktischer Ausgangspunkt für ein Team von 5–15:

• –Ein Server mit 32–64 GB RAM
• –Eine GPU mit 16–24 GB VRAM (z. B. NVIDIA RTX 3090, A4000 oder gleichwertig)
• –Schneller NVMe-Speicher für Modellgewichte
• –Stabiler 1-Gbit-Uplink

OpenClaw-Installation auf Debian/AlmaLinux:

curl -fsSL https://openclaw.ai/install.sh | sh
systemctl enable --now openclaw

Für den Produktivbetrieb schalten Sie den Dienst hinter einen Reverse Proxy (nginx oder Caddy) mit TLS und Basic-Authentifizierung. Geben Sie ihn nur für Ihr VPN-Subnetz frei, nicht für das öffentliche Internet.

Ein Beispiel-nginx-Block:

server {
    listen 443 ssl;
    server_name ai.internal.example.com;

    ssl_certificate     /etc/ssl/certs/internal.crt;
    ssl_certificate_key /etc/ssl/private/internal.key;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        auth_basic "Restricted";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

VPN-Anbindung: WireGuard zwischen Rechenzentrum und Büro

WireGuard ist hier das richtige Werkzeug. Es ist schnell, einfach zu konfigurieren und integriert sich auf beiden Seiten sauber in systemd.

Rechenzentrums-Server (wg0.conf):

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <datacenter-private-key>

[Peer]
PublicKey = <office-public-key>
AllowedIPs = 10.10.0.2/32

Büro-Arbeitsplatz (wg0.conf):

[Interface]
Address = 10.10.0.2/24
PrivateKey = <office-private-key>

[Peer]
PublicKey = <datacenter-public-key>
Endpoint = <datacenter-public-ip>:51820
AllowedIPs = 10.10.0.0/24
PersistentKeepalive = 25

Damit erreicht der Büro-Arbeitsplatz den Rechenzentrums-Server unter 10.10.0.1 und umgekehrt. Beide OpenClaw-Instanzen sehen sich über das private Subnetz.

GPU-Arbeitsplatz im Büro: der Knoten für schwere Rechenlasten

Der Büro-Rechner hat typischerweise mehr VRAM als der Rechenzentrums-Server – ein Arbeitsplatz mit RTX 4090 (24 GB) oder zwei GPUs kann große Modelle in voller Präzision laufen lassen, die anderswo starke Quantisierung bräuchten.

Betreiben Sie hier eine zweite OpenClaw-Instanz, die auf die lokale GPU zeigt:

OPENCLAW_HOST=10.10.0.2 openclaw serve --gpu

Für Routing-Entscheidungen zwischen den beiden Backends kann eine leichte Proxy-Schicht (oder eine einfache Konfiguration in Ihrem Tooling) große Modell-Anfragen an die Büro-Maschine leiten, wenn sie verfügbar ist, und andernfalls an den Rechenzentrums-Server zurückfallen.

Modell-Verwaltung

Eine praktische Modell-Aufteilung:

• –Rechenzentrums-Server: Kleinere, quantisierte Modelle (Bereich 7B–13B) für schnelle Antworten, immer verfügbar, erledigt die meisten alltäglichen Aufgaben.
• –Büro-GPU: Modelle in voller Präzision oder leicht quantisiert (Bereich 30B–70B) für komplexes Reasoning, Code-Generierung, Dokumentenanalyse. Bei Bedarf genutzt.

Modelle laden mit:

openclaw pull mixtral:8x7b
openclaw pull codestral:22b

Modelle werden lokal gespeichert. Ein 7B-Modell mit Q4-Quantisierung braucht grob 4 GB; ein 70B-Modell mit Q4 grob 40 GB. Planen Sie den Speicher entsprechend ein.

Zugriffssteuerung und Audit-Logging

Für ein Team-Setup sollte der Zugriff kontrolliert und nachvollziehbar sein. Ein paar Praktiken, die sich bewährt haben:

• –Pro Nutzer oder pro Dienst eigene API-Keys ausstellen, keine geteilten Credentials
• –Alle Anfragen an der Proxy-Schicht loggen – mit Nutzerkennung, Modell und Zeitstempel
• –Keys nach Zeitplan rotieren und sofort bei Team-Veränderungen
• –Modellgewichte auf verschlüsseltem Speicher halten

Wenn Sie OpenClaw innerhalb eines Kubernetes-Clusters betreiben, deployen Sie es als normalen Workload mit einem Service und steuern den Zugriff über Network Policies und einen Ingress mit Authentication-Middleware.

Was dieses Setup kostet

Grobe Zahlen für ein kleines Team-Setup:

• –Colocation + Server-Hardware (gebraucht): 150–300 EUR/Monat alles inklusive
• –GPU-Arbeitsplatz im Büro (einmalig): 2,000–4,000 EUR
• –Strom (Büro-Arbeitsplatz, im Betrieb): ~50–80 EUR/Monat

Vergleichen Sie das mit API-Kosten bei steigender Nutzung: Bei 10 Millionen Token pro Monat über ein Team erreichen SaaS-API-Kosten je nach Modell leicht 100–500 EUR/Monat – und skalieren linear. Das selbst gehostete Setup hat höhere Anfangskosten, aber eine klare Kostendeckelung und keine Abrechnung pro Token.

Für Teams mit erheblichen AI-Workloads und sensiblen Daten sprechen die Ökonomie und die Compliance-Bilanz gleichermaßen für das Selbst-Hosting.

Praktische Empfehlungen

• –Starten Sie nur mit dem Rechenzentrums-Server. Bringen Sie zunächst ein Modell zuverlässig Ende-zu-Ende zum Laufen, bevor Sie den GPU-Knoten hinzufügen.
• –Verwenden Sie WireGuard für das VPN – nicht OpenVPN, kein Cloud-NAT-Gateway. Es ist einfacher und schneller.
• –Setzen Sie den Inferenz-Endpoint nicht dem öffentlichen Internet aus. Nur-VPN-Zugriff ist die richtige Voreinstellung.
• –Überwachen Sie GPU-Auslastung und Temperatur, besonders am Büro-Arbeitsplatz bei Dauerläufen.
• –Testen Sie Ihr Fallback-Verhalten: Was passiert mit Nutzeranfragen, wenn die Büro-GPU offline ist?

Fazit

KI-Inferenz selbst zu hosten ist nicht mehr exotisch. Die Werkzeuge sind ausgereift, die Hardware ist zugänglich, und der operative Overhead ist vergleichbar mit dem jedes anderen zustandsbehafteten Dienstes. Für Teams mit Data-Residency-Anforderungen oder nennenswerten AI-Nutzungsvolumen ist es die stimmigere Wahl.

Das Zwei-Stufen-Setup – ständig verfügbares Rechenzentrum für den Alltag, lokale GPU für die schweren Fälle – gibt Ihnen Verfügbarkeit und Performance, ohne dass eine einzelne Maschine alles erledigen muss.

Fragen zum Aufbau dieses Setups in Ihrer Umgebung? Melden Sie sich.