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
        |
   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 + TinySearch + SearXNG
             +-- Home-Assistant-MCP-Relay
             +-- ARR-MCP
             +-- Unraid-MCP

Container und Vertrauensgrenzen

Komponente	Außen erreichbar	Aufgabe
WireGuard Gateway	VPN-Adresse, Port 8080/8081	Tunnel und eng begrenzte TCP-Proxys
Open WebUI	nur Docker-intern	Chat-Oberfläche
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	nein	voneinander getrennte Werkzeugbereiche
SearXNG/TinySearch	nein	Suchbackend des Web-MCP

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 vier 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 nur 8080/8081 zu den internen Diensten 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 bleiben im Basissystem deaktiviert. Home Assistant, ARR 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.

Zentrale MCP-Werkzeugebene

Werkzeuge werden nicht in llama.cpp eingebaut. Sie laufen als eigene, zentrale MCP-Container. Open WebUI greift intern darauf zu. Für externe Clients wie Hermes wird später ein authentifizierter MCP-Gateway über WireGuard vorgeschaltet; die unauthentifizierten internen Ports werden niemals direkt veröffentlicht. So können alle Oberflächen dieselben geprüften 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 ───────────┬── web-mcp
                                       ├── home-assistant-mcp
                                       ├── arr-mcp
                                       └── unraid-mcp-read

Hermes Agent ─ WireGuard ─┐
weitere MCP-Clients ──────┴── mcp-gateway (später) ── dasselbe interne Netz

Container	Werkzeugbereich	Standardrecht
`web-mcp`	Websuche, Seitenabruf, GitHub/Hugging Face	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
`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
`mcp-gateway`	Auth, Routing, Limits und Werkzeugauswahl	keine Fach-Secrets

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.

Eine allgemeine Host-Shell ist ausdrücklich ausgeschlossen. sandbox-mcp läuft ohne Docker-Socket, ohne Infrastruktur-Secrets und nur mit einem begrenzten Arbeitsverzeichnis. Administrative Aktionen werden als feste, prüfbare Werkzeuge mit Vorschau und Freigabe modelliert.

Clients aktivieren nur die für den aktuellen Chat benötigte Werkzeuggruppe. Das reduziert Tool-Schemas, Kontextverbrauch und Fehlaufrufe kleiner Modelle.

8.7 KiB Raw Blame History Unescape Escape