AI-Profile-Router/docs/CURRENT_REFERENCE.md

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-<profil>
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 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, drei begrenzte 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 drei passende Fach-MCP-Verbindungen pro Anfrage. 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; web-local ist nur noch manuell für Spezialfälle verfügbar. 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 zwölf einzelne Werkzeuge aus, höchstens vier Varianten desselben Werkzeugs und niemals 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-v5.

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.