65 lines
3.0 KiB
Markdown
65 lines
3.0 KiB
Markdown
# Roadmap: sauberer KI-Host
|
||
|
||
## Phase 0 – Entscheidungen und Freigaben
|
||
|
||
- VPN-Nutzung mit der Universität abstimmen.
|
||
- Eindeutige Netze und Heim-WireGuard-Peer festlegen.
|
||
- Festplattenverschlüsselung und Remote-Unlock entscheiden.
|
||
- Repository- und Secret-Backup prüfen.
|
||
|
||
## Phase 1 – Grundsystem
|
||
|
||
- Debian 13 minimal und OpenSSH installieren.
|
||
- Firmware/BIOS und beide NVIDIA-Karten prüfen.
|
||
- Updates, Zeitsynchronisation und administrativen Zugang testen.
|
||
|
||
## Phase 2 – automatischer Bootstrap
|
||
|
||
- `config/install.env` ausfüllen.
|
||
- `install.sh` ausführen, bei Treiberinstallation neu starten und wiederholen.
|
||
- WireGuard-Peer zuhause ergänzen.
|
||
- Docker-, GPU- und Fail-Closed-Netztest bestehen.
|
||
|
||
## Phase 3 – Inferenz abnehmen
|
||
|
||
- Fast/Medium/Long mit derselben Testserie messen.
|
||
- Kontext, Prompt-Speed, Ausgabe-Speed und VRAM dokumentieren.
|
||
- RTX 3060 zuerst nur im Experimentalprofil testen.
|
||
- Erst nach Qualitäts- und Geschwindigkeitsvergleich Produktionswerte ändern.
|
||
|
||
## Phase 4 – optionale Fähigkeiten
|
||
|
||
- Zentrale MCP-Werkzeugebene gemäß `ARCHITECTURE.md` aufbauen.
|
||
- Schlanken `mcp-gateway` nur über WireGuard veröffentlichen.
|
||
- `web-mcp` als unabhängigen Standard-Werkzeugcontainer betreiben.
|
||
- Home Assistant als getrennte Read-/Write-Instanzen desselben Images.
|
||
- Den vorhandenen kompakten `homeassistant-admin-mcp` zum zentralen
|
||
Streamable-HTTP-Werkzeugcontainer ausbauen. Er soll dem Modell kleine,
|
||
eindeutige Werkzeuge anbieten und den nativen Home-Assistant-MCP intern als
|
||
Datenquelle beziehungsweise Fallback verwenden, statt dessen sehr großen
|
||
Werkzeugkatalog direkt an jedes Modell durchzureichen.
|
||
- YAML-Unterstützung für Home Assistant ergänzen: zunächst lesen und
|
||
validieren; Änderungen ausschließlich über Diff/Vorschau, Sicherung,
|
||
Konfigurationsprüfung und explizite Freigabe. Keine freie Host-Shell und kein
|
||
ungeprüftes Überschreiben von Konfigurationsdateien.
|
||
- Den Admin-MCP anschließend gemeinsam für Open WebUI, Hermes und weitere
|
||
Clients anbieten; Read-only und Write/Approval bleiben getrennte Profile.
|
||
- ARR als getrennte Read-/Write-Instanzen mit Preview/Approval.
|
||
- Unraid-Diagnose und bewusst aktivierbare Administration trennen.
|
||
- Terminal ausschließlich als isolierten `sandbox-mcp`, nie als Host-Shell.
|
||
- Open WebUI, Hermes und weitere Clients mit denselben zentralen Endpunkten
|
||
verbinden und pro Chat nur benötigte Werkzeuggruppen aktivieren.
|
||
- Piper-TTS als eigener interner CPU-Container; Whisper oder Bildgenerierung
|
||
bei Bedarf ebenfalls jeweils als eigener Container.
|
||
|
||
## Phase 5 – Betrieb
|
||
|
||
- Open-WebUI-Volume, Konfigurationen und Secrets verschlüsselt sichern.
|
||
- Image- und llama.cpp-Upgrades im Experimentalprofil testen.
|
||
- Logs ohne Prompts/Secrets, Metriken für GPU, RAM und Tokenraten.
|
||
- Recovery auf leerem Testsystem regelmäßig proben.
|
||
|
||
Fertig ist der Host erst, wenn er sich aus Repository und Secret-Backup neu
|
||
erzeugen lässt, das Uni-Netz keine KI-Ports sieht, ein Tunnelverlust
|
||
fail-closed ist und alle drei Profile den Standardbenchmark bestehen.
|