Inside OpenClaw #5: Production-Ready KI auf WSL2

“Läuft doch” — bis Montagmorgen

Sie haben vLLM installiert, das Modell geladen, die richtigen Flags gesetzt. Der Agent antwortet, die Tool-Calls funktionieren. Sie gehen freitags aus dem Büro. Am Montag ist der Inference-Server tot.

Keine Fehlermeldung. Kein Crash-Log. WSL2 hat einfach aufgehört zu laufen. Produktionsstabilität von KI-Systemen ist ein Aspekt meiner KI & Automatisierungs-Beratung.

In der OpenClaw-Serie haben wir beschrieben, wie unser KI-Agent lokal auf einer einzelnen GPU arbeitet. Dieser Artikel beschreibt, was nötig war, um das System von “funktioniert auf meinem Rechner” zu “läuft 24/7 ohne Eingriff” zu bringen.

Das Grundproblem: WSL2 ist kein Server

Microsoft hat WSL2 als Entwicklungsumgebung gebaut. Für Programmierer, die tagsüber Linux-Tools brauchen und abends den Rechner herunterfahren. Nicht für einen Inference-Server, der rund um die Uhr erreichbar sein muss.

Drei Schwachstellen machen WSL2 im Rohzustand produktionsuntauglich:

• Idle-Shutdown: Die VM fährt nach Inaktivität herunter — inklusive aller Dienste
• Speicherverwaltung: Ohne explizite Limits frisst WSL2 den gesamten RAM oder wird vom System gekillt
• Netzwerk-Instabilität: NAT-Networking verursacht DNS-Ausfälle und abgebrochene Verbindungen

vmIdleTimeout: Der stille Killer

WSL2 erkennt, ob Prozesse aktiv sind. Wenn aus Sicht des Hypervisors nichts passiert — etwa weil der Inference-Server auf Requests wartet — kann die VM nach einigen Minuten heruntergefahren werden.

Für einen KI-Agenten ist das katastrophal. Die Lösung steht in der .wslconfig:

# %USERPROFILE%\.wslconfig
[wsl2]
vmIdleTimeout=-1

vmIdleTimeout=-1 deaktiviert den Idle-Timeout vollständig. Die VM läuft, bis Sie sie manuell stoppen oder den Rechner herunterfahren. Ohne diesen Eintrag verlieren Sie Ihren Inference-Server jedes Mal, wenn er ein paar Minuten keine Anfragen bekommt.

Speicher explizit kontrollieren

Standardmäßig kann WSL2 bis zu 50% des Host-RAM beanspruchen — oder mehr, wenn Windows es zulässt. Das klingt großzügig, aber bei einem System mit 64 GB RAM, einer RTX 4090 und einem 24B-Modell wird es eng:

• vLLM braucht System-RAM für Tokenizer, Scheduling und KV-Cache-Overflow
• Der Gateway-Prozess verwaltet Sessions, Tool-Aufrufe und Kontext
• Linux selbst braucht Speicher für systemd, Cron und Netzwerk-Stack

Unsere .wslconfig für den Produktivbetrieb:

[wsl2]
vmIdleTimeout=-1
memory=24GB
swap=8GB
processors=8

• memory=24GB: Festes Limit. Verhindert, dass WSL2 Windows in die Knie zwingt, und schützt vor OOM-Kills durch den Host.
• swap=8GB: Fängt Lastspitzen ab, ohne dass Prozesse sterben.
• processors=8: Begrenzt die CPU-Kerne. Auf einem 16-Kern-System bleibt so genug für Windows.

systemd: Dienste richtig verwalten

Seit 2022 unterstützt WSL2 systemd nativ. Das ist ein Gamechanger — denn damit können Sie vLLM und den OpenClaw-Gateway als echte Linux-Dienste betreiben, mit automatischem Neustart bei Absturz:

# /etc/systemd/system/vllm.service
[Unit]
Description=vLLM Inference Server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/opt/vllm/start.sh
Restart=always
RestartSec=10
Environment=CUDA_VISIBLE_DEVICES=0

[Install]
WantedBy=multi-user.target

Wichtig dabei:

• Restart=always startet den Dienst nach jedem Absturz neu — auch nach OOM-Kills
• After=network-online.target wartet auf eine funktionierende Netzwerkverbindung
• RestartSec=10 gibt der GPU 10 Sekunden zum Freigeben des VRAM

Aktivieren Sie systemd in der wsl.conf:

# /etc/wsl.conf
[boot]
systemd=true

Netzwerk stabilisieren

WSL2 nutzt standardmäßig NAT-Networking. Das bedeutet: Die Linux-VM hat eine interne IP, und Windows leitet Ports weiter. In der Praxis führt das zu zwei Problemen:

• DNS-Ausfälle: Der automatisch generierte /etc/resolv.conf zeigt auf einen Windows-DNS-Proxy, der gelegentlich nicht antwortet
• Verbindungsabbrüche: Langlebige HTTP-Verbindungen zum Inference-Server werden durch NAT-Timeouts gekappt

Unsere Lösung für DNS:

# /etc/wsl.conf
[network]
generateResolvConf=false

# /etc/resolv.conf
nameserver 8.8.8.8
nameserver 1.1.1.1

Für stabile Erreichbarkeit von außen richten wir Port-Forwarding über netsh ein, statt uns auf die automatische Weiterleitung zu verlassen.

Keepalive: Nicht einschlafen lassen

Selbst mit vmIdleTimeout=-1 empfehlen wir einen aktiven Keepalive. Ein systemd-Timer prüft alle 60 Sekunden, ob der Inference-Server antwortet — und startet ihn bei Bedarf neu:

#!/bin/bash
# /opt/openclaw/keepalive.sh
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" \
  --max-time 10 http://localhost:8000/health)

if [ "$RESPONSE" != "200" ]; then
  systemctl restart vllm
  logger "OpenClaw Keepalive: vLLM neugestartet (HTTP $RESPONSE)"
fi

Dieses Skript hat uns in drei Monaten Betrieb sieben unbemerkte Ausfälle erspart. Ohne Monitoring kein stabiler Betrieb.

Backup: Wiederherstellung in Minuten

WSL2-Distributionen lassen sich als tar-Archiv exportieren:

wsl --export Ubuntu-OpenClaw D:\Backups\openclaw-backup.tar

Bei einem Totalausfall steht damit in unter fünf Minuten eine funktionsfähige Kopie bereit. Konfigurationsdateien — .wslconfig, systemd-Units, Skripte — versionieren wir zusätzlich in Git.

Fazit für die Praxis

Der Unterschied zwischen “funktioniert” und “läuft produktiv” ist bei WSL2 keine Code-Frage. Es ist reine Konfiguration. Sechs Dateien entscheiden darüber, ob Ihr lokaler KI-Agent am Montagmorgen noch läuft:

• .wslconfig — Idle-Timeout, RAM, Swap, CPU
• /etc/wsl.conf — systemd, DNS
• systemd-Units — Dienstverwaltung mit Auto-Restart
• Keepalive-Skript — Aktive Überwachung
• Backup-Routine — Wiederherstellung ohne Neuaufbau

WSL2 macht lokale KI auf Windows zugänglich, ohne Dual-Boot oder dedizierte Server-Hardware. Aber produktionsstabil wird es erst durch gezielte Härtung.

Nächster Schritt

Sie betreiben lokale KI-Infrastruktur und wollen Ausfälle vermeiden? Ich helfe Ihnen, den Schritt von der Entwicklung in den Dauerbetrieb zu machen.

→ Erstgespräch vereinbaren — kostenfrei

→ Oder zuerst mehr lesen: Lokales LLM als KI-Agent — ohne Cloud