Add configurable TTS and STT residency policies

This commit is contained in:
Mikei386 committed 2026-09-29 20:47:47 +02:00
1 parent 90a97567f3
commit b2256647e9
9 files changed
+209 -40

No files matched your search

+6
View File
@@ -176,6 +176,12 @@ Profilfreigaben: mehrere Chatprofile, höchstens ein Bildprofil. Die Auswahl ein
`POST /v1/audio/transcriptions` benötigt Bearer-Token und ein explizit freigegebenes STT-Profil. Multipart-Felder: `model` (API-Profilname), `file` (PCM16-WAV, mono, 16 kHz, maximal 120 Sekunden / 8 MiB), optional `language` (`de`, `en`, `auto`, Standard `de`), `response_format` (`json`). Antwort: `{"text":"…"}`. Andere Formate, Chunked-Uploads, Zeitstempel und Streaming werden abgelehnt. Ein STT-Auftrag zur Zeit; der CPU-Worker bleibt danach für weitere Aufnahmen geladen. Er wird bei Endpunkt-Stopp, einem neuen Build oder Fehler entladen. Keine Nutzung des alten Routers.
### Speicherverhalten von TTS und STT
Unter **TTS/STT → Einrichten** lässt sich für beide Worker unabhängig **Automatisch** (Standard: beim ersten Auftrag laden und behalten), **Immer bereit** (ausgewähltes ausführbares Profil bei laufendem Endpunkt vorladen und nach Verdrängung erneut laden) oder **Nach jeder Anfrage entladen** wählen. TTS lädt in „Immer bereit“ nur im LLM-GPU-Modus und nur bei ausreichendem freiem RTX-3060-Speicher; der exklusive Videomodus behält Vorrang. STT lädt auf der CPU. Bei fehlender Laufzeit oder unzureichenden Ressourcen bleibt die Auswahl gespeichert und die Fehlermeldung erscheint in der Verwaltungs-API. Das Vorladen wird später erneut versucht und unterbricht keine fremden Dienste. Die Auswahl ändert keine Modellprofile und benötigt keine zusätzliche Runtime.
Interne Verwaltungs-API (angemeldete Oberfläche): `GET /api/v1/audio-policy` liefert `settings` und `errors`; `POST /api/v1/audio-policy` erwartet `{ "kind": "tts|stt", "mode": "auto|warm|per_request", "profile_id": "Profil-ID oder null" }`. Für `warm` muss ein ausführbares Profil gewählt werden. Die Oberfläche verwendet diese API.
### Modelllisten für Clients
`GET /v1/models` listet ausschließlich Chatprofile, damit Chatclients keine Bild-/Audio-Profile anbieten. Deck-Erweiterungen: `GET /v1/images/models` für Bildprofile, `GET /v1/audio/speech/models` für TTS und `GET /v1/audio/transcriptions/models` für STT. Alle Listen erfordern denselben Bearer-Token und enthalten nur freigegebene, ausführbare Profile. Die Inferenzrouten bleiben unverändert. Die Verwaltungs-API liefert weiterhin die Gesamtübersicht.