127 lines
5.2 KiB
Markdown
127 lines
5.2 KiB
Markdown
# Athena / MikeAI – kurze Plattformübersicht
|
||
|
||
Stand: 23. August 2026. Diese Datei erklärt die Plattform in kurzer Form. Für
|
||
operative Änderungen gilt zusätzlich `QWEN_OPERATOR_CONTEXT.md`.
|
||
|
||
## Zweck
|
||
|
||
Athena ist ein selbst betriebener, datenschutzorientierter KI-Host. Er steht
|
||
physisch an einem entfernten Standort ohne KVM und wird ausschließlich remote
|
||
administriert. Open WebUI ist die Benutzeroberfläche. Ein eigener Profile
|
||
Router stellt eine OpenAI-kompatible API bereit und schaltet zwischen mehreren
|
||
reproduzierbaren llama.cpp-Profilen um. Fachwerkzeuge laufen als getrennte MCP-
|
||
Container; Zugangsdaten gelangen weder in llama.cpp noch in Modellprompts.
|
||
|
||
## Hardware
|
||
|
||
- Debian 13 `trixie`, Kernel 6.12
|
||
- AMD Ryzen 5 5600, 6 Kerne / 12 Threads
|
||
- 48 GiB DDR4-RAM
|
||
- RTX 5080 mit 16 GiB VRAM
|
||
- RTX 3060 mit 12 GiB VRAM
|
||
- System-SSD und getrennte `/data`-SSD, jeweils ungefähr 1 TB
|
||
- keine RX 470 mehr im System
|
||
|
||
GPU-Indizes auf dem Host sind nicht stabil genug für Konfigurationen. Wo eine
|
||
eindeutige Karte benötigt wird, werden GPU-UUIDs verwendet. Innerhalb eines
|
||
Containers kann `CUDA0` aufgrund von `NVIDIA_VISIBLE_DEVICES` eine andere Karte
|
||
bezeichnen als Index 0 von `nvidia-smi` auf dem Host.
|
||
|
||
## Hauptfluss
|
||
|
||
```text
|
||
Browser / API-Client
|
||
|
|
||
| WireGuard, ausschließlich VPN
|
||
v
|
||
Open WebUI ---> Profile Router ---> Profile Controller ---> genau ein llama.cpp-Profil
|
||
| |
|
||
| +-- Vision direkt über Qwen + mmproj
|
||
| +-- FLUX-Hotswap für Bildgenerierung
|
||
| +-- Whisper für Speech-to-Text
|
||
| +-- TTS-Gateway -> XTTS-v2 -> Piper-Fallback
|
||
|
|
||
+-- internes MCP-Netz
|
||
+-- Web
|
||
+-- GitHub Repository read-only
|
||
+-- Home Assistant
|
||
+-- Sonarr/Radarr
|
||
+-- Navidrome
|
||
+-- Unraid
|
||
```
|
||
|
||
Open WebUI und Router veröffentlichen keinen normalen Host-Port. Der
|
||
WireGuard-Gateway-Container stellt nur die vorgesehenen VPN-Endpunkte bereit.
|
||
Anwendungscontainer erreichen Heimnetz und Internet fail-closed über WireGuard;
|
||
ein Tunneldefekt darf nicht auf das Universitätsgateway zurückfallen. SSH auf
|
||
dem Debian-Host ist davon getrennt.
|
||
|
||
## Inferenzprofile
|
||
|
||
| Profil | Kontext | Modell/Verteilung | Zweck |
|
||
|---|---:|---|---|
|
||
| Fast | 76.800 | IQ4-MIX, Text auf RTX 5080 | schnell; Visionprojektor auf RTX 3060 |
|
||
| Medium | 160.000 | IQ4_XS Pure, 90:10 | Standardprofil; Vision; MTP3 |
|
||
| Large | 192.000 | IQ4_XS Pure, 86:14 | große Agentensitzungen; Vision |
|
||
| Ultra | 262.144 | IQ4_XS Pure, 80:20 | maximaler Textkontext, keine Vision |
|
||
| Uncensored | 80.000 | Abliterated Q4_K_M, 90:10 | weniger Verweigerungen; Rechte unverändert |
|
||
| Experimental | variabel | isoliert | Tests, niemals automatisch Produktion |
|
||
|
||
Es darf immer nur ein Textprofil aktiv sein. Medium ist der verbindliche
|
||
Standard. Ein „unkonditionierteres“ Modell hebt niemals Werkzeugrechte,
|
||
Bestätigungspflichten oder Netzwerkgrenzen auf.
|
||
|
||
## MCP-Prinzip
|
||
|
||
Ein Container entspricht einem Fachbereich und einer Vertrauensgrenze. Große
|
||
Allzweck-MCPs, ein allgemeiner Root-Shell-MCP und pauschale Werkzeugfreigaben
|
||
sind ausdrücklich nicht Teil der Architektur. Standard ist read-only; jede
|
||
Schreibaktion benötigt eine konkrete Vorschau, eine daran gebundene Freigabe
|
||
und eine anschließende Verifikation.
|
||
|
||
Der offizielle GitHub-MCP bietet nur vier Werkzeuge:
|
||
|
||
- Repository suchen
|
||
- Repositorybaum lesen
|
||
- Dateiinhalt lesen
|
||
- Code suchen
|
||
|
||
Andere GitHub-Werkzeuge sowie Schreibzugriffe sind serverseitig deaktiviert.
|
||
|
||
## Verbindliche Quellen
|
||
|
||
1. aktuell mit einem zuständigen Werkzeug gemessener Laufzeitzustand
|
||
2. `CURRENT_REFERENCE.md` und `STANDARD_PROFILE_MATRIX.md`
|
||
3. Compose-, Installer- und Konfigurationsdateien im Repository
|
||
4. Architektur-, Sicherheits- und Betriebsdokumentation
|
||
5. frühere Chatangaben nur als Hinweis, niemals als aktueller Nachweis
|
||
|
||
Widersprechen Laufzeit und Dokumentation einander, wird nichts vorschnell
|
||
geändert. Die Abweichung wird benannt und zuerst geklärt.
|
||
|
||
## Unverhandelbare Sicherheitsregeln
|
||
|
||
- Keine Secrets, Tokens, privaten Schlüssel, Chats oder Promptinhalte auslesen
|
||
oder ausgeben, sofern das nicht ausdrücklich und eng begrenzt verlangt wurde.
|
||
- Kein Shutdown, Reboot, Netzwerk-, SSH-, Firewall-, WireGuard-, Kernel- oder
|
||
Bootloader-Eingriff ohne ausdrückliche Freigabe und belastbaren Rückweg.
|
||
- Keine Änderung direkt im Livecontainer als dauerhafte Lösung.
|
||
- Zuerst Bestand prüfen, dann versionierte Quelle ändern, testen, deployen,
|
||
verifizieren, dokumentieren und sichern.
|
||
- Bestehende fremde Änderungen und Dirty Worktrees erhalten.
|
||
- Niemals behaupten, etwas geprüft oder ausgeführt zu haben, wenn kein
|
||
zuständiges Werkzeug erfolgreich war.
|
||
|
||
## Wichtige Pfade
|
||
|
||
```text
|
||
/opt/mike-ai/stack installierte versionierte Plattformquelle
|
||
/data/models produktive Modelle; für Inferenz read-only eingehängt
|
||
/etc/mike-ai root-only Secrets und Standortkonfiguration
|
||
/data persistente Daten- und Recovery-SSD
|
||
/var/lib/docker/volumes Docker-Volumes, darunter OpenWebUI-Daten
|
||
```
|
||
|
||
Secrets unter `/etc/mike-ai` werden ausschließlich verschlüsselt gesichert und
|
||
gehören nie in Git, ein Wissensdokument oder einen Modellkontext.
|