62 lines
3.2 KiB
Markdown
62 lines
3.2 KiB
Markdown
# Dashboard und übernommene Historie
|
|
|
|
**Dashboard** steht an erster Stelle der Deck-Navigation. Die frühere
|
|
Hardware-Seite entfällt. Die Übersicht für Endpunkt und GPU-Modus bleibt als
|
|
separater Bereich erhalten; die alten Router-, Bild- und Modus-Umschalter
|
|
werden im Dashboard nicht eingeblendet.
|
|
|
|
Die Karten und Ansichten ab „Aktives Profil“ übernehmen die Struktur des alten
|
|
Athena-Dashboards: CPU, RAM, beide GPUs mit VRAM/Temperatur/Takt/Leistung,
|
|
Inferenzraten, Prompt-Cache, Anfragen, Slots, Kontextfenster, MTP,
|
|
Tokenzähler, GPU- und Slot-Verlauf, Nutzung nach Profil, Modellwechsel,
|
|
Profile, Dienste, Host/Netzwerk, GPU-Prozesse, llama.cpp-Parameter,
|
|
GGUF-Dateien und verschlüsselte portable Backups. Die Farbwerte sind an Deck
|
|
angepasst. Nicht verfügbare Laufzeitwerte erscheinen als „–“; sie werden nicht
|
|
aus historischen Werten geschätzt. Profil und Modell beziehen sich auf Decks
|
|
eigenen Worker, nicht auf den alten Router.
|
|
|
|
## Datenquellen
|
|
|
|
- CPU, RAM, Host-Uptime und Netzwerk: Host-`/proc`, im Docker-Testbetrieb
|
|
ausschließlich lesend nach `/host/proc` eingebunden. Für das Host-Netzwerk
|
|
wird `/host/proc/1/net/dev` verwendet; `/host/proc/net/dev` würde die
|
|
Container-Namespace messen.
|
|
- GPU, VRAM, Temperatur, Leistung, Takt und Prozesse: `nvidia-smi`.
|
|
- Inferenz, Slots und Modellparameter: Decks eigener `llama-server`, dessen
|
|
lesende `/metrics`, `/slots` und `/props`-Routen; `--metrics` wird beim
|
|
Modellstart aktiviert. Deck liest daraus nur Zahlen und Slotzustände.
|
|
- Profile und GGUF-Dateien: Deck-Bibliothek plus, sofern vorhanden, das
|
|
lesend eingebundene alte `/data/models`.
|
|
- Backups: optionales, lesend eingebundenes `/data/emergency-backups`.
|
|
Downloads laufen nur über die angemeldete Deck-Oberfläche.
|
|
|
|
Das Dashboard verwendet die internen, sitzungsgeschützten GET-Routen
|
|
`/api/v1/dashboard`, `/api/v1/dashboard/history?range=24h` und
|
|
`/api/v1/dashboard/backups`. Mögliche Zeiträume sind 1 Stunde, 24 Stunden,
|
|
7 Tage, 21 Tage und Gesamt. Die Live-Ansicht aktualisiert jede Sekunde,
|
|
die History alle 15 Sekunden. Die Aufzeichnung schreibt alle 15 Sekunden;
|
|
Detailwerte bleiben 21 Tage, ältere GPU- und Slotwerte werden auf
|
|
Stundenwerte verdichtet. Prompts, Antworten, Medien und Anwendungslogs
|
|
werden nicht in die History geschrieben.
|
|
|
|
## Bestehende History einmalig übernehmen
|
|
|
|
Vor dem ersten Start einer Deck-Version mit Dashboard die alte SQLite-Datei
|
|
mit der mitgelieferten Importfunktion kopieren:
|
|
|
|
```sh
|
|
python3 deploy/import_dashboard_history.py \
|
|
/data/llama-dashboard/history.sqlite3 \
|
|
/opt/athena-deck-dev/runtime/state/dashboard-history.sqlite3
|
|
```
|
|
|
|
Der Import nutzt SQLite-Backup und schließt die laufende WAL-Datei ein.
|
|
Die Quelle bleibt unverändert; ein vorhandenes Deck-Ziel wird nicht
|
|
überschrieben. Im installierten Deck liegt die neue Datenbank allgemein
|
|
unter `<Installationsverzeichnis>/state/dashboard-history.sqlite3`.
|
|
Auf einem frisch installierten Debian-Server ohne alte Datenbank beginnt
|
|
Deck automatisch eine neue History. Historische Tokenzahlen und Modellwechsel
|
|
aus dem alten Router bleiben nach dem Import erhalten; neue Messungen werden
|
|
als Deck-Messungen fortgeführt. Das alte Dashboard muss dafür nicht gestoppt
|
|
werden.
|