AI-Profile-Router/docs/ATHENA_REBUILD_LOG.md

Athena-Leerhostaufbau – Praxisprotokoll

Dieses Protokoll hält die Abweichungen fest, die beim realen Neuaufbau auf einem frischen Debian-13-Host sichtbar wurden. Jede dauerhaft notwendige Korrektur muss zusätzlich im Installer, Restore-Skript oder in der regulären Betriebsdokumentation umgesetzt werden. Das Protokoll enthält keine Secrets, Chats oder privaten Nutzdaten.

Zielsystem

• Hostname: Athena
• Betriebssystem: Debian 13 amd64
• Persistente Datenplatte: /data, ext4
• Haupt-GPU: NVIDIA RTX 5080 mit 16 GB VRAM
• Containerbetrieb: Docker CE und Compose-Plugin
• Inferenz: gepinnter llama.cpp-Build in Docker
• Oberfläche: OpenWebUI
• Werkzeuge: getrennte MCP-Container für Web, Home Assistant, ARR und Unraid

Bereits eingearbeitete Korrekturen

Bereich	Beobachtung im Leerhosttest	Dauerhafte Umsetzung
NVIDIA	Debian-Basispakete allein lieferten nicht den benötigten aktuellen Treiberzweig.	Offizielles NVIDIA-Repository, Mindestversion, Open-Kernelmodule und reproduzierbarer Neustartpfad im Installer.
CUDA	Container fanden einzelne CUDA-Kompatibilitätsbibliotheken nicht zuverlässig.	Bibliothekspfad und ldconfig werden vom Installer hergestellt und geprüft.
Modelle	Durch die restriktive Installer-Umask konnte der unprivilegierte Inferenzprozess GGUF-Dateien nicht lesen.	Nach erfolgreicher Hashprüfung werden Modelle unveränderlich, aber lesbar mit Modus 0444 gesetzt.
MTP	Das Fast-Modell besitzt den verwendeten MTP-Tensor bereits im IQ4-MIX-GGUF.	Kein redundanter Draft-Download und kein falscher separater Startparameter.
Router	Frische Volumes und der unmittelbar folgende API-Aufruf führten zu Ownership- beziehungsweise Start-Rennen.	Minimale Dateisystem-Capabilities, eigener Healthcheck, Abhängigkeit von gesundem Controller und explizite Readiness-Prüfung.
Installer	Ein erfolgreicher Containerstart wurde zu früh als erfolgreiche Installation gewertet.	Abschluss erst nach Router-Health, erfolgreicher Fast-Aktivierung und eindeutigem INSTALL_READINESS_OK-Marker.
Websuche	TinySearch/SearXNG wurden in mehreren Pfaden gestartet.	Websuche wird ausschließlich durch den Tool-Stack installiert und gestartet.
MCP	Altcontainer sollten nicht in die neue Architektur übernommen werden.	Neue, getrennte Tool-Container; Restore importiert nur freigegebene Secret- und Laufzeitdateien.
OpenWebUI	Eine gesicherte Datenbank war neuer als das zunächst gepinnte OpenWebUI-Image.	Datenbank und Image werden versionsgleich wiederhergestellt; Registry-Digest und OCI-Build-Revision werden geprüft.
Image-Backup	Das alte Archiv openwebui-mcp-images.tar.gz enthielt trotz seines Namens nicht das inventarisierte OpenWebUI-Image.	Restore nutzt als sicheren Fallback nur den gesicherten unveränderlichen Digest. Künftige Backups benötigen einen isolierten Probeimport.
Wiederholung	Ein späterer Installerlauf hätte die restaurierte OpenWebUI-Version wieder überschrieben.	Das Restore schreibt den geprüften lokalen Image-Tag auch in die dauerhafte Installationskonfiguration.
TinySearch-Volume	Das vom Installer vorbereitete Modellvolume wurde von Compose gleichzeitig als Compose-eigen behandelt.	Das Volume besitzt einen festen Namen und ist in Compose ausdrücklich als extern vorbereitet markiert.
Reasoning-Filter	Beide globalen Filter besaßen Priorität 0; bei gleicher Priorität entschied die ID-Sortierung statt der gewünschten Logik.	Reasoning Default Off läuft mit Priorität 10 sicher vor dem optionalen Thinking-Override mit Priorität 20. Filter und sicherer Installer liegen versioniert im Repository.
Folgefragen	OpenWebUI erzeugte nach Antworten zusätzliche Vorschläge und verbrauchte dafür einen weiteren Modellaufruf.	Folgefragengenerierung ist in der persistenten OpenWebUI-Konfiguration und im Compose-Standard deaktiviert.
Werkzeug-/Kontextschutz	Große MCP-Antworten und wiederholte identische Aufrufe konnten Kontextfenster sprengen beziehungsweise Tool-Schleifen erzeugen.	Globaler Stability Guard begrenzt Resultate, verdichtet alte Inhalte profilabhängig und stoppt Wiederholungen; JSON-Schemas und Bilder werden nicht beschädigt.
Leistungsdaten	Benchmarkdaten sollten sichtbar sein, ohne private Chat-Inhalte zu protokollieren.	Ein globaler Abschlussfilter schreibt ausschließlich technische Zahlen in eine lokal rotierende JSONL-Datei und zeigt eine knappe Statuszeile.
Antwortaktionen	Wiederkehrende Nachbearbeitungen sollten bewusst per Klick statt als permanenter Zusatzprompt laufen.	Eine versionierte globale Action bietet lokale Kurzfassung, Checkliste, Diagnose, Unsicherheits-/Quellenprüfung, Thinking-Verbesserung und Markdown-Kopie; keine Schreib- oder Profilwechselaktion.
Sprachausgabe	Beim ersten Leerhostaufbau war kein TTS-Dienst Bestandteil des Compose-Stacks.	Piper piper-tts 1.6.0 läuft als eigener interner CPU-Container mit persistenter deutscher Stimme; Open WebUI nutzt ihn ausschließlich über den authentifizierten Router.
Persistente Audioeinstellungen	Die restaurierte OpenWebUI-Datenbank überstimmte Compose mit dem alten Modell tts-1 und der Stimme coral; der Router antwortete deshalb mit HTTP 400.	Der OpenWebUI-Konfigurator setzt bei Installation und Restore gezielt Engine openai, Modell piper, Stimme alloy und die interne Router-URL. Andere Audio- oder Nutzereinstellungen bleiben unangetastet.

Abnahmezustand am 21. August 2026

• Basisinstallation einschließlich Treiber, Docker, llama.cpp, Router und Fast-Profil erfolgreich.
• Fast-Profil mit 76.800 Token Kontext gestartet und durch Readiness bestätigt.
• HA-, ARR-, Unraid- und Web-MCP als getrennte Container gestartet.
• OpenWebUI-Daten und freigegebene MCP-Konfiguration aus dem Referenzbackup übernommen.
• Exakter OpenWebUI-Build anhand des gesicherten Registry-Digests und Commits rekonstruiert.
• Vollständiger Restore ein zweites Mal erfolgreich und ohne Datenbankmigration ausgeführt.
• OpenWebUI, Router und Fast-Inferenz sind gesund; HTTP-Zugriffe liefern Status 200 und der Router meldet qwen-fast, qwen-medium und qwen-long.
• Alle vier MCP-Endpunkte sind aus dem OpenWebUI-Netz per TCP erreichbar.

Noch abzunehmen

1. Anmeldung und Profilwechsel über die Oberfläche ohne Lesen alter Chat-Inhalte.
2. MCP-Protokolltest jedes Werkzeugs und Prüfung seiner Sicherheitsgrenze.
3. Neustarttest des gesamten Hosts.
4. WireGuard- und Fail-closed-Test am späteren Universitätsstandort.
5. Standardbenchmark mit RTX 5080 und anschließend mit der RTX 3060.
6. Push der lokalen Commits nach unabhängiger Prüfung des Git-Server- Hostschlüssels.

Erst nach diesen Punkten gilt Athena als vollständig reproduzierbare Referenzinstallation.