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
        +-- 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
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, 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.

Optionale Erweiterungen

Bildgenerierung, Whisper und TTS benötigen eigene Modelle und 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.

6.3 KiB Raw Blame History Unescape Escape