Add owned OpenAI endpoint and coordinated native model switching

README.md

@@ -1,4 +1,4 @@
-# Athena Deck · Prototyp 0.4
+# Athena Deck · Router 0.7
 
 Eigenständige neue Oberfläche, Python-Standardbibliothek und HTML/CSS/JavaScript.
 Keine Installation von Python-Paketen oder Frontend-Builds nötig. Python >= 3.10.
@@ -17,7 +17,7 @@ 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. Andere Modellstarts sind noch nicht angebunden. Details: [Modellverwaltung](STUDIO.md).
+Bildprofile mit vollständigem Qwen-Image-2.1-GGUF-Rezept lassen sich unter „Testen“ ausführen. Textprofile sind am eigenen [OpenAI-kompatiblen Endpunkt](ENDPOINT.md) ausführbar. Audio und Video sind noch nicht angebunden. Details: [Modellverwaltung](STUDIO.md).
 
 ## Zugang und API-Token
 
@@ -33,38 +33,21 @@ angebunden; der Zugriff erfolgt über SSH-Tunnel. Der bestehende Gateway bleibt
 ## Zielsystem und Entwicklung
 
 Athena Deck läuft vollständig auf einem Debian-Server mit RTX 5080 und RTX 3060.
-Oberfläche, API, Demo-Prozess und Hardware-Erfassung laufen dort. Der Arbeitsplatz
+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. Modelllaufzeiten sind noch nicht angebunden.
+Integrationstests werden auf Athena ausgeführt. Chat- und Qwen-Image-Laufzeiten sind am eigenen Endpunkt angebunden.
 
 Die isolierte Entwicklungsinstallation ist in [DEVELOPMENT.md](DEVELOPMENT.md)
 beschrieben. Hardware wird direkt über `/proc`, hwmon und nvidia-smi gelesen;
-Deck benötigt dafür keinen SSH-Schlüssel. Der Demo-Prozess lädt kein Modell.
+Deck benötigt dafür keinen SSH-Schlüssel. Der eigene Router ist in [ENDPOINT.md](ENDPOINT.md) dokumentiert.
 
 ## Interne API v1
 
-Alle Antworten JSON. Zugangsdaten werden geschützt persistiert; Demo-Zustand ist flüchtig. GUI verwendet nur diese API.
-
-| Methode | Pfad | Ergebnis |
-|---|---|---|
-| GET | `/api/v1/status` | Name, Version, Laufzeit, Modus, Demo-Zustand |
-| GET | `/api/v1/hardware` | Verfügbarkeit, Messzeit, CPU, RAM, GPU-Liste, Fehler |
-| GET | `/api/v1/demo` | state, reachable, pid, port, location |
-| POST | `/api/v1/demo/start` | Idempotent starten und Health prüfen |
-| POST | `/api/v1/demo/stop` | Idempotent eigenen Kindprozess stoppen |
-
-Browser-POST benötigt Sitzung und `X-Athena-Deck: 1`; Browser-Origin muss zum Host passen.
-API-Clients verwenden für freigegebene Dienst-Endpunkte den separaten Bearer-Token.
-Host-Allowlist: localhost oder 127.0.0.1 mit tatsächlichem UI-Port.
-Keine CORS-Freigabe. 403 bei ungültigem Zugriff, 404 bei unbekannten Pfaden,
-503 bei fehlgeschlagener Demo-Bereitschaft. Keine frei übergebbaren Befehle,
-Prozess-IDs, Service-Namen oder Remote-Ziele.
-
-```sh
-curl -H 'Authorization: Bearer <API-TOKEN>' http://127.0.0.1:8108/api/v1/status
-curl -X POST -H 'Authorization: Bearer <API-TOKEN>' http://127.0.0.1:8108/api/v1/demo/start
-curl -X POST -H 'Authorization: Bearer <API-TOKEN>' http://127.0.0.1:8108/api/v1/demo/stop
-```
+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](ENDPOINT.md)**.
 
 Hardware: `available` bezeichnet Erfolg der Hardware-Abfrage, einzelne
 Messwerte können trotzdem fehlen (`null`). Ein Ausfall der Erfassung liefert available=false,
@@ -80,21 +63,16 @@ Keine Historie und kein Hintergrund-Collector bei geschlossener Hardware-Seite.
 
 ## Struktur und Grenzen
 
-- `server.py`: API, separater HardwareProvider, eigenständiger DemoService.
-- `demo.py`: Health-only HTTP-Kindprozess auf dem Debian-Server, ohne Modellabhängigkeiten.
-- `collect_hardware.py`: fest begrenzte lesende Linux-Hardware-Abfragen.
-- `index.html`, `app.js`, `style.css`: neue responsive Oberfläche.
-- `test_server.py`: Prozess-Lebenszyklus, Kontrollgrenzen, Hardware-Ausfall.
+- `server.py`: Verwaltungs-API und lesende Hardware-Abfragen.
+- `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/Chat, Bildgenerierung, Audio und Video besitzen jetzt eine
-gemeinsame Modellverwaltung; Weitere Dienste bleibt Platzhalter. Downloads und Profile sind aktiv, Chats und Modellwechsel noch nicht.
-Spätere Modellprofile und native llama.cpp-Worker sollten eigene Service-Adapter
-mit derselben Status-/Start-/Stopp-Trennung erhalten. Noch kein Worker-Registry,
-Scheduler oder produktionsreifer Worker-Supervisor. Die optionale Server-Instanz
-hat eine eigene Passwortanmeldung; ihre Netzwerkgrenzen stehen in der Modul-Dokumentation.
-SIGKILL/Absturz-Cleanup ist nicht implementiert; regulär Ctrl+C/SIGTERM verwenden.
-Der Hardware-Collector ändert keine Host-Konfiguration. Die optionale
-Netzwerkmodul-Installation erzeugt einen eigenen Docker-Container samt Portbindungen.
+Sprachmodelle und Qwen-Image-Profile sind ausführbar. 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