Files
AI-Profile-Router/docs/CURRENT_REFERENCE.md
T

8.9 KiB
Raw Blame History

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 Terminal: eng begrenzte Lesebefehle und Syntaxprüfung in Stack/Snapshot
  • 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 ergänzende Athena Terminal MCP ist kein Host-Terminal. Er sieht nur den read-only Stack und Laufzeitsnapshot und besitzt eine Positivliste weniger Lesebefehle. SSH/SCP, Docker, Netzwerkclients, Interpreter, systemctl, Prozesssignale, Reboot, Shutdown, Secrets und Schreibzugriffe sind nicht verfügbar. Der Auto Tool Selector lädt ihn nur bei ausdrücklich auf Athena bezogener Terminal-/Shell-Arbeit.

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.