OpenClaw + Qwen 3.5 auf eigenem Kubernetes-Cluster: KI-Agenten mit vLLM, Docker und DGX Spark lokal betreiben

Carl Bednorz

|5 min read

OpenClaw hat sich innerhalb weniger Monate zum meistdiskutierten Open-Source-KI-Agenten entwickelt — 190.000 GitHub Stars, ein wachsendes Ökosystem von über 10.700 Skills und eine Community, die zwischen Begeisterung und berechtigten Security-Bedenken pendelt. Was dabei oft übersehen wird: OpenClaw ist vollständig self-hostbar und lässt sich mit lokalen Modellen betreiben — komplett ohne Cloud-API-Anbindung.

Mit der Veröffentlichung von Alibabas Qwen 3.5 122B-A10B unter Apache-2.0-Lizenz und der Möglichkeit, dieses Frontier-Modell über vLLM auf eigener GPU-Infrastruktur zu serven, entsteht ein Stack, der für uns als Studio für Künstliche Intelligenz besonders spannend ist: Ein vollwertiger KI-Agent auf komplett lokaler Infrastruktur — DSGVO-konform, ohne Token-Kosten, ohne Abhängigkeit von externen Providern.

Wir bei Surfgreen.dev bauen gerade diesen Stack auf und testen ihn im Produktivbetrieb. Hier ist unser Ansatz.

Die Architektur: Drei Schichten, ein Cluster

Unser Setup besteht aus drei Kernkomponenten, die auf einem Kubernetes-Cluster laufen:

vLLM als Model-Serving-Layer — hostet Qwen 3.5 122B-A10B mit OpenAI-kompatibler API
OpenClaw als KI-Agent — verbindet sich über die OpenAI-kompatible API mit vLLM
Kubernetes als Orchestrierungsschicht — für Skalierung, Isolation und Lifecycle-Management

Der Vorteil dieser Architektur: Jede Schicht ist austauschbar. Modell-Upgrade? Neues vLLM-Deployment, OpenClaw zeigt auf den neuen Endpoint. Mehr Last? Kubernetes skaliert horizontal. Security-Incident? Network Policies isolieren den Blast Radius.

Schicht 1: Qwen 3.5 122B mit vLLM serven

vLLM ist der De-facto-Standard für hochperformantes LLM-Serving. Es bietet eine OpenAI-kompatible API, Tensor Parallelism über mehrere GPUs und — entscheidend für MoE-Modelle wie Qwen 3.5 — Expert Parallelism.

vLLM als Docker-Container starten

docker run --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  --ipc=host \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen3.5-122B-A10B \
  --tensor-parallel-size 2 \
  --max-model-len 65536 \
  --enable-expert-parallel \
  --trust-remote-code \
  --api-key "surfgreen-local-key"

Für das 122B-Modell empfehlen wir mindestens zwei A100-80GB oder vergleichbare GPUs mit --tensor-parallel-size 2. Mit dem Flag --enable-expert-parallel werden die MoE-Experten-Layer optimal auf die verfügbaren GPUs verteilt.

vLLM auf Kubernetes deployen

vllm-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-qwen35
  namespace: ai-serving
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm-qwen35
  template:
    metadata:
      labels:
        app: vllm-qwen35
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
          - "--model"
          - "Qwen/Qwen3.5-122B-A10B"
          - "--tensor-parallel-size"
          - "2"
          - "--max-model-len"
          - "65536"
          - "--enable-expert-parallel"
          - "--trust-remote-code"
        ports:
        - containerPort: 8000
        resources:
          limits:
            nvidia.com/gpu: 2
        env:
        - name: HUGGINGFACEHUB_TOKEN
          valueFrom:
            secretKeyRef:
              name: hf-secret
              key: token
        volumeMounts:
        - name: model-cache
          mountPath: /root/.cache/huggingface
        livenessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 120
          periodSeconds: 30
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 120
          periodSeconds: 10
      volumes:
      - name: model-cache
        persistentVolumeClaim:

          claimName: model-cache-pvc

apiVersion: v1
kind: Service
metadata:
  name: vllm-qwen35-svc
  namespace: ai-serving
spec:
  selector:
    app: vllm-qwen35
  ports:

port: 8000
targetPort: 8000
type: ClusterIP

Der ClusterIP-Service stellt sicher, dass vLLM nur cluster-intern erreichbar ist — kein externer Zugriff auf den Inference-Endpoint.

Schicht 2: OpenClaw mit vLLM verbinden

OpenClaw unterstützt vLLM nativ als Model Provider über die openai-completions-API. Die Konfiguration erfolgt in der openclaw.json:

{
  "models": {
    "providers": {
      "local-qwen": {
        "baseUrl": "http://vllm-qwen35-svc.ai-serving:8000/v1",
        "apiKey": "surfgreen-local-key",
        "api": "openai-completions",
        "models": [
          {
            "id": "Qwen/Qwen3.5-122B-A10B",
            "name": "Qwen 3.5 122B Local",
            "reasoning": true,
            "input": ["text"],
            "cost": {
              "input": 0,
              "output": 0
            },
            "contextWindow": 65536,
            "maxTokens": 16384
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "local-qwen/Qwen/Qwen3.5-122B-A10B"
      }
    }
  }
}

Wichtig: Die id unter models muss exakt dem Modell-Identifier entsprechen, der an vllm serve übergeben wurde. Bei Abweichungen lehnt vLLM die Anfragen ab.

OpenClaw als Docker-Container

docker run -d \

  --name openclaw \

  -v ~/.openclaw:/root/.openclaw \

  -v ~/openclaw/workspace:/workspace \

  -e OPENCLAW_SKIP_API_KEY_CHECK=true \

  --network ai-network \

  alpine/openclaw:latest

Schicht 3: Security Hardening — nicht optional

OpenClaw hat Shell-Zugriff, liest Dateien und verarbeitet Eingaben aus potenziell nicht vertrauenswürdigen Quellen. In einer Kubernetes-Umgebung sind folgende Maßnahmen Pflicht:

Network Policy: OpenClaw isolieren

networkpolicy-openclaw.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: openclaw-isolation
  namespace: ai-agents
spec:
  podSelector:
    matchLabels:
      app: openclaw
  policyTypes:

Egress
egress:
# Nur Zugriff auf vLLM erlauben

to:

namespaceSelector:
matchLabels:
  name: ai-serving
ports:

port: 8000
protocol: TCP
# DNS erlauben

to:

namespaceSelector: {}
ports:

port: 53
protocol: UDP

Secrets nicht im Klartext

Kubernetes Secrets sind nur base64-kodiert — nicht verschlüsselt. Für Production-Setups empfehlen wir HashiCorp Vault oder den External Secrets Operator

DGX Spark: Unser Testkandidat für den Desktop

Parallel zum Kubernetes-Cluster testen wir den NVIDIA DGX Spark als kompakte Alternative für lokale KI-Inferenz. Die Specs sind beeindruckend: Grace Blackwell Superchip, 128 GB kohärenter CPU-GPU-Speicher, bis zu 1 Petaflop KI-Rechenleistung — in einem Desktop-Formfaktor.

Für uns ist der DGX Spark besonders als Edge-Device für kleinere Modelle und als Entwicklungsmaschine interessant. Die Benchmark-Ergebnisse aus der Community zeigen: Mit NVFP4-Quantisierung und vLLM erreicht der DGX Spark auf einem 120B-Modell rund 38 Tokens pro Sekunde — und bei der Prompt-Verarbeitung ist er sogar schneller als ein 3x RTX 3090 Setup.

Für das volle Qwen 3.5 122B-A10B reicht der DGX Spark allein nicht — aber mit Dual-Node-Setup (2x DGX Spark über ConnectX-7 mit 200 Gbps verbunden) werden in der Community bereits 75 tok/s auf vergleichbaren Modellen berichtet. Wir testen gerade, wie sich das in unserem Workflow anfühlt — insbesondere für Entwicklung und lokales Prototyping, bevor wir auf den Kubernetes-Cluster deployen.

#vLLM auf DGX Spark starten (einzelner Node)

vllm serve Qwen/Qwen3.5-122B-A10B \
  --quantization nvfp4 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.95 \
  --api-key "dgx-local"

Warum wir diesen Stack bauen

Die Motivation ist klar: Datensouveränität, Kosteneffizienz und Unabhängigkeit.

Ein Cloud-basierter KI-Agent mit kommerziellem Modell kostet bei intensiver Nutzung schnell 500–1.000 Euro pro Monat und Nutzer. Die Daten fließen an externe Provider — bei sensiblen Unternehmensdaten ein K.O.-Kriterium. Und die Abhängigkeit von einer einzigen API bedeutet: Wenn der Provider seine Preise ändert, die API umstellt oder den Service einstellt, steht man ohne Alternative da.

Mit dem Stack aus OpenClaw + vLLM + Qwen 3.5 auf eigenem Kubernetes-Cluster:

Keine Token-Kosten — einmal Hardware, dann Flatrate
Volle DSGVO-Compliance — kein Byte verlässt das eigene Netzwerk
Modell-Flexibilität — Qwen heute, Llama morgen, Mistral übermorgen
Skalierbar — von einem DGX Spark auf dem Schreibtisch bis zum Multi-GPU-Cluster

Fazit: Der KI-Agent, der dir gehört

OpenClaw auf lokaler Infrastruktur mit einem Frontier-Modell wie Qwen 3.5 122B zu betreiben ist heute keine Zukunftsmusik mehr — es ist ein konkreter, umsetzbarer Stack. Die Kombination aus Docker-basiertem Deployment, vLLM als hochperformantem Serving-Layer und Kubernetes für Orchestrierung und Security bildet eine solide Grundlage für Unternehmen, die KI-Agenten produktiv einsetzen wollen, ohne die Kontrolle über ihre Daten abzugeben.

Wir bei Surfgreen.dev begleiten Unternehmen bei genau diesem Weg — vom initialen Proof of Concept über das Hardware-Sizing bis zum Production-Deployment. Der DGX Spark als Einstiegs- und Entwicklungsgerät, ein Kubernetes-Cluster für Production — die Bausteine sind da.

Wer diesen Stack für sein Unternehmen evaluieren möchte — sprecht uns an.

Quellen: OpenClaw Docker Docs, OpenClaw Model Providers, vLLM Qwen 3.5 Recipe, NVIDIA DGX Spark, OpenClaw Helm Chart, DGX Spark Benchmarks