Files

T

Mikei386 662913f8ab Add compact Athena MCP release workflow

2026-08-25 08:51:46 +02:00

20 KiB

Raw Blame History

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

Kontextkompression läuft frühzeitig bei 65 Prozent des jeweiligen Profilfensters. Alte große Werkzeugausgaben werden ab 50.000 Token zunächst ohne Modellaufruf bereinigt; tail_mode: lean hält nach der Kompression einen kleinen, zusammenhängenden jüngsten Abschnitt. Dadurch sollen keine mehrfachen minutenlangen Zusammenfassungen eines bereits weit überfüllten Threads mehr nötig werden.
Die Kompressionszusammenfassung nutzt weiterhin dasselbe aktive Modell. Ein kleineres Fast-Modell wäre zwar schneller, besitzt aber nicht genug Kontext, um die vollständige Mitte einer Medium-, Large- oder Ultra-Sitzung sicher zu verarbeiten. reasoning_effort: none vermeidet unnötiges Nachdenken beim reinen Zusammenfassen.
Summarizing thread ist eine echte zusätzliche Modellanfrage. Bei sehr alten Sitzungen kann die Desktop-Anzeige nach abgeschlossener Kompression außerdem veraltet stehen bleiben. Maßgeblich sind dann Sitzungsfortschritt und Backend-Log, nicht das Label allein.
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
Profile: Fast 76,8K, Medium 160K, Large 192K, Ultra 262K und Uncensored 80K; alle verwenden dieselben MCPs, Skills, Sprach- und Sicherheitsvorgaben
Der verwaltete Skill athena-operator wird aus dem Repository in das Standardprofil und alle fünf benannten Profile synchronisiert. Er enthält nur die verbindliche Arbeitslogik; Architektur und Ist-Zustand werden bedarfsgerecht aus Platform-Context- und Operator-MCP gelesen.
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
Optionale Community-WebUI 0.52.113 auf WireGuard-Port 8787: eigener Container und eigener Zustand unter /data/hermes-webui; Chats laufen über die vorhandene Hermes-Gateway-API. Der vom Upstream-Entrypoint benötigte gemeinsame Hermes-Home-Mount ist beschreibbar; UI-eigener Zustand bleibt davon getrennt. Änderungen in WebUI-Einstellungen wirken daher bewusst auf die zentrale Hermes-Konfiguration. Eine schreibgeschützte Kopie des exakt gepinnten Hermes-Agent-Codes liegt unter /data/hermes-webui/hermes-agent, damit Modell-, Skill- und Sitzungsfunktionen nicht im reduzierten Modus laufen; der Installer erneuert sie nur bei geändertem Hermes-Image. Der kleine Container mike-ai-hermes-webui-vpn-proxy teilt ausschließlich den Netzwerk-Namespace des WireGuard-Gateways und hält Port 8787 rebootfest, ohne das Gateway für Installation oder Entfernung neu zu erstellen.

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.

Seit Operator 2.2 werden kleine Änderungen als SHA-geschützte Unified Diffs über patch_update übertragen. mcp_release fasst den üblichen vollständigen MCP-Ablauf in einem bestätigten Auftrag zusammen: Patch, Tests, benannter Deploy, OpenWebUI-Sync, selektiver Git-Publish und Recovery. Damit muss das Modell keine kompletten Compose- oder Installationsdateien rekonstruieren.

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.

20 KiB Raw Blame History Unescape Escape