2.2 KiB
Laufzeiten erkennen und vorbereiten
In Bibliothek → Modell und bei der Einrichtung von Profilen zeigt Deck die erkannte Modellfamilie, den Ausführungsstatus und Mögliche Laufzeiten. Das gilt für Sprache/Chat, Bild, TTS, STT, Musik, Stimme und Video.
Eine vorhandene Laufzeit wird wiederverwendet. Ein fehlender Worker oder Workflow bleibt ausdrücklich sichtbar. Unbekannte Familien erhalten nur gekennzeichnete Recherchehinweise aus ihrer Kategorie; das ist keine Kompatibilitätszusage. Es wird nichts automatisch installiert.
Über den Link „Laufzeit herunterladen / bereitmachen“ gelangt man zur jeweiligen Laufzeitseite. Dort wird die Installation bewusst gestartet. Ohne gepflegten Installer zeigt Deck dies an, statt eine Installation vorzutäuschen.
YuE2 GGUF / audio.cpp
audio-cpp/Yue2-3B-GGUF, Hauptdateien yue2-3b-*.gguf, werden als YuE2 erkannt. Die VAE-Dateien sind Komponenten, keine eigenständigen Modelle. Das Paket braucht zusätzlich VAE, Modell-/Generierungskonfiguration, VAE-Konfiguration und Qwen-Tokenizer; .tiktoken ist herunterladbar.
Einstellungen → Laufzeiten → audio.cpp bietet einen isolierten CUDA-Build aus 0xShug0/audio.cpp, Version v0.8.1, Commit f2b4937306daa25f5c78520f3c626ed31495a37a. Voraussetzung: Debian/Linux, Git, CMake, g++, nvcc, nvidia-smi und mindestens 6 GiB frei. GPU-Architekturen werden gelesen; gebaut wird mit sechs Jobs. Keine Host-Pakete, Treiber oder bestehenden Laufzeiten werden verändert. Fehlende Voraussetzungen werden gemeldet.
Installation liegt im Deck-Zustandsverzeichnis unter audio-cpp-runtime. Status, Abbruch und eigene Build-Ausgabe sind in der GUI verfügbar. Der CLI-Start wird ohne Modell geprüft. Dieser Build lädt keine Gewichte. Der ausführbare Deck-Musikworker und die Ladypoly-WebUI-Anbindung fehlen noch; sie sind separat umzusetzen. Auch andere audio.cpp-Familien brauchen geprüfte modellspezifische Anbindungen.
Interne Admin-API: GET /api/v1/audio-cpp-runtime, GET /api/v1/audio-cpp-runtime/log, POST /api/v1/audio-cpp-runtime/install und /cancel (JSON {}, vorhandene Sitzung und CSRF-Header). Backup/Restore enthält das gepinnte Laufzeitrezept und baut es bei Bedarf neu; keine Binärdateien im Backup.