Zielarchitektur des neuen KI-Hosts

Grundsatz

Der Host läuft auf Debian 13. Das Betriebssystem darf im Universitätsnetz administrierbar bleiben. Ein eigener Docker-Gateway beendet WireGuard und ist der einzige von außen erreichbare Einstieg in die KI-Plattform. KI-Container erreichen Heimnetz und Internet über die Fritzbox; Quellrouting zum Gateway verhindert bei Tunnelausfall einen Rückfall auf das Universitätsgateway.

Heimnetz / VPN-Clients
        |
     WireGuard
        |
  <Fritz-VPN-IP>:8080     Open WebUI
  <Fritz-VPN-IP>:8081     Profile Router API
  <Fritz-VPN-IP>:9119     Hermes Dashboard
  <Fritz-VPN-IP>:8642     Hermes Agent API
  <Fritz-VPN-IP>:8201-08  direkte MCP-Endpunkte
        |
   Docker-intern
        +-- Profile Controller -- Docker Socket (feste Allowlist)
        +-- llama-fast         --\
        +-- llama-medium         > exakt einer aktiv
        +-- llama-large        --/
        +-- llama-uncensored (80K, Abliterated, dual GPU)
        +-- llama-experimental
        +-- llama-ultra (256K, text-only, dual GPU)
        +-- TTS-Gateway
        |    +-- XTTS-v2 / Annmarie Nele (RTX 3060, primär)
        |    +-- Piper-TTS (CPU, automatischer Fallback)
        +-- internes MCP-Netz
             +-- Web-MCP + SearXNG + TinySearch/Crawl4AI + YouTube-Adapter
             +-- offizieller GitHub-MCP (drei kleine read-only Werkzeuge)
             +-- Home-Assistant-MCP-Relay
             +-- ARR-MCP
             +-- Unraid-MCP

Container und Vertrauensgrenzen

Komponente	Außen erreichbar	Aufgabe
WireGuard Gateway	VPN-Adresse, feste Portmatrix	Tunnel und direkte TCP-Proxys für UI, API und Werkzeuge
Open WebUI	nur Docker-intern	Chat-Oberfläche
Hermes Agent	nur Docker-intern; Dashboard/API über VPN-Gateway	agentische Oberfläche, Skills, Sitzungen und MCP-Client
Profile Router	nur Docker-intern	OpenAI-API und Profilwahl
Profile Controller	nein	startet ausschließlich fest erlaubte Profile
llama.cpp Profile	nein	Inferenz, Tool Calling, integrierte Vision
XTTS-v2	nein	primäre deutsche/englische Text-to-Speech-Ausgabe auf RTX 3060
TTS-Gateway	nein	serialisiert XTTS, segmentiert Sprachwechsel und fällt auf Piper zurück
Piper	nein	CPU-basierte Text-to-Speech-Rückfallebene
MCP-Tool-Stack	über feste VPN-Ports	voneinander getrennte Werkzeugbereiche für OpenWebUI, Pi und Hermes
SearXNG/TinySearch	nein	private Suche, Crawl4AI-Extraktion und lokales Reranking

Nur der Profile Controller erhält den Docker-Socket. Der Router erhält weder Socket noch Shell-Zugriff und kann dem Controller nur fast, medium, large, ultra, uncensored oder experimental übergeben. Die llama-Container laufen ohne UI, Capabilities und Schreibzugriff auf die Modelldateien.

Profilprinzip

Alle Profile verwenden dasselbe selbst gebaute llama.cpp-Image. Separate, normalerweise gestoppte Containerdefinitionen halten Parameter wie Kontext, MTP und CPU-Offload reproduzierbar. Ein Wechsel stoppt das alte Profil und startet genau einen bereits angelegten Container. Dadurch lassen sich Profile einzeln verändern oder duplizieren, ohne mehrere Modelle parallel im VRAM zu halten.

Profil	Ausgangswert	Zweck
fast	76.800 Kontext, MTP	mindestens ungefähr 80 Token/s anstreben
medium	160.000 Kontext, Pure, 90:10, MTP3	Standardprofil
large	192.000 Kontext, Pure, 86:14, MTP3	große Agenten-/MCP-Sitzungen
ultra	262.144 Kontext, Pure, 80:20, MTP2	maximaler Textkontext
uncensored	80.000 Kontext, Abliterated Q4_K_M, 90:10, MTP2	weniger Verweigerungen bei unveränderten Tool-Grenzen
experimental	76.800 Kontext	isolierte Tests ohne Produktion zu ändern

Diese Matrix wurde auf RTX 5080 und RTX 3060 gemessen und ist bis zu einer bewussten Neubewertung der verbindliche Produktionsstandard.

Bei Fast, Medium, Large und Uncensored bleibt das Sprachmodell wie in der Tabelle verteilt, während MTMD_BACKEND_DEVICE=CUDA1 den vollständigen Multimodal-Projektor auf die RTX 3060 legt. Ein reproduzierbarer Test mit einem synthetischen Bild (1024×768, 835 Eingabetoken) senkte die Bild-/Promptzeit im Medium-Profil von 23,17 auf 1,68 Sekunden und die gesamte Anfrage von 24,96 auf 2,94 Sekunden. Der Projektor belegte dabei rund 1,1 GiB zusätzlichen VRAM auf der 3060. Das Uncensored-Profil nutzt seinen passenden eigenen Projektor. Ultra bleibt für maximalen Kontext bewusst text-only.

Netzwerk

Docker-Netze liegen ausschließlich unter 172.30.0.0/16.
Open WebUI und Router besitzen keine Docker-Host-Portfreigabe.
Der Gateway lauscht in seinem eigenen Namespace auf der Fritz-VPN-IP und leitet die dokumentierte Portmatrix zu UI, API, TTS und MCPs weiter.
Quellrouting schickt 172.30.10.0/24 und 172.30.50.0/24 zum Gateway; Regeln für 172.30.0.0/16 bewahren rein internen Docker-Verkehr.
Die verschlüsselten äußeren Gateway-Pakete sind eng von diesen Quellregeln ausgenommen und verlassen Athena über die normale Standortverbindung.
Bleibt die Gateway-Adresse aus, existiert keine alternative Route für die Anwendungscontainer (fail-closed).
Der Host routet weder Universitätsverkehr ins Heimnetz noch Heimverkehr ins Universitätsnetz.
Adressen, Heimrouten, Full-Tunnel und Keepalive stammen aus dem root-only Fritzbox-Clientexport; der Debian-Host übernimmt dessen Default-Route nicht.

Optionale Erweiterungen

Open WebUI spricht ausschließlich den Router an. Dieser reicht TTS intern an das TTS-Gateway weiter. Das Gateway nutzt primär XTTS-v2 mit der Stimme Annmarie Nele auf der RTX 3060. Gemischte deutsch-englische Antworten laufen bewusst als vollständige deutsche Satzblöcke: Das vermeidet die langen Pausen, Tonhöhensprünge und unverständlichen Übergänge, die beim Zusammensetzen vieler kurzer Sprachsegmente entstanden. Vollständig englische Texte werden weiterhin automatisch mit language=en gesprochen. Da der offizielle XTTS-Streamingserver nur einen Auftrag gleichzeitig unterstützt, serialisiert das Gateway die Aufträge. Bei Fehler, Timeout oder belegter Queue übernimmt automatisch Piper auf der CPU. Kein TTS-Port wird veröffentlicht. Der äußere Kompatibilitätsname bleibt bewusst piper/alloy, damit persistente Open-WebUI-Einstellungen nach Updates und Restores gültig bleiben. Bildgenerierung und Whisper werden bei Bedarf über die stabilen Router-Endpunkte gestartet; ihre Worker sind keine dauerhaft geladenen Inferenzprofile. Home Assistant, ARR, GitHub und Unraid sind vorbereitete MCP-Profile: Sie werden erst gestartet, wenn die jeweilige root-only Secret-Datei vorhanden ist. Multimodale Bildanalyse erfolgt direkt über Qwen plus Projektor. Nicht installierte Worker-Endpunkte antworten klar mit feature_disabled, statt alte systemd-Pfade aufzurufen.

Vor der Synthese wandelt das Gateway visuelle Schreibweisen in natürliche deutsche Sprache um. Dazu gehören Datumsangaben, Temperaturbereiche, Prozentwerte, fünfstellige Postleitzahlen und Internet-Domains. Das verhindert Ausgaben wie „zweiundzwanzig Komma zehn“ für 22° / 10°; Domain-Endungen werden eindeutig buchstabiert.

Zentrale MCP-Werkzeugebene

Werkzeuge werden nicht in llama.cpp eingebaut. Sie laufen als eigene, zentrale MCP-Container. Open WebUI greift intern darauf zu; Pi, Hermes und andere Clients verwenden ihre festen Ports direkt auf Athenas WireGuard-Adresse. Ein zusätzliches MCP-Gateway ist nicht erforderlich. So können alle Oberflächen dieselben Werkzeuge verwenden, ohne Secrets zu duplizieren.

Die Trenneinheit ist ein Container pro Fachbereich und Vertrauensstufe – nicht ein Container pro einzelner Funktion und nicht ein gemeinsamer Allzweck-MCP mit sämtlichen Zugangsdaten.

Open WebUI ── internes Netz ───────────┬── native Websuche / TinySearch-MCP
                                       ├── platform-context-mcp
                                       ├── home-assistant-mcp
                                       ├── arr-mcp
                                       ├── github-mcp-read
                                       ├── navidrome-mcp
                                       └── unraid-mcp-read

Hermes Agent ─ WireGuard ─┐
Pi / weitere MCP-Clients ─┴── feste VPN-Ports 8201-8208 ── MCP-Container

Container	Werkzeugbereich	Standardrecht
`tinysearch`	allgemeine portable Websuche für beliebige Sites	nur lesen; kurze Resultate
`athena-operator`	strukturierte Plattformarbeit plus breites Terminal	Power und Erreichbarkeitsumbau blockiert
`platform-context-mcp`	Architektur, Quellen, Snapshot und Docs-Pflege	kein Docker-Socket; Docs nur Preview/Approval
`github-mcp-read`	Repositorysuche, gezielte Datei- und Code-Suche	drei Tools, strikt nur lesen
`home-assistant-mcp-read`	Entities, Bereiche, Historie, Diagnose	nur lesen
`home-assistant-mcp-write`	kontrollierte HA-Änderungen	Preview/Approval
`arr-mcp-read`	Sonarr/Radarr-Status und Releasesuche	nur lesen
`arr-mcp-write`	Suche fehlender Episoden über Sonarr-Indexer	Preview/Approval; Monitoring unverändert
`navidrome-mcp`	Musikbibliothek, Suche, Playlists, Favoriten, Hörverlauf	eigener Navidrome-Benutzer; gezielt aktivieren
`unraid-mcp-read`	System-, Container- und begrenzte Logdiagnose	nur lesen
`unraid-mcp-admin`	eng definierte Verwaltungsaktionen	bewusst aktivieren
`sandbox-mcp`	temporäre Code- und Dateiarbeit	isolierter Arbeitsraum
Read- und Write-Instanzen dürfen dasselbe Image verwenden, laufen aber mit
unterschiedlichen Tokens, Netzwerkzugriffen und Werkzeug-Allowlisten. Der
Gateway besitzt keine HA-, ARR- oder Unraid-Secrets. Er authentifiziert Clients,
routet zum zuständigen MCP und begrenzt Antwortgröße, Laufzeit und Aufrufrate.

Ein zweiter allgemeiner Host-Shell-MCP ist ausgeschlossen, weil das breite Terminal bereits im Athena Operator liegt. Der Operator hält Ausgaben kurz und blockiert ausschließlich Befehle, die Stromversorgung oder Athenas entfernte Erreichbarkeit gefährden. Wiederkehrende Administrative Aktionen bleiben als strukturierte, prüfbare Werkzeuge modelliert.

OpenWebUI ergänzt passende Fachgruppen automatisch; das allgemeine Web bleibt immer verfügbar. Andere Clients können dieselben MCP-Endpunkte direkt nutzen.

10 KiB Raw Blame History Unescape Escape