Eigenständige Oberfläche mit Python und HTML/CSS/JavaScript. Python >= 3.10; verschlüsselte Backups benötigen python3-cryptography (im Docker-Installer enthalten). Kein Frontend-Build nötig.

Die Navigation beginnt mit dem Dashboard. Es zeigt die Live-Telemetrie und die aus dem alten Athena-Dashboard übernommene History; die frühere separate Hardware-Seite wurde entfernt.

Die Übersicht enthält Dashboard und Steuerung (Endpunkt und GPU-Modi). KI-Werkzeuge trennt Chat & Sprachmodelle, Bildgenerierung, Musikgenerierung, Sprachausgabe, Spracherkennung, Stimmwerkzeuge und Videogenerierung. Zusätzliche Oberflächen stehen unter Anwendungen → Weitere Dienste.

Unter Einstellungen → Laufzeiten führt eine aufklappbare Liste zu den Installations-, Versions- und Statusseiten. Der Laufzeiten-Katalog zeigt den aktuellen Installationsstatus, lässt sich nach Name und Bereich filtern und bietet eine direkte llama.cpp-Releaseprüfung mit Änderungsnotizen. „Build vorbereiten“ übernimmt das Release in das Buildformular; erst dessen Bestätigung startet den Build. Audio Separator besitzt einen eigenen Installer und WAV-Trenntest. Unterstützte BS-/MelBand-RoFormer-Pakete werden einschließlich passender YAML-Konfiguration geladen; ungeprüfte Hub-Dateien werden dadurch nicht freigeschaltet. Die einzelnen Laufzeiten stehen nicht mehr separat in der Seitenleiste. Bibliothek und Profile verwenden kompakte, aufklappbare Zeilen. Bibliotheken gruppieren die Dateien nach Hauptgewichten, Vision-/Audio-Projektoren, Textencodern, VAE, Konfigurationen und weiteren Zusatzkomponenten; nur vorhandene Gruppen werden angezeigt. Unbekannte Rollen bleiben separat sichtbar. In den Zeilen: Details, API-Freigabe, Komponenten und Aktionen stehen in der geöffneten Zeile. Downloads behalten Fortschritt, Geschwindigkeit, Restzeit und Warteschlangenaktionen. Der laufende Betrieb wird zentral unter Steuerung angezeigt; Testbereiche behalten ihre jeweiligen Formulare. Bestehende URL-Fragmente bleiben gültig.

Vorläufige Testinstallation auf Debian

Zielprodukt: nativer systemd-Dienst auf Debian. Der derzeitige Docker-Installer dient ausschließlich der isolierten Testphase.

Ein eigenständiger Testinstaller ohne WireGuard ist vorhanden: Debian-Installation. Auf dem Zielserver: sudo ./install.sh --check, anschließend sudo ./install.sh --install. Vorhandenes Docker wird vorausgesetzt; produktive Dienste werden nicht verändert.

Neu: Modellverwaltung und llama.cpp-Einstellungen

Katalog, Datei-Downloads, Bibliothek, serverseitig gespeicherte Profile und llama.cpp-Buildverwaltung sind live. Der Download-Reiter erlaubt das Ausblenden abgeschlossener Einträge ohne Dateiverlust. Entdecken zeigt Größen und eine konservative Gewichts-Speicherprüfung; noch keine vollständige Laufzeitprognose. Bildprofile mit vollständigem Qwen-Image-2.1-GGUF-Rezept lassen sich unter „Testen“ ausführen. Textprofile sind am eigenen OpenAI-kompatiblen Endpunkt ausführbar. Qwen3-TTS CustomVoice ist über eine eigene CUDA-Laufzeit ausführbar; Qwen3-ASR bietet Spracherkennung; Musik, Voice und Video bleiben vorbereitet. Sprachmodelle besitzen außerdem einen internen Testchat mit Abbruch und Speicherdiagnose. Details: Modellverwaltung.

Der Bildtest und /v1/images/edits akzeptieren beim geprüften Qwen-Image-2.1-Rezept bis zu vier Referenzbilder. Die Zahl wird pro aktivem Modellrezept angezeigt; andere Bildmodelle erhalten keine ungeprüfte Edit-Fähigkeit.

Entdecken und Bibliothek zeigen die aus Hugging-Face-Metadaten erkennbare Modellfamilie und den Status der vorhandenen Laufzeit. Bei unbekannten Bildvarianten kann Deck eine vorhandene ComfyUI-Installation als mögliche Basis anzeigen. Ohne geprüftes Komponentenrezept und Workflow bleibt das Modell gesperrt; ein weiterer Runtime-Build wird daraus nicht automatisch abgeleitet.

LTX Original und LTX DeskWEB

Unter Einstellungen → Laufzeiten → LTX Original wird das gepinnte originale LTX-Desktop-Backend separat installiert. Vorhandene Modellgewichte werden per Dateiansicht wiederverwendet. Im Bereich Video kann zwischen ComfyUI und LTX Original gewählt werden; LTX DeskWEB benötigt LTX Original. Details: LTX Original.

Zugang und API-Token

Beim ersten Öffnen werden Oberflächenkennwort und separater API-Token eingerichtet. Beide sind unter Zugang & API änderbar. Der Debian-Installer richtet den Zugang vor dem Serverstart ein. Details und API-Rechte: Zugangsverwaltung.

WireGuard-Einstellungen

Das separate WireGuard-Modul enthält Conf-Import und LAN-/Tunnel-Zugriff. In der aktuellen Debian-Entwicklungsinstanz ist es nicht angebunden; der Zugriff erfolgt über SSH-Tunnel. Der bestehende Gateway bleibt unverändert.

Zielsystem und Entwicklung

Athena Deck läuft vollständig auf einem Debian-Server mit RTX 5080 und RTX 3060. Oberfläche, API, Router und Hardware-Erfassung laufen dort. Der Arbeitsplatz benötigt nur Browser und SSH; er ist kein Anwendungsserver. Auch Builds und Integrationstests werden auf Athena ausgeführt. Chat- und Qwen-Image-Laufzeiten sind am eigenen Endpunkt angebunden.

Die isolierte Entwicklungsinstallation ist in DEVELOPMENT.md beschrieben. Hardware wird direkt über /proc, hwmon und nvidia-smi gelesen; Deck benötigt dafür keinen SSH-Schlüssel. Der eigene Router ist in ENDPOINT.md dokumentiert.

Interne API v1

Die GUI verwendet eine sitzungsgeschützte Verwaltungs-API. GET /api/v1/status und GET /api/v1/hardware sind auch mit dem separaten API-Token lesbar. Die Übersicht steuert den eigenen OpenAI-kompatiblen API-Listener; Demo-Dienst und Demo-Routen wurden entfernt. Port, Profilfreigaben, Inferenzrouten, Betriebsgrenzen und SSH-Tunnel: ENDPOINT.md.

Hardware: available bezeichnet Erfolg der Hardware-Abfrage, einzelne Messwerte können trotzdem fehlen (null). Ein Ausfall der Erfassung liefert available=false, leere Daten und eine Fehlermeldung, keine alten Werte als vermeintliches Livebild. CPU-Auslastung: 250-ms-Differenz aus /proc/stat ohne doppelte Guest-Zählung. RAM: MemTotal minus MemAvailable aus /proc/meminfo, Einheit Bytes. CPU-Temperatur: k10temp/coretemp temp1_input, Grad Celsius. GPU: nvidia-smi CSV mit Index, UUID, Name, VRAM in MiB, GPU-Auslastung in Prozent, Temperatur in Grad Celsius. Keine Zuordnung nach vermuteter GPU-Reihenfolge. Die Anzeige rechnet Speicher in GiB um. Fehlende Werte heißen „Nicht verfügbar“. Abfrage mit höchstens einer Sekunde Cache; das Dashboard aktualisiert jede Sekunde und zeichnet unabhängig von der geöffneten Seite alle 15 Sekunden auf. Details zur historischen Datenbank stehen in DASHBOARD.md.

Struktur und Grenzen

server.py: Verwaltungs-API und lesende Dashboard-/Hardware-Abfragen.
dashboard_data.py und dashboard_history.py: Live-Telemetrie und persistente History.
endpoint.py: separater authentifizierter Inferenz-Listener.
inference.py: native llama.cpp-Prozesse und gemeinsame GPU-Reservierung.
image_test.py: eigene ComfyUI-Aufträge, gemeinsam mit dem Router koordiniert.
endpoint-ui.js: Übersicht, Port und Profilfreigaben.

Sprachmodelle und Qwen-Image-Profile sind ausführbar. Qwen3-TTS CustomVoice ist ebenfalls ausführbar; übrige Audio-/Video-Laufzeiten bleiben vorbereitet; weitere Docker-Dienste werden nur mit Deck-Labels angezeigt. Der native systemd-Installer ist noch nicht vollständig; aktuell gilt der isolierte Docker-Testinstaller. Keine Migration oder Steuerung des bisherigen Routers.

Verifikation am 28.09.2026

python3 -m unittest discover -s . -v: drei Tests erfolgreich. Zusätzlich GUI-Start → Läuft/Erreichbar → Stopp → Gestoppt/Nicht erreichbar geprüft. Hardware im Browser mit Ryzen 5 5600, 46,9 GiB RAM, RTX 3060 und RTX 5080 geprüft; CPU-/GPU-Temperaturen, VRAM und Auslastung vorhanden. Hardware-Ausfall im Test simuliert, ohne Athena oder SSH zu unterbrechen. Produktive Router-/Modell-/Bild-/Audio-/Netzwerkdienste nicht verändert. Vorhandene ungesicherte Änderungen im übergeordneten Repository unangetastet.

Bildlaufzeit installieren und Profile entfernen

Unter Einstellungen → Laufzeiten → Bildgenerierung zeigt Deck die Herkunft und die festgelegten ComfyUI-/GGUF-Versionen. Fehlt die Umgebung, installiert Bildlaufzeit installieren sie ohne Rootrechte in state/image-runtime. Voraussetzungen: Linux, Python mit venv, Git, Internet und 25 GiB freier Speicher; ein kompatibler NVIDIA-Treiber muss vom Systeminstaller bereitgestellt sein. Die Installation ist abbrechbar, startet kein Modell und aktiviert die neue Umgebung erst nach Paketprüfung. Bereits mitgelieferte Umgebungen werden erkannt; ein Versionsupdate der Bildlaufzeit ist hier noch nicht vorgesehen.

Profile lassen sich in allen Kategorien löschen. Modell- und Komponentendateien bleiben erhalten. Die API verhindert das Löschen des gerade ausgeführten Bildprofils und prüft die Profilrevision gegen zwischenzeitliche Änderungen.

Neue sitzungsgeschützte API-Routen: GET /api/v1/image-runtime, POST /api/v1/image-runtime/install und /cancel mit {} sowie POST /api/v1/profiles/delete mit { "id": "…", "revision": 1 }. POST benötigt wie die übrigen Verwaltungsaktionen X-Athena-Deck: 1.

Das Dashboard zeigt GPU-Rechenlast und VRAM-Belegung mit separaten Balken. Es sind Host-Gesamtwerte einschließlich anderer Dienste. Der Bild-Textencoder arbeitet auf der RTX 3060, Bildmodell und VAE auf der RTX 5080. CPU/System-RAM bleiben für Laden und Offload beteiligt. Beide GPUs müssen frei sein; es gibt keinen stillen CPU-Fallback. GPU-Last kann während Vorbereitung und Laden null sein. Nach Abschluss beendet Deck den eigenen Worker und gibt dessen VRAM frei.

Unter Entdecken steht zusätzlich Neu hinzugefügt zur Verfügung. Die Abfrage sortiert bereits auf Hugging Face nach dem Erstellungsdatum des Repositories absteigend; sie sortiert nicht nur die beliebtesten 20 Treffer um. Name A–Z sortiert weiterhin die angezeigte Treffermenge.

Prüfung vorhandener Studios: Native Anwendungen und Docker.

Optionale Docker-Anwendungen

Einstellungen → Laufzeiten → Docker zeigt Verbindung, Version und gegebenenfalls Docker-Erstinstallation. Weitere Dienste zeigt ausschließlich Container mit io.athena-deck.managed=true und io.athena-deck.role=application. Bestehende Container werden nicht automatisch übernommen. Details zu Systemhelfer, Installer und Grenzen: Docker-Dienste.

Unter Entdecken blendet Nur Basismodelle anhand von base_model, base_model_relation und Hub-Tags gekennzeichnete Ableitungen aus (Finetunes, Adapter/LoRAs, Merges und separate Quantisierungen). Es werden bis zu 100 nach der gewählten Sortierung gelieferte Kandidaten geprüft und maximal 20 angezeigt. Die Einstellung bleibt im Browser über Kategorien hinweg erhalten. Fehlende Herausgeber-Metadaten können dazu führen, dass Ableitungen sichtbar bleiben; es handelt sich nicht um eine verifizierte Liste offizieller Herausgeber. API-Parameter: GET /api/v1/catalog/search?...&base_only=true.

Die Suche akzeptiert auch owner/repository und direkte Hugging-Face-Repository- URLs. Eine solche Direktauswahl umgeht Kategorie- und Basismodellfilter mit einem sichtbaren Hinweis. Bei GGUF-Dateinamen wird die Endung für die Repositorysuche entfernt. Findet die Chat-Suche nichts, werden zusätzlich als conversational gekennzeichnete GGUF-Repositories ohne text-generation-Tag geprüft. Das ist keine globale Suche nach beliebigen Dateinamen im Hub.

Hugging-Face-Zugang

Unter Einstellungen → Zugang → Hugging Face einen eigenen hf_…-Token mit Leserechten speichern, ersetzen oder entfernen. Bei freigabepflichtigen Modellen vorher auf der Modellkarte mit demselben HF-Konto Zugang beantragen. Deck akzeptiert keine Lizenzbedingungen automatisch. Siehe HF-Zugangsrechte und Token.

Der Token wird ausschließlich serverseitig unter models/huggingface.json im Deck-Zustandsverzeichnis gespeichert (0600, unverschlüsselt); Zustandsbackups entsprechend schützen. Er gilt für Katalogabfragen, Modell- und Komponentendownloads aller Kategorien. HTTP-Weiterleitungen auf andere Hosts erhalten keinen Authorization-Header. Entfernen verhindert neue authentifizierte Anfragen, beendet aber keinen bereits autorisierten Download. Download abbrechen bei Bedarf separat nutzen.

Interne API (nur angemeldete Administratorsitzung): GET /api/v1/huggingface liefert ausschließlich {configured: boolean}; POST mit {token: "hf_…"} speichert/ersetzt, mit {token: null} entfernt. POST benötigt X-Athena-Deck: 1. Kein API-Endpunkt liefert den gespeicherten Token zurück. HTTP 401/403 von HF ergeben Hinweise auf Token, Leserechte und Modellfreigabe; die tatsächliche Freigabe wird beim Download geprüft.

Video: vorhandene ComfyUI-Laufzeit wiederverwenden

Video nutzt dieselbe ComfyUI-Installation wie Bildgenerierung. Es wird keine zweite Python-/CUDA-/ComfyUI-Umgebung installiert. Der gepflegte Ausführungsweg ist derzeit LTX 2.5 Distilled BF16 aus Lightricks/LTX-2.5; unbekannte Varianten erhalten keine automatische Freigabe.

Unter Video → Laufzeit / Aktives Modell prüft Deck die Bibliothek: Transformer, Textencoder, Video-VAE, Audio-VAE und Spatial-Upsampler müssen vollständig sein und aus derselben Quellversion stammen. Vorhandene Dateien werden automatisch zugeordnet. Komponenten prüfen / nachladen bietet fehlende Dateien an; sie landen in derselben Download-Warteschlange. Bei erfüllten Voraussetzungen erscheint Laufzeit bereit · lädt bei Anfrage. Das bedeutet verfügbare Dateien und Anbindung, keine Garantie gegen OOM oder einen erfolgreich geprüften Render.

Als Videomodell aktivieren wählt Gewichte ohne Generierungsparameter. Übersicht → Video beendet Decks andere GPU-Aufträge und startet einen eigenen ComfyUI-Prozess aus der gemeinsamen Installation. Die Gewichte werden erst bei einem ComfyUI-Workflow geladen. LLM beendet den kompletten Videoprozess und gibt dessen GPU-Speicher frei. Auch ein Deck-Neustart beendet den Deck-eigenen Prozess. Fremde Videodienste werden nur lesend geprüft und niemals von dieser Steuerung gestartet oder gestoppt.

CUDA0 ist die RTX 5080 (Diffusion und VAE); CUDA1 die RTX 3060. Der mitgelieferte Node Deck · LTX Textencoder auf RTX 3060 weist den Encoder ausdrücklich CUDA1 zu. Frei gestaltete Workflows mit anderen Loader-Nodes können davon abweichen. Große BF16-Gewichte nutzen zusätzlich CPU-Auslagerung; Transformer und Encoder passen nicht vollständig in 16 beziehungsweise 12 GiB VRAM. ComfyUI nutzt Low-VRAM-Modus mit 1,5 GiB GPU-Reserve. Auf Athena sind etwa 47 GiB System-RAM vorhanden, der Deck-Testcontainer ist auf 32 GiB begrenzt: Ein echter Render muss hinsichtlich RAM und VRAM separat geprüft werden.

Im Videomodus stellt der gemeinsame API-Port die native ComfyUI-API und Browseroberfläche einschließlich WebSocket bereit, ohne Parameterübersetzung. Im LLM-Modus bleibt er OpenAI-kompatibel. Während eines Wechsels gilt HTTP 503. API-Clients verwenden den Deck-Bearer-Token. Die Browseroberfläche verwendet die vorhandene Deck-Anmeldung; Cross-Origin-Zugriff ist gesperrt. Der Link ComfyUI öffnen erscheint in der Übersicht bei laufendem Videomodus. Die bestehende LTX DeskWEB-Oberfläche erwartet die Desktop-Backend-API und ist mit diesem ComfyUI-Port nicht direkt kompatibel.

Für Zugriff auf den API-/ComfyUI-Port 8120 vom Entwicklungsrechner:

ssh -N -i /Users/mike_i386/.ssh/athena_key -o BatchMode=yes -o ExitOnForwardFailure=yes -L 8120:127.0.0.1:8120 root@192.168.1.212

Danach http://127.0.0.1:8120/ im Videomodus öffnen; zunächst unter http://127.0.0.1:8108/ anmelden. Auflösung, FPS, Dauer und Prompts werden im ComfyUI-Workflow eingestellt. Es gibt aktuell keinen automatisch vorbereiteten Video-Workflow und keinen integrierten Deck-Render-Test. Die native ComfyUI-Oberfläche bietet ihre Workflow-Templates; für die Gerätezuordnung den Deck-Textencoder-Node verwenden.

Interne Verwaltungs-API: GET /api/v1/video meldet Modelle, Komponenten, Blocker, Laufzeit und Prozessstatus; POST /api/v1/video/service mit {id: "<Bibliotheks-ID>"} wählt das Modell, mit {id: ""} hebt die Auswahl auf; POST /api/v1/video/mode mit {mode: "video"} oder {mode: "llm"} wechselt den GPU-Modus. Änderungen benötigen eine angemeldete Deck-Sitzung und X-Athena-Deck: 1. Gewichte der aktiven Auswahl bleiben gegen Bibliothekslöschung geschützt.

Für reine App-Updates kann der Debian-Installer mit --update --reuse-runtime die installierten Laufzeiten aus dem bisherigen Deck-Image übernehmen. Diese Option ist für App-Änderungen gedacht; gewünschte Runtime-Updates werden weiterhin ausdrücklich gebaut. Regenerierbare Video-Laufzeiten und ComfyUI-Arbeitsdaten werden bei App-Updates nicht mehr in jedes Zustandsbackup kopiert.

Optionales SwarmUI mit vorhandener ComfyUI-Laufzeit: Installation und Betrieb.

Backup und Wiederherstellung unter Einstellungen → Backup & Restore: Umfang, Bedienung, API und Grenzen.

LadyPoly YuE2

Die optionale LadyPoly-WebUI läuft als markierter Anwendungscontainer unter Weitere Dienste und nutzt Decks Musikworker statt einer eigenen GPU-Laufzeit. Installation, Verbindung und Einschränkungen: LadyPoly.

Sprachmodell-GPUs und Vision-Projektor werden unabhängig zugeordnet. Der Modell-Split verteilt ausschließlich LLM-Gewichte; eine zusätzliche Projektor-GPU wird nur für mmproj sichtbar gemacht, nicht für Modell-Offload. Die Speicherprüfung berücksichtigt beide Geräte einschließlich Projektorbedarf.

Referenzbilder: Alle derzeit ausführbaren Bildrezepte (Qwen Image 2.1 und FLUX.2 Klein 9B) erlauben bis zu vier Bilder pro Bearbeitungsauftrag. FLUX nutzt VAEEncode und verkettete ReferenceLatent-Nodes für beide Conditioning-Zweige nach dem offiziellen ComfyUI-Workflow: https://github.com/Comfy-Org/workflow_templates/blob/main/templates/image_flux2_klein_image_edit_9b_distilled.json . Neue Modellfamilien benötigen einen passenden Workflow; hochgeladene Referenzen werden niemals stillschweigend verworfen.

Bildadapter werden zentral in profiles.IMAGE_ADAPTERS definiert: Modellfamilie, unterstütztes Gewichtsformat, Komponenten, Laufzeit, Workflow, Referenzbildlimit und Speicherpolitik. Bibliothek, Profile und Bildworker verwenden denselben Resolver image_adapter. Bekannte Quellen bleiben kompatibel; neue Varianten können über gespeicherte präzise Architektur-Metadaten oder die Hugging-Face-Basismodell-Zuordnung dieselbe Anbindung wiederverwenden. Ein Name mit „Qwen“ oder „Flux“ genügt nicht. Allgemeine FLUX-Architekturangaben unterscheiden Klein 9B nicht sicher von anderen FLUX-Varianten und schalten daher keinen Worker frei. Metadaten sind eine Zuordnungshilfe, keine Garantie für den Inhalt oder die Qualität veränderter Gewichte. Neue Architekturen und Dateiformate benötigen einen registrierten Adapter. Bereits heruntergeladene Varianten ohne ausreichende Metadaten bleiben ungeprüft; bestehende bekannte Profile bleiben erhalten.

Audio-Trennung

Eigener Werkzeugbereich #separation mit BS-Roformer, MelBand und Demucs FT/6s. Die alte Web-GUI läuft optional als CPU-only Container unter Weitere Dienste und nutzt den nativen Deck-Worker. Installation und Grenzen. Modellquellen, alle Ensemble-Dateien und SHA-256 sind in separator_sources.json festgelegt. Paket-Downloads und Backup-Restore verwenden diese geprüften Rezepte; Nutzmedien werden nicht exportiert. Bei lokalen Bibliotheksdateien wird eine belegte Originalquelle separat vom Übernahmeort angezeigt, ohne IDs oder Profilreferenzen zu ändern. Unbekannte lokale Quellen werden nicht geraten.

README.md Unescape Escape

Athena Deck · Router 0.7

Navigation und Detailansichten