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)
• Medium/Hermes: Thinking-Sampler gemäß Qwen-Empfehlung mit Temperatur 1,0, Top-p 0,95 und Top-k 20
• Medium/Hermes: maximal 8.192 Reasoning-Token pro einzelner Denkphase; Werkzeugrunden erhalten jeweils eine neue Denkphase
• andere Profile: 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

Hermes Agent

• Container: mike-ai-hermes
• Standardsprache: Deutsch (display.language, deutsches SOUL.md)
• Spracheingabe: lokales Faster-Whisper, Modell base, Sprachhinweis de
• Sprachausgabe: Athena-TTS über die OpenAI-kompatible Router-API; XTTS v2 mit Annmarie Nele, Piper als automatischer Fallback
• Bei einer entfernten Hermes-Desktop-App läuft Audio bewusst über das Hermes-Backend (voice.client_direct: false), weil Router und TTS nur im internen Docker-Netz erreichbar sind.
• Version: 0.20.5, offizielles Image per OCI-Digest gepinnt
• Standardmodell: qwen-medium, 160.000 Kontext, über den Profile Router
• Dashboard: WireGuard-Port 9119 mit Basic-Auth
• Agent-API: WireGuard-Port 8642 mit eigenem Bearer-Key
• persistenter Zustand: /data/hermes
• lokales Terminal: ausschließlich /data/hermes/workspace im Container
• MCPs: Athena-Plattform, Athena-Operator, allgemeines Web, GitHub, Home Assistant, ARR, Navidrome und ein gemeinsamer MUA-Unraid-Zugang
• kein Docker-Socket, kein Host-Root-Mount und keine Veröffentlichung auf der Universitätsadresse
• Start verweigert, wenn die verwaltete Konfiguration nicht lesbar ist oder nicht ausdrücklich custom und den lokalen Router als Provider nennt

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

Ab MUA r022 stehen für lange, explizit autorisierte Arbeiten zusätzlich unraid_system_job_start, unraid_system_job_status und unraid_system_job_cleanup bereit. Der Start kehrt sofort mit einer Job-ID zurück; Statusabfragen liefern nur kompakte, redigierte Ausgaben. Damit blockiert ein Download, Transcode oder vergleichbarer Auftrag weder Open WebUI noch Hermes oder Pi bis zum Prozessende. Die drei Werkzeuge erben dieselbe ausdrücklich erteilte Berechtigung wie die uneingeschränkte Shell.

Ab MUA r023 begrenzt unraid_system_shell_readonly seine Ausgabe bereits auf dem Unraid-Server standardmäßig auf 12.000 Zeichen; pro Aufruf sind explizit 1.000 bis 30.000 Zeichen möglich. Auto Tool Selector 4.7 ergänzt für offene Diagnosen eine allgemeine Beweiskette: kompakten Status oder Benachrichtigung prüfen, das neueste exakte Artefakt lokalisieren, nur entscheidende Zeilen lesen, die führende Ursache mit einem unabhängigen Fakt bestätigen und dann antworten. Vollständige Konfigurationen, rekursive Verzeichnisbäume und breite historische Logs sind kein zulässiger Standardweg.

Auto Tool Selector 4.7 kennzeichnet allgemeine lange Operator-Aufgaben produktunabhängig. Der OpenWebUI-Agentenloop stellt dafür bis zu 64 Werkzeugausführungen insgesamt und 24 je Werkzeug bereit; normale Aufgaben bleiben bei 40/12. Zusätzlich verlangt der Systemhinweis das generische Start-Status-Ergebnis-Muster und reserviert den Abschluss für Verifikation, Zielablage und Aufräumen.

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 bei normalen Aufgaben höchstens 40 einzelne Werkzeuge und höchstens zwölf Aufrufe desselben Werkzeugnamens aus. Allgemeine lange Operator-Aufgaben erhalten 64 beziehungsweise 24. Exakt dieselbe Signatur bleibt stets auf zwei Wiederholungen begrenzt. 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-v9.

Das in V9 enthaltene Verhalten aus V8 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.

Auto Tool Selector 4.6 erkennt zusätzlich allgemeine operative Arbeit über Fähigkeitsklassen: Eine ausdrückliche Ausführungs- oder Änderungsabsicht in Verbindung mit Host, Dateisystem, Kommando, Dienst, Pfad oder typischen Kommandozeilenwerkzeugen stellt den Athena Operator bereit. Dadurch benötigen neue Programme wie Download- oder Medienwerkzeuge keine eigene Selector-Regel. Bei Unraid-Arbeit werden MUA für kompakte Bestandsaufnahme und der Operator für die ausdrücklich verlangte allgemeine Schreibarbeit gemeinsam angeboten. Lange Operator-Aufgaben werden dabei produktunabhängig markiert und folgen dem Start-Status-Ergebnis-Muster, damit Recherche und Vorbereitung nicht das Budget für Ausführung, Verifikation und Aufräumen verbrauchen.

Für andere Clients gilt docs/CLIENT_TOOL_STANDARD.md. Hermes lädt die drei Kern-MCPs Web, Operator und Plattformwissen direkt per Streamable HTTP; die Vorlage liegt unter config/hermes-mcp-core.yaml.example. Damit hängt die Fähigkeit nicht vom OpenWebUI-Filter ab.

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.