Fix two podcast failures: dead TTS server after reboot + CUDA OOM

Podcast generation failed twice at the audio stage, for two unrelated reasons
that look similar from the UI but need opposite fixes.

1) TTS/STT ran as nohup background processes and silently did not survive a
   reboot. Podcasts then failed with "Failed to generate speech: All connection
   attempts failed" (httpx.ConnectError) even though outline and transcript had
   generated fine.

   Both now run as systemd user units. The unit files are versioned in
   services/systemd/ (using %h, not a hardcoded home) and installed by
   scripts/start_services.sh, which also enables linger so they start on boot
   without a login session. They pin GPU 2 by UUID, not by index: CUDA orders
   devices "fastest first", so index 2 can resolve to the T600.

2) GPU 2 is shared by three processes (TTS, STT and the separate chatterbox-tts
   MCP service on :9999), leaving ~12 GB of headroom. podcast_creator sends
   TTS_BATCH_SIZE (default 5) clips concurrently, and since /audio/speech is a
   sync FastAPI handler, they generated genuinely in parallel on one shared
   model. Activation memory multiplied, the TTS process hit 16.7 GB and threw
   torch.OutOfMemoryError, surfacing as "HTTP 500" from the endpoint.

   tts_server.py now serializes generation behind a lock (GPU-bound work, so
   parallelism buys no throughput — it only multiplies peak VRAM) and frees the
   cache afterwards. TTS_BATCH_SIZE=1 keeps the client from queuing requests in
   that lock and running into esperanto's 300s TTS timeout; ESPERANTO_TTS_TIMEOUT
   is raised to 600s as headroom.

Verified: 5 concurrent /audio/speech requests all return 200 with GPU 2 peaking
at ~11.5 GB (was 16.7 GB for the TTS process alone), and the previously failed
episode now completes end to end — 38/38 batches, 10:56 min of audio, zero OOM.

Docs record both failure signatures side by side, since ConnectError (server
dead) and HTTP 500 (server alive, out of VRAM) have very different remedies.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Dieter Schlüter 2026-07-11 13:02:32 +02:00
commit 03877588e1
8 changed files with 244 additions and 52 deletions

View file

@ -24,8 +24,8 @@ Weiterentwicklung: siehe [`CLAUDE.md`](CLAUDE.md).
| `surrealdb` | Docker | Datenbank (nur `127.0.0.1:8000`) |
| `open_notebook` | Docker | Web-UI (`:8502`) + REST-API (`:5055`) |
| Ollama | Host (systemd) | Chat-/Embedding-Modelle, GPU 1+2 |
| `services/tts_server.py` | Host (Hintergrundprozess) | Chatterbox TTS, GPU 2, Port `8901` |
| `services/stt_server.py` | Host (Hintergrundprozess) | faster-whisper STT, GPU 2, Port `8902` |
| `services/tts_server.py` | Host (systemd-User-Dienst) | Chatterbox TTS, GPU 2, Port `8901` |
| `services/stt_server.py` | Host (systemd-User-Dienst) | faster-whisper STT, GPU 2, Port `8902` |
Der `open_notebook`-Container erreicht Ollama und die TTS/STT-Wrapper über
`host.docker.internal` (Linux-Route via `extra_hosts: host-gateway`).
@ -101,15 +101,25 @@ sudo ufw allow 8902/tcp comment 'open-notebook STT (faster-whisper)'
Ohne diesen Schritt bleiben TTS/STT vom Container aus unerreichbar (Timeout), obwohl sie lokal
laufen und funktionieren.
### 2.5 TTS/STT-Server starten
### 2.5 TTS/STT-Server einrichten
```bash
./scripts/start_services.sh
```
Startet `tts_server.py` und `stt_server.py` als Hintergrundprozesse auf GPU 2 (nicht GPU 0/1,
um Ollama und die Desktop-GPU nicht zu belasten). Nicht systemd-verwaltet — nach einem Reboot
erneut ausführen. Logs: `services/logs/`.
Installiert `services/systemd/*.service` nach `~/.config/systemd/user/`, aktiviert `linger`
(damit die Dienste auch ohne aktive Login-Session laufen) und startet beide. Sie laufen auf
GPU 2 — nicht GPU 0/1, um die Desktop-GPU und Ollamas Chat-Modell nicht zu verdrängen.
Das Skript ist idempotent und **überlebt Reboots**: die Dienste starten automatisch mit. Status
und Logs:
```bash
systemctl --user status open-notebook-tts open-notebook-stt
journalctl --user -u open-notebook-tts -f
```
> Der erste Start dauert bis zu einer Minute, weil whisper `large-v3` geladen wird.
Für Stimmklonung mindestens eine Referenz-WAV in `services/voices/default.wav` ablegen (z. B.
Symlink auf eine eigene Sprachaufnahme, 1030s, WAV) — siehe
@ -163,9 +173,16 @@ docker compose up -d # starten
docker compose down # stoppen (Daten bleiben erhalten)
docker compose logs -f open_notebook # Logs verfolgen
docker compose ps # Status
./scripts/start_services.sh # TTS/STT (re-)starten, z.B. nach Reboot
systemctl --user status open-notebook-tts open-notebook-stt # TTS/STT-Status
systemctl --user restart open-notebook-tts # z.B. nach neuer Stimme
journalctl --user -u open-notebook-tts -f # TTS-Logs
./scripts/start_services.sh # Units neu installieren + starten (idempotent)
```
TTS/STT starten nach einem Reboot von selbst — `start_services.sh` ist nur für die
Ersteinrichtung bzw. nach Änderungen an den Unit-Dateien nötig.
---
## 4. Verzeichnisstruktur
@ -180,11 +197,12 @@ open-notebook/
├── services/
│ ├── tts_server.py # Chatterbox-Wrapper (OpenAI-API-kompatibel)
│ ├── stt_server.py # faster-whisper-Wrapper
│ ├── systemd/ # Unit-Dateien für die beiden Wrapper
│ ├── voices/ # Referenz-WAVs fürs Voice-Cloning (gitignored)
│ └── logs/ # (gitignored)
│ └── logs/ # (gitignored, Altlast der früheren nohup-Variante)
├── scripts/
│ ├── setup_models.sh # Provider/Modelle einrichten (idempotent)
│ └── start_services.sh # TTS/STT starten
│ └── start_services.sh # TTS/STT als systemd-User-Dienste installieren+starten
├── README.md # diese Datei
├── BEDIENUNGSANLEITUNG.md # ausführliche Bedienungsanleitung (Deutsch)
└── CLAUDE.md # technische Architektur-Doku für Weiterentwicklung
@ -204,6 +222,11 @@ Kurzreferenz — Details jeweils in [`CLAUDE.md`](CLAUDE.md):
leere Chat-Antworten bei größerem Kontext, ohne sichtbaren Fehler.
- **Neue Host-Ports brauchen eine `ufw`-Regel**, sonst kann der Container sie nicht erreichen
(Timeout, keine Fehlermeldung in Open Notebook selbst).
- **GPU 2 teilen sich drei Prozesse** (TTS, STT und der separate `chatterbox-tts`-MCP-Dienst auf
Port 9999) — es bleiben nur ~12 GB Arbeitsspeicher für die Sprachsynthese. Deshalb serialisiert
`tts_server.py` seine Generierung intern und `TTS_BATCH_SIZE=1` steht in `docker-compose.yml`:
ohne beides schickt der Podcast-Generator 5 Clips gleichzeitig, die parallel auf der GPU laufen
und sie mit `CUDA out of memory` sprengen (sichtbar als `HTTP 500` beim Vertonen).
- **Podcast-Sprache** wird über das `language`-Feld des Episode-Profils gesteuert, aber nur
dank der gepatchten Prompt-Vorlagen unter `prompts/podcast/` (per Bind-Mount in
`docker-compose.yml` eingehängt) — die Original-Vorlagen im Image ignorieren `language`, was