184 lines
9.6 KiB
Markdown
184 lines
9.6 KiB
Markdown
# 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.
|
||
|
||
```text
|
||
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
|
||
+-- offizieller GitHub-MCP (vier read-only Werkzeuge)
|
||
+-- 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 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. 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.
|
||
|
||
```text
|
||
Open WebUI ── internes Netz ───────────┬── web-mcp
|
||
├── home-assistant-mcp
|
||
├── arr-mcp
|
||
├── github-mcp-read
|
||
├── navidrome-mcp
|
||
└── unraid-mcp-read
|
||
|
||
Hermes Agent ─ WireGuard ─┐
|
||
weitere MCP-Clients ──────┴── mcp-gateway (später) ── dasselbe interne Netz
|
||
```
|
||
|
||
| Container | Werkzeugbereich | Standardrecht |
|
||
|---|---|---|
|
||
| `web-mcp` | Websuche, Seitenabruf, Hugging Face und öffentliche Quellen | nur lesen |
|
||
| `github-mcp-read` | Repositorysuche, Baum, Dateiinhalt und Code-Suche | vier 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 |
|
||
| `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.
|