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

186 lines
10 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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
<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 |
| 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.
```text
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.