8.6 KiB
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/24und172.30.50.0/24zum Gateway; Regeln für172.30.0.0/16bewahren 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. Deutsche Texte werden an bekannten
englischen IT-Begriffen segmentiert; reine englische Texte laufen vollständig
mit language=en. 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.