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.

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-long         --/
        +-- llama-experimental
        +-- SearXNG + Web-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
SearXNG	nein	Websuche für den lokalen 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, long 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	94.208 Kontext	mehr Kontext ohne CPU-FFN-Offload
long	131.072 Kontext	maximale Nutzbarkeit, CPU-Offload erlaubt
experimental	76.800 Kontext	isolierte Tests ohne Produktion zu ändern

Diese Werte sind reproduzierbare Startwerte, keine Garantie. Nach Einbau der RTX 3060 werden sie auf dem Zielhost erneut gemessen. Die zweite Karte wird nicht automatisch in die Produktionsprofile aufgenommen.

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.

Nicht automatisch installiert

Bildgenerierung, Whisper, TTS sowie Home-Assistant-, ARR- und Unraid-MCPs sind Erweiterungen. Sie benötigen eigene Modelle, Rechte oder Secrets und bleiben im sauberen Basissystem deaktiviert. 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 fest in Open WebUI, Hermes oder einen anderen Client eingebaut. Sie laufen als zentrale, über WireGuard erreichbare MCP-Server. Alle MCP-fähigen Oberflächen verwenden dadurch dieselben geprüften Werkzeuge, ohne Secrets oder Installationen 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 ──┐
Hermes Agent ├── mcp-gateway ──┬── web-mcp
weitere MCP- ┘                 ├── home-assistant-mcp-read
Clients                         ├── home-assistant-mcp-write
                                ├── arr-mcp-read
                                ├── arr-mcp-write
                                ├── unraid-mcp-read
                                ├── unraid-mcp-admin
                                └── sandbox-mcp

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, Monitoring und Downloadtrigger	Preview/Approval
`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.

6.0 KiB Raw Blame History Unescape Escape