# Aktueller produktiver Referenzstand Stand: 24. 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 - erhaltener Reasoning-Zustand über Werkzeugrunden (`--reasoning-preserve`) - 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.6.1, per Digest gepinnt - TinySearch ausschließlich im internen Docker-Netz, ohne Host-Port - lokale ONNX-Embeddings - OpenWebUI-native allgemeine Suche und Seitenabruf in allen normalen Profilen - portabler TinySearch-Upstream-MCP mit vier breiten Werkzeugen auf VPN-Port 8203 - die frühere sechsfach spezialisierte Web-Fassade ist nur noch Rollback-Profil - 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, drei begrenzte Werkzeuge) - Navidrome-Bibliothek und Last.fm-Empfehlungen - Unraid read-only - eigener Unraid-Administrationsserver OpenWebUI bindet nicht pauschal sämtliche großen Fachkataloge ein. Der lokale `MikeAI Auto Tool Selector` hält das allgemeine Web immer verfügbar und ergänzt anhand der jüngsten Nutzernachricht alle passenden Fach-MCP-Verbindungen. Eine echte Mehrdomänen-Aufgabe erhält automatisch ein begrenztes mittleres Reasoning- Budget; einfache Aufgaben bleiben schnell. Allgemeine Webrecherche erfolgt über Open WebUIs native `search_web`/`fetch_url`-Werkzeuge; für andere Clients liegt TinySearch direkt auf Port 8203. Dadurch bleiben Fachkataloge klein und kurze Profile verlieren keinen unnötigen Kontext. Reine Unraid-Abfragen erhalten nur MUA read-only. Verlangt die aktuelle Nachricht ausdrücklich eine Unraid-Änderung, stellt die Automatik zusätzlich den Verwaltungszugang für die feste Kette Prüfen → Ändern → Verifizieren bereit. Die Bereitstellung ersetzt niemals die ausdrückliche Änderungsanweisung. Unraid ist ausschließlich über das MUA-Plugin angebunden. Die Verbindungen `mua-readonly-local` und `mua` nutzen denselben MUA-Endpunkt. Mehrere bestätigte Docker-Updates laufen ab MUA r019 gebündelt und idempotent; echte Image-IDs verhindern Neuerstellungen aufgrund eines veralteten Statuscaches. Ab MUA r021 inventarisiert `unraid_files_inventory` Datei- und Ordnernamen begrenzt, ohne Dateiinhalte zu lesen, und beendet eine gefilterte Erkennung an einem passenden Sammlungsordner. Auto Tool Selector 3.5 hält ausdrücklich lesende Bibliotheksprüfungen bei MUA read-only und verwechselt Hörspielfolgen nicht mit Sonarr-Episoden. Verlangt derselbe Auftrag aktuelle Onlinebelege, aktiviert er zusätzlich die native Websuche. Der Ablauf steht in `docs/UNRAID_MEDIA_AUDIT_WORKFLOW.md`. 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 drei read-only Werkzeuge wurden am 24. 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. Die agentische OpenWebUI-Schleife führt höchstens 40 einzelne Werkzeuge aus, höchstens zwölf Aufrufe desselben Werkzeugnamens und höchstens zweimal exakt dieselbe Signatur. Nach Ende des Budgets stehen zusätzliche interne Runden ausschließlich für eine sichtbare werkzeugfreie Schlussantwort bereit. Das produktive OpenWebUI-Derivat trägt den Tag `mike-ai/openwebui:main-01f4282-agent-loop-v8`. Das in V8 enthaltene Verhalten aus V7 begrenzt zusätzlich die Werkzeugantworten in OpenWebUIs internen Fortsetzungsrunden auf 12.000 Zeichen je Ergebnis und 64.000 Zeichen pro Antwortlauf. Damit greift die Begrenzung auch bei Ergebnissen, die erst nach dem ersten Request entstehen. Auto Tool Selector 4.3 hält native Websuche immer verfügbar, ergänzt bei expliziter Webrecherche den TinySearch-Fallback und erkennt unter anderem `Home Assistant`, `Home-Assistant` sowie direkte `ha_*`-Werkzeugbezüge. Für Home Assistant verlangt er gezielte Zustandsabfragen und verbietet die Ableitung einer `entity_id` aus einer YAML-`id`. Auto Tool Selector 4.3 ergänzt ein site-unabhängiges Marketplace-Protokoll. Es begrenzt normale Kaufsuchen auf wenige fokussierte Recherche- und Verifikationsschritte, nutzt Ergebnis-/Kategorieseiten bei blockierten Detailseiten und verlangt einen aktuellen Beleg, bevor ein Angebot als aktiv bezeichnet wird. Dafür existiert kein eBay-, MakerWorld- oder Shop-spezifischer MCP. OpenWebUI V8 setzt für erkannte Marketplace-Aufträge über beide breiten Webengines zusammen höchstens drei Such- und fünf Abrufoperationen durch; danach folgt die sichtbare Synthese aus den vorhandenen Belegen. Der produktive eBay-Praxistest am 24. August 2026 endete nach exakt drei TinySearch-Suchen und drei konkreten Seitenabrufen. Qwen lieferte danach eine sichtbare Antwort, trennte verifizierte, plausible und nicht verifizierbare Angebote und sortierte Notebook, Zubehör sowie ein Ersatzteilgerät aus. Das belegt sowohl die technische Grenze als auch eine brauchbare Synthese; ein eBay-spezifischer MCP war nicht erforderlich. 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. Zusätzlich bietet er ein breites, ausgabebegrenztes Root-Terminal für Docker, Dateien, Git, HTTP, Modelle und SSH zu konfigurierten Zielsystemen. Strombefehle und Änderungen an Athenas SSH, Netzwerk, WireGuard, Firewall, Boot, Kernel, Mounts und Partitionen sind serverseitig blockiert. Ein separater allgemeiner Shell-MCP wird nicht benötigt; die breite Fähigkeit ist portabel im Athena Operator auf VPN-Port 8202 enthalten. ## 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.