Hitonabi
c863f01a78
W2: install akzeptiert HF-URL ODER org/repo (normalize_repo); GET /api/hf/
search + /api/hf/quants; Frontend AddModel-Panel (URL+Quant-Dropdown+freie
Suche) im Discover-Tab. W3: POST /api/models/{id}/role + /ctx; Installiert-
Tab mit Rollen-Select (fast/heavy/coder/...), ctx-Edit, Loeschen → LLM
tauschen per Klick.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
39 lines
3.0 KiB
Markdown
39 lines
3.0 KiB
Markdown
# Cutover — Stand & Anleitung
|
||
|
||
## Was auf der Box LÄUFT (verifiziert)
|
||
- **MC2** auf `:9001` (sudo-freier User-Dienst, `~/mission-control-v2`). Update: `deploy/deploy.sh`.
|
||
- **Modelle:** `fast` = Qwen3.6-35B-A3B (21 GB, lädt in ~6 s) + `heavy` = Qwen3.5-122B-A10B (77 GB,
|
||
lädt in ~32 s). Beide tool-fähig (`--jinja`). Plus die bestehenden coder/vision/scout.
|
||
- **Gateway (eingebaut, `:9001/v1`, OpenAI-kompatibel):** `model: auto` → kurz/Standard = `fast`,
|
||
lang/komplex = `heavy`. End-to-End verifiziert (short→fast, keyword→heavy lädt + antwortet).
|
||
- **Hermes:** Brain = `model: auto` über den Gateway (provider `custom`, `:9001/v1`). MCP verdrahtet:
|
||
`mission-control-memory` + `mission-control-stack` (mcp_mc). Antwortet.
|
||
- **Gedächtnis vereinheitlicht:** MC2 nutzt die bestehende v1-DB (`mission-control-memory.db`,
|
||
16 Einträge) — eine geteilte „Verfassung" für Cockpit, Hermes, IDEs.
|
||
|
||
## Bekannte Tuning-Punkte (vor „rundem" Cutover sinnvoll, kein Blocker)
|
||
1. **Hermes-Thrash → BEHOBEN (W1).** Ursache war eine **vergiftete Dauer-Session** (mein Test hatte sie
|
||
mit einem Vision-Fehl-Lauf verseucht; Hermes fütterte sie jeden Zug erneut → ~249k Tokens, Vision-auf-
|
||
Text, Such-Schleifen). **Verifiziert:** frische Session = sauber & kohärent, **34k statt 249k**,
|
||
keine Fehl-Tools. Maßnahmen: `code_execution.max_tool_calls` 50→20 (Schleifen-Bremse); **History
|
||
unangetastet** (64 Sessions/1048 Msgs bleiben — Hermes' Gedächtnis). Sessions reseten ohnehin täglich
|
||
(4 Uhr) / nach 24 h idle; das WebUI nutzt pro Chat eine eigene Session. **Speed:** Gateway schaltet
|
||
auf der `fast`-Spur **Thinking aus** (Qwen3.6) → bare Gateway-Antwort ~10 s, direkt.
|
||
**Rest-Tuning (mit dir, optional):** Hermes' erste Nachricht dauert noch ~60–90 s wegen **34k Basis-
|
||
Kontext** (Tool-Schemas + 26 Skills) + Agent-Loop. Hebel: unnötige Toolsets/Skills prunen
|
||
(`config toolsets`/`platform_toolsets`, 26 Skills sichten) → schlankerer Prompt = schnellerer Agent.
|
||
2. **SSH→Windows (voller PC-Zugriff):** Windows-seitig OpenSSH-Server aktivieren + Key
|
||
`id_ed25519_hermes_agent` autorisieren (vom Box-Host aus). Erst dann erreicht Hermes' Shell den PC.
|
||
3. **hermes-webui (nesquena) standalone:** optional — aktuell läuft das eingebaute `hermes-dashboard`.
|
||
Für die reichere Oberfläche `docs/HERMES_SETUP.md` §3 (Port 8787, Passwort).
|
||
|
||
## Cutover-Schritte (wenn v2 dir reicht)
|
||
1. v2 läuft bereits auf `:9001` parallel — teste alles dort: `http://192.168.178.151:9001`.
|
||
2. Vibe-Coding-Tools auf den Gateway zeigen (Verbinden-Tab liefert Snippets → `:9001/v1`, `model: auto`).
|
||
3. **v1 stilllegen:** `systemctl --user stop hermes-dashboard` (nur wenn nesquena/anderes übernimmt) und
|
||
den alten Mission-Control-Dienst deaktivieren. llama-swap + hermes-gateway bleiben (von beiden genutzt).
|
||
4. Optional v2 auf den „Haupt"-Port legen (z.B. 9000) — `MC_PORT` im Unit ändern.
|
||
5. Backup vorher: Cockpit → System → „Backup jetzt" (sichert Memory-DB + Configs).
|
||
|
||
> v1 bleibt bis dahin unangetastet und lauffähig — Cutover ist reversibel.
|