Athena-Deck/STUDIO.md

Modellverwaltung in Athena Deck

Serverprofile, Downloads und Größen (2026-09-28)

Profile sind jetzt echte, serverseitig persistierte Konfigurationen in state/profiles.json. Die Bibliothek bietet „Profil anlegen“ für heruntergeladene Gewichtsdateien. Alle vier Bereiche unterstützen Anlegen, Bearbeiten und Duplizieren. Namen sind global eindeutig; Änderungen werden anhand einer Revisionsnummer gegen versehentliches Überschreiben geprüft. Frühere lokale Browserentwürfe werden weder gelöscht noch automatisch als echte Profile importiert.

Bildprofile speichern Auflösung, Schritte, Seed und Guidance. Chatprofile speichern Kontextbudget, Slots, Threads, Batch und Microbatch; Audio derzeit Sprechgeschwindigkeit, Video Auflösung, Frames, FPS, Schritte und Seed. Ein Profil startet noch keinen Worker. Fehlende Laufzeiten und bei Qwen-Image-2.1 Textencoder/VAE werden angezeigt. Auf Wunsch des Betreibers werden in diesem Schritt keine Bildlaufzeiten oder Zusatzmodelle installiert.

Der Reiter Downloads zeigt die persistierte Downloadhistorie (models/downloads.json). „Aus Liste entfernen“ blendet ausschließlich einen beendeten Eintrag aus, auch über Neustarts hinweg. Es löscht keine Modelldatei und keinen Bibliothekseintrag. Bestehende Bibliotheksdateien werden einmalig als abgeschlossene Downloads übernommen. Unterbrochene Downloads bleiben erkennbar; noch kein Fortsetzen/Resume. Abgeschlossene Downloads belegen nicht mehr dauerhaft die Entdecken-Ansicht.

Entdecken lädt Dateigrößen mit zwei parallelen Metadatenanfragen nach. Angaben stammen aus Hugging Face und werden fünf Minuten gecacht (maximal 64 Repositories). Die Übersicht bevorzugt GGUF-Hauptgewichte, schließt erkennbare Encoder/VAE/LoRA- Dateien aus und summiert vollständig vorhandene Shards einer Variante. Die angegebene Spanne enthält keine zusätzlichen Pipeline-Komponenten.

Die Speicherprüfung ist bewusst eine Untergrenze für Gewichte, keine vollständige Lauffähigkeitsprognose: Dateigröße gegen jede GPU einzeln, insgesamt und aktuell frei, mit 5 Prozent / mindestens 512 MiB Reserve. GPUs werden nicht pauschal addiert. Die Dateiauswahl zeigt GPU-Werte, Messzeit und ein vorhandenes Deck-RAM-Limit. KV-Cache, Kontext, Aktivierungen, Encoder/VAE und backendabhängige Formate bleiben als unbekannter Zusatzbedarf gekennzeichnet. Ein positives Gewichts-Ergebnis bedeutet nicht „Modell kann gestartet werden“.

API (Administrator-Sitzung erforderlich, bestehender CSRF-Schutz):

• GET /api/v1/catalog/assessment?repo=owner/name: Größenbereich und Gewichtsprüfung.
• GET /api/v1/catalog/files?repo=owner/name: zusätzlich Prüfung pro Datei.
• GET /api/v1/catalog: Bibliotheks-IDs und downloads neben aktivem job.
• POST /api/v1/catalog/dismiss mit { "id": "download-id" }: beendeten Eintrag ausblenden.
• GET /api/v1/profiles: Profile, Blocker und Parameterschemata.
• POST /api/v1/profiles/save: id (bei Neuanlage null), revision (anfangs 0), name, kind, model_id und parameters. Die Modelldatei muss tatsächlich vollständig in der Bibliothek liegen. Keine beliebigen Pfade/Startbefehle.

Die eigenständig implementierte Galerie orientiert sich an LocalAIs Explore-/Detailansicht. Kein LocalAI-Frontendcode wurde übernommen. llama.cpp-Buildverwaltung und Einpassung der alten Referenzprofile sind unter Einstellungen verfügbar; Details in DEVELOPMENT.md.

Validiert: 54 Python-Tests; JavaScript-Syntaxprüfung; isolierter Browsertest mit echten Katalogdaten und einer temporären Testdatei für Profilanlage, Komponentenhinweise und Download-Ausblenden. Keine produktiven Modellstarts.

Laufzeiten und Zusatzkomponenten

Einstellungen → Laufzeiten bündelt #runtime (llama.cpp, bestehende aktive Buildverwaltung) und #image-runtime (Bildgenerierung). Die Bildseite beschreibt ComfyUI + ComfyUI-GGUF als vorgesehene Umgebung und zeigt ausdrücklich, dass noch kein Deck-Bildworker installiert ist. Dieser Schritt installiert keine Laufzeit.

Bildgenerierung → Profile → Komponenten bietet für abenzerps/Qwen-Image-2.1-Uncensored-GGUF ein explizites Rezept gemäß Modellkarte: Textencoder INT8 ConvRot oder BF16, dazu Qwen-Image-2.1-VAE BF16. Größen und feste Quellrevision werden beim Öffnen aus dem öffentlichen Repository gelesen. Downloads laufen über die vorhandene geprüfte Katalog-API und erscheinen unter Downloads. Danach „Bibliothek aktualisieren“, je eine Datei auswählen und „Zuordnung auf Athena speichern“. Mehrere Profile können dieselben Dateien nutzen.

Die Zuordnung ist kein Nachweis eines funktionierenden Workers. Andere Modelle bekommen ohne hinterlegtes Rezept keine behauptete automatische Kompatibilität. Textencoder/VAE werden nicht als Hauptmodell des Qwen-Profils zugelassen. Zuordnungen bleiben bei Parameteränderungen erhalten; bei Wechsel des Hauptmodells werden sie zurückgesetzt. Fehlende Dateien bleiben als Blocker sichtbar.

API (nur Administrator-Sitzung):

• GET /api/v1/profiles/components?model_id=<Bibliotheks-ID> liefert Rezept, verfügbare Dateien und Quellkandidaten.
• POST /api/v1/profiles/components mit id, revision, components (text_encoder und/oder vae: Bibliotheks-ID, leer zum Entfernen) speichert atomar mit Konfliktprüfung. Rollen und tatsächliche Dateien werden geprüft.

Validiert: 55 Tests und Browserprüfung der neuen Navigation und realen Komponentenmetadaten. Keine Zusatzgewichte heruntergeladen, keine Modelle gestartet.

Bibliotheksrollen

Bibliothek, Profilauswahl und Profil-API verwenden dieselbe serverseitige Dateiklassifikation (role, role_label, profile_eligible). Erkannte Textencoder, VAE, Projektoren und Adapter bleiben als Zusatzdateien sichtbar, bieten aber kein „Profil anlegen“ und können nicht als Hauptmodell gespeichert werden. Bestehende Komponenten-Zuordnungen und Dateien bleiben unverändert.

Bildgenerierung → Testen

Der Reiter Testen startet jetzt echte Qwen-Image-2.1-GGUF-Aufträge über einen eigenen ComfyUI-Prozess. Profil wählen, Prompt eingeben, Bild generieren; danach erscheinen Vorschau und PNG-Download. Auflösung, Schritte, CFG und Seed kommen aus dem Profil. Zunächst ein Bild pro Auftrag, maximal 1024 × 1024, keine Referenzbilder und keine öffentliche OpenAI-Bild-API. Der interne Admin-Endpunkt ist ausreichend für die GUI.

• GET /api/v1/image-tests: Status der eigenen Laufzeit und des letzten Tests.
• POST /api/v1/image-tests/start: {profile_id, prompt}; Prompt 1–4000 Zeichen.
• POST /api/v1/image-tests/cancel: {}; beendet ausschließlich den eigenen Worker.
• GET /api/v1/image-tests/image?id=<job-id>: letztes fertiges PNG, Sitzung erforderlich.

Serialisierte Aufträge, eigene Prozessgruppe, 30-Minuten-Generierungslimit, Abbruch und Entladen auch bei Fehlern. Der Textencoder läuft auf CPU; Diffusion und VAE nutzen eine einzelne GPU. Vor dem Start werden RAM und GPU-Speicher geprüft. Eine GPU mit vorhandenen Compute-Prozessen wird nicht verwendet; bei einem weiteren Compute-Prozess während des Tests bricht Deck seinen Auftrag ab. Das ist eine Schutzprüfung, keine exklusive Hardware-Reservierung gegenüber fremden Prozessen. Produktive Router/Modelle werden nicht gesteuert.

Die eigene ComfyUI-HTTP-Schnittstelle bindet nur Container-/Prozess-Loopback auf einem freien Port, ohne Host-Portfreigabe. Es werden keine Produktionspfade verwendet. ComfyUI-Ausgaben werden nicht als Logs gespeichert. PNG-Promptmetadaten sind deaktiviert; Jobstatus enthält keinen Prompt. Ergebnisse und temporäre Worker-Dateien liegen privat unter state/image-tests/; die GUI zeigt nur das letzte Ergebnis. Frühere Jobverzeichnisse bleiben bislang auf dem Datenträger.

Versionsgebundene Quellen: ComfyUI 8d534945ebd53cff61e8def81757c6a6c1b9cf2d, ComfyUI-GGUF 373048b8403a7820620065210a691263d4da0a61, PyTorch 2.11.0 CUDA 12.8. Python-Pakete sind in deploy/image-requirements.lock festgehalten. Eigenes Virtualenv /opt/deck-image-python, ComfyUI /opt/deck-comfy. Der Docker-Installer baut diese Umgebung mit ein; image_runtime: true im eigenen Installationsmanifest setzt dafür 32 GiB RAM-Limit und 256 PIDs. CPU-Limit bleibt zwei Kerne. Bestehende Installationen behalten ihre Ressourceneinstellung bis zur expliziten Aktivierung. Keine NVIDIA-Treiber-/Hostinstallation im Container-Update.

Validierung: 63 Tests; reale isolierte Generierungen 512 × 512 / 2 Schritte und 1024 × 1024 / 25 Schritte. Letztere dauerte ca. 99 Sekunden, PNG visuell geprüft, GPU danach wieder frei. Nutzerprofile unverändert. Die einfache Profil-/Prompt-/ Ergebnisanordnung orientiert sich an LocalAIs ImageGen-Seite, ohne deren Code zu kopieren.

Chatprofile: GPU- und Sampling-Einstellungen

Der Profileditor speichert Kontextbudget, Slots, Batch/Microbatch, Temperature, Top-p und Top-k sowie geordnete GPU-UUIDs, Split-Modus (none, layer, row) und relative Verteilungsgewichte. Zwei GPU-Auswahlen zeigen die echten Kartennamen; die Reihenfolge definiert die vorgesehenen logischen CUDA0/CUDA1-Geräte. UUIDs verhindern Verwechslungen mit wechselnden nvidia-smi-Indizes. CPU-Threads stehen unter „Erweitert“. Die Auswahl startet keinen Worker. Nach expliziter Freigabe am Endpunkt lädt der eigene Router das Profil bei einer Chat-Anfrage; siehe ENDPOINT.md. Die GPU-Verteilung ist keine Speicherzusage.

Medium aus der Referenztabelle: Kontext 160000 insgesamt für zwei Slots, RTX 5080 zuerst, RTX 3060 danach, Layer-Split 85,15, Batch 2048, Microbatch 256, Temperature 1.0, Top-p 0.95, Top-k 20. Fast: 76800, ein Slot, nur RTX 5080, keine Aufteilung, Batch 2048, Microbatch 64, Temperature 0.2, Top-p 0.8, Top-k 20.

API profiles/save: zusätzliche Chat-Parameter gpu_devices (geordnete UUID-Liste), split_mode, tensor_split (Zahlenliste), temperature, top_p, top_k. Leere Geräte-/Gewichtelisten bedeuten automatische Auswahl/Verteilung. Alte Profile bleiben lesbar; fehlende neue Felder erhalten bei Anzeige/Speichern Standardwerte (automatische Geräte, keine Aufteilung, Temperature 0.8, Top-p 0.95, Top-k 40). Bestehende Dateien werden beim Lesen nicht umgeschrieben.

Sprachmodelle besitzen jetzt den Reiter Testen: interner Textchat mit Streaming, Profilauswahl und Speicherdiagnose. Öffentliche Profilfreigabe ist dafür nicht erforderlich. Details: ENDPOINT.md.

MTP bei Sprachmodellprofilen

Im Profileditor kann MTP aktiviert werden, mit 1–8 Draft-Token und Mindestwahrscheinlichkeit 0–1. Medium-Referenz: 2 und 0,05; Draft-KV ist f16. Bestehende Profile bleiben standardmäßig ohne MTP. Das Modell muss eingebettete MTP-Gewichte enthalten. Der CUDA-Build benötigt den Deck-MTP-Fit-Adapter; neue GUI-Builds installieren ihn automatisch. Die Prognose zählt die gemeinsamen Gewichte einmal sowie Haupt- und MTP-Kontext und deren Compute-Puffer. Ein inkompatibles Modell oder ein alter Build wird nicht still ohne MTP gestartet. MTP garantiert keinen Geschwindigkeitsgewinn.

GPU-Ausführung: „Automatisch“ darf bei Platzmangel Schichten auf die CPU verlagern. „Vollständig auf GPU“ verlangt alle Schichten einschließlich Ausgabe und bricht sonst vor dem Laden ab. Die Prognose lässt je GPU mindestens 512 MiB bzw. 2,5 % Gesamtspeicher frei (der größere Wert gilt); keine Garantie für beliebige Last. Die Chat-Diagnose kennzeichnet eine begrenzte Layerzahl.

Auto-Test für heruntergeladene Sprachmodelle

Unter Sprachmodelle → Auto-Test ein GGUF und eine obere Kontextgrenze auswählen. Feste Gerätepriorität RTX 5080, dann RTX 3060; andere Hardware wird ausdrücklich abgelehnt. Kontextstufen: 2048, 4096, 8192, 16384, 32768, 65536, 131072, 160000, 192000, 262144 bis zur gewählten Grenze. Pro Kontext zuerst nur 5080, dann Layer-Splits 95:5, 90:10, 85:15, 75:25, 50:50. Nur wenn kein GPU-Kandidat besteht, wird automatische CPU-Auslagerung mit 85:15 getestet. Die erste erfolgreiche Gerätestufe hat Priorität; keine Behauptung eines globalen Geschwindigkeitsoptimums.

Microbatch 128, 64 und 256, Batch 2048, ein Slot; optional MTP2/p-min0,05. Erst Speicherprognose, dann echter Start, Aufwärmrunde und synthetischer, per Modelltokenizer auf 75 Prozent des Kontexts gefüllter Prompt mit bis zu 64 Ausgabetoken. Speicherung nur von Parametern, Prognose, Messwerten und Fehlerstatus; keine Antworten. Keine absichtliche Überschreitung der Speicherreserve. Höchstens 96 Kandidaten bzw. zwei Stunden zwischen Kandidaten; laufende Einzeloperationen haben eigene Zeitlimits. Ein kurzer erfolgreicher Lauf ist kein Vollkontext-/Parallelitäts-Stabilitätsnachweis.

Der gemeinsame Scheduler sperrt die Deck-Modelle während der Testreihe exklusiv. Bereits laufende Anfragen verhindern den Start; fremde GPU-Prozesse werden nicht beendet. Abbrechen schließt die eigene Anfrage, beendet nur die eigenen Testprozesse und gibt die Reservierung frei. Beim App-Neustart wird eine offene Reihe als unterbrochen markiert. Ergebnisse bleiben in auto-tests.json; ein neuer Test ersetzt diese Ergebnisliste. Erfolgreiche Kandidaten lassen sich explizit als neues Profil speichern, ohne Veröffentlichung am Endpunkt.

Admin-API: GET /api/v1/auto-tests; POST /start mit model_id, max_context, mtp; POST /cancel mit {}; POST /save mit job_id, index, name (jeweils unter /api/v1/auto-tests). Session und CSRF-Schutz wie Profilverwaltung; API-Bearer gewährt keinen Zugriff.

Layer-Feinsuche

Nach der ersten erfolgreichen Dual-GPU-Stufe erhöht Deck den geplanten Anteil der 5080 jeweils um eine Schicht bis vor die zuvor abgelehnte Verteilung. Die Anzahl wird aus GGUF block_count/nextn_predict_layers einschließlich Ausgabeschicht berechnet; Tensor-Split wird zwischen Rundungsgrenzen gesetzt. Jede Stufe prüft erneut Speicher und Microbatch128/64/256. Wenn alle drei scheitern, endet die Feinsuche. Erfolgreiche Ergebnisse bleiben einzeln speicherbar; mehr 5080-Layer bedeutet nicht zwingend mehr Geschwindigkeit. Die angezeigte Layerzahl ist eine aus Metadaten und llama.cpp-Layer-Split-Regel berechnete Zuordnung, keine Log-Auswertung. Fehlende/ungültige GGUF-Metadaten überspringen die Feinsuche mit sichtbarem Hinweis. Laufende Testreihen werden nicht nachträglich verändert.

Vision und Tool-Calling

Entdecken zeigt positive Hub-Tags als Hinweise, Projektordateien separat und ansonsten „Unbekannt“. Dies ist kein Kompatibilitätsnachweis; kein Rückschluss aus Modellnamen. Tool-Calling wird bereits an llama.cpp weitergereicht; Fähigkeiten hängen von Modell und Chat-Template ab.

Passende mmproj-GGUF über Entdecken herunterladen, anschließend im Chat-Profil auswählen. „Deaktiviert“ schaltet Vision aus. Projektorziel CPU oder eine ausgewählte GPU; für ein GPU-Ziel muss diese Karte auch in der GPU-Auswahl enthalten sein. Die Reihenfolge legt CUDA0/CUDA1 fest, die GUI benennt die tatsächlichen Karten. Modell und Projektor müssen zusammenpassen; der Dateiname reicht als Nachweis nicht.

Zusätzliche konservative Speicherplanung: Projektordateigröße plus 2 GiB Arbeitsreserve auf dem Zielgerät, zusätzlich im Lade-RAM. Das ist keine exakte Vision-Peak-Prognose. Die bisherigen Auto-Tests bleiben reine Texttests ohne Projektor. Der interne Chat-Test ist weiterhin Text; Vision ist über /v1/chat/completions mit einem eingebetteten PNG/JPEG/WebP-Bild im image_url-Feld möglich. Externe URLs sind gesperrt, die gesamte JSON-Anfrage bleibt auf 1 MiB beschränkt.

Projektoren direkt im Profil finden

Der LLM-Profileditor prüft das Hugging-Face-Repository der ausgewählten Modelldatei auf separate mmproj-GGUF-Dateien. Eigene Projektoren werden direkt angeboten; nur wenn dort keine gefunden werden, erscheint die externe Repository-Suche. Bei nicht erreichbaren Metadaten bleibt die Suche bis zur erneuten Prüfung geschlossen. Dies erkennt separate Dateien, nicht eingebettete Vision-Gewichte oder garantierte Architekturkompatibilität.

Eine Modellfamilie oder ein vollständiger Hugging-Face-Repository-Link sucht unabhängig vom Textgenerierungs-Tag (GET /api/v1/catalog/search?kind=chat&purpose=projector&q=…). Nach Auswahl eines Repositorys zeigt der Editor nur mmproj-GGUF-Dateien mit Größe, Quelle und Lizenz. Herunterladen startet keinen Worker. Fortschritt steht unter Downloads. Danach „Bibliothek aktualisieren“, Projektor auswählen, Gerät wählen und Profil speichern. Vorhandene Profilwerte bleiben beim Suchen erhalten. Externe Projektoren müssen zur Modellarchitektur und Version passen; sie erweitern reine Textarchitekturen nicht um Vision.

Offizielle llama.cpp-Versionen

Die Update-Abfrage zeigt das aktuelle reguläre Release (releases/latest) zuerst und ergänzt die jüngsten Nightlies. Reguläre Tags vX.Y.Z, Nightly-Tags bNNNN und vollständige Commit-IDs sind zulässig. Reguläre Releases werden mit LLAMA_BUILD_IS_DEV=OFF, Nightlies mit ON gebaut. Ein reguläres Release ist keine automatische Kompatibilitätszusage für Decks Fit-/MTP-Adapter; Standardwechsel bleiben explizit. Versionsschema: https://github.com/ggml-org/ggml/discussions/1579

GPU-Reserve pro LLM-Profil

Unter GPU-Auswahl: Automatisch (maximaler Wert aus 512 MiB und 2,5 Prozent je GPU), Manuell (0–32768 MiB je ausgewählter GPU) oder Keine zusätzliche Reserve. Manuelle Werte werden per GPU-UUID gespeichert. Alte Profile verwenden weiter Automatisch. Die Reserve beeinflusst Fit-Ziel und Speicherentscheidung; Modell/KV/MTP sowie die konservative Projektor-Schätzung (Dateigröße plus 2 GiB Arbeitsbedarf) bleiben enthalten. Host-RAM-Grenzen bleiben bestehen. Ohne Reserve ist ein erfolgreicher Modellstart nicht garantiert.

Für einen Versuch ohne CPU-Offloading zusätzlich „Vollständig auf GPU · sonst Start abbrechen“ wählen. Dann gibt es bei negativer Prognose keinen automatischen Layer-Rückfall. „Automatisch“ unter GPU-Ausführung erlaubt ihn weiterhin ausdrücklich. Der Testchat zeigt Layerlimit und Reserve je GPU. Gespeicherte Profile werden durch dieses Update nicht umgestellt.

Download-Warteschlange und Geschwindigkeit

Während eines Downloads können bis zu 20 weitere Dateien eingereiht werden, auch kategorienübergreifend. Genau ein Transfer läuft; nach Abschluss, Fehler oder manuellem Abbruch startet der nächste. Doppelte Dateien werden abgewiesen. Unter Downloads lassen sich wartende Einträge entfernen. Die Speicherprüfung berücksichtigt noch ausstehende Bytes aller geplanten Transfers plus 10 GiB Reserve.

Die API liefert queued, bytes_per_second und eta_seconds. Geschwindigkeit basiert auf einem gleitenden Zeitfenster; ETA ist eine Schätzung und enthält keine abschließende Dateiverarbeitung. Vor ausreichenden Messwerten bleibt die Anzeige offen. Beim Serverneustart werden laufende und wartende Einträge als unterbrochen markiert; keine automatische Wiederaufnahme.

FLUX.2 Klein 9B einrichten und testen

Unterstützt ist die Datei Flux.2 Klein-9B_fp16_nsfw.safetensors aus RunningHubAI/rh-flux.2-klein-9b-fp16-unet-2067980602644717569. Die geprüfte Datei enthält BF16-Gewichte (16,9 GiB). Andere FLUX-Dateien werden nicht allein anhand ihres Namens automatisch freigegeben.

Bildprofil anlegen → Komponenten → Alle fehlenden Dateien herunterladen → nach Abschluss Bibliothek aktualisieren → Zuordnung speichern → Testen. Die Komponenten stammen aus Comfy-Org/flux2-klein-9B: split_files/text_encoders/qwen_3_8b_fp8mixed.safetensors und split_files/vae/flux2-vae.safetensors. Wenn genau eine passende Datei vorhanden ist, wird sie vorausgewählt. Downloads nutzen die bestehende Queue. Laufzeitinstallation bleibt unter Einstellungen / Laufzeiten / Bildgenerierung verfügbar.

Neue FLUX-Profile starten mit 4 Schritten und Guidance 1. Bestehende Profile behalten ihre Werte. Pipeline: ComfyUI UNETLoader, Qwen3-FLUX2-Textencoder auf zweiter GPU, EmptyFlux2LatentImage, Flux2Scheduler und Euler, VAE. Der bestehende Low-VRAM-Modus lagert Teile des 16,9-GiB-Modells in den System-RAM aus; es wird nicht vollständige GPU-Belegung versprochen. Beide GPUs müssen frei sein; fremde Prozesse werden nicht gestoppt. Zunächst Text-zu-Bild bis 1024×1024; kein Image-to-Image-Editor für diese Integration.

Verifikation auf Athena: eigene ungespeicherte Testprofilkopie, 512×512, 4 Schritte, Guidance 1, Seed 123, neutrales Fahrradmotiv. Vollständiger Job circa 43 Sekunden einschließlich Start und Entladen. PNG visuell geprüft. 150 automatisierte Tests erfolgreich. Gespeicherte Benutzerprofile und produktiver Router nicht verändert.

Audio-Bereiche

Audio ist in Text-to-Speech (audio, bestehende Dateien und Links bleiben erhalten), Spracherkennung (stt), Musik (music) und Stimme / Voice (voice) aufgeteilt. Jede Kategorie hat eigene Suchergebnisse, Bibliothek, Downloads und vorbereitende Profile. Hub-Filter: text-to-speech, automatic-speech-recognition, text-to-audio, audio-to-audio. Musik umfasst gemäß Hub-Task auch Geräuscherzeugung; Voice umfasst auch Audiotrennung. Direkte Repository-Links umgehen wie bisher den Suchfilter.

Neue Downloads behalten die gewählte Kategorie. Alte Audio-Dateien bleiben bei TTS; es erfolgt keine ungesicherte automatische Umklassifizierung. TTS unterstützt jetzt die unten beschriebene CustomVoice-Laufzeit; Musik und Voice speichern zunächst nur Modell und Namen; STT unterstützt die unten dokumentierte Qwen3-ASR-Variante. Eigenständige Studio-Oberflächen bleiben Weitere Dienste.

Qwen3-TTS einrichten und testen

Unter TTS → Einrichten oder Einstellungen → Laufzeiten → Text-to-Speech installiert der Button eine eigene Python-Umgebung, CUDA-PyTorch und das vollständige offizielle Qwen3-TTS-12Hz-1.7B-CustomVoice inklusive Sprach-Tokenizer. Versionen und Modellrevision sind festgelegt (deploy/tts-requirements.lock, tts_runtime.py). Mindestens 25 GiB freier Datenträgerplatz werden vorausgesetzt. Bestehende Laufzeiten bleiben unverändert. Das Modell erscheint anschließend in der TTS-Bibliothek.

Ein bestehendes MLX-/Base-Profil kann mit CUDA-Modell diesem Profil zuordnen ausdrücklich auf CustomVoice umgestellt werden. Name und Geschwindigkeit bleiben erhalten, die alte Datei wird nicht gelöscht. Alternativ ein neues Profil aus der neuen Bibliotheksdatei erstellen. MLX-Dateien sind für Apple; Base-Referenzstimmen und VoiceDesign sind in dieser ersten Version nicht ausführbar.

Unter TTS → Testen Profil, Stimme und Sprache wählen, Text eingeben und erzeugen. Der Player spielt die WAV-Ausgabe ab; Download und Abbruch sind verfügbar. Die freie RTX 3060 benötigt mindestens 7 GiB VRAM, Deck mindestens 8 GiB RAM-Spielraum. Der Worker läuft offline, nutzt ausschließlich diese GPU und wird nach jedem Auftrag beendet. Die 5080 ist für diesen TTS-Worker noch nicht auswählbar. Geschwindigkeit wird dem Profil entnommen.

Text wird nur über stdin übertragen und nicht gespeichert. WAV-Dateien bleiben unter tts-tests/<job-id>/result.wav im privaten Deck-Zustand; es gibt noch keine automatische Aufräumfunktion. Audio ist nur nach Anmeldung abrufbar. Die API-Freigabe erfolgt wie bei anderen Profilen ausdrücklich über den Endpunkt-Schalter.

Interne authentifizierte API: GET /api/v1/tts, GET /api/v1/tts/audio?id=…, POST /api/v1/tts/install, /install-cancel, /assign (id, revision), /start (profile_id, text, optional speaker, language) und /cancel.

Gemeinsame Laufzeitprüfung

Dateiauswahl unter Entdecken, Bibliothek und Profile zeigen jetzt einen gemeinsamen Einrichtungsstatus. Die lesende Zuordnung in execution_setup.py verwendet die vorhandenen Bildrezepte, die festgelegte CustomVoice-Revision und Chat-GGUF als llama.cpp-Kandidaten. Ein Chat-GGUF ist ohne Ladetest keine Zusage über Architekturunterstützung. Musik, Voice, Video und unbekannte Bild-/TTS-/STT-Varianten bleiben ausdrücklich nicht unterstützt.

„Ausführung einrichten“ führt zum passenden vorhandenen Installer. Ist die Umgebung installiert, wird sie wiederverwendet und „Einrichtung ansehen“ angeboten. Bei Bildprofilen führt „Komponenten“ zu Textencoder-/VAE-Download und Zuordnung. TTS installiert sein vollständiges Modellpaket; ein alternatives TTS-Modell wird nie stillschweigend ersetzt. Konfigurationen, Projektoren, Encoder und VAE sind Zusatzdateien ohne eigenen Worker. Es werden weder beliebiger Installationscode gesucht noch Modelle automatisch gestartet.

Die Verwaltungsantworten für Katalogdateien, Bibliothek und Profile enthalten execution mit Zustand, Erklärung, Laufzeit, Installationsstatus und festem Einrichtungslink. /api/v1/catalog/files akzeptiert dafür kind. Speicherpassung bleibt eine separate Prüfung. Der Download nicht unterstützter Modelle bleibt für spätere Verwendung möglich.

STT: Qwen3-ASR mit wiederverwendeter llama.cpp-Laufzeit

Unter Spracherkennung (STT) → Einrichten oder Einstellungen → Laufzeiten → Spracherkennung werden Qwen3-ASR-0.6B-Q8_0.gguf und der Audio-Projektor aus ggml-org (Revision 928ab958557df9aa2ef1c93e0e83c7ad0933fae2) heruntergeladen. Vorhandene Dateien werden wiederverwendet. Die vorhandene aktive llama.cpp-Laufzeit wird verwendet; auf frischer Installation führt der Link zu deren Build-Verwaltung. Es wird kein zusätzlicher Docker-Dienst benötigt.

Die handy-computer-Konvertierung verwendet qwen3_asr, das der auf Athena getestete Build nicht versteht. Sie bleibt erhalten und wird nicht als ausführbar ausgegeben. Im Einrichtungsdialog lässt sich ein bestehendes Profil ausdrücklich auf die geprüfte ggml-org-Variante umstellen; alternativ ein neues Profil aus der Bibliothek anlegen. Der dazugehörige Audio-Projektor wird anhand fester Quelle, Revision und Datei automatisch gewählt.

STT → Testen: Profil wählen, Audiodatei auswählen, Sprache (Deutsch, Englisch, automatisch) wählen und transkribieren. Der Browser dekodiert maximal 20 MiB / 120 Sekunden und wandelt in PCM16-Mono-WAV bei 16 kHz um. Eingabeformate hängen von den Browser-Codecs ab. Abbrechen beendet ausschließlich den eigenen STT-Prozess. CPU-Ausführung mit zwei Threads, keine GPU-Belegung; mindestens 4 GiB freier Deck-RAM werden vorausgesetzt. Ein API-Schlüssel schützt den kurzlebigen internen Loopback-Worker. Audio und Transkript werden nicht persistiert; das letzte Transkript liegt bis zum nächsten Auftrag oder Neustart im Speicher und ist nach Anmeldung einsehbar. Keine Mikrofonaufnahme, Zeitstempel oder Sprechertrennung in dieser Version.

Interne API: GET /api/v1/stt, POST /api/v1/stt/setup ({}), /assign (id, revision), /start (Multipart: profile_id, file, optional language), /cancel ({}). /setup verwendet die normale Downloadwarteschlange und startet kein Modell. Ausführung setzt ein vollständiges Profil voraus.