151 lines
7.2 KiB
Markdown
151 lines
7.2 KiB
Markdown
# Zielarchitektur des neuen KI-Hosts
|
||
|
||
## Grundsatz
|
||
|
||
Der Host läuft auf Debian 13. Das Betriebssystem darf im Universitätsnetz
|
||
administrierbar bleiben; die KI-Plattform wird ausschließlich an die
|
||
WireGuard-Adresse gebunden. KI-Container erreichen Heimnetz und Internet über
|
||
den Heim-WireGuard-Peer. Bei Tunnelausfall verhindert eine Blackhole-Route den
|
||
unbeabsichtigten Rückfall auf das Universitätsgateway.
|
||
|
||
```text
|
||
Heimnetz / VPN-Clients
|
||
|
|
||
WireGuard
|
||
|
|
||
10.77.0.2:8080 Open WebUI
|
||
10.77.0.2:8081 Profile Router API
|
||
|
|
||
Docker-intern
|
||
+-- Profile Controller -- Docker Socket (feste Allowlist)
|
||
+-- llama-fast --\
|
||
+-- llama-medium > exakt einer aktiv
|
||
+-- llama-large --/
|
||
+-- llama-experimental
|
||
+-- llama-ultra (256K, text-only, dual GPU)
|
||
+-- Piper-TTS (CPU, nur intern)
|
||
+-- internes MCP-Netz
|
||
+-- Web-MCP + TinySearch + SearXNG
|
||
+-- Home-Assistant-MCP-Relay
|
||
+-- ARR-MCP
|
||
+-- Unraid-MCP
|
||
```
|
||
|
||
## Container und Vertrauensgrenzen
|
||
|
||
| Komponente | Außen erreichbar | Aufgabe |
|
||
|---|---|---|
|
||
| Open WebUI | nur WireGuard, Port 8080 | Chat-Oberfläche |
|
||
| Profile Router | nur WireGuard, Port 8081 | OpenAI-API und Profilwahl |
|
||
| Profile Controller | nein | startet ausschließlich vier bekannte Profile |
|
||
| llama.cpp Profile | nein | Inferenz, Tool Calling, integrierte Vision |
|
||
| Piper | nein | lokale deutsche Text-to-Speech-Ausgabe |
|
||
| 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` 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 |
|
||
| 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 und Large 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. 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 binden an `AI_BIND_ADDRESS`, die WireGuard-IP.
|
||
- Quellrouting schickt KI-Container in Tabelle 51820 über WireGuard.
|
||
- Eine Blackhole-Default-Route bleibt als Fail-Closed-Fallback bestehen.
|
||
- Firewallregeln gestatten aus dem VPN nur die beiden veröffentlichten Ports.
|
||
- Der Host routet weder Universitätsverkehr ins Heimnetz noch Heimverkehr ins
|
||
Universitätsnetz.
|
||
- Das Heimnetz muss die Rückroute zur WireGuard-Adresse kennen. Soll auch der
|
||
Internetzugang der KI über zuhause laufen, braucht der Heim-Peer zusätzlich
|
||
IP-Forwarding und NAT ins Heim-WAN.
|
||
|
||
## Optionale Erweiterungen
|
||
|
||
Piper läuft als eigener CPU-Container und wird von Open WebUI über den Router
|
||
angesprochen. Sein Port wird nicht veröffentlicht. Das Stimmenmodell liegt im
|
||
persistenten Volume `piper-data` und wird beim ersten Start reproduzierbar
|
||
nachgeladen. 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.
|
||
|
||
```text
|
||
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.
|