plan: Task 3.1 erledigt, 3.2 vorbereitet; Sprach-Auftrag NEX als 6.2, HDD-Befund in 5.1

ops-LXC, vfio auf allen GPU-Knoten (Bildschirm danach schwarz), Templates
9044/9046/9048/9052, API-Benutzer tofu@pve. Auftrag Sprachmodelle mit
Abgleich gegen den echten Cluster unter docs/auftraege/. Die 4-TB-HDD ist
die Toshiba BACKUP und scheidet für den Cluster aus.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/auftraege/2026-10-12-sprachmodelle-nex.md

@@ -0,0 +1,77 @@
+# Auftrag: Sprachmodelle (Spracherkennung + Sprachausgabe) für NEX auf dem knaster-Cluster
+
+Eingang 12.10.2026 (vom NEX-Team, ohne Schlüssel). Ausführung **nach** Task 3.2 (GPU-VMs mit Treiber), gern durch einen Subagenten. Im Plan als Task 6.5 geführt.
+
+## Abgleich mit dem echten Cluster (Stand 12.10.2026, vor Ausführung lesen)
+
+Der Auftrag geht von einem älteren Bild aus. Es gilt:
+
+| Auftrag sagt | Wirklichkeit |
+|---|---|
+| 2 Knoten + QDevice | 5 Knoten (pve44, pve46, pve48, pve52, pve61), 5 Stimmen, kein QDevice |
+| Knoten A 2× P2000, Knoten B 2× M4000, GPU per LXC oder VM | Eine Ubuntu-24.04-VM pro GPU-Knoten mit allen Karten (D2): `gpu-pve44`, `gpu-pve46`, `gpu-pve48` je M4000 + P2000, `gpu-pve52` nur M4000. Treiber R580 in der VM |
+| Feste IP per DHCP-Reservierung | D5 ist zurückgestellt. Gäste laufen per DHCP, der Nutzer hat keinen Zugriff auf den DHCP-Server. **Vor der Abnahme klären:** Reservierung durch die DHCP-Verwaltung oder statische IP außerhalb des DHCP-Bereichs |
+
+Daraus folgt für die Umsetzung:
+- **Erkennung:** whisper.cpp (CUDA 12, `CMAKE_CUDA_ARCHITECTURES="52;61"`) auf einer **M4000**. Naheliegend ist `gpu-pve52`: Dort steckt nur die M4000, und Placement verteilt keine andere Rolle dorthin. Die P2000 bleiben für embed/rerank (pve44, pve46) und `gpu-small` (pve48). Die M4000 sind im Inventar `disabled` bis zum Benchmark-Tag (Task 3.3); die Messwerte aus 4. Abnahme liefern genau diesen Benchmark für whisper und gehören in Task 3.3.
+- **Ausgabe Stufe 1 (Piper, CPU):** laut Registry `tts-de` im Infra-LXC (`infra`, Task 5.2). Solange `infra` nicht steht, als Container in derselben GPU-VM wie die Erkennung (CPU reicht).
+- **Firewall „nur von 192.168.100.29“:** Proxmox-Firewall an der Netzkarte der VM (`firewall=1`, Regeln für 8178/8179) plus `ufw` in der VM.
+- Globale Vorgabe aus dem Plan passt: whisper-server auf Port 8178, nur von `.29`, `stt.openai.base_url` nur als IP-Literal.
+
+## Auftrag (Originaltext)
+
+NEX sind Hermes-Agenten auf appsrv08 (192.168.100.29). Sprache läuft dort: Hermes → nex-router → LiteLLM → Sprach-Backend. Das Backend ist austauschbar (Eintrag in LiteLLM). Der Dienst auf dem Cluster ist das **Rückfall-Modell**. Solange kein Cloud-Anbieter Guthaben hat, ist er der einzige aktive Weg. Die NEX-Seite trägt danach nur IP:Port und Modellnamen in LiteLLM ein. Gebraucht werden zwei **OpenAI-kompatible** HTTP-Dienste im internen Netz. Ein Dienst für beides ist auch in Ordnung.
+
+Formate laut Hermes-Code: mp3 als Standard, Opus für Sprachnachrichten, rohes PCM mit Sample-Rate-Header für das Streaming.
+
+### Hardware und Grenzen
+- Treiber **R580**, die letzte Serie für Maxwell/Pascal.
+- **faster-whisper/CTranslate2 laufen nicht auf CC 5.2.** Auf der M4000 nur whisper.cpp, und zwar als **CUDA-12-Build**, nicht CUDA 13 (`-DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES="52;61"`).
+- PyTorch-Unterstützung für sm_50/sm_61 in aktuellen Wheels **vorher prüfen** (`python -c "import torch; print(torch.cuda.get_arch_list())"`), nicht annehmen. Keine Tensor-Cores: bei faster-whisper `int8` oder `int8_float32`.
+
+### 1. Spracherkennung (Pflicht)
+- Modell **Whisper large-v3-turbo**, Sprache fest `de`.
+  - Empfehlung M4000: whisper.cpp `whisper-server` mit `-m ggml-large-v3-turbo.bin -l de -bs 5 --convert --inference-path /v1/audio/transcriptions`, **ohne** `--print-realtime`, `--tmp-dir` auf tmpfs (z. B. `/run/nex-whisper`). Nach dem Start einmal mit 1 s Stille aufwärmen.
+  - Alternative P2000: speaches (faster-whisper) mit `deepdml/faster-whisper-large-v3-turbo-ct2`, `int8_float32`.
+  - Optional mitmessen: `primeline/whisper-large-v3-turbo-german`.
+- Schnittstelle: `POST /v1/audio/transcriptions`, multipart
+  - Felder: `file`, `model`, `language=de`, `response_format`.
+  - `file` muss wav, mp3, ogg/opus, webm und m4a annehmen (Umwandlung mit ffmpeg).
+  - `response_format`: `json` → `{"text": "…"}`, `text`, `verbose_json` (wenn möglich mit Wort-Wahrscheinlichkeiten).
+  - Unbekannte Felder ignorieren, nicht mit Fehler antworten.
+
+### 2. Sprachausgabe (Pflicht Stufe 1, optional Stufe 2)
+- **Stufe 1:** Piper Deutsch, CPU reicht. Stimmen: `de_DE-thorsten-high` und eine weibliche deutsche Stimme. Genauen Namen nennen. Server OpenAI-kompatibel, z. B. speaches (kann Piper) oder ein schlanker Wrapper.
+- Schnittstelle: `POST /v1/audio/speech`
+  - JSON-Body `{model, voice, input, response_format, speed}`.
+  - `response_format` muss können: `mp3` (Standard), `opus` (im Ogg-Container), `wav`, `flac`, `pcm` (rohes int16, little-endian, mono; Sample-Rate im Header `X-Audio-Sample-Rate` oder in `Content-Type: audio/pcm; rate=<Hz>`).
+  - Antwort möglichst gestreamt (chunked), damit die Wiedergabe früh beginnt.
+- **Stufe 2 (optional, GPU, nach PyTorch-Prüfung):** eine natürlichere deutsche Stimme.
+  - **Lizenz für kommerzielle Nutzung prüfen.** Nach Stand des NEX-Teams sind XTTS-v2 (Coqui Public Model License) und die Gewichte von Fish Speech/OpenAudio **nicht kommerziell**.
+  - Chatterbox Multilingual (MIT) ist ein Kandidat.
+  - Kokoro hat nach diesem Stand keine deutsche Stimme. Prüfen, nicht voraussetzen.
+
+### 3. Für beide Dienste
+- `GET /health` → 200.
+- Feste IP in `192.168.100.0/24` (siehe Abgleich oben). Ports zum Beispiel 8178 (Erkennung) und 8179 (Ausgabe).
+- Firewall: Zugriff **nur von 192.168.100.29**. LiteLLM läuft dort in einem Bridge-Netz und erscheint mit der Host-IP.
+- Kein API-Key nötig. Erzwingt der Server einen, einen festen Dummy-Wert nennen (kein Geheimnis).
+- Autostart nach Neustart (systemd oder Docker `restart: unless-stopped`), Energiesparen aus, Sicherheitsupdates.
+- **Datenschutz:** keine Ablage von Audio oder Text; Temp-Dateien nur im RAM, alte regelmäßig löschen; **keine Transkripte oder vorgelesenen Texte in Logs.**
+
+### 4. Abnahme
+Von appsrv08 aus prüfen, Testaudio ohne Kundendaten, danach löschen.
+- **Erkennung:**
+  - `curl -s -w ' %{time_total}s\n' -F file=@t10.wav -F model=whisper -F language=de -F response_format=json http://IP:8178/v1/audio/transcriptions`
+  - Text muss deutsch und plausibel sein.
+  - Median aus 3 Läufen: 10 s Audio **≤ 4 s** (Ziel ≤ 3 s), 60 s Audio **≤ 12 s**. Den ersten Aufruf getrennt notieren.
+- **Ausgabe:** `curl -s -o t.mp3 -w ' TTFB %{time_starttransfer}s gesamt %{time_total}s\n' -H 'Content-Type: application/json' -d '{"model":"piper","voice":"de_DE-thorsten-high","input":"Guten Tag, hier ist Ihr NEX-Assistent. Die Baubesprechung in Haslach ist am vierten November.","response_format":"mp3"}' http://IP:8179/v1/audio/speech`
+  - Ergebnis abspielbar, Zeit bis zum ersten Byte möglichst ≤ 1 s.
+  - Dasselbe mit `pcm` (Sample-Rate-Header prüfen) und `opus`.
+- **Last:** 2 Erkennungen gleichzeitig. Mit `nvidia-smi` prüfen, dass GPU-Last und VRAM steigen.
+
+### 5. Rückmeldung (genau so)
+Je Dienst: Basis-URL (IP:Port) · Knoten und GPU · Software mit Version oder Image-Digest · Modellname(n), wie im Feld `model` erwartet · Stimmen-IDs · unterstützte `response_format` · PCM-Sample-Rate · Messwerte (Median, erster Aufruf, VRAM, RAM) · Autostart nach Neustart getestet (ja/nein) · Auffälligkeiten.
+
+### Gegenseite (NEX, zur Information)
+Die Agenten fragen nur noch neutrale Namen an: `nex-stt` für die Erkennung, `nex-tts` für die Ausgabe. Welches Backend dahinter antwortet und in welcher Reihenfolge, legt allein LiteLLM fest: heute das Cluster, später ein Cloud-Anbieter davor und das Cluster als Rückfall. nex-router 0.2.3 wird um die Sprachausgabe (gestreamt) erweitert. Nach der Rückmeldung trägt das NEX-Team die Endpunkte in LiteLLM ein und testet die Kette. Live erst mit dem neuen Router-Image.

docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md

@@ -95,7 +95,7 @@ pve48 hat laut Inventar vom 12.10. M4000 und P2000 und ist damit der vierte GPU-
 |---|---|---|
 | `gpu-pve44`, `gpu-pve46`, `gpu-pve48`, `gpu-pve52` | je 12 GB, fest | auf dem eigenen Knoten |
 | `infra` (LXC) | 8 GB | pve44 auf `tank`, Replikation nach pve52 und pve48 |
-| `ops` (LXC) | 1 GB | pve46 (kein HA nötig, per Ansible neu aufsetzbar) |
+| `ops` (LXC) | 2 GB | pve46 (kein HA nötig, per Ansible neu aufsetzbar; 2 GB statt 1 GB, pve46 hat keinen ZFS-ARC) |
 | `pbs` (VM) | 4 GB | pve52 |
 | `grp-test` (LXC) | 4 GB | pve48 auf `tank`, Replikation nach pve44 |
 | pve61 | 8 GB gesamt | keine Gäste, nur Kiosk |
@@ -260,18 +260,21 @@ Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig.
 
 **Wo:** remote · **Files:** Modify `platform/proxmox/ansible/inventory.yml`, `platform/proxmox/ansible/playbooks/site.yml`, Create `platform/proxmox/README.md` (Abschnitt ops-LXC)
 
-- [ ] LXC `ops` (Debian 13, vmid 100, auf pve46 laut RAM-Budget, IP aus D5) mit `ansible-core`, `opentofu`, `git` und dem Repo-Clone. Ansible läuft nicht auf dem Windows-Laptop.
-- [ ] `site.yml`: `pve-host` nur für `pve_gpu_hosts` (pve44, pve46, pve48, pve52). pve61 steht in `pve_kiosk` ohne VFIO und Blacklist.
-- [ ] Rolle `pve-host` ergänzen: `/etc/modprobe.d/vfio.conf` mit `options vfio-pci ids=<liste>` und `softdep nvidia pre: vfio-pci`. Die Liste enthält die Grafik- **und** die Audio-Funktionen der Karten. Die IDs aus `lspci -nn -s 01:00` und `lspci -nn -s 02:00` auf dem Knoten lesen, nicht aus dem Gedächtnis eintragen; auf allen GPU-Knoten gelesen (12.10.): M4000 `10de:13f1` + Audio `10de:0fbb`, P2000 `10de:1c30` + Audio `10de:10f1`.
-- [ ] `ansible-playbook playbooks/site.yml --limit pve_gpu_hosts --check`, danach der echte Lauf. Knoten **einzeln** neu starten.
+- [x] LXC `ops` (12.10.): CT 100 auf pve46, Debian 13.6, unprivilegiert, 2 Kerne, 2 GB, 8 GB `local-lvm`, DHCP (heute `192.168.100.173`, Alias `ops` in der SSH-Konfiguration des Laptops). `ansible-core` 2.19.11, OpenTofu 1.13.1 (offizielles signiertes Repo), `git`, `make`, `python3-venv`. Eigener Schlüssel `root@ops` steht in `/etc/pve/priv/authorized_keys` (gilt für alle Knoten), `known_hosts` vom Laptop übernommen (geprüfte Einträge), `StrictHostKeyChecking yes`. Repo-Clone anonym über HTTPS (Branch `plan/aufbau-2026-10-12`); geändert wird auf dem Laptop, `ops` macht nur `git pull`.
+- [x] `site.yml`: `pve-host` nur für `pve_gpu_hosts` (pve44, pve46, pve48, pve52). pve61 steht in `pve_kiosk` ohne VFIO und Blacklist.
+- [x] Rolle `pve-host` ergänzen (12.10., IDs liest die Rolle per `lspci -n -d 10de:` auf dem Knoten; zusätzlich `softdep nouveau/snd_hda_intel pre: vfio-pci`, `initcall_blacklist=sysfb_init`, Handler `update-initramfs`; Handler-Fehler behoben: `proxmox-boot-tool refresh || update-grub` erreichte `update-grub` nie): `/etc/modprobe.d/vfio.conf` mit `options vfio-pci ids=<liste>` und `softdep nvidia pre: vfio-pci`. Die Liste enthält die Grafik- **und** die Audio-Funktionen der Karten. Die IDs aus `lspci -nn -s 01:00` und `lspci -nn -s 02:00` auf dem Knoten lesen, nicht aus dem Gedächtnis eintragen; auf allen GPU-Knoten gelesen (12.10.): M4000 `10de:13f1` + Audio `10de:0fbb`, P2000 `10de:1c30` + Audio `10de:10f1`.
+- [x] `ansible-playbook playbooks/site.yml --limit pve_gpu_hosts --check`, danach der echte Lauf. Knoten **einzeln** neu starten (12.10.: pve48 als Pilot inkl. Wegwerf-VM mit beiden Karten, dann pve44, pve52, pve46).
+  Ergebnis 12.10.: auf allen vier GPU-Knoten jede NVIDIA-Funktion an `vfio-pci`, keine fehlgeschlagenen Dienste. Die M4000 ist überall die Boot-Grafik und es gibt keine iGPU: **Der lokale Bildschirm bleibt nach dem frühen Start schwarz**, Zugang per SSH/Weboberfläche, GRUB-Menü bleibt sichtbar. Die P2000 kann kein FLR, der Bus-Reset klappt („reset done“).
   Prüfung: `lspci -nnk -s 01:00` und `lspci -nnk -s 02:00` auf jedem GPU-Knoten → bei allen Funktionen `Kernel driver in use: vfio-pci`. Auf pve61: `lspci -k -s 00:02.0` → `i915`.
 
 ### Task 3.2: Resource Mappings, Template und GPU-VMs
 
 **Wo:** remote (ops-LXC) · **Planner:** „GPU-Knoten 3 …“ (Teil NVIDIA, GPU-Container)
 
-- [ ] PCI-Resource-Mappings aus `sites/knaster/proxmox.yaml` anlegen (Namen aus Task 0.4).
-- [ ] Ubuntu-24.04-Cloud-Template vmid 9000 auf jedem GPU-Knoten.
+- [ ] PCI-Resource-Mappings aus `sites/knaster/proxmox.yaml` anlegen (Namen aus Task 0.4) – per tofu (`proxmox_hardware_mapping_pci`).
+- [x] Ubuntu-24.04-Cloud-Template je Knoten (12.10.): **9044, 9046, 9048, 9052** statt 9000 überall, weil VMIDs clusterweit eindeutig sind. `platform/proxmox/scripts/make-template.sh <knoten> <vmid>` (Prüfsumme gegen SHA256SUMS, kein Secure Boot wegen DKMS, Gast-Agent an).
+- [x] API-Benutzer `tofu@pve` mit Token `tofu@pve!ops` (12.10.), Rechte nur: `/` PVEAuditor, `/vms` PVEVMAdmin, `/storage` PVEDatastoreUser, `/sdn/zones/localnetwork` PVESDNUser, `/mapping/pci` PVEMappingAdmin. Token nur auf `ops` in `/root/.config/knaster/tofu.env` (600). Für HA (5.2) kommt `Sys.Console` hinzu.
+- [x] tofu-Code an D2/D5 angepasst (12.10.): `bpg/proxmox ~> 0.116.0`, `hostpci` dynamisch aus `vms.*.gpus`, DHCP mit Adresse über den `qemu-guest-agent` (Vendor-Snippet `local:snippets/knaster-vendor.yaml` aus `pve-host`), Speicher je Gast, Ausgabe `ansible_inventory`. `tofu plan`: 11 neue Objekte.
 - [ ] `tofu plan` und dann `tofu apply` für `gpu-pve44`, `gpu-pve46`, `gpu-pve48` und `gpu-pve52`: alle Karten des Knotens, 12 GB RAM, 4 Kerne, Systemplatte 40 GB und Modellplatte 60 GB auf `local-lvm` (Variante B) bzw. `local-zfs` (Variante A), IPs aus D5.
 - [ ] `ansible-playbook … --limit gpu_vms` (Rollen `docker-host` und `gpu-node`, `driver_generation: legacy` = R580).
   Prüfung in jeder VM: `nvidia-smi -L` → beide Karten. `docker run --rm --gpus all nvidia/cuda:12.6.3-base-ubuntu24.04 nvidia-smi` → beide Karten.
@@ -309,7 +312,8 @@ Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig.
 
 **Wo:** remote, Speicherort vor Ort · **Planner:** „Proxmox: Backup-System überlegen“ (beantwortet PLAN §9, offener Punkt 6)
 
-- [ ] Ziel-Speicher entscheiden. Empfehlung: externer Datenträger oder NAS, **nicht** die Toshiba-Platte „BACKUP“ des Nutzers. PBS als VM `pbs` (vmid 110), Datastore auf dem Ziel.
+- [ ] Ziel-Speicher entscheiden. Empfehlung: externer Datenträger oder NAS, **nicht** die Toshiba-Platte „BACKUP“ des Nutzers.
+  Prüfung 12.10. (nur lesend): Die angeschlossene 4-TB-HDD **ist** die Toshiba „BACKUP“ (USB, exFAT, rund 126 GB belegt), Windows meldet „Full Repair Needed“ und Controller-/Paging-Fehler (Event 11/51). Für den Cluster ausgeschlossen. Vorschlag: eigene 4-TB-CMR-Platte intern per SATA in pve52 oder pve44 (auf allen vier P310/P320 melden ata2–ata4 „link down“, freie Schächte/Kabel vor Ort prüfen). Surface/pve61 scheidet aus (Platte und einzige Netzkarte hängen an derselben USB-Kette). PBS als VM `pbs` (vmid 110), Datastore auf dem Ziel.
 - [ ] Jobs: nächtlich Infra-LXC, ops-LXC und GPU-VMs (ohne Modellplatte), Aufbewahrung 7 Tage, 4 Wochen und 6 Monate. Dazu ein wöchentlicher Verify-Job.
 - [ ] **Restore-Test:** Infra-LXC als Kopie zurückspielen.
   Prüfung: Die Kopie startet, `docker ps` zeigt die Dienste.
@@ -340,7 +344,7 @@ Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig.
 Ersetzt PLAN §8 „1 Data Plane“.
 
 - [ ] **6.1 GPU-Rollen:** `deploy/compose/gpu-llamacpp` in den GPU-VMs nach der Zuordnung aus Task 3.3, also Embedding und Rerank redundant auf zwei Knoten, Chat für verifier und signature. Prüfung: Canary-Checks grün (`knaster` Canary-Prober).
-- [ ] **6.2 STT** (nex-STT-Plan Tasks 2–4): `whisper-server` als zusätzlicher Dienst in der GPU-VM des in Task 3.3 gewählten Knotens. Neuer Slot `stt-de` im Katalog. Port 8178 nur von `192.168.100.29` (Firewall der VM bzw. des Gasts). Prüfung: Von appsrv08 liefert `curl -F file=@probe.wav http://<IP>:8178/v1/audio/transcriptions` deutschen Text, von einem anderen Rechner wird der Zugriff abgelehnt.
+- [ ] **6.2 STT und TTS für NEX** – Auftrag vom 12.10. mit Abgleich: `docs/auftraege/2026-10-12-sprachmodelle-nex.md` (Erkennung whisper.cpp auf einer M4000, naheliegend `gpu-pve52`; Ausgabe Piper auf CPU, Port 8179; Abnahme und Rückmeldeformat dort). Läuft nach Task 3.2, gern als Subagent. **Blockiert für die Abnahme:** feste IP (D5). Bisheriger Text (nex-STT-Plan Tasks 2–4): `whisper-server` als zusätzlicher Dienst in der GPU-VM des in Task 3.3 gewählten Knotens. Neuer Slot `stt-de` im Katalog. Port 8178 nur von `192.168.100.29` (Firewall der VM bzw. des Gasts). Prüfung: Von appsrv08 liefert `curl -F file=@probe.wav http://<IP>:8178/v1/audio/transcriptions` deutschen Text, von einem anderen Rechner wird der Zugriff abgelehnt.
 - [ ] **6.3 Lokale Slots in LiteLLM (D4):** `embed-default`, `rerank-default`, `verifier-small` und `signature-extractor` als Modelle im LiteLLM auf appsrv08 eintragen (IP-Literale). Prüfung: `curl http://192.168.100.29:<port>/v1/models` listet die Slots, ein Aufruf je Slot antwortet.
 - [ ] **6.4 Ada-Worker (D3)** · **Planner:** „LLM-Worker: direkte Inferenz-Schnittstelle für LiteLLM (zusätzlich zum Job-Poll), Tunnel, Registry, Fallback-Kette“
   - Offene Schritte der Worker-Registry v2 im Repo `mygodel/nex` abschließen.