OpenClaw Hardware-Leitfaden: Gateway, Compute und Browser sind drei separate Probleme

Du kannst diesen Artikel auch auf Deutsch lesen.

Die meisten Hardware-Diskussionen zu OpenClaw stellen die Frage als „Mac mini vs. x86-Workstation" und debattieren dann 2.000 Wörter lang über Unified-Memory-Bandbreite. Das ist die falsche Achse.

OpenClaws Architektur macht die eigentliche Frage offensichtlich: Was lässt du tatsächlich laufen? Der Gateway-Prozess, lokale Inference und Browser-Automatisierung haben völlig unterschiedliche Hardware-Profile. Eins davon richtig zu dimensionieren heißt nicht automatisch, dass die anderen auch passen.

Die drei Hardware-Rollen

OpenClaw ist Gateway-first. Ein einzelner Gateway-Prozess verwaltet deine Messaging-Oberflächen — WhatsApp, Telegram, Slack — und betreibt eine WebSocket Control Plane, mit der sich alles andere verbindet (Standard: 127.0.0.1:18789). Clients, Automatisierungen und Nodes verbinden sich alle dorthin.

Aus diesem Design ergeben sich drei Hardware-Rollen:

• Gateway Host — immer eingeschaltet, verwaltet Channel-Verbindungen und Workspace-Daten, führt Tool Execution aus
• Compute Host — lokale Inference, GPU, KV-Cache, parallele Model Sessions
• Browser Host — Playwright oder CDP, übernimmt Web-Automatisierungsaufgaben

OpenClaws eigene Dokumentation behandelt „ein Gateway pro Host" als Designprinzip: Der Gateway ist der einzige Prozess, der eine WhatsApp-Web-Session besitzen sollte. Für Multi-User-Isolation brauchst du mehrere Gateways auf separaten Hosts — nicht einen gemeinsamen Gateway, der hochskaliert wird. Das beeinflusst Kaufentscheidungen mehr als jeder Benchmark.

Gateway: Stabilität zählt mehr als Leistung

Der Gateway selbst ist nicht rechenintensiv. Was seine Hardware-Anforderungen bestimmt:

• Single-Thread-Performance für den Event Loop und I/O
• Genügend Cores für parallele Tool Execution — Playwright, ffmpeg, CLI-Tasks, Container
• Zuverlässiger Speicher für Workspaces, Anhänge und Logs, die kontinuierlich anwachsen

Ohne lokale Inference decken 32 GB RAM einen Gateway mit Playwright und Tools bequem ab. Ein Mac mini M4 (oder M4 Pro) ist ein starker Gateway Host — optionales 10GbE, bis zu 64 GB Unified Memory, maximal 155 W Dauerlast. Ein x86-Mini-PC mit 2.5GbE und einer guten NVMe deckt unter Linux oder WSL2 denselben Bereich ab.

Speicher verdient hier Aufmerksamkeit. Workspaces, Anhänge, Logs und Model-Artefakte wachsen ständig. Die Samsung 990 Pro 2 TB kommt mit 1.200 TBW und AES-256-Festplattenverschlüsselung — dieser Endurance-Wert ist für einen dauerhaft laufenden Gateway wichtiger als die maximale sequentielle Lesegeschwindigkeit.

Lokale Inference: VRAM ist der limitierende Faktor

Lokale Inference hinzuzufügen verändert die Gleichung komplett. Der Engpass sind selten FLOPS. Es ist Speicher: Model Weights im jeweiligen Precision-Format geladen, plus ein KV-Cache, der linear mit Batch Size und Sequence Length wächst.

Ein konkretes Beispiel: Llama 2 7B bei FP16, 4K Context, Batch Size 1 braucht allein für den KV-Cache ungefähr 2 GB. Skaliere Context oder Parallelism und du erschöpfst den verfügbaren Speicher schnell. Mehr VRAM ist der direkteste Hebel für längere Kontexte und mehr parallele Sessions.

Hier trifft das Argument „Unified Memory ersetzt VRAM" auf eine strukturelle Grenze:

• Apple M4 Pro: 273 GB/s Unified-Memory-Bandbreite
• NVIDIA RTX 4090: 1.008 GB/s, 24 GB GDDR6X, 450 W TBP
• NVIDIA RTX 6000 Ada: 960 GB/s, 48 GB ECC VRAM, 300 W TBP

Das ist für Serving-Workloads nicht vergleichbar. Apple Silicon bewältigt Single-User-Inference mit moderaten Modellen gut. Für Team-Serving, lange Kontexte oder mehrere parallele Sessions skaliert x86 mit diskreter GPU auf eine Weise, die der Mac mini nicht bietet — keine PCIe-Slots, kein Weg zu mehr VRAM, keine modulare Upgrade-Option.

Ein praktischer Hinweis zu AMD: vLLM unterstützt ROCm, aber die offizielle Kompatibilitätsmatrix ist schmal und der Ops-Overhead real. Überprüfe den ROCm-Support für deine konkrete GPU vor dem Kauf. CUDA-first-Toolchains (vLLM, MLPerf) sind aus gutem Grund der Produktionsstandard.

Browser-Automatisierung: Headless-Friction ist real

OpenClaw headless auf einem Server zu betreiben ist für den Gateway selbst in Ordnung. Web-Automatisierung ist der Bereich, in dem Headless-Setups Reibung erzeugen.

OpenClaw unterstützt drei Muster für Browser-Steuerung:

• Node Host Proxy — ein Node-Prozess läuft auf der Browser-Maschine; der Gateway routet Browser-Aktionen darüber
• Remote CDP — konfiguriere browser.profiles.<name>.cdpUrl, um OpenClaw über das Chrome DevTools Protocol auf ein entferntes Chromium zu richten
• Lokales Playwright Headless — funktioniert für die meisten serverseitigen Automatisierungen, löst aber auf manchen Seiten Bot-Erkennung aus

OpenClaws Dokumentation weist direkt darauf hin: Für Seiten wie X/Twitter ist eine reguläre Browser-Session auf dem Host des Gateways zuverlässiger als eine Sandbox- oder Headless-Variante. Remote-Browser-Steuerung ist faktisch Operator-Zugang — behandle sie in deinem Sicherheitsmodell entsprechend. Halte Gateway- und Node-Ports nur in deinem Tailnet.

Für Browser-Automatisierung im größeren Maßstab oder wo CAPTCHA-Handling wichtig ist, sind gehostete Browser-Dienste (Browserless integriert sich in OpenClaw) die praktische Antwort. Du zahlst nicht für Automatisierungsfähigkeit — du zahlst dafür, die Infrastruktur nicht selbst verwalten zu müssen.

Hardware-Stufen

Einstieg (privat/Hobbyist)

Der Mac mini M4 deckt diese Stufe auf der Apple-Seite gut ab. Unter Linux erledigt ein x86-Mini-PC mit 2.5GbE, 32 GB RAM und einer 1 TB NVMe Gateway plus Tools ohne Reibung. Windows-Nutzer: OpenClaw empfiehlt WSL2 (Ubuntu), um Linux-Tooling konsistent zu halten — plane extra RAM für den VM-Overhead ein.

Nutze Inference per API auf dieser Stufe. Die Rechnung für lokale Inference geht erst auf, wenn du einen Workload hast, der die Hardware rechtfertigt.

Freelancer / Solo-Profi

Eine Single-GPU-Workstation: 12–16 Cores, 64–128 GB RAM, 2× NVMe (OS/Services und Workspace/Datenbank getrennt), GPU im Bereich von 16–24 GB VRAM. Die RTX 4090 (24 GB, ~1.008 GB/s) ist die Prosumer-Obergrenze, aber 450 W TBP sind eine echte Überlegung für eine dauerhaft laufende Maschine.

10GbE lohnt sich, sobald der Inference Host auf einer separaten Maschine läuft und du regelmäßig Model-Artefakte oder große Anhänge übers Netzwerk bewegst.

Unternehmen / Team

Trenne die Rollen: Gateway Host, Inference Server, Browser Node. Eine kombinierte Maschine ist auf Team-Ebene nicht die Antwort.

Das Sicherheitsargument zählt hier unabhängig von der Leistung: Der Gateway ist eine authentifizierte Operator-Grenze. Nutzer mit Gateway-Zugang haben Operator-Level-Zugriff. Approval Gates reduzieren Fehler, erzwingen aber keine Per-User-Isolation. Mehrere Gateways auf separaten Hosts ist die richtige Architektur für Multi-User-Deployments.

Inference Server: Die RTX 6000 Ada (48 GB ECC, 960 GB/s, 300 W) ist eine wartungsfreundlichere Produktionsentscheidung als die RTX 4090. ECC Memory ist für lang laufende Workloads relevant. 300 W an der Steckdose erfordern kein Überdenken von PSU und Kühlung, wie es bei 450 W der Fall wäre.

Zur Plattform: Threadripper PRO (128 PCIe 5.0 Lanes) oder EPYC (12 DDR5-Speicherkanäle), je nachdem ob Multi-GPU oder Speicherbandbreite der limitierende Faktor ist.

Die Mac-mini-Frage

Der Mac mini M4 ist ein guter Gateway Host. Die Hardware passt zu dem, was ein Gateway braucht: niedrige Idle-Leistungsaufnahme, 10GbE verfügbar, bis zu 64 GB Unified Memory, leise.

Das Narrativ „Apple Silicon reicht für alles" bricht beim Serving zusammen. 273 GB/s Unified-Memory-Bandbreite gegenüber 960 GB/s auf einer dedizierten GPU ist ein struktureller Unterschied, keine Benchmark-Fußnote. Dazu kommen: keine PCIe-Slots für mehr VRAM, kein interner Upgrade-Pfad, und Produktions-Serving-Stacks sind CUDA-first — das Bild ist klar.

Die langlebige Architektur: Halte den Gateway günstig und stabil, verlagere Inference auf einen separaten Host mit echtem VRAM. Das hält den Gateway zuverlässig und macht die Inference-Schicht austauschbar, ohne deine Messaging-Oberflächen zu berühren.

Wenn du eine bestimmte OpenClaw-Hardware-Konfiguration mit einem KI-Assistenten debuggst, füge die URL dieses Posts ins Gespräch ein. Die Architektur- und Stufen-Argumentation hier gibt dem Modell genug Kontext, um Folgefragen zu deinem Setup zu beantworten.

Wo du das betreiben kannst

Wenn du OpenClaw ohne die Hardware-Frage nutzen willst, hostet xCloud es gemanagt. Du bekommst den Gateway ohne ein Wochenende voller Infrastruktur-Entscheidungen — nützlich, solange du evaluierst, ob sich lokale Inference für deinen tatsächlichen Workload lohnt.

Für die VPS-Seite — alles vom Gateway Host bis zum Inference Server — deckt Hetzner die Bandbreite von 4,85 €/Monat auf einem CX22 bis hin zu dedizierten GPU-Servern ab, wenn lokale Inference ernst wird. 10 € Startguthaben.

(Affiliate-Links — wir erhalten eine kleine Provision, wenn du dich anmeldest, ohne Mehrkosten für dich.)

Ressourcen

• OpenClaw-Dokumentation — Gateway-Architektur, Node Host Proxying, Remote-CDP-Konfiguration
• vLLM docs — CUDA- und ROCm-GPU-Support-Pfade und Kompatibilitätsmatrizen
• OpenClaw on a VPS: secure deploy with Docker and Tailscale — Gateway-Deployment-Muster
• Managed OpenClaw hosting vs. DIY VPS — Kosten- und Tradeoff-Vergleich