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>
3.0 KiB
3.0 KiB
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 (providercustom,: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)
- 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_calls50→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 derfast-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. - SSH→Windows (voller PC-Zugriff): Windows-seitig OpenSSH-Server aktivieren + Key
id_ed25519_hermes_agentautorisieren (vom Box-Host aus). Erst dann erreicht Hermes' Shell den PC. - hermes-webui (nesquena) standalone: optional — aktuell läuft das eingebaute
hermes-dashboard. Für die reichere Oberflächedocs/HERMES_SETUP.md§3 (Port 8787, Passwort).
Cutover-Schritte (wenn v2 dir reicht)
- v2 läuft bereits auf
:9001parallel — teste alles dort:http://192.168.178.151:9001. - Vibe-Coding-Tools auf den Gateway zeigen (Verbinden-Tab liefert Snippets →
:9001/v1,model: auto). - 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). - Optional v2 auf den „Haupt"-Port legen (z.B. 9000) —
MC_PORTim Unit ändern. - Backup vorher: Cockpit → System → „Backup jetzt" (sichert Memory-DB + Configs).
v1 bleibt bis dahin unangetastet und lauffähig — Cutover ist reversibel.