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`](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.

Auto Tool Selector 4.6 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.