# Stand Laufzeitverwaltung

llama.cpp-Prüfung, Releases, Builds, Abbruch und Standard-/Rückfallauswahl sind
jetzt live. Kein manuelles VRAM-Reservefeld mehr. Modellbezogene Prognosen verwenden die lesend eingebundenen alten Routermodelle
und llama-fit-params; ein Modellstart erfolgt nicht. Die folgenden
0.4/0.5-Beschreibungen der Laufzeitansicht sind historisch.

# Stand 0.5

Katalog und Datei-Downloads sind jetzt live. Die folgende Beschreibung der
Katalogbeispiele ist historisch (0.4). Aktuelle API und Grenzen: DEVELOPMENT.md.
Profile und Laufzeitsteuerung bleiben Entwürfe.

# Modellverwaltung und llama.cpp · GUI-Prototyp 0.4

Diese Erweiterung ist ausdrücklich rein optisch und lokal bedienbar. Keine
Modelldateien, Laufzeiten, Downloads, Builds oder produktiven Dienste werden verändert.

## Ansichten

- Sprachmodelle/Chat, Bild, Audio und Video: Entdecken, Bibliothek, Profile, Laufend.
- Katalog: Suche/Quellenfilter über gekennzeichnete Beispiele, Detailansicht mit
  getrennter Prüfung von Unterstützung, grundsätzlicher Eignung und aktueller
  Startmöglichkeit. Keine Online-Suche und keine berechneten Speicherwerte.
- Bibliothek: Beispiel einer einmaligen Modelldatei mit mehreren Profilen;
  ausdrücklich keine bestätigte Installation.
- LLM-Profile: drei vorbelegte Beispiele, Anlegen, Bearbeiten, Duplizieren und
  Entfernen lokaler Entwürfe. Name, Modellvariante, Kontextbudget, Slots,
  GPU-Zuordnung, KV-Cache, gemeinsamer Pool, GPU-Gewichtung, Batch/Microbatch,
  CPU-Threads, Flash Attention und vorgesehener Vision-Projektor.
- Einzigartige API-Profilnamen, gültige Zahlenbereiche, Microbatch <= Batch und
  nicht ausschließlich nullwertige GPU-Gewichtung werden im Formular geprüft.
- API-Vorschau zeigt die vorgesehenen Profilnamen. `/v1/models` wird dadurch
  **nicht** als funktionsfähiger Endpunkt implementiert.
- Laufend: leerer Zustand sowie geplanter Ablauf des Profilwechsels, ohne
  simulierte laufende Modelle oder Warteschlangen.
- Bild/Audio/Video-Profile: vorbereitete, deaktivierte aufgabenspezifische Felder.

## Einstellungen → llama.cpp & Updates

Build-Entwurf mit Backend (CUDA/CPU/Vulkan), gewünschtem Release oder Commit,
automatischer bzw. expliziter GPU-Architekturauswahl, Toolkit-Prüfung, parallelen
Build-Jobs und vorgesehener VRAM-Reserve. Für Athena sind RTX 5080 und RTX 3060 als
bekanntes Zielsystem benannt; eine Live-Build-Kompatibilitätsprüfung erfolgt nicht.

Die Update-Ansicht lässt sich aufklappen. Sie zeigt Platz für aktuellen Build,
verfügbares Release, echte Release-Notes mit Quelle und Datum sowie Neubau und
spätere Wiederherstellung. Alle zustandsändernden Laufzeit-Aktionen und die
Live-Update-Suche sind deaktiviert. Keine erfundenen Versionsnummern oder Fixes.
Ein Link führt zu den offiziellen llama.cpp-Releases.

## Speicherung und spätere Anbindung

Entwürfe liegen ausschließlich im localStorage dieses Browsers und Origins unter
`athena-deck-studio-v1`. Sie bleiben nach Neuladen erhalten, enthalten keine
Zugangsdaten und werden nicht zum Server übertragen. Andere Browser oder die
Server-Instanz teilen diesen Stand nicht. Bei gesperrtem Browser-Speicher weist die
Oberfläche darauf hin, dass der Entwurf nur im aktuellen Speicher bleibt.

Die neuen Ansichten in `studio.js` rufen keine API auf. Vorhandene Anmeldung,
Hardwareanzeige, Demo-Service und Netzwerkverwaltung behalten ihre bisherigen
Funktionen. `server.py` liefert zusätzlich nur die neue JavaScript-Datei aus.

Vor echter Nutzung erforderlich: Modellkatalog-Adapter, Metadaten-/GGUF-Auswertung,
Downloadverwaltung, persistente Profil-API, GPU-/KV-Planung, Build-Manager und
Prozess-Supervisor mit Warteschlange. Gespeicherte Entwürfe dürfen nicht ungeprüft
als Shell-Befehle interpretiert werden. Die genaue Kontext-/Slot-Semantik muss an
die eingesetzte llama.cpp-Version gekoppelt und überprüft werden.

## Prüfung

JavaScript-Syntax geprüft. In einer isolierten statischen Browservorschau:
Profil bearbeitet (Kontext geändert), gespeichert und nach Reload wiedergefunden;
Build-Einstellungen und Update-Ansicht geöffnet, deaktivierte Aktionsknöpfe sowie
Layout kontrolliert. Die Testvorschau verwendet einen eigenen Origin, sodass keine
Entwürfe der eigentlichen Anwendung überschrieben wurden. Keine SSH-/Modell- oder
Build-Aktion für diese GUI-Erweiterung ausgeführt.

## Modellgalerie und Download-Ablauf (2026-09-28)

Die Live-Galerie verwendet eine eigene Deck-Oberfläche, inspiriert von LocalAIs
[Modellgalerie](https://github.com/mudler/LocalAI/blob/master/core/http/react-ui/src/pages/Models.jsx)
und [Download-Anzeige](https://github.com/mudler/LocalAI/blob/master/core/http/react-ui/src/components/OperationCard.jsx).
Es wurde kein LocalAI-Frontendcode übernommen.

- Beim Öffnen erscheinen beliebte Hugging-Face-Repositories des Bereichs.
- Suche liefert bis zu 20 Treffer; Sortierung nach Downloads oder Namen.
- Ergebnis auswählen: Modelldetails, Lizenzlink und feste Quellrevision.
- Dateien nach Name/Quantisierungsbezeichnung und Format filtern; genau eine Datei auswählen.
- Download explizit starten. Zugangsbeschränkte Repositories, bereits vorhandene
  Dateien, laufende Downloads und unzureichender Speicher sperren den Button.
- Fortschritt, Bytes, Abbruch und Fehler werden aus der vorhandenen API angezeigt.
- Bibliothek zeigt abgeschlossene Dateien einschließlich Version und Integritätsprüfung.

Grenzen: weiterhin Einzeldateien, keine vollständige Pipeline-Installation,
keine Warteschlange, kein Resume, keine automatischen Modellstarts. Audio-Suche
ist derzeit auf Text-to-Speech begrenzt. Hardware-/Kontext-Eignung wird in dieser
Galerie noch nicht berechnet; Dateigröße wird ausdrücklich nicht als VRAM-Bedarf
angezeigt. Der separate llama.cpp-Einpassungstest bleibt unter Einstellungen.

Validierung: 46 bestehende Python-Tests bestanden; JavaScript-Syntax geprüft;
Browserprüfung mit echten Hugging-Face-Such- und Dateidaten, Dateifilter,
Auswahl und Speicherreserve-Sperre. Keine Modellgewichte für den UI-Test geladen.