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.

Der zuschaltbare mike-ai-mcp-platform-context stellt allen Textprofilen das gleiche versionierte Plattformwissen zur Verfügung. Ein begrenzter Host-Snapshot ersetzt einen Docker-Socket. Dokumentationsänderungen laufen nur über Vorschau, ausdrückliche Freigabe und atomare Sicherung; Git und Recovery bleiben getrennte, nachzuweisende Abschlussarbeiten. Details stehen in PLATFORM_CONTEXT_MCP.md.

Das versionierte, secret-freie Diensteverzeichnis config/service-catalog.json dokumentiert bereits vorhandene externe Abhängigkeiten. Vor der Planung eines neuen Backends muss es gelesen und der Bestand mit dem dort genannten Fachwerkzeug geprüft werden. Ein nicht erreichbares Werkzeug bedeutet „nicht verifiziert“, niemals „nicht vorhanden“.

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

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
          +-- Athena Plattformwissen
          +-- Web
          +-- GitHub Repository read-only
          +-- Home Assistant
          +-- Sonarr/Radarr
          +-- Navidrome
          +-- Unraid

Deemix läuft bereits als Container auf dem Unraid-HomeServer. Eine künftige Deemix-MCP-Integration auf Athena verwendet dieses Backend über WireGuard und erzeugt nicht ungefragt eine zweite Deemix-Instanz.

Automatische Unraid-Abfragen verwenden einen eigenen MUA-Read-only-Zugang, der in Open WebUI ausschließlich Diagnosewerkzeuge sichtbar macht. Der vollständige MUA-Verwaltungszugang bleibt davon getrennt und muss bewusst gewählt werden.

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.

Für Entwicklung und Betrieb der KI-Plattform existiert ein zentraler Athena Operator MCP. Eine unprivilegierte MCP-Fassade spricht ausschließlich über einen Unix-Socket mit einem rootseitigen strukturierten Executor. Dadurch kann Qwen MCPs, Docker-Dienste, Modelle, Profile, OpenWebUI, Tests, Git und Recovery selbst pflegen, erhält aber keinen freien Root-Befehl. Jede Mutation wird als gebundene Vorschau vorbereitet und erst nach ausdrücklicher späterer Freigabe ausgeführt. Netzwerk-, SSH-, Boot- und Powerzugriffe sind nicht Teil davon.

Verbindliche Quellen

aktuell mit einem zuständigen Werkzeug gemessener Laufzeitzustand
CURRENT_REFERENCE.md und STANDARD_PROFILE_MATRIX.md
Compose-, Installer- und Konfigurationsdateien im Repository
Architektur-, Sicherheits- und Betriebsdokumentation
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

/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.

7.0 KiB Raw Blame History Unescape Escape