[Projekt] KI-Server Umbau: Lokaler Coding-Agent + Cloud-Monitoring #75

New issue

Open

opened 2026-04-10 19:24:29 +00:00 by orbitalo · 2 comments

orbitalo commented

2026-04-10 19:24:29 +00:00

Owner

Ziel

Cursor-Kosten (~€500/Monat) durch lokalen Coding-Agent auf KI-Server (RTX 3090) ersetzen.
Hausmeister-Bot in die Cloud verschieben um GPU komplett freizumachen.

Phase 1: Hausmeister in die Cloud (1h)

Grok 4.1 Fast als Backend fuer Hausmeister-Bot testen (CT 116)
monitor.py auf OpenRouter API umstellen statt lokales Ollama
Vision-Checks identifizieren — braucht er wirklich VL?
Wenn ja: guenstiges Vision-Modell waehlen (Gemini Flash, GPT-5.4 Nano)
Ollama Qwen3-VL 30B vom KI-Server entladen
Kosten monitoren (Ziel: unter €10/Monat)

Phase 2: Qwen3-Coder-Next installieren (1h)

ollama pull qwen3-coder-next auf KI-Server
Testlauf: einfaches Coding-Problem loesen lassen
Tool-Calling testen (SSH, Forgejo, OpenMemory)
Geschwindigkeit messen (Ziel: >10 tok/s)
VRAM-Verbrauch pruefen (muss in 24GB passen)

Phase 3: OpenCode auf lokales Modell umstellen (30min)

opencode.json: model auf lokales Ollama Endpoint zeigen
MCP-Tools testen mit lokalem Modell
Vergleichstest: gleiche Aufgabe mit Grok 4.1 Fast vs lokal

Phase 4: Praxistest (1 Woche)

Eine Woche nur mit lokalem Coder arbeiten
Cursor nur bei Bedarf oeffnen
Cloud-Kosten tracken
Qualitaet dokumentieren: wo reicht es, wo nicht

Erfolgskriterien

Lokaler Coder schafft 80%+ der taeglichen Aufgaben
Cloud-Kosten sinken von €500 auf unter €50/Monat
Hausmeister laeuft stabil in der Cloud
Keine spuerbare Verschlechterung im Homelab-Monitoring

Hardware

KI-Server: RTX 3090 24GB, 64GB RAM, Windows
Modell: Qwen3-Coder-Next (80B MoE, 3B aktiv, Apache 2.0)
SWE-Bench: 70.6% (87% von Claude Opus)

Kostenschaetzung

Vorher	Nachher
Cursor + OpenRouter: ~€500/Monat	Cloud-Monitoring: ~€10/Monat
Lokal: Qwen3-VL (Hausmeister)	Lokal: Qwen3-Coder-Next (Coding)
Gesamt: ~€500	Gesamt: ~€30 (€10 Cloud + €20 Cursor Reserve)

## Ziel Cursor-Kosten (~€500/Monat) durch lokalen Coding-Agent auf KI-Server (RTX 3090) ersetzen. Hausmeister-Bot in die Cloud verschieben um GPU komplett freizumachen. ## Phase 1: Hausmeister in die Cloud (1h) - [ ] Grok 4.1 Fast als Backend fuer Hausmeister-Bot testen (CT 116) - [ ] monitor.py auf OpenRouter API umstellen statt lokales Ollama - [ ] Vision-Checks identifizieren — braucht er wirklich VL? - [ ] Wenn ja: guenstiges Vision-Modell waehlen (Gemini Flash, GPT-5.4 Nano) - [ ] Ollama Qwen3-VL 30B vom KI-Server entladen - [ ] Kosten monitoren (Ziel: unter €10/Monat) ## Phase 2: Qwen3-Coder-Next installieren (1h) - [ ] `ollama pull qwen3-coder-next` auf KI-Server - [ ] Testlauf: einfaches Coding-Problem loesen lassen - [ ] Tool-Calling testen (SSH, Forgejo, OpenMemory) - [ ] Geschwindigkeit messen (Ziel: >10 tok/s) - [ ] VRAM-Verbrauch pruefen (muss in 24GB passen) ## Phase 3: OpenCode auf lokales Modell umstellen (30min) - [ ] opencode.json: model auf lokales Ollama Endpoint zeigen - [ ] MCP-Tools testen mit lokalem Modell - [ ] Vergleichstest: gleiche Aufgabe mit Grok 4.1 Fast vs lokal ## Phase 4: Praxistest (1 Woche) - [ ] Eine Woche nur mit lokalem Coder arbeiten - [ ] Cursor nur bei Bedarf oeffnen - [ ] Cloud-Kosten tracken - [ ] Qualitaet dokumentieren: wo reicht es, wo nicht ## Erfolgskriterien - Lokaler Coder schafft 80%+ der taeglichen Aufgaben - Cloud-Kosten sinken von €500 auf unter €50/Monat - Hausmeister laeuft stabil in der Cloud - Keine spuerbare Verschlechterung im Homelab-Monitoring ## Hardware - KI-Server: RTX 3090 24GB, 64GB RAM, Windows - Modell: Qwen3-Coder-Next (80B MoE, 3B aktiv, Apache 2.0) - SWE-Bench: 70.6% (87% von Claude Opus) ## Kostenschaetzung | Vorher | Nachher | |--------|--------| | Cursor + OpenRouter: ~€500/Monat | Cloud-Monitoring: ~€10/Monat | | Lokal: Qwen3-VL (Hausmeister) | Lokal: Qwen3-Coder-Next (Coding) | | **Gesamt: ~€500** | **Gesamt: ~€30** (€10 Cloud + €20 Cursor Reserve) |

orbitalo commented

2026-04-11 08:40:27 +00:00

Author

Owner

Status-Update 11.04.2026

Phase 1: Cloud-Migration — ERLEDIGT

Hausmeister-Bot LLM → OpenRouter Grok 4.1 Fast
monitor.py auf OpenRouter API umgestellt
Flugscanner Vision → OpenRouter gpt-4o-mini
OpenMemory komplett auf Cloud (LLM=gpt-4o-mini, Embedder=text-embedding-3-small)
286 Memories neu embedded nach Qdrant-Dimension-Fix
Alle lokalen Modelle vom KI-Server entfernt, GPU 100% frei

Phase 2: Lokalen Coding-Agent installieren — ERLEDIGT

Modell: Devstral Small 2 (24B) statt Qwen3-Coder-Next (zu groß für 24GB)

Metrik	Ergebnis
VRAM	15 GB / 24 GB (21 GB mit KV-Cache)
Speed	52 tok/s
Tool-Calling	Perfekt (OpenAI-kompatible API)
Multi-Step Reasoning	Korrekt (liest erst, analysiert, dann fix)
Dateigröße GGUF	14 GB (Q4_K_M auf NAS via CT 146 model-library)

Getestete und verworfene Modelle:

qwen3-coder-next (79.7B) — 9.5 tok/s, zu langsam, passt nicht in VRAM
qwen3-coder:30b (MoE) — 128 tok/s aber kein Output bei echten Aufgaben

Phase 3: OpenCode-Config — ERLEDIGT

opencode.json auf ollama/devstral-small-2 konfiguriert
Bug gefunden: Projekt-Config homelab-brain/opencode.json hat globale Config überschrieben → Model war immer x-ai/grok-4.1-fast statt lokal
Projekt-Config + globale Config beide auf devstral-small-2 gesetzt
OpenCode-Server als Scheduled Task konfiguriert (Autostart)
Erster erfolgreicher Praxistest: Aufgabe korrekt gelöst mit lokalem Modell

Phase 4: Praxistest — GESTARTET

Ab heute 1 Woche Praxistest mit devstral-small-2 als Default.
Grok 4.1 Fast bleibt als Cloud-Fallback in der Config verfügbar.

Infrastruktur-Entdeckung

CT 146 model-library auf pve-mu-3: Web-UI zum Download/Verwalten von GGUF-Modellen
NAS-Mount /mnt/ki-modelle mit 25 vorinstallierten Modellen (LLM, Code, Vision, Embedding)
Devstral Small 2 GGUF zusätzlich dort gesichert

## Status-Update 11.04.2026 ### Phase 1: Cloud-Migration — ERLEDIGT - [x] Hausmeister-Bot LLM → OpenRouter Grok 4.1 Fast - [x] monitor.py auf OpenRouter API umgestellt - [x] Flugscanner Vision → OpenRouter gpt-4o-mini - [x] OpenMemory komplett auf Cloud (LLM=gpt-4o-mini, Embedder=text-embedding-3-small) - [x] 286 Memories neu embedded nach Qdrant-Dimension-Fix - [x] Alle lokalen Modelle vom KI-Server entfernt, GPU 100% frei ### Phase 2: Lokalen Coding-Agent installieren — ERLEDIGT **Modell: Devstral Small 2 (24B)** statt Qwen3-Coder-Next (zu groß für 24GB) | Metrik | Ergebnis | |--------|----------| | VRAM | 15 GB / 24 GB (21 GB mit KV-Cache) | | Speed | 52 tok/s | | Tool-Calling | Perfekt (OpenAI-kompatible API) | | Multi-Step Reasoning | Korrekt (liest erst, analysiert, dann fix) | | Dateigröße GGUF | 14 GB (Q4_K_M auf NAS via CT 146 model-library) | Getestete und verworfene Modelle: - `qwen3-coder-next` (79.7B) — 9.5 tok/s, zu langsam, passt nicht in VRAM - `qwen3-coder:30b` (MoE) — 128 tok/s aber kein Output bei echten Aufgaben ### Phase 3: OpenCode-Config — ERLEDIGT - [x] opencode.json auf `ollama/devstral-small-2` konfiguriert - [x] **Bug gefunden:** Projekt-Config `homelab-brain/opencode.json` hat globale Config überschrieben → Model war immer `x-ai/grok-4.1-fast` statt lokal - [x] Projekt-Config + globale Config beide auf devstral-small-2 gesetzt - [x] OpenCode-Server als Scheduled Task konfiguriert (Autostart) - [x] Erster erfolgreicher Praxistest: Aufgabe korrekt gelöst mit lokalem Modell ### Phase 4: Praxistest — GESTARTET Ab heute 1 Woche Praxistest mit devstral-small-2 als Default. Grok 4.1 Fast bleibt als Cloud-Fallback in der Config verfügbar. ### Infrastruktur-Entdeckung - **CT 146 `model-library`** auf pve-mu-3: Web-UI zum Download/Verwalten von GGUF-Modellen - NAS-Mount `/mnt/ki-modelle` mit 25 vorinstallierten Modellen (LLM, Code, Vision, Embedding) - Devstral Small 2 GGUF zusätzlich dort gesichert

orbitalo commented

2026-04-11 09:07:00 +00:00

Author

Owner

Abschluss-Fazit 11.04.2026

Ergebnis Phase 1-3

Cloud-Migration (Phase 1): Komplett erledigt. Hausmeister-Bot, Flugscanner Vision, OpenMemory laufen auf OpenRouter. GPU ist frei.

Lokaler Coding-Agent (Phase 2+3): devstral-small-2 installiert und funktionsfähig in OpenCode. Limitierungen im Praxistest erkannt (siehe unten).

Praxistest-Ergebnisse

Modell	Stärken	Schwächen
devstral-small-2 (lokal)	Schnell (52 tok/s), Tool-Calls korrekt, einfache Code-Tasks	Kein eigenständiges Recherchieren, verrennt sich bei komplexen Aufgaben
Grok 4.1 Fast (Cloud)	Gute Analyse, führt Befehle korrekt aus, findet Ursachen	Ignoriert Korrekturen (3x swapoff vorgeschlagen trotz Ablehnung), kein Memory zwischen Sessions
Cursor	Voller Kontext, lernt aus Korrekturen, kennt Infrastruktur aus Doku	Teurer

Empfehlung (umgesetzt)

OpenCode Default: Grok 4.1 Fast — für alltägliche Coding-Tasks und einfaches Debugging
devstral-small-2 bleibt auf GPU — manuell wählbar für schnelle lokale Code-Edits
Cursor — für komplexe Aufgaben die Kontext und Aufsicht brauchen
Geschätzte Kosten: ~30-50€/Monat statt ~500€

Offenes Problem: Memory/Kontext

Alle Coding-Agents (Grok, devstral) vergessen Kontext wenn der 32K-Token-Context voll ist. Bei Infrastruktur-Debugging mit langen SSH-Outputs passiert das schnell. Mögliche Lösungen:

OpenMemory-MCP aktiver nutzen (Agent speichert Erkenntnisse)
Bessere System-Prompts die den Agent zum Nachschlagen in Doku zwingen
Warten auf größere Context-Windows bei lokalen Modellen
Eigenes RAG über die CT-999 Dokumentation

→ Neues Issue für Memory-Problem erstellen.

Heute zusätzlich erledigt: pve-hetzner Stabilisierung

Load von 17 auf 6 reduziert
vm.swappiness=10 (persistent)
CT 103, 121, 144 gestoppt (nicht kritisch)
I/O-Wait von 82% auf 21%

## Abschluss-Fazit 11.04.2026 ### Ergebnis Phase 1-3 **Cloud-Migration (Phase 1):** Komplett erledigt. Hausmeister-Bot, Flugscanner Vision, OpenMemory laufen auf OpenRouter. GPU ist frei. **Lokaler Coding-Agent (Phase 2+3):** devstral-small-2 installiert und funktionsfähig in OpenCode. Limitierungen im Praxistest erkannt (siehe unten). ### Praxistest-Ergebnisse | Modell | Stärken | Schwächen | |--------|---------|----------| | **devstral-small-2 (lokal)** | Schnell (52 tok/s), Tool-Calls korrekt, einfache Code-Tasks | Kein eigenständiges Recherchieren, verrennt sich bei komplexen Aufgaben | | **Grok 4.1 Fast (Cloud)** | Gute Analyse, führt Befehle korrekt aus, findet Ursachen | Ignoriert Korrekturen (3x swapoff vorgeschlagen trotz Ablehnung), kein Memory zwischen Sessions | | **Cursor** | Voller Kontext, lernt aus Korrekturen, kennt Infrastruktur aus Doku | Teurer | ### Empfehlung (umgesetzt) - **OpenCode Default: Grok 4.1 Fast** — für alltägliche Coding-Tasks und einfaches Debugging - **devstral-small-2 bleibt auf GPU** — manuell wählbar für schnelle lokale Code-Edits - **Cursor** — für komplexe Aufgaben die Kontext und Aufsicht brauchen - **Geschätzte Kosten:** ~30-50€/Monat statt ~500€ ### Offenes Problem: Memory/Kontext Alle Coding-Agents (Grok, devstral) vergessen Kontext wenn der 32K-Token-Context voll ist. Bei Infrastruktur-Debugging mit langen SSH-Outputs passiert das schnell. Mögliche Lösungen: - OpenMemory-MCP aktiver nutzen (Agent speichert Erkenntnisse) - Bessere System-Prompts die den Agent zum Nachschlagen in Doku zwingen - Warten auf größere Context-Windows bei lokalen Modellen - Eigenes RAG über die CT-999 Dokumentation **→ Neues Issue für Memory-Problem erstellen.** ### Heute zusätzlich erledigt: pve-hetzner Stabilisierung - Load von 17 auf 6 reduziert - vm.swappiness=10 (persistent) - CT 103, 121, 144 gestoppt (nicht kritisch) - I/O-Wait von 82% auf 21%