# Aktueller produktiver Referenzstand Stand: 23. August 2026. Dieses Dokument beschreibt die auf Athena installierte und geprüfte Docker-Referenz. Die verbindlichen Profilparameter stehen in `STANDARD_PROFILE_MATRIX.md`. ## Hardware und Betriebssystem | Bereich | Referenz | |---|---| | Betriebssystem | Debian 13 `trixie` | | Kernel | 6.12.101+deb13-amd64 | | CPU | AMD Ryzen 5 5600, 6 Kerne/12 Threads | | RAM | 48 GiB DDR4-2666 | | GPUs | NVIDIA GeForce RTX 5080, 16 GiB + RTX 3060, 12 GiB VRAM | | NVIDIA-Treiber | 610.57.04 | | System-SSD | Samsung 980 PRO 1 TB | | Daten-SSD | WD Blue SN580 1 TB, unter `/data` | Die früher verwendete Radeon RX 470 ist ausgebaut und gehört nicht zur Zielplattform. ## Produktiver Text-Stack | Eigenschaft | Aktueller Wert | |---|---| | Runtime | llama.cpp | | Repository | `https://github.com/ggml-org/llama.cpp.git` | | Commit | `3f545beccee69d9975f466ec7e45fd9aacd8ba90` | | Compiler | GCC 14.2 | | Hauptdienst | jeweils ein Container `mike-ai-llama-` | | llama.cpp-Port | 8080, ausschließlich im internen Docker-Netz | | Client-Port | 8081 über den Router | | MCP-Konfiguration | getrennte Container unter `/opt/mike-ai/stack/platform/mcp` | ### Aktives Standardprofil - Qwen3.8-27B IQ4_XS Pure - Dateigröße: 14.534.384.640 Bytes - SHA256: `ea5a3c45d407f9b9e5d2c0d647f0ea600f486f6b86b92b56d0823ba073dae675` - Quelle: `jpetrina/Qwen3.8-27B-IQ4_XS-pure-GGUF` - Kontext 160.000 - RTX 5080 + RTX 3060 im Verhältnis 90:10 - Flash Attention - KV-Cache Q4_0 für K und V - MTP Draft, maximal drei Tokens - MTP-Akzeptanzschwelle 0,05; im Referenzlauf 77,26 statt 73,88 Tok/s - sechs Threads und sechs Batch-Threads - Batch 64, Micro-Batch 32 - ein paralleler Slot - Jinja und automatisches Reasoning - Temperatur 0,2, Top-p 0,8, Top-k 20 ### Profile | Profil | Virtuelles Modell | Kontext | Besonderheit | |---|---|---:|---| | Fast | `qwen-fast` | 76.800 | IQ4-MIX, MTP2, Text auf RTX 5080, mmproj auf RTX 3060 | | Medium **(Standard)** | `qwen-medium` | 160.000 | IQ4_XS Pure, MTP3, beide GPUs 90:10, mmproj auf RTX 3060 | | Large | `qwen-large` | 192.000 | IQ4_XS Pure, MTP3, beide GPUs 86:14, mmproj auf RTX 3060 | | Ultra | `qwen-ultra` | 262.144 | IQ4_XS Pure, MTP2, beide GPUs 80:20, text-only; 68,2 Tok/s und 220K-Fülltest bestanden | | Uncensored | `qwen-uncensored` | 80.000 | Abliterated Q4_K_M, MTP2, beide GPUs 90:10, eigener mmproj auf RTX 3060; etwa 52,2 Tok/s | ## Router - Container: `mike-ai-router` - Port: 8081 - Upstream: `llama-upstream:8080` im internen Inferenznetz - Commit des Plattform-Repositories: siehe jeweils aktuelles `main` - Umschaltung: `mike-ai-profile-controller` mit fester Container-Allowlist - Timeout für Profilwechsel und Requests: 600 Sekunden Der Router übernimmt: - OpenAI-kompatibles Chat-Proxying und Streaming - virtuelle Modelle und automatische Profilumschaltung - Tool Calls - direkte integrierte Vision in Fast, Medium, Large und Uncensored - FLUX-Hotswap zur Bildgenerierung - Whisper Speech-to-Text - XTTS-v2 über das TTS-Gateway als primäre Text-to-Speech-Ausgabe - Piper als automatischer CPU-Fallback - Zustands- und Modellendpunkte ## Vision | Bereich | Referenz | |---|---| | Text-/Visionmodell | jeweils aktives Qwen3.8-27B-Profil | | Projektor | BF16-mmproj | | Speicherort des Projektors | RTX 3060 (`MTMD_BACKEND_DEVICE=CUDA1`) | | Kontext | entspricht Fast/Medium/Large; Ultra ist bewusst text-only | Vision ist Bestandteil von Fast, Medium, Large und Uncensored. Der Router prüft Bildgröße und URL, leitet das Bild dann direkt weiter und führt keinen Modellwechsel mehr aus. ## Bildgenerierung - Modell: FLUX.2 Klein 4B Distilled, Apache-2.0 - Runtime: eigener PyTorch-2.11/CUDA-12.8-/Diffusers-0.40-Container - fest auf vier Schritte und Guidance 1,0 destilliert - Worker läuft ausschließlich auf der RTX 5080 und ist im Normalbetrieb gestoppt - der Controller beendet Qwen vor dem Job; Bildprompts bleiben im internen Netz - Worker wird nach jedem Job vollständig beendet - Qwen wird anschließend mit exakt dem vorherigen Profil wiederhergestellt - gemessene reine Bildgenerierung bei 1024 × 1024: 11,67 bis 14,59 Sekunden - gemessener kompletter Hot-Swap einschließlich Qwen-Wiederherstellung: etwa 31 Sekunden - OpenWebUI ist global auf den OpenAI-kompatiblen Router-Endpunkt, vier Schritte und 1024 × 1024 Pixel vorkonfiguriert - OpenWebUI zeigt aus Kompatibilitätsgründen den Alias `gpt-image-1`; tatsächlich rechnet ausschließlich das lokale FLUX.2-Klein-Modell, es fließen keine Daten an OpenAI - Bilder werden zwischen Router und OpenWebUI als eingebettete Base64-Daten übertragen. Dadurch bleibt OpenWebUIs SSRF-Schutz für private URLs aktiv, ohne die lokale Bildrückgabe zu blockieren ## Sprache ### Whisper - Modell: large-v3-turbo - lokale Standardsprache: Deutsch - CPU-Ausführung - acht Threads im produktiven Worker - Port 8084, nur localhost - ffmpeg für Eingabeumwandlung ### XTTS Der aktuelle Docker-Stack nutzt Coqui XTTS-v2 als primäre Sprachausgabe. Der isolierte Eignungs- und Ausfalltest ist in [`XTTS_EVALUATION_2026-08-23.md`](XTTS_EVALUATION_2026-08-23.md) dokumentiert. - Modell: Coqui XTTS-v2, offizielles CUDA-12.1-Image per Digest gepinnt - GPU: ausschließlich RTX 3060 über ihre stabile GPU-UUID - Stimme: `Annmarie Nele` - Deutsch und Englisch; bekannte englische IT-Begriffe werden segmentiert - kein veröffentlichter Port, nur Docker-intern erreichbar - serielles TTS-Gateway vor XTTS, weil der Server nur einen Auftrag zugleich zuverlässig verarbeitet - Piper mit `de_DE-thorsten-high` bleibt als automatischer CPU-Fallback aktiv - OpenWebUI behält aus Kompatibilitätsgründen `model=piper` und `voice=alloy`; der Router leitet diese Werte an das Gateway weiter ## Websuche - Docker Compose - SearXNG, per Digest gepinnt - TinySearch 0.5.1, per Digest gepinnt - TinySearch ausschließlich im internen Docker-Netz, ohne Host-Port - lokale ONNX-Embeddings - kompakte Web-MCP-Fassade 3.0 mit sechs Werkzeugen: Suche, Seite lesen, YouTube, Vergleich, Einkauf und Recherche - YouTube-Kanalfeed, Metadaten und Untertitel über fest versioniertes `yt-dlp`; keine Auswertung von Consent-Seiten - technisch erzwungener Abbruch nach drei semantisch ähnlichen Suchaufrufen - aktuelle Suchen erhalten keinen pauschalen Wikipedia-Fallback - strukturierter API-Pfad für Hugging Face; GitHub-Quellcode läuft über den getrennten offiziellen GitHub-MCP ## MCP-Referenz Aktuell existieren funktionale Adapter für: - Athena-Plattformwissen, Laufzeitsnapshot und kontrollierte Docs-Pflege - Athena Operator: Entwicklung, Docker/MCP/Modelle, Tests, Git und Recovery - Websuche - Home Assistant - Sonarr/Radarr - GitHub Repository read-only (offizieller Server, vier Werkzeuge) - Navidrome-Bibliothek und Last.fm-Empfehlungen - Unraid read-only - eigener Unraid-Administrationsserver OpenWebUI bindet diese Kataloge nicht pauschal an jedes Modellprofil. Der lokale `MikeAI Auto Tool Selector` ergänzt anhand der jüngsten Nutzernachricht höchstens zwei passende MCP-Verbindungen pro Anfrage. Dadurch bleiben normale Chats schemafrei und kurze Profile verlieren keinen unnötigen Kontext. MUA mit erweiterten Verwaltungsrechten bleibt von der Automatik ausgeschlossen; eine automatisch bereitgestellte Verbindung erteilt niemals Schreibrechte oder eine Änderungsfreigabe. Unraid ist ausschließlich über das MUA-Plugin angebunden. Die automatische Verbindung `mua-readonly-local` und die bewusst aktivierte Verbindung `mua` nutzen denselben MUA-Endpunkt. Der frühere GraphQL-basierte Unraid-MCP wurde entfernt und gehört weder zum Start noch zum Recovery. Der GitHub-Container läuft produktiv. Token-Datei, interner Streamable-HTTP-Handshake, fehlende Host-Portfreigabe und exakt vier read-only Werkzeuge wurden am 23. August 2026 verifiziert. Die Transportbrücke verwendet den OpenWebUI-kompatiblen `mcp-proxy` 0.12.0 im stateless Betrieb. Supergateway wurde nach reproduzierbaren HTTP-400-Fehlern bei `notifications/initialized` aus diesem Pfad entfernt. Der Platform Context MCP läuft ohne Docker-Socket, Shell, Egress oder Secrets. Ein root-eigener Minutentimer erzeugt nur einen begrenzten Laufzeitsnapshot. Der Schreibpfad ist auf `docs/*.md`, Vorschau, ausdrückliche Freigabe, atomare Sicherung und sichtbare Git-/Recovery-Nacharbeit begrenzt. Der Athena Operator MCP ersetzt die frühere begrenzte Terminal-Fassade. Er ist die zusammenhängende Bedienebene, mit der Qwen die KI-Plattform selbst weiterentwickeln und betreiben kann. Quellenlesen, Dateiänderungen, Tests, Compose-Deployments, Containeraktionen, Modell-Downloads, Benchmarks, Git-Publishing und Recovery sind strukturiert verfügbar. Zustandsänderungen benötigen immer Vorschau und ein content-gebundenes Approval-Ticket. Ein freies Root-Terminal sowie Remotezugang, Netzwerk/SSH/Boot/Power bleiben getrennt. Der frühere allgemeine Shell-MCP und doppelte, schreibende Werkzeuge gehören nicht zum Sicherheitsziel und werden nicht ungeprüft wiederhergestellt. ## Bekannte Probleme des alten Hosts - Systempartition vollständig gefüllt - Datenpartition nahezu vollständig gefüllt - etwa 1,27 TB Modelle, darunter Duplikate - mehrere alte llama.cpp-Builds - RX-Dienste trotz ausgebauter Karte - aktivierte Benchmark-/Race-Dienste - alte systemd-Overrides und Sicherungskopien - unvollständiger großer Modelldownload - zu viele MCP-Werkzeuge gleichzeitig im Kontext Diese Punkte erklären den Neuaufbau, sind aber keine Bestandteile der neuen Plattform. Zusätzliche bekannte Sicherheitsabweichung: llama.cpp auf Port 8080 und XTTS auf Port 8085 sind im alten Zustand breiter gebunden als im Zielsystem. Beim Neuaufbau werden beide auf localhost begrenzt; Clients verwenden ausschließlich den Router auf Port 8081.