mission-control-v2/docs/ZEROCLAW_POC_BRIEF.md

Brief: ZeroClaw-PoC als Lucys schlanker Agent-Runtime (Latenz-Fix an der Wurzel)

Für eine frische Claude-Code-Session. Aufgabe: ZeroClaw (ultraleichter Rust-Agent) als risikoarmen Proof-of-Concept neben Hermes aufsetzen und gegen Hermes benchmarken (Prompt-Größe + Latenz). Hermes bleibt unangetastet parallel laufen — null Risiko für die laufende Lucy.

Warum (die ganze Vorgeschichte in Kürze)

Lucy (Hermes-Agent, Hirn = gemma-4-26B-A4B) braucht ewig zum Antworten (Output top, aber 20–80 s/Turn). Eine sehr lange Latenz-Jagd (2026-06-30) hat die Ursachen definitiv geklärt:

1. mem0 nutzte fast (Qwen) als LLM (MEM0_LLM_MODEL=fast) — das war noch von früher, als fast Lucys Hirn WAR. Nach dem Umzug auf gemma blieb mem0 auf fast → jede Erinnerungs-Op lud fast → verdrängte gemmas Warm-Gruppe → gemma-KV-Cache tot → 40 s Re-Prefill. (Halb-fertige Hirn-Migration.)
2. gemma ist architektonisch langsam auf Vulkan/Strix-Halo. Verifiziert am Box-GGUF: attention.key/value_length = 512 (head_dim 512!) vs. Qwen3.6 256, plus mixed sliding/full attention → Flash-Attention auf RADV ineffizient → langsamer Prefill + CPU-Spike (teils CPU-Fallback). gemma-GENERIERUNG ist ok (~93 t/s), gecachter Prompt 0,3 s — nur Cache-Misses (Prefill, ~11–27 s) sind tödlich.
3. gemmas Thinking ist per Default AN (~90 Extra-Tokens/Antwort). Abschaltbar NUR via chat_template_kwargs:{enable_thinking:false} (verifiziert; /no_think & reasoning_effort wirken nicht).
4. Hermes selbst ist Schwergewicht — DER eigentliche Overhead: 20k-Token-Prompt = 79 Tool-Schemas (~17,5k) + Skills-Manifest (27 Skills, ~8,7k) + 3-Schichten-Memory mit Auto-Injektion. Die Auto-Injektion variiert den Prompt jeden Turn → bricht gemmas Cache → Re-Prefill.

Verdikt: Auch nach JEDEM Fix (Eviction behoben: mem0/aux→fast + fast ko-resident; Slot geschützt; Thinking aus; Auto-Injektion aus; RADV ✓; FA ✓; single-slot cache-reuse) blieb gemma 6–80 s, unzuverlässig — der Prozess lief stabil (kein Crash/Eviction), aber gemmas Prefill kommt mit Hermes' pro-Turn-wechselndem 20k-Prompt nicht klar. gemma ist auf dieser HW+Agent fundamental ungeeignet für verlässlich niedrige Latenz. Einziger gemma-Vorteil: deutlich besseres Deutsch (Qwen leakt englische Wörter, z.B. „biggest"; gemma = natürlich + echte Umlaute).

Die These des PoC

Hermes' Schwergewicht (Skills + ChromaDB + Auto-Injektion) baut den fetten, instabilen Prompt. Ein schlanker Agent (ZeroClaw: 3,4 MB Rust, SQLite-Memory statt ChromaDB, minimaler Overhead, „ruthless about cutting") würde einen kleinen, STABILEN Prompt bauen → gemmas langsamer Prefill hat kaum was zu kauen → Lucy schnell mit gemma UND Qwen → gemmas Deutsch gerettet + Lucy entschlackt. Wurzel-Fix statt Modell-Pflaster.

PoC-Aufgabe (risikoarm, Hermes bleibt parallel)

1. ZeroClaw auf die Box holen (Rust-Binary; Repos: github.com/zeroclaw-labs/zeroclaw bzw. github.com/elev8tion/zeroclaw — beides prüfen, das gepflegtere/passende nehmen). Eigener Port, NICHT :8642 (Hermes) anfassen.
2. An euer MC2-Gateway hängen (OpenAI-kompatibel, http://127.0.0.1:9001/v1). Erst mit Modell fast (Qwen, schnell) testen, dann hermes (gemma) für den Deutsch-Vergleich.
3. Nur Kern-Tools zuerst: Memory (ZeroClaw-eigenes SQLite ODER per MCP an mc2-memory) + 1–2 Stack-Tools. Eure bestehenden MCP-Server (hermes-pc-control, mission-control-stack, mission-control-memory, hermes-web-fetch) kann ZeroClaw als MCP-Client mitnutzen.
4. Benchmark gegen Hermes (Zahlen, nicht Gefühl):
   • Prompt-Größe (prompt_tokens) eines simplen Turns: ZeroClaw vs. Hermes (Hermes ≈ 20.000).
   • Latenz mehrerer Folge-Turns (Cache-Verhalten): wird der Prompt klein+stabil → cached gemma → schnell?
   • Messmethode wie in der Saga: curl an den Agent + /v1/chat/completions-usage.prompt_tokens + llama-swap-POST-Dauer (journalctl -u llama-swap).
5. Entscheidung: Wird Lucy mit ZeroClaw schnell (idealerweise mit gemma) → voller Umzug planen (Persona, Memory-Migration mem0/Chroma→SQLite, MCP-Tools, Telegram/Voice). Wenn nicht → Fallback: Lucys Hirn auf Qwen3.6-35B-A3B (schnell+verlässlich) + harte Deutsch-Direktive im System-Prompt.

Box-Fakten (für den PoC)

• Box: ssh hitonabi@192.168.178.151 (key-based). Strix Halo, 122 GB, GTT ~124 GB, Vulkan/RADV.
• MC2-Gateway: :9001/v1 (OpenAI-kompat). Aliase: hermes→gemma-4-26B (Lucys Hirn), fast→Qwen3.6-35B, heavy→Qwen3.5-122B, coder/coder-lite, vision→Qwen3-VL-8B, embed→Qwen3-Embedding.
• llama-swap: :8080 (Engine v9843, Vulkan/RADV, --list-devices zeigt nur die RADV-GPU — kein llvmpipe-Fallback). gemma-cmd: -c 65536 -fa on --cache-reuse 256 -cram 16384 + MTP-Draft.
• Hermes: :8642 (NousResearch), Config ~/.hermes/config.yaml, API-Key in ~/.hermes/.env (API_SERVER_KEY). 4 MCP-Server aktiv. NICHT anfassen — bleibt Lucys Live-Agent bis ZeroClaw steht.
• mem0-Sidecar: :8765 (~/.mem0/, Chroma unter /srv/models/mem0/chroma), MEM0_LLM_MODEL=fast, MEM0_EMBED_MODEL=embed. Systemd-User-Unit ~/.config/systemd/user/mem0-service.service.
• brains-Gruppe (immer warm, ko-resident): gemma + fast + embed + vision.

Modell-Kandidaten (falls Fallback/Vergleich)

Modell	Profil	Speed (Strix Halo)	Deutsch
gemma-4-26B-A4B	head_dim 512, Thinking, multimodal	langsam (Prefill)	exzellent
Qwen3.6-35B-A3B (auf Box)	head_dim 256, GQA kv=2	~85–100 t/s	gut, aber English-Leaks
Qwen3-30B-A3B-Instruct	gleiche Familie	755 pp / 85 tg (RADV)	wie Qwen3.6
LFM2-8B-A1B (Liquid)	8B/1B aktiv, Hybrid Conv+MoE	~170 t/s	klein → unsicher Deutsch

Leitplanken

• Hermes/Lucy bleibt live — PoC läuft isoliert (eigener Port, eigene Memory-Datei). Null Risiko.
• Vor Box-Config-Änderungen Backup; llama-swap reloadt per -watch-config.
• Erst messen (Prompt-Größe + Latenz), dann über vollen Umzug entscheiden.