AI-Profile-Router/docs/CURRENT_REFERENCE.md

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-<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
• 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 mit vier Werkzeugen
• 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.

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.