orbitalo/homelab-brain
1
0
Fork 0
Code Issues 89 Pull requests Projects Releases Packages Wiki Activity Actions

[Plan] Jervais Echtzeit-Uebersetzung - KM/EN -> DE im Ohr, lokal auf RTX 3080 #103

New issue
Open
opened 2026-06-13 12:31:34 +00:00 by orbitalo · 16 comments
orbitalo commented 2026-06-13 12:31:34 +00:00
Owner
Copy link

Ziel

Live-Uebersetzung eingehender Sprache (Khmer, Englisch) -> Deutsch im Kopfhoerer. Ich hoere nur die Uebersetzung in meiner Sprache; das System spricht kein Khmer (keine Khmer-TTS noetig). Phase 2: zusaetzlich Text-Einblendung auf der Even-Realities-Brille.

Warum lokal (Kosten-Kontext)

Laufende Cloud-Wartung ist bereits teuer (~250 EUR/Monat im Schnitt, Spitzen bis 800 EUR). Eine dauerlaufende, streaming-intensive Uebersetzung auf gemeterter Cloud-API wuerde das massiv erhoehen. Loesung: lokal auf vorhandener GPU -> Marginalkosten ~0 EUR. Cloud nur als gezielter Fallback (s. u.).

Hardware

  • RTX 3080 dediziert fuer die Uebersetzungs-Pipeline (STT+MT+TTS).
  • RTX 3090 bleibt frei fuer Qwen3-VL 30B (Hauptmodell) -> keine VRAM-/Latenz-Konkurrenz.
  • OFFEN: 3080-Variante (10 oder 12 GB) + Standort (selber Rechner wie 3090 / separat).

Architektur (eine Richtung: zuhoeren)

Eingang-Audio -> STT -> MT -> TTS(DE) -> Kopfhoerer

  • STT: faster-whisper (CTranslate2, int8), large-v3, streaming. ~2-3 GB.
  • MT: NLLB-200 (many-to-many, KM<->DE direkt, kein Englisch-Pivot). 1.3B (schlank) oder 3.3B (bessere Khmer-Qualitaet, ~12 GB). ~1-7 GB.
  • TTS: Piper (deutsche Stimme) oder vorhandenes Hermes-TTS - schnell, faktisch geloest.

Sprachen / Risiko-Verteilung

  • DE<->EN: unkritisch, exzellent lokal.
  • KM->DE: Hauptrisiko (Low-Resource). Schwachstellen: (1) Khmer-STT-Genauigkeit - Khmer schreibt ohne Wortabstaende -> Streaming-Segmentierung kniffliger; (2) Khmer->DE-MT-Qualitaet.
  • Ausgabe (Deutsch) ist unkritisch, da DE-TTS exzellent lokal laeuft.

Phasen

Phase 0 - Validierung (VOR Aufbau)

  • Quality-Spike NLLB-200 KM->DE: echte Khmer-Saetze, Vergleich gegen Cloud-Referenz.
  • Khmer-STT-Test: echtes Khmer-Audio durch faster-whisper, Verstaendlichkeit/WER pruefen.
  • Entscheidung: voll-lokal ausreichend ODER gezielter Khmer-Cloud-Fallback noetig?

Phase 1 - Kopfhoerer-Pipeline (MVP)

  • 3080 einrichten (Treiber/CUDA, Pipeline auf die 3080 pinnen via CUDA_VISIBLE_DEVICES).
  • faster-whisper Streaming-STT.
  • NLLB-200 MT-Service.
  • Piper DE-TTS -> Audio-Ausgabe in Kopfhoerer.
  • End-to-End-Latenz messen (Ziel < ~1-2 s, sonst nicht 'real-time').

Phase 2 - Even Realities Text-Einblendung

  • Even-Realities-G1-SDK/BLE pruefen: kann man Live-Untertitel-Text einblenden? (separate Integration, eigenes Risiko)
  • Text-Render-Pfad parallel zur Audio-Ausgabe.

Offene Fragen

  • 3080: VRAM-Variante (10/12 GB) + Standort.
  • Even-Realities-SDK: offen genug fuer beliebigen Live-Text?
  • Cloud-Fallback nur fuer Khmer (falls lokal zu schwach): welcher Anbieter + harter Budget-Deckel.

Erfolgskriterien

  • KM/EN -> DE im Ohr, Latenz konversationstauglich (< ~1-2 s).
  • Khmer->DE 'verstaendlich genug' (konkretes Kriterium in Phase 0 festzurren).
  • Keine neuen laufenden Cloud-Kosten (ausser optionalem Khmer-Fallback mit Deckel).

Kontext

  • Teil des Projekts Jervais (Voice-Schale / hands-free, KI-Brille-Pipeline, Hermes-TTS).
  • KI-Server (100.84.255.83, Windows, RTX 3090 + RTX 3080), Ollama vorhanden.
## Ziel Live-Uebersetzung eingehender Sprache (**Khmer**, **Englisch**) -> **Deutsch** im Kopfhoerer. Ich hoere nur die Uebersetzung in meiner Sprache; das System spricht **kein** Khmer (keine Khmer-TTS noetig). Phase 2: zusaetzlich Text-Einblendung auf der **Even-Realities**-Brille. ## Warum lokal (Kosten-Kontext) Laufende Cloud-Wartung ist bereits teuer (~250 EUR/Monat im Schnitt, Spitzen bis 800 EUR). Eine dauerlaufende, streaming-intensive Uebersetzung auf gemeterter Cloud-API wuerde das massiv erhoehen. Loesung: lokal auf vorhandener GPU -> Marginalkosten ~0 EUR. Cloud nur als gezielter Fallback (s. u.). ## Hardware - **RTX 3080 dediziert** fuer die Uebersetzungs-Pipeline (STT+MT+TTS). - **RTX 3090 bleibt frei** fuer Qwen3-VL 30B (Hauptmodell) -> keine VRAM-/Latenz-Konkurrenz. - OFFEN: 3080-Variante (10 oder 12 GB) + Standort (selber Rechner wie 3090 / separat). ## Architektur (eine Richtung: zuhoeren) `Eingang-Audio -> STT -> MT -> TTS(DE) -> Kopfhoerer` - **STT:** faster-whisper (CTranslate2, int8), large-v3, streaming. ~2-3 GB. - **MT:** NLLB-200 (many-to-many, KM<->DE **direkt**, kein Englisch-Pivot). 1.3B (schlank) oder 3.3B (bessere Khmer-Qualitaet, ~12 GB). ~1-7 GB. - **TTS:** Piper (deutsche Stimme) oder vorhandenes Hermes-TTS - schnell, faktisch geloest. ## Sprachen / Risiko-Verteilung - **DE<->EN:** unkritisch, exzellent lokal. - **KM->DE:** Hauptrisiko (Low-Resource). Schwachstellen: (1) Khmer-STT-Genauigkeit - Khmer schreibt ohne Wortabstaende -> Streaming-Segmentierung kniffliger; (2) Khmer->DE-MT-Qualitaet. - Ausgabe (Deutsch) ist unkritisch, da DE-TTS exzellent lokal laeuft. ## Phasen ### Phase 0 - Validierung (VOR Aufbau) - [ ] Quality-Spike NLLB-200 KM->DE: echte Khmer-Saetze, Vergleich gegen Cloud-Referenz. - [ ] Khmer-STT-Test: echtes Khmer-Audio durch faster-whisper, Verstaendlichkeit/WER pruefen. - [ ] Entscheidung: voll-lokal ausreichend ODER gezielter Khmer-Cloud-Fallback noetig? ### Phase 1 - Kopfhoerer-Pipeline (MVP) - [ ] 3080 einrichten (Treiber/CUDA, Pipeline auf die 3080 pinnen via CUDA_VISIBLE_DEVICES). - [ ] faster-whisper Streaming-STT. - [ ] NLLB-200 MT-Service. - [ ] Piper DE-TTS -> Audio-Ausgabe in Kopfhoerer. - [ ] End-to-End-Latenz messen (Ziel < ~1-2 s, sonst nicht 'real-time'). ### Phase 2 - Even Realities Text-Einblendung - [ ] Even-Realities-G1-SDK/BLE pruefen: kann man Live-Untertitel-Text einblenden? (separate Integration, eigenes Risiko) - [ ] Text-Render-Pfad parallel zur Audio-Ausgabe. ## Offene Fragen - 3080: VRAM-Variante (10/12 GB) + Standort. - Even-Realities-SDK: offen genug fuer beliebigen Live-Text? - Cloud-Fallback nur fuer Khmer (falls lokal zu schwach): welcher Anbieter + harter Budget-Deckel. ## Erfolgskriterien - KM/EN -> DE im Ohr, Latenz konversationstauglich (< ~1-2 s). - Khmer->DE 'verstaendlich genug' (konkretes Kriterium in Phase 0 festzurren). - Keine neuen laufenden Cloud-Kosten (ausser optionalem Khmer-Fallback mit Deckel). ## Kontext - Teil des Projekts **Jervais** (Voice-Schale / hands-free, KI-Brille-Pipeline, Hermes-TTS). - KI-Server (100.84.255.83, Windows, RTX 3090 + RTX 3080), Ollama vorhanden.
orbitalo commented 2026-06-13 12:55:27 +00:00
Author
Owner
Copy link

Plan-Besprechung mit Cline (13.06.2026)

Kontext-Korrektur (vorab)

Hermes läuft NICHT mehr auf dem Mac. Der aktuelle Stand laut CT-151-Doku (13.05.2026):

  • Hermes-Gateway als systemd-Service auf CT 151 (pve-mu-3, 100.109.101.12)
  • Nutzt Ollama-Modell qwen3.6:35b-a3b-fast (MoE, 3B aktiv) auf dem KI-Server (100.84.255.83:11434)
  • Hauptmodell via OpenRouter: google/gemini-2.5-flash
  • Honcho (CT 149) als Memory-Backend
  • Der Mac (@JervaisBot) war nur temporär und läuft aus

Damit ist die 3080 auf demselben KI-Server (100.84.255.83) wirklich frei für die Übersetzungspipeline – CUDA_VISIBLE_DEVICES reicht zum Pinnen.

Phase 0 – Validierung

NLLB-200 KM→DE Quality-Spike

VRAM-Korrektur zum Plan: NLLB-200-3.3B-distilled braucht ~7 GB, nicht 12 GB. Der Plan verwechselte das mit dem full 54B-Modell.

Test-Design:

Komponente Vorschlag
Test-Sätze 50 Sätze, 3 Domänen (Alltag, formell, technisch)
Referenz Google Translate KM→DE (Cloud) + DeepL EN→DE (via EN-Pivot)
Metrik COMET (neuronale Metrik, besser als BLEU für Low-Resource)
Schwelle COMET > 0.6 = voll-lokal; 0.3–0.6 = Cloud-Fallback; < 0.3 = EN-Pivot zwingend

Zusätzlicher Test (empfohlen): Den EN-Pivot-Pfad (KM→EN→DE) gleich mitmessen. Selbst wenn KM→DE direkt "akzeptabel" ist, könnte der Pivot deutlich besser sein – und die Zusatzlatenz (~200 ms für zweiten MT-Durchlauf) ist der Qualitätsgewinn wahrscheinlich wert.

Khmer-STT-Test

Das Hauptrisiko ist die Segmentierung, nicht die MT-Qualität:

  • Khmer schreibt ohne Wortabstände (wie Chinesisch, Thailändisch) → Streaming-Segmentierung schwieriger als bei spaced languages (EN, DE)
  • VAD (Voice Activity Detection) muss auf Khmer-Phonetik kalibriert sein
  • Fehler in der Segmentierung pflanzen sich in die Übersetzung fort

Test-Vorschlag: Echte Khmer-Aufnahmen (Alltagsgespräch, nicht Studio) durch faster-whisper large-v3 jagen, WER (Word Error Rate) messen. Ziel: WER < 20 %.

Phase 1 – VRAM-Realitätscheck

Korrigierte VRAM-Rechnung:

Komponente VRAM
faster-whisper large-v3 (int8) ~3 GB
NLLB-200-3.3B-distilled (float16) ~7 GB (nicht 12 GB)
Piper DE-TTS ~0.5 GB
Summe parallel ~10.5 GB
Summe sequenziell ~8 GB (nur aktuelles Modell im VRAM)

Fazit: Passt auf eine 12-GB-3080, aber nicht auf 10 GB. Sequenzielle Pipeline (STT→MT→TTS nacheinander) senkt die Spitze auf ~8 GB.

Empfehlung: Erstmal mit NLLB-1.3B starten (~2 GB, schnell), dann auf 3.3B upgraden wenn Phase 0 zeigt, dass es nötig ist.

Phase 2 – Even Realities G1

Keine Doku-Infos im gesamten Homelab. Das ist ein separates Risiko – unklar ob das SDK offen genug ist, beliebigen Live-Text einzublenden. Unabhängig von der Audio-Pipeline.

Offene Fragen (geklärt / noch offen)

Frage Stand
3080-Variante (10 vs. 12 GB) ❓ Ungeklärt – kritisch für VRAM-Budget
Standort (selber Rechner wie 3090?) ✅ Gleicher Rechner (100.84.255.83), CUDA_VISIBLE_DEVICES reicht
Strom/Kühlung ⚠️ 3080+3090 in einem Gehäuse = ~650 W combined – muss die Kühlung/Kabelage hergeben?
Cloud-Fallback-Anbieter ❓ Ungeklärt – braucht harten Budget-Deckel

Nächste Schritte (Vorschlag)

  1. 3080-Variante klären – nvidia-smi auf KI-Server, VRAM auslesen
  2. NLLB-200-Test vorbereiten – Khmer-Testdaten beschaffen (falls nicht vorhanden)
  3. Kühlung/Strom prüfen – 650 W combined in einem Gehäuse ist ambitioniert
## Plan-Besprechung mit Cline (13.06.2026) ### Kontext-Korrektur (vorab) **Hermes läuft NICHT mehr auf dem Mac.** Der aktuelle Stand laut CT-151-Doku (13.05.2026): - Hermes-Gateway als **systemd-Service auf CT 151 (pve-mu-3, 100.109.101.12)** - Nutzt Ollama-Modell **qwen3.6:35b-a3b-fast (MoE, 3B aktiv)** auf dem KI-Server (`100.84.255.83:11434`) - Hauptmodell via OpenRouter: **google/gemini-2.5-flash** - Honcho (CT 149) als Memory-Backend - Der Mac (`@JervaisBot`) war nur temporär und läuft aus Damit ist die **3080 auf demselben KI-Server (100.84.255.83) wirklich frei** für die Übersetzungspipeline – CUDA_VISIBLE_DEVICES reicht zum Pinnen. --- ### Phase 0 – Validierung #### NLLB-200 KM→DE Quality-Spike **VRAM-Korrektur zum Plan:** NLLB-200-3.3B-distilled braucht **~7 GB**, nicht 12 GB. Der Plan verwechselte das mit dem full 54B-Modell. **Test-Design:** | Komponente | Vorschlag | |---|---| | Test-Sätze | 50 Sätze, 3 Domänen (Alltag, formell, technisch) | | Referenz | Google Translate KM→DE (Cloud) + DeepL EN→DE (via EN-Pivot) | | Metrik | **COMET** (neuronale Metrik, besser als BLEU für Low-Resource) | | Schwelle | COMET > 0.6 = voll-lokal; 0.3–0.6 = Cloud-Fallback; < 0.3 = EN-Pivot zwingend | **Zusätzlicher Test (empfohlen):** Den **EN-Pivot-Pfad** (KM→EN→DE) gleich mitmessen. Selbst wenn KM→DE direkt "akzeptabel" ist, könnte der Pivot *deutlich* besser sein – und die Zusatzlatenz (~200 ms für zweiten MT-Durchlauf) ist der Qualitätsgewinn wahrscheinlich wert. #### Khmer-STT-Test Das **Hauptrisiko** ist die Segmentierung, nicht die MT-Qualität: - Khmer schreibt ohne Wortabstände (wie Chinesisch, Thailändisch) → Streaming-Segmentierung schwieriger als bei spaced languages (EN, DE) - VAD (Voice Activity Detection) muss auf Khmer-Phonetik kalibriert sein - Fehler in der Segmentierung pflanzen sich in die Übersetzung fort **Test-Vorschlag:** Echte Khmer-Aufnahmen (Alltagsgespräch, nicht Studio) durch faster-whisper large-v3 jagen, WER (Word Error Rate) messen. Ziel: WER < 20 %. --- ### Phase 1 – VRAM-Realitätscheck **Korrigierte VRAM-Rechnung:** | Komponente | VRAM | |---|---| | faster-whisper large-v3 (int8) | ~3 GB | | NLLB-200-3.3B-distilled (float16) | ~7 GB (nicht 12 GB) | | Piper DE-TTS | ~0.5 GB | | **Summe parallel** | **~10.5 GB** | | **Summe sequenziell** | **~8 GB** (nur aktuelles Modell im VRAM) | **Fazit:** Passt auf eine 12-GB-3080, aber nicht auf 10 GB. Sequenzielle Pipeline (STT→MT→TTS nacheinander) senkt die Spitze auf ~8 GB. **Empfehlung:** Erstmal mit NLLB-1.3B starten (~2 GB, schnell), dann auf 3.3B upgraden wenn Phase 0 zeigt, dass es nötig ist. --- ### Phase 2 – Even Realities G1 **Keine Doku-Infos** im gesamten Homelab. Das ist ein separates Risiko – unklar ob das SDK offen genug ist, beliebigen Live-Text einzublenden. Unabhängig von der Audio-Pipeline. --- ### Offene Fragen (geklärt / noch offen) | Frage | Stand | |---|---| | **3080-Variante (10 vs. 12 GB)** | ❓ Ungeklärt – kritisch für VRAM-Budget | | **Standort (selber Rechner wie 3090?)** | ✅ Gleicher Rechner (100.84.255.83), CUDA_VISIBLE_DEVICES reicht | | **Strom/Kühlung** | ⚠️ 3080+3090 in einem Gehäuse = ~650 W combined – muss die Kühlung/Kabelage hergeben? | | **Cloud-Fallback-Anbieter** | ❓ Ungeklärt – braucht harten Budget-Deckel | --- ### Nächste Schritte (Vorschlag) 1. **3080-Variante klären** – `nvidia-smi` auf KI-Server, VRAM auslesen 2. **NLLB-200-Test vorbereiten** – Khmer-Testdaten beschaffen (falls nicht vorhanden) 3. **Kühlung/Strom prüfen** – 650 W combined in einem Gehäuse ist ambitioniert
orbitalo commented 2026-06-13 13:02:47 +00:00
Author
Owner
Copy link

Korrektur & Architektur-Update (verifiziert per nvidia-smi / OpenMemory)

Einige Punkte aus der vorigen Analyse waren falsch bzw. ungeprueft. Richtiggestellt:

Hardware (geprueft am KI-Server 100.84.255.83)

  • nvidia-smi -L -> nur GPU 0: RTX 3090 im KI-Server. Keine 3080 verbaut. Die fruehere Aussage '3080 auf KI-Server frei' war NICHT bestaetigt (CUDA_VISIBLE_DEVICES-Pinning waere bei einer GPU sinnlos gewesen).
  • 3090: 24576 MiB total, aktuell nur ~1.2 GB belegt (Qwen3-VL wird von Ollama on-demand geladen/entladen, laeuft nicht dauerhaft).

ENTSCHEIDUNG Hardware-Topologie

  • 3090 bleibt im KI-Server (Qwen3-VL / Cline).
  • 3080 kommt in ein separates, neues Board = dedizierter Uebersetzungs-Rechner.
  • Vorteil ggue. Originalplan: echte Trennung, keine VRAM-/Latenz-Konkurrenz zwischen Live-Uebersetzung und Coding. CUDA_VISIBLE_DEVICES-Pinning entfaellt (eigene Maschine).

Weitere Korrekturen

  • Hermes laeuft auf CT 151 (pve-mu-3) als Service, NICHT auf dem Mac (das war das alte Mai-Setup). Hauptmodell weiterhin google/gemini-2.5-flash via OpenRouter.
  • NLLB-200-3.3B ~7 GB (fp16), nicht 12 GB. Meine 12-GB-Angabe im Ausgangsplan war zu grob geschaetzt.
  • 'NLLB-200-3.3B-distilled' gibt es nicht. NLLB-200-Groessen: distilled-600M, distilled-1.3B, dense-1.3B, dense-3.3B, 54.5B-MoE. Distilled gibt es NUR bis 1.3B; die 3.3B ist das dichte Modell. Korrekt zu vergleichen: dense-3.3B vs. distilled-1.3B.
  • '1.3B ist zu schwach' ist eine unbelegte Vorab-Behauptung und widerspricht dem Sinn von Phase 0. Da dies eine ECHTZEIT-Pipeline ist (Latenz = harte Randbedingung, dense-3.3B ist ~2.5x groesser/langsamer), muessen beide Modelle an echten Khmer-Saetzen gemessen und nach Qualitaet/Latenz-Verhaeltnis ausgewaehlt werden.

Aktualisierte offene Fragen

  1. Neuer Uebersetzungs-Rechner (3080-Board): CPU, RAM, Netzteil-Reserve, OS (Linux empfohlen), Standort/Netz + Tailscale-Onboarding.
  2. 3080-VRAM-Variante (10 vs 12 GB) - weiterhin relevant, da das jetzt DIE Uebersetzungs-GPU ist (10 GB reicht fuer Whisper+NLLB-3.3B+Piper sequenziell, aber knapp bei parallel).
  3. Cloud-Fallback-Anbieter fuer Khmer (falls lokal zu schwach) + harter Budget-Deckel.

Naechste konkrete Schritte (unveraendert sinnvoll)

  • Khmer-Testdaten beschaffen (~50 Saetze, 3 Domaenen).
  • Phase-0-Spike: dense-3.3B UND distilled-1.3B Khmer->DE vergleichen (Qualitaet + Latenz), gegen Cloud-Referenz.
  • Khmer-STT-Test mit echtem Audio (faster-whisper).
## Korrektur & Architektur-Update (verifiziert per nvidia-smi / OpenMemory) Einige Punkte aus der vorigen Analyse waren falsch bzw. ungeprueft. Richtiggestellt: ### Hardware (geprueft am KI-Server 100.84.255.83) - `nvidia-smi -L` -> **nur GPU 0: RTX 3090** im KI-Server. **Keine 3080 verbaut.** Die fruehere Aussage '3080 auf KI-Server frei' war NICHT bestaetigt (CUDA_VISIBLE_DEVICES-Pinning waere bei einer GPU sinnlos gewesen). - 3090: 24576 MiB total, aktuell nur ~1.2 GB belegt (Qwen3-VL wird von Ollama on-demand geladen/entladen, laeuft nicht dauerhaft). ### ENTSCHEIDUNG Hardware-Topologie - **3090 bleibt im KI-Server** (Qwen3-VL / Cline). - **3080 kommt in ein separates, neues Board = dedizierter Uebersetzungs-Rechner.** - Vorteil ggue. Originalplan: echte Trennung, keine VRAM-/Latenz-Konkurrenz zwischen Live-Uebersetzung und Coding. CUDA_VISIBLE_DEVICES-Pinning entfaellt (eigene Maschine). ### Weitere Korrekturen - **Hermes laeuft auf CT 151 (pve-mu-3)** als Service, NICHT auf dem Mac (das war das alte Mai-Setup). Hauptmodell weiterhin google/gemini-2.5-flash via OpenRouter. - **NLLB-200-3.3B ~7 GB** (fp16), nicht 12 GB. Meine 12-GB-Angabe im Ausgangsplan war zu grob geschaetzt. - **'NLLB-200-3.3B-distilled' gibt es nicht.** NLLB-200-Groessen: distilled-600M, distilled-1.3B, dense-1.3B, dense-3.3B, 54.5B-MoE. Distilled gibt es NUR bis 1.3B; die 3.3B ist das dichte Modell. Korrekt zu vergleichen: **dense-3.3B vs. distilled-1.3B**. - **'1.3B ist zu schwach' ist eine unbelegte Vorab-Behauptung** und widerspricht dem Sinn von Phase 0. Da dies eine ECHTZEIT-Pipeline ist (Latenz = harte Randbedingung, dense-3.3B ist ~2.5x groesser/langsamer), muessen beide Modelle an echten Khmer-Saetzen gemessen und nach Qualitaet/Latenz-Verhaeltnis ausgewaehlt werden. ### Aktualisierte offene Fragen 1. **Neuer Uebersetzungs-Rechner (3080-Board):** CPU, RAM, Netzteil-Reserve, OS (Linux empfohlen), Standort/Netz + Tailscale-Onboarding. 2. **3080-VRAM-Variante (10 vs 12 GB)** - weiterhin relevant, da das jetzt DIE Uebersetzungs-GPU ist (10 GB reicht fuer Whisper+NLLB-3.3B+Piper sequenziell, aber knapp bei parallel). 3. **Cloud-Fallback-Anbieter fuer Khmer** (falls lokal zu schwach) + harter Budget-Deckel. ### Naechste konkrete Schritte (unveraendert sinnvoll) - Khmer-Testdaten beschaffen (~50 Saetze, 3 Domaenen). - Phase-0-Spike: dense-3.3B UND distilled-1.3B Khmer->DE vergleichen (Qualitaet + Latenz), gegen Cloud-Referenz. - Khmer-STT-Test mit echtem Audio (faster-whisper).
orbitalo commented 2026-06-13 13:10:34 +00:00
Author
Owner
Copy link

Bauplan Uebersetzungs-Rechner (Hardware final spezifiziert)

Hardware (steht fest)

Komponente Wert Anmerkung
Board MSI MPG B550 Gaming Plus AM4, PCIe 4.0
CPU Ryzen 5 5600G iGPU (Vega) treibt Display -> 3080 zu 100% frei, volle 10 GB fuer Modelle
RAM 16 GB reicht (Pipeline ist GPU-gebunden)
Netzteil 850 W reichlich (Peak ~450 W)
GPU RTX 3080 10 GB dedizierte Uebersetzungs-GPU
OS Linux (Ubuntu LTS) - EMPFOHLEN aenderbar; bestes CUDA/faster-whisper-Setup
Netz Tailscale-Onboarding eigene IP im Tailnet wie andere Hosts

Detail (harmlos): 5600G (Cezanne-APU) bindet den GPU-Slot mit PCIe 3.0 x8 an. Fuer Inferenz irrelevant (Modell wird einmal ins VRAM geladen, danach kaum PCIe-Verkehr).

VRAM-Budget auf 10 GB (alles resident, quantisiert)

  • faster-whisper large-v3 int8: ~1.5 GB
  • NLLB-200 dense-3.3B int8: ~3.5-4 GB
  • Piper DE-TTS: ~0.1 GB
  • CUDA-Context: ~1 GB
  • = ~6-7 GB, komfortabel. Kein sequenzielles Nachladen noetig (das waere toedlich fuer Echtzeit-Latenz).

Software-Stack

  1. NVIDIA-Treiber + CUDA-Runtime.
  2. STT: faster-whisper (CTranslate2) large-v3, int8, Streaming.
  3. MT: NLLB-200 via CTranslate2, int8. Phase-0-Vergleich dense-3.3B vs distilled-1.3B.
  4. TTS: Piper, deutsche Stimme.
  5. Audio: Input-Capture -> Pipeline -> Output auf Kopfhoerer.

Reihenfolge-Empfehlung

Phase 0 (Khmer-Spike) VOR dem Aufbau - laeuft auf der freien 3090 im KI-Server (23 GB frei, kostet nichts). Erst wenn Khmer->DE lokal brauchbar ist, lohnt der 3080-Aufbau. Englisch->DE ist ohnehin unkritisch.

Verbleibende offene Entscheidung

  • OS final bestaetigen (Default: Ubuntu LTS).
  • Cloud-Fallback-Anbieter fuer Khmer (nur falls Phase 0 zeigt, dass lokal zu schwach) + Budget-Deckel.
## Bauplan Uebersetzungs-Rechner (Hardware final spezifiziert) ### Hardware (steht fest) | Komponente | Wert | Anmerkung | |---|---|---| | Board | MSI MPG B550 Gaming Plus | AM4, PCIe 4.0 | | CPU | Ryzen 5 5600G | iGPU (Vega) treibt Display -> **3080 zu 100% frei**, volle 10 GB fuer Modelle | | RAM | 16 GB | reicht (Pipeline ist GPU-gebunden) | | Netzteil | 850 W | reichlich (Peak ~450 W) | | GPU | RTX 3080 **10 GB** | dedizierte Uebersetzungs-GPU | | OS | **Linux (Ubuntu LTS)** - EMPFOHLEN | aenderbar; bestes CUDA/faster-whisper-Setup | | Netz | Tailscale-Onboarding | eigene IP im Tailnet wie andere Hosts | Detail (harmlos): 5600G (Cezanne-APU) bindet den GPU-Slot mit PCIe 3.0 x8 an. Fuer Inferenz irrelevant (Modell wird einmal ins VRAM geladen, danach kaum PCIe-Verkehr). ### VRAM-Budget auf 10 GB (alles resident, quantisiert) - faster-whisper large-v3 **int8**: ~1.5 GB - NLLB-200 dense-3.3B **int8**: ~3.5-4 GB - Piper DE-TTS: ~0.1 GB - CUDA-Context: ~1 GB - **= ~6-7 GB, komfortabel.** Kein sequenzielles Nachladen noetig (das waere toedlich fuer Echtzeit-Latenz). ### Software-Stack 1. NVIDIA-Treiber + CUDA-Runtime. 2. **STT:** faster-whisper (CTranslate2) large-v3, int8, Streaming. 3. **MT:** NLLB-200 via CTranslate2, int8. Phase-0-Vergleich dense-3.3B vs distilled-1.3B. 4. **TTS:** Piper, deutsche Stimme. 5. **Audio:** Input-Capture -> Pipeline -> Output auf Kopfhoerer. ### Reihenfolge-Empfehlung **Phase 0 (Khmer-Spike) VOR dem Aufbau** - laeuft auf der freien 3090 im KI-Server (23 GB frei, kostet nichts). Erst wenn Khmer->DE lokal brauchbar ist, lohnt der 3080-Aufbau. Englisch->DE ist ohnehin unkritisch. ### Verbleibende offene Entscheidung - OS final bestaetigen (Default: Ubuntu LTS). - Cloud-Fallback-Anbieter fuer Khmer (nur falls Phase 0 zeigt, dass lokal zu schwach) + Budget-Deckel.
orbitalo commented 2026-06-13 13:11:46 +00:00
Author
Owner
Copy link

OS-Entscheidung: Proxmox (statt blankes Ubuntu) + GPU-Sharing via LXC

Neuer Rechner wird Proxmox-Node - damit auch Jellyfin mit drauf laeuft (Konsolidierung, passt zum restlichen Proxmox-Stack).

KRITISCH: GPU-Zugriff = LXC, NICHT VM-Passthrough

Die eine 3080 soll von ZWEI Workloads genutzt werden (Uebersetzung + Jellyfin):

  • VM + PCIe-Passthrough (VFIO): GPU wird exklusiv an eine VM gebunden -> Jellyfin bekaeme nichts. Falsch fuer dieses Ziel.
  • LXC + GPU-Sharing (RICHTIG): NVIDIA-Treiber auf dem Proxmox-HOST, dann /dev/nvidia* in mehrere unprivilegierte LXCs durchreichen. Uebersetzungs-LXC und Jellyfin-LXC teilen sich dieselbe Karte gleichzeitig.

Warum das zusammen funktioniert

  • Jellyfin nutzt NVENC/NVDEC (Video-Engine), Whisper/NLLB nutzen CUDA-Compute - verschiedene Engines auf der GPU, kein direkter Konflikt.
  • VRAM: Uebersetzung ~6-7 GB + Jellyfin-Transcode (paar hundert MB/Stream) -> passt in 10 GB.
  • iGPU des 5600G treibt die Proxmox-Konsole -> 3080 bleibt voll fuer die Container.

Ehrliche Vorbehalte

  1. Latenz-Konkurrenz bei Gleichzeitigkeit: schwerer Jellyfin-Transcode + Live-Uebersetzung gleichzeitig -> beide konkurrieren um GPU-Zeit. Fuer Heim-Nutzung unkritisch, aber DER potenzielle Ruckel-Punkt unter Volllast.
  2. NVENC-Session-Limit (Consumer-Karte, historisch wenige parallele Sessions; per nvidia-patch aufhebbar) - fuer einen Nutzer egal.
  3. Treiber-Versionen Host und Container muessen matchen.

Setup-Schritte (Host)

  1. Proxmox VE installieren (Debian-basiert).
  2. NVIDIA-Treiber auf dem Host (nur Kernel-Modul + Userspace, kein Xorg).
  3. Pro LXC: /dev/nvidia* durchreichen (cgroup2 devices.allow + mount.entry), matching Userspace-Treiber im Container (ohne Kernel-Modul).
  4. Tailscale auf dem Host oder per Container.
  5. Uebersetzungs-LXC: faster-whisper + NLLB + Piper. Jellyfin-LXC separat.

Damit ist die Hardware/OS-Planung abgeschlossen. Offen bleibt nur Phase 0 (Khmer-Qualitaet) - die laeuft vorab auf der freien 3090, bevor die Kiste gebaut wird.

## OS-Entscheidung: Proxmox (statt blankes Ubuntu) + GPU-Sharing via LXC Neuer Rechner wird **Proxmox-Node** - damit auch **Jellyfin** mit drauf laeuft (Konsolidierung, passt zum restlichen Proxmox-Stack). ### KRITISCH: GPU-Zugriff = LXC, NICHT VM-Passthrough Die eine 3080 soll von ZWEI Workloads genutzt werden (Uebersetzung + Jellyfin): - **VM + PCIe-Passthrough (VFIO):** GPU wird **exklusiv** an eine VM gebunden -> Jellyfin bekaeme nichts. **Falsch fuer dieses Ziel.** - **LXC + GPU-Sharing (RICHTIG):** NVIDIA-Treiber auf dem Proxmox-HOST, dann `/dev/nvidia*` in mehrere unprivilegierte LXCs durchreichen. Uebersetzungs-LXC und Jellyfin-LXC teilen sich dieselbe Karte gleichzeitig. ### Warum das zusammen funktioniert - **Jellyfin** nutzt **NVENC/NVDEC** (Video-Engine), **Whisper/NLLB** nutzen **CUDA-Compute** - verschiedene Engines auf der GPU, kein direkter Konflikt. - **VRAM:** Uebersetzung ~6-7 GB + Jellyfin-Transcode (paar hundert MB/Stream) -> passt in 10 GB. - iGPU des 5600G treibt die Proxmox-Konsole -> 3080 bleibt voll fuer die Container. ### Ehrliche Vorbehalte 1. **Latenz-Konkurrenz bei Gleichzeitigkeit:** schwerer Jellyfin-Transcode + Live-Uebersetzung gleichzeitig -> beide konkurrieren um GPU-Zeit. Fuer Heim-Nutzung unkritisch, aber DER potenzielle Ruckel-Punkt unter Volllast. 2. **NVENC-Session-Limit** (Consumer-Karte, historisch wenige parallele Sessions; per nvidia-patch aufhebbar) - fuer einen Nutzer egal. 3. **Treiber-Versionen** Host und Container muessen matchen. ### Setup-Schritte (Host) 1. Proxmox VE installieren (Debian-basiert). 2. NVIDIA-Treiber auf dem Host (nur Kernel-Modul + Userspace, kein Xorg). 3. Pro LXC: `/dev/nvidia*` durchreichen (cgroup2 devices.allow + mount.entry), matching Userspace-Treiber im Container (ohne Kernel-Modul). 4. Tailscale auf dem Host oder per Container. 5. Uebersetzungs-LXC: faster-whisper + NLLB + Piper. Jellyfin-LXC separat. Damit ist die Hardware/OS-Planung abgeschlossen. Offen bleibt nur Phase 0 (Khmer-Qualitaet) - die laeuft vorab auf der freien 3090, bevor die Kiste gebaut wird.
orbitalo commented 2026-06-14 13:01:00 +00:00
Author
Owner
Copy link

Pipeline-Design: Machbarkeit, Latenz, Input (Stand Planung)

Hardware-Fazit

RTX 3080 10GB reicht locker (komplett dediziert, da Jellyfin auf iGPU laeuft). VRAM-Budget:

  • STT: faster-whisper large-v3 (int8) ~3GB
  • MT: NLLB-200 (600M-1.3B) ~2-5GB
  • TTS: Piper (laeuft auf CPU) ~0GB
  • Summe ~5-8GB, passt mit Reserve.

Die GPU ist NICHT der Engpass. Die echten Schwierigkeiten: Khmer-Qualitaet + Latenz/Audio-Architektur.

Latenz - realistische Erwartung

Zwei Quellen: (1) Netzwerk (Tailscale, abhaengig von geografischer Distanz Feldgeraet<->Server), (2) Haupttreiber: Whisper braucht ~2-4s Audio-Kontext.
Ergebnis: ~3-5s Verzoegerung = 'verzoegerte Untertitel im Ohr', NICHT simultanes Dolmetschen. Physikalisch nicht umgehbar, keine Hardware-Frage.

Richtung

Start mit EINER Richtung: Gegenueber (Khmer/EN) -> Deutsch ins Ohr. Bei passivem Zuhoeren stoert der Lag kaum. Bidirektional (Deutsch->Khmer fuer sie) = Phase 2, wegen Lag zaeh fuer echtes Hin-und-Her.

Input = wichtigster Faktor (garbage in/out)

Loesung: Wireless Clip-Mikro a la DJI Mic / Rode Wireless GO (2,4-GHz-RF, kein WLAN; wenige ms Latenz, top Qualitaet).

  • Kerntrick: Sender direkt an/neben den Sprecher -> Nahbesprechung loest das Laermproblem an der Wurzel (besserer SNR als 2m-Distanz-Mikro). Wichtiger als jede Software-Stoerunterdrueckung.
  • Verbessert Input-QUALITAET, NICHT die Gesamt-Latenz (die bleibt Whisper-bedingt).
  • Sozialer Haken: bekanntes Gegenueber = anklippen ideal; Fremde = Sender in der Hand Richtung Sprecher.
  • Zwei-Sender-Variante (DJI/Rode) ermoeglicht spaeter beide Gespraechsseiten (Phase 2).

Architektur-Kette

Clip-Mikro (am Sprecher) -> Empfaenger -> Handy (USB-C) -> App -> Tailscale -> Server (STT->MT->TTS) -> Deutsch ins Ohr (Einzel-Ohrhoerer, Umgebung bleibt hoerbar).

Realistische Erwartung

  • Ruhig + EN->DE: laeuft sehr gut.
  • Ruhig + Khmer->DE: brauchbar mit Fehlern (Khmer ist Low-Resource).
  • Laut + Khmer + distanziert: grenzwertig, Clip-Mikro Pflicht.
  • Sofort-Simultan / schnelles bidirektionales Geplaenkel: nicht drin.

Offen

  • Geografische Distanz Feldgeraet<->Server (Latenz-Feinheit).
  • Bessere Khmer-spezifische ASR als Whisper pruefen.
  • Streaming-Ansatz: whisper_streaming / WhisperLive / RealtimeSTT + VAD.
## Pipeline-Design: Machbarkeit, Latenz, Input (Stand Planung) ### Hardware-Fazit RTX 3080 10GB reicht **locker** (komplett dediziert, da Jellyfin auf iGPU laeuft). VRAM-Budget: - STT: faster-whisper large-v3 (int8) ~3GB - MT: NLLB-200 (600M-1.3B) ~2-5GB - TTS: Piper (laeuft auf CPU) ~0GB - Summe ~5-8GB, passt mit Reserve. Die GPU ist NICHT der Engpass. Die echten Schwierigkeiten: Khmer-Qualitaet + Latenz/Audio-Architektur. ### Latenz - realistische Erwartung Zwei Quellen: (1) Netzwerk (Tailscale, abhaengig von geografischer Distanz Feldgeraet<->Server), (2) **Haupttreiber: Whisper braucht ~2-4s Audio-Kontext**. **Ergebnis: ~3-5s Verzoegerung** = 'verzoegerte Untertitel im Ohr', NICHT simultanes Dolmetschen. Physikalisch nicht umgehbar, keine Hardware-Frage. ### Richtung **Start mit EINER Richtung: Gegenueber (Khmer/EN) -> Deutsch ins Ohr.** Bei passivem Zuhoeren stoert der Lag kaum. Bidirektional (Deutsch->Khmer fuer sie) = Phase 2, wegen Lag zaeh fuer echtes Hin-und-Her. ### Input = wichtigster Faktor (garbage in/out) **Loesung: Wireless Clip-Mikro a la DJI Mic / Rode Wireless GO** (2,4-GHz-RF, kein WLAN; wenige ms Latenz, top Qualitaet). - Kerntrick: Sender **direkt an/neben den Sprecher** -> Nahbesprechung loest das Laermproblem an der Wurzel (besserer SNR als 2m-Distanz-Mikro). Wichtiger als jede Software-Stoerunterdrueckung. - Verbessert Input-QUALITAET, NICHT die Gesamt-Latenz (die bleibt Whisper-bedingt). - Sozialer Haken: bekanntes Gegenueber = anklippen ideal; Fremde = Sender in der Hand Richtung Sprecher. - Zwei-Sender-Variante (DJI/Rode) ermoeglicht spaeter beide Gespraechsseiten (Phase 2). ### Architektur-Kette Clip-Mikro (am Sprecher) -> Empfaenger -> Handy (USB-C) -> App -> Tailscale -> Server (STT->MT->TTS) -> Deutsch ins Ohr (Einzel-Ohrhoerer, Umgebung bleibt hoerbar). ### Realistische Erwartung - Ruhig + EN->DE: laeuft sehr gut. - Ruhig + Khmer->DE: brauchbar mit Fehlern (Khmer ist Low-Resource). - Laut + Khmer + distanziert: grenzwertig, Clip-Mikro Pflicht. - Sofort-Simultan / schnelles bidirektionales Geplaenkel: nicht drin. ### Offen - Geografische Distanz Feldgeraet<->Server (Latenz-Feinheit). - Bessere Khmer-spezifische ASR als Whisper pruefen. - Streaming-Ansatz: whisper_streaming / WhisperLive / RealtimeSTT + VAD.
orbitalo commented 2026-06-14 13:04:04 +00:00
Author
Owner
Copy link

Stoergeraeusch-Strategie (in Schichten, frueh schlaegt spaet)

Grundregel: Was einmal im Signal ist, kriegt Software nur teilweise raus -> verhindern vor unterdruecken. Von wirksamster zu schwaechster Schicht:

1. Physik (groesster Hebel, kostenlos)

  • Naehe zur Quelle: Schall faellt mit Quadrat der Entfernung -> Clip-Mikro nah am Sprecher = Nutzstimme laut, Laerm relativ leise. Ersetzt mehr als jede Software.
  • Richtmikrofon (Niere/Shotgun): nimmt nur auf, worauf es zeigt.

2. Hardware-NC im Mikro

DJI Mic 2 / Rode haben eingebaute DSP-Rauschunterdrueckung (Knopfdruck) -> gleichmaessiger Laerm (Verkehr, AC, Gewirr) reduziert, bevor das Signal den Server erreicht.

3. Software vor dem STT (auf dem Server)

  • VAD (Silero) - schneidet Stille/Nicht-Sprache, verhindert halluzinierte Woerter aus Laerm.
  • Echtzeit-Denoiser: DeepFilterNet (sehr gut, echtzeitfaehig) oder RNNoise (leichter), VOR dem STT.

4. Mehrere Stimmen gleichzeitig (harter Fall)

Denoise hilft kaum -> Target-Speaker-Extraction (SepFormer/SpeechBrain), Zielstimme isolieren. Rechenintensiv, aber 3080 dediziert vorhanden. Phase 2.

5. Echo/Rueckkopplung

Deutsches Output im Ohr darf nicht ins Mikro zurueck. Bei Clip-Mikro AM SPRECHER kaum ein Thema (weit vom Ohr) - Pluspunkt. Sonst geschlossener In-Ear + AEC.

Ehrliche Grenze

Laerm ist nicht restlos loesbar. Lauter Markt + mehrere Khmer-Sprecher + Distanz = Fehler bleiben. Ziel: 'gut genug bei moderatem Laerm mit Nahbesprechung', nicht 'perfekt im Chaos'. Zuverlaessigster Trick: naeher ran, Mikro Richtung Sprecher, ruhigere Ecke.

Empfohlener Stack

DJI Mic 2 (Hardware-NC) nah am Sprecher -> Silero VAD -> DeepFilterNet -> faster-whisper. Target-Speaker-Extraction als Phase-2-Option.

## Stoergeraeusch-Strategie (in Schichten, frueh schlaegt spaet) Grundregel: Was einmal im Signal ist, kriegt Software nur teilweise raus -> **verhindern vor unterdruecken.** Von wirksamster zu schwaechster Schicht: ### 1. Physik (groesster Hebel, kostenlos) - **Naehe zur Quelle**: Schall faellt mit Quadrat der Entfernung -> Clip-Mikro nah am Sprecher = Nutzstimme laut, Laerm relativ leise. Ersetzt mehr als jede Software. - **Richtmikrofon** (Niere/Shotgun): nimmt nur auf, worauf es zeigt. ### 2. Hardware-NC im Mikro DJI Mic 2 / Rode haben eingebaute DSP-Rauschunterdrueckung (Knopfdruck) -> gleichmaessiger Laerm (Verkehr, AC, Gewirr) reduziert, bevor das Signal den Server erreicht. ### 3. Software vor dem STT (auf dem Server) - **VAD** (Silero) - schneidet Stille/Nicht-Sprache, verhindert halluzinierte Woerter aus Laerm. - **Echtzeit-Denoiser**: DeepFilterNet (sehr gut, echtzeitfaehig) oder RNNoise (leichter), VOR dem STT. ### 4. Mehrere Stimmen gleichzeitig (harter Fall) Denoise hilft kaum -> **Target-Speaker-Extraction** (SepFormer/SpeechBrain), Zielstimme isolieren. Rechenintensiv, aber 3080 dediziert vorhanden. **Phase 2.** ### 5. Echo/Rueckkopplung Deutsches Output im Ohr darf nicht ins Mikro zurueck. Bei Clip-Mikro AM SPRECHER kaum ein Thema (weit vom Ohr) - Pluspunkt. Sonst geschlossener In-Ear + AEC. ### Ehrliche Grenze Laerm ist nicht restlos loesbar. Lauter Markt + mehrere Khmer-Sprecher + Distanz = Fehler bleiben. Ziel: 'gut genug bei moderatem Laerm mit Nahbesprechung', nicht 'perfekt im Chaos'. Zuverlaessigster Trick: naeher ran, Mikro Richtung Sprecher, ruhigere Ecke. ### Empfohlener Stack DJI Mic 2 (Hardware-NC) nah am Sprecher -> Silero VAD -> DeepFilterNet -> faster-whisper. Target-Speaker-Extraction als Phase-2-Option.
orbitalo commented 2026-06-14 13:08:10 +00:00
Author
Owner
Copy link

Festlegung: bewaehrte Technik, keine Experimente

Entscheidung: Kein Forschungsprojekt. Die Technik ist bekannt und erprobt, das Ergebnis haengt primaer vom Input ab - ein guter Filter ist damit machbar.

  • Filter-Stack (Standard, kein Experiment): Silero VAD + DeepFilterNet (Echtzeit) vor faster-whisper.
  • Qualitaet kommt vom Input: Clip-Mikro nah am Sprecher (DJI Mic 2 mit Hardware-NC) macht den Loewenanteil. Naehe > Filter.
  • Keine exotischen/experimentellen Modelle (Target-Speaker-Extraction etc.) zum Start - nur wenn der Mehrsprecher-Lautfall es konkret erzwingt (Phase 2).
  • DaVinci Resolve nur als optionaler Best-Case-Benchmark, nicht in der Pipeline.

Damit ist die Input-/Filter-Frage abgeschlossen.

## Festlegung: bewaehrte Technik, keine Experimente Entscheidung: **Kein Forschungsprojekt.** Die Technik ist bekannt und erprobt, das Ergebnis haengt primaer vom **Input** ab - ein guter Filter ist damit machbar. - **Filter-Stack (Standard, kein Experiment):** Silero VAD + DeepFilterNet (Echtzeit) vor faster-whisper. - **Qualitaet kommt vom Input:** Clip-Mikro nah am Sprecher (DJI Mic 2 mit Hardware-NC) macht den Loewenanteil. Naehe > Filter. - **Keine exotischen/experimentellen Modelle** (Target-Speaker-Extraction etc.) zum Start - nur wenn der Mehrsprecher-Lautfall es konkret erzwingt (Phase 2). - DaVinci Resolve nur als optionaler Best-Case-Benchmark, nicht in der Pipeline. Damit ist die Input-/Filter-Frage abgeschlossen.
orbitalo commented 2026-06-14 13:11:07 +00:00
Author
Owner
Copy link

Feldgeraet-Konzept (Mikros, App, Ohrhoerer, Brille)

2 Mikros - der saubere Weg

DJI Mic 2 Dual-Kit = 2 Sender + 1 Empfaenger. Empfaenger per USB-C ins Handy, liefert beide Mikros als Stereo (A=links, B=rechts). App trennt die Kanaele:

  • Mikro A = Gegenueber (Khmer/EN -> Deutsch ins Ohr)
  • Mikro B = du (Deutsch -> ihre Sprache, Phase 2)

Was noch fehlt

  1. Handy-App = das eigentlich fehlende Stueck / groesster Dev-Posten. Klebstoff: Mikro-Kanaele aufnehmen -> ueber Tailscale zum Server -> deutsches Audio empfangen -> ins Ohr. Gibt es NICHT von der Stange, muss gebaut werden. Alles andere ist Kaufware.
  2. Tailscale aufs Handy (App) - sichere Leitung zum Server.
  3. Ohrhoerer (AirPods o.ae.): nur EINEN Stoepsel (anderes Ohr frei fuer Umgebung); BT fuegt ~0,15-0,2s Latenz hinzu (auf 3-5s Pipeline vernachlaessigbar).
  4. Strom/Laden: USB-C durch Mikro-Empfaenger belegt -> USB-C-Hub mit Passthrough-Charging fuers gleichzeitige Laden; Mikro-/Ohrhoerer-Cases ebenfalls laden.

Brille = Ausbauphase (stark)

AR-/Smart-Brille blendet Uebersetzung als Text ins Sichtfeld. Lesen umgeht das Lag-Gefuehl (eigenes Tempo statt verzoegertes Audio). Untertitel-Brillen existieren (XREAL etc.), Technik reift noch. Phase 3.

Phasenplan (nicht alles auf einmal)

  • Phase 1 (MVP): 1 Mikro (Gegenueber) -> App -> Server -> 1 Ohrhoerer. Eine Richtung. Konzept beweisen.
  • Phase 2: 2. Mikro + bidirektional (Deutsch -> ihre Sprache, Output Handy-Lautsprecher oder ihr Ohrhoerer).
  • Phase 3: Brille fuer Text-Untertitel.

Jede Phase ist fuer sich nuetzlich.

## Feldgeraet-Konzept (Mikros, App, Ohrhoerer, Brille) ### 2 Mikros - der saubere Weg **DJI Mic 2 Dual-Kit** = 2 Sender + 1 Empfaenger. Empfaenger per USB-C ins Handy, liefert beide Mikros als **Stereo** (A=links, B=rechts). App trennt die Kanaele: - **Mikro A = Gegenueber** (Khmer/EN -> Deutsch ins Ohr) - **Mikro B = du** (Deutsch -> ihre Sprache, Phase 2) ### Was noch fehlt 1. **Handy-App = das eigentlich fehlende Stueck / groesster Dev-Posten.** Klebstoff: Mikro-Kanaele aufnehmen -> ueber Tailscale zum Server -> deutsches Audio empfangen -> ins Ohr. Gibt es NICHT von der Stange, muss gebaut werden. Alles andere ist Kaufware. 2. **Tailscale aufs Handy** (App) - sichere Leitung zum Server. 3. **Ohrhoerer (AirPods o.ae.)**: nur EINEN Stoepsel (anderes Ohr frei fuer Umgebung); BT fuegt ~0,15-0,2s Latenz hinzu (auf 3-5s Pipeline vernachlaessigbar). 4. **Strom/Laden:** USB-C durch Mikro-Empfaenger belegt -> USB-C-Hub mit Passthrough-Charging fuers gleichzeitige Laden; Mikro-/Ohrhoerer-Cases ebenfalls laden. ### Brille = Ausbauphase (stark) AR-/Smart-Brille blendet Uebersetzung als **Text** ins Sichtfeld. Lesen umgeht das Lag-Gefuehl (eigenes Tempo statt verzoegertes Audio). Untertitel-Brillen existieren (XREAL etc.), Technik reift noch. **Phase 3.** ### Phasenplan (nicht alles auf einmal) - **Phase 1 (MVP):** 1 Mikro (Gegenueber) -> App -> Server -> 1 Ohrhoerer. Eine Richtung. Konzept beweisen. - **Phase 2:** 2. Mikro + bidirektional (Deutsch -> ihre Sprache, Output Handy-Lautsprecher oder ihr Ohrhoerer). - **Phase 3:** Brille fuer Text-Untertitel. Jede Phase ist fuer sich nuetzlich.
orbitalo commented 2026-06-14 13:16:41 +00:00
Author
Owner
Copy link

Korrektur Mikro-Anbindung (Bluetooth-Diskussion war falsch)

Klarstellung: Die drahtlose Kopplung laeuft ueber 2,4-GHz-RF zwischen Sendern und Empfaenger - NICHT Bluetooth. Bluetooth-Direktmodus nutzt in der Praxis niemand (Latenz/Qualitaet).

Standard-Setup:

  • 2 Sender -> 1 Empfaenger via 2,4-GHz-RF (die drahtlose Strecke)
  • Empfaenger direkt in den USB-C-Port des Handys -> beide Mikros als Stereo, niedrige Latenz, gute Qualitaet
  • Kein Hub fuer den Normalbetrieb noetig
  • Hub nur, falls man gleichzeitig laden will (USB-C dann belegt) - meist nicht mal das

Die fruehere Erwaehnung von Bluetooth-Direktkopplung / BT-Trade-offs ist hinfaellig.

## Korrektur Mikro-Anbindung (Bluetooth-Diskussion war falsch) Klarstellung: Die drahtlose Kopplung laeuft ueber **2,4-GHz-RF zwischen Sendern und Empfaenger** - NICHT Bluetooth. Bluetooth-Direktmodus nutzt in der Praxis niemand (Latenz/Qualitaet). **Standard-Setup:** - 2 Sender -> 1 Empfaenger via 2,4-GHz-RF (die drahtlose Strecke) - Empfaenger **direkt in den USB-C-Port** des Handys -> beide Mikros als Stereo, niedrige Latenz, gute Qualitaet - **Kein Hub** fuer den Normalbetrieb noetig - Hub nur, falls man gleichzeitig laden will (USB-C dann belegt) - meist nicht mal das Die fruehere Erwaehnung von Bluetooth-Direktkopplung / BT-Trade-offs ist hinfaellig.
orbitalo commented 2026-06-14 13:25:51 +00:00
Author
Owner
Copy link

Lade-Loesung: MagSafe statt Hub (iPhone)

Feldgeraet ist ein iPhone. Da der USB-C-Port durch den Mikro-Empfaenger-Dongle belegt ist, wird drahtlos per MagSafe/Qi geladen - kein Hub noetig.

  • Mobil: MagSafe-Akkupack hinten ans iPhone -> Laden im Gehen, Dongle bleibt im Port.
  • Hinweis: Drahtlosladen ist langsamer + macht etwas Waerme; MagSafe (~15W) haelt das Handy bei App-/Streaming-/Tailscale-Last eher am Leben bzw. laedt langsam nach - fuer eine Gespraechssession ausreichend.

Damit ist die frueher erwaehnte Hub-Option vom Tisch.

## Lade-Loesung: MagSafe statt Hub (iPhone) Feldgeraet ist ein iPhone. Da der USB-C-Port durch den Mikro-Empfaenger-Dongle belegt ist, wird **drahtlos per MagSafe/Qi geladen** - kein Hub noetig. - Mobil: **MagSafe-Akkupack** hinten ans iPhone -> Laden im Gehen, Dongle bleibt im Port. - Hinweis: Drahtlosladen ist langsamer + macht etwas Waerme; MagSafe (~15W) haelt das Handy bei App-/Streaming-/Tailscale-Last eher am Leben bzw. laedt langsam nach - fuer eine Gespraechssession ausreichend. Damit ist die frueher erwaehnte Hub-Option vom Tisch.
orbitalo commented 2026-06-14 13:29:21 +00:00
Author
Owner
Copy link

Nordstern: Hermes/KI als Gespraechs-Co-Pilot (Phase 4)

Vision ueber die reine Uebersetzung hinaus: Hermes mischt mit, gibt live Tipps/Kontext, KI spielt mit. Architektur-Trick, damit das den MVP NICHT bremst:

Zwei getrennte Spuren auf gemeinsamem Transkript

  • Spur 1 - Echtzeit (muss schnell): STT -> MT -> TTS -> Ohr. Kerngeschaeft, bleibt flott.
  • Spur 2 - asynchron (darf langsamer): Hermes/LLM liest den laufenden Transkript-Stream mit, denkt nach, blendet Tipps zeitversetzt ein. Verzoegerter Tipp = ok, verzoegerte Uebersetzung = nicht ok.
  • Transkript = gemeinsame Grundlage. Beide Spuren haengen am selben STT-Output.

Architektur-Hinweis fuer JETZT (spart spaeter Umbau)

Pipeline von Tag 1 so bauen, dass der STT-Strom abgegriffen werden kann (Fan-out) - auch wenn Hermes erst Phase 4 dazukommt.

Brille als Display (passt perfekt)

Ohr = Uebersetzung (Audio), Brille = Hermes-Tipps (Text). Zwei Kanaele, kein Gerangel. Aus Uebersetzer wird Gespraechs-Co-Pilot (z.B. 'hoefliche Absage', 'ueblicher Preis X', 'er erwaehnte vorhin Y').

Geerdet

Phase 3-4, Nordstern - nicht der Start. Erst MVP. Hermes existiert bereits im Homelab -> spaeter Integration, nicht Neubau (LLM evtl. auf der 3080, oder Hermes liest Transkript uebers Netz).

Phasen aktualisiert

  • Phase 1: MVP 1 Mikro, eine Richtung, ins Ohr
  • Phase 2: 2. Mikro, bidirektional
  • Phase 3: Brille (Text-Untertitel)
  • Phase 4: Hermes/KI-Co-Pilot (Tipps auf der Brille, asynchrone 2. Spur)
## Nordstern: Hermes/KI als Gespraechs-Co-Pilot (Phase 4) Vision ueber die reine Uebersetzung hinaus: Hermes mischt mit, gibt live Tipps/Kontext, KI spielt mit. Architektur-Trick, damit das den MVP NICHT bremst: ### Zwei getrennte Spuren auf gemeinsamem Transkript - **Spur 1 - Echtzeit (muss schnell):** STT -> MT -> TTS -> Ohr. Kerngeschaeft, bleibt flott. - **Spur 2 - asynchron (darf langsamer):** Hermes/LLM liest den laufenden Transkript-Stream mit, denkt nach, blendet Tipps zeitversetzt ein. Verzoegerter Tipp = ok, verzoegerte Uebersetzung = nicht ok. - **Transkript = gemeinsame Grundlage.** Beide Spuren haengen am selben STT-Output. ### Architektur-Hinweis fuer JETZT (spart spaeter Umbau) Pipeline von Tag 1 so bauen, dass der STT-Strom **abgegriffen werden kann (Fan-out)** - auch wenn Hermes erst Phase 4 dazukommt. ### Brille als Display (passt perfekt) Ohr = Uebersetzung (Audio), Brille = Hermes-Tipps (Text). Zwei Kanaele, kein Gerangel. Aus Uebersetzer wird Gespraechs-Co-Pilot (z.B. 'hoefliche Absage', 'ueblicher Preis X', 'er erwaehnte vorhin Y'). ### Geerdet Phase 3-4, Nordstern - nicht der Start. Erst MVP. Hermes existiert bereits im Homelab -> spaeter Integration, nicht Neubau (LLM evtl. auf der 3080, oder Hermes liest Transkript uebers Netz). ### Phasen aktualisiert - Phase 1: MVP 1 Mikro, eine Richtung, ins Ohr - Phase 2: 2. Mikro, bidirektional - Phase 3: Brille (Text-Untertitel) - Phase 4: Hermes/KI-Co-Pilot (Tipps auf der Brille, asynchrone 2. Spur)
orbitalo commented 2026-06-16 16:17:46 +00:00
Author
Owner
Copy link

Phase-0-Ergebnis + Richtungsentscheidung (16.06.2026, verifiziert auf CT201/pve-jervais)

Aufbau des Spikes

Neuer LXC CT201 jervais-translate auf pve-jervais, RTX-3080-Sharing funktioniert (Treiber 580.126.09 Host+Container, fp16-Modelle real auf der GPU, GPU-Util 96-97 %). Damit ist Phase E (NVIDIA-LXC-Sharing) praktisch bewiesen. Testdaten: FLEURS km_kh / de_de.

Befund 1 - Khmer-STT ist der Showstopper (robust)

faster-whisper large-v3 auf sauberem FLEURS-Studio-Khmer: avg CER = 0.95 (95 % Zeichenfehler), reproduziert ueber 3 Laeufe. Reale Gespraeche (Laerm/Distanz) waeren schlechter. Whisper kann Khmer nicht - kein Tuning-/Hardware-Problem. RTranslator etc. nutzen sogar kleineres Whisper -> helfen nicht.

Befund 2 - MT-Zahl war ungueltig (Mess-Bug, nicht Modellurteil)

Erste NLLB-Khmer->DE-Messung ergab chrF=14.4 - das war ein Alignment-Bug (FLEURS km/de per Position statt ueber FLORES-id gepaart -> Uebersetzung gegen den falschen deutschen Satz gemessen). Per id-Join gefixt, aber bewusst NICHT zu Ende validiert, weil die Richtungsentscheidung (unten) das Khmer-Thema obsolet macht.

ENTSCHEIDUNG (User, 16.06.2026): Khmer-lokal verworfen, Zielpfad = EN->DE

  • Hauptbedarf ist Englisch->Deutsch, nicht Khmer. Damit ist das Khmer-Hauptrisiko aus diesem Issue fuer den realen Use-Case irrelevant.
  • Khmer-lokal wird nicht gebaut (Whisper-Khmer unbrauchbar). Falls Khmer punktuell noetig: Cloud-STT als Einzelfall (nur STT-Sekunden, billig), MT+TTS lokal. SeamlessM4T-Khmer wurde bewusst NICHT mehr getestet.
  • EN->DE laeuft lokal exzellent (Whisper-EN + NLLB EN->DE + Piper-DE) - kein Qualitaetsrisiko.

Naechster Schritt

KI-Modelle sind geloest; der eigentliche Restaufwand ist der Klebstoff (siehe Kommentar 297): Server-Streaming-Pipeline auf CT201 + Handy-App. Statt selbst bauen werden PolyTalkIO/polytalk bzw. SunnyYadav16/audio-streaming-poc (exakt der Stack: faster-whisper + NLLB + Piper, self-hosted, WebSocket) als Basis evaluiert.

Wert des Spikes

Phase 0 hat ihren Zweck erfuellt: an einem Nachmittag + ~0 Cloud-Kosten geklaert, dass die Khmer-Vollausbau-Pipeline NICHT gebaut werden sollte - bevor Infrastruktur verbrannt wurde. Negatives, aber korrektes Validierungsergebnis.

## Phase-0-Ergebnis + Richtungsentscheidung (16.06.2026, verifiziert auf CT201/pve-jervais) ### Aufbau des Spikes Neuer LXC **CT201 `jervais-translate`** auf pve-jervais, **RTX-3080-Sharing funktioniert** (Treiber 580.126.09 Host+Container, fp16-Modelle real auf der GPU, GPU-Util 96-97 %). Damit ist **Phase E (NVIDIA-LXC-Sharing) praktisch bewiesen**. Testdaten: FLEURS km_kh / de_de. ### Befund 1 - Khmer-STT ist der Showstopper (robust) faster-whisper **large-v3** auf sauberem FLEURS-Studio-Khmer: **avg CER = 0.95** (95 % Zeichenfehler), reproduziert ueber 3 Laeufe. Reale Gespraeche (Laerm/Distanz) waeren schlechter. **Whisper kann Khmer nicht** - kein Tuning-/Hardware-Problem. RTranslator etc. nutzen sogar kleineres Whisper -> helfen nicht. ### Befund 2 - MT-Zahl war ungueltig (Mess-Bug, nicht Modellurteil) Erste NLLB-Khmer->DE-Messung ergab chrF=14.4 - das war ein **Alignment-Bug** (FLEURS km/de per Position statt ueber FLORES-`id` gepaart -> Uebersetzung gegen den falschen deutschen Satz gemessen). Per id-Join gefixt, aber **bewusst NICHT zu Ende validiert**, weil die Richtungsentscheidung (unten) das Khmer-Thema obsolet macht. ### ENTSCHEIDUNG (User, 16.06.2026): Khmer-lokal verworfen, Zielpfad = EN->DE - **Hauptbedarf ist Englisch->Deutsch**, nicht Khmer. Damit ist das Khmer-Hauptrisiko aus diesem Issue fuer den realen Use-Case **irrelevant**. - **Khmer-lokal wird nicht gebaut** (Whisper-Khmer unbrauchbar). Falls Khmer punktuell noetig: **Cloud-STT als Einzelfall** (nur STT-Sekunden, billig), MT+TTS lokal. SeamlessM4T-Khmer wurde bewusst NICHT mehr getestet. - **EN->DE laeuft lokal exzellent** (Whisper-EN + NLLB EN->DE + Piper-DE) - kein Qualitaetsrisiko. ### Naechster Schritt KI-Modelle sind geloest; der eigentliche Restaufwand ist der **Klebstoff** (siehe Kommentar 297): Server-Streaming-Pipeline auf CT201 + Handy-App. Statt selbst bauen werden **PolyTalkIO/polytalk** bzw. **SunnyYadav16/audio-streaming-poc** (exakt der Stack: faster-whisper + NLLB + Piper, self-hosted, WebSocket) als Basis evaluiert. ### Wert des Spikes Phase 0 hat ihren Zweck erfuellt: an einem Nachmittag + ~0 Cloud-Kosten geklaert, dass die Khmer-Vollausbau-Pipeline NICHT gebaut werden sollte - bevor Infrastruktur verbrannt wurde. Negatives, aber korrektes Validierungsergebnis.
orbitalo commented 2026-06-16 16:30:00 +00:00
Author
Owner
Copy link

Aufgabenstellung fuer SPAETER (Phase 4 praezisiert, 16.06.2026): Hermes als Intelligenzverstaerker

Nicht jetzt bauen - aber als Ziel festhalten, damit die Pipeline von Anfang an dafuer vorbereitet wird.

Idee: Hermes klinkt sich als stiller Zuhoerer ins laufende Gespraech ein und blendet Tipps/Kontext im Display (Brille, Phase 3) ein - als Intelligenzverstaerker / Gespraechs-Co-Pilot, nicht als Uebersetzer.

Konkret:

  • Hermes liest den STT-Transkript-Stream mit (Fan-out aus der Echtzeit-Pipeline), uebersetzt selbst nichts.
  • Ausgabe = Text im Display, NICHT Audio -> kein Gerangel mit der Uebersetzungs-Audiospur im Ohr (zwei getrennte Kanaele: Ohr=Uebersetzung, Auge=Tipps).
  • Beispiel-Tipps: Hintergrundwissen, uebliche Preise, hoefliche Formulierung/Absage, Erinnerung an frueher Gesagtes, Vorschlaege fuer die naechste Frage.
  • Darf asynchron/langsamer sein (verzoegerter Tipp = ok, verzoegerte Uebersetzung = nicht ok) -> zweite, entkoppelte Spur.

Architektur-Konsequenz fuer JETZT (damit Phase 4 spaeter ohne Umbau andockt):
Die EN->DE-Pipeline (Phase 1) von Tag 1 so bauen, dass der STT-Output abgegriffen werden kann (Fan-out / Event-Stream) - auch wenn Hermes erst viel spaeter dazukommt.

Voraussetzungen: Phase 1 (EN->DE-MVP ins Ohr) + Phase 3 (Display/Brille). Hermes existiert bereits (CT151, pve-mu-3) -> spaeter Integration ueber den Transkript-Stream, kein Neubau.

## Aufgabenstellung fuer SPAETER (Phase 4 praezisiert, 16.06.2026): Hermes als Intelligenzverstaerker Nicht jetzt bauen - aber als Ziel festhalten, damit die Pipeline von Anfang an dafuer vorbereitet wird. **Idee:** Hermes klinkt sich als **stiller Zuhoerer** ins laufende Gespraech ein und blendet **Tipps/Kontext im Display** (Brille, Phase 3) ein - als **Intelligenzverstaerker / Gespraechs-Co-Pilot**, nicht als Uebersetzer. **Konkret:** - Hermes liest den **STT-Transkript-Stream** mit (Fan-out aus der Echtzeit-Pipeline), uebersetzt selbst nichts. - Ausgabe = **Text im Display**, NICHT Audio -> kein Gerangel mit der Uebersetzungs-Audiospur im Ohr (zwei getrennte Kanaele: Ohr=Uebersetzung, Auge=Tipps). - Beispiel-Tipps: Hintergrundwissen, uebliche Preise, hoefliche Formulierung/Absage, Erinnerung an frueher Gesagtes, Vorschlaege fuer die naechste Frage. - Darf **asynchron/langsamer** sein (verzoegerter Tipp = ok, verzoegerte Uebersetzung = nicht ok) -> zweite, entkoppelte Spur. **Architektur-Konsequenz fuer JETZT (damit Phase 4 spaeter ohne Umbau andockt):** Die EN->DE-Pipeline (Phase 1) von Tag 1 so bauen, dass der **STT-Output abgegriffen werden kann (Fan-out / Event-Stream)** - auch wenn Hermes erst viel spaeter dazukommt. **Voraussetzungen:** Phase 1 (EN->DE-MVP ins Ohr) + Phase 3 (Display/Brille). Hermes existiert bereits (CT151, pve-mu-3) -> spaeter Integration ueber den Transkript-Stream, kein Neubau.
orbitalo commented 2026-06-16 16:32:37 +00:00
Author
Owner
Copy link

Aufgabenstellung fuer SPAETER (Phase 4 praezisiert, 16.06.2026): Hermes als Intelligenzverstaerker

Nicht jetzt bauen - aber als Ziel festhalten, damit die Pipeline von Anfang an dafuer vorbereitet wird.

Idee: Hermes klinkt sich als stiller Zuhoerer ins laufende Gespraech ein und blendet Tipps/Kontext im Display (Brille, Phase 3) ein - als Intelligenzverstaerker / Gespraechs-Co-Pilot, nicht als Uebersetzer.

Konkret:

  • Hermes liest den STT-Transkript-Stream mit (Fan-out aus der Echtzeit-Pipeline), uebersetzt selbst nichts.
  • Ausgabe = Text im Display, NICHT Audio -> kein Gerangel mit der Uebersetzungs-Audiospur im Ohr (zwei getrennte Kanaele: Ohr=Uebersetzung, Auge=Tipps).
  • Beispiel-Tipps: Hintergrundwissen, uebliche Preise, hoefliche Formulierung/Absage, Erinnerung an frueher Gesagtes, Vorschlaege fuer die naechste Frage.
  • Darf asynchron/langsamer sein (verzoegerter Tipp = ok, verzoegerte Uebersetzung = nicht ok) -> zweite, entkoppelte Spur.

Architektur-Konsequenz fuer JETZT (damit Phase 4 spaeter ohne Umbau andockt):
Die EN->DE-Pipeline (Phase 1) von Tag 1 so bauen, dass der STT-Output abgegriffen werden kann (Fan-out / Event-Stream) - auch wenn Hermes erst viel spaeter dazukommt.

Voraussetzungen: Phase 1 (EN->DE-MVP ins Ohr) + Phase 3 (Display/Brille). Hermes existiert bereits (CT151, pve-mu-3) -> spaeter Integration ueber den Transkript-Stream, kein Neubau.

## Aufgabenstellung fuer SPAETER (Phase 4 praezisiert, 16.06.2026): Hermes als Intelligenzverstaerker Nicht jetzt bauen - aber als Ziel festhalten, damit die Pipeline von Anfang an dafuer vorbereitet wird. **Idee:** Hermes klinkt sich als **stiller Zuhoerer** ins laufende Gespraech ein und blendet **Tipps/Kontext im Display** (Brille, Phase 3) ein - als **Intelligenzverstaerker / Gespraechs-Co-Pilot**, nicht als Uebersetzer. **Konkret:** - Hermes liest den **STT-Transkript-Stream** mit (Fan-out aus der Echtzeit-Pipeline), uebersetzt selbst nichts. - Ausgabe = **Text im Display**, NICHT Audio -> kein Gerangel mit der Uebersetzungs-Audiospur im Ohr (zwei getrennte Kanaele: Ohr=Uebersetzung, Auge=Tipps). - Beispiel-Tipps: Hintergrundwissen, uebliche Preise, hoefliche Formulierung/Absage, Erinnerung an frueher Gesagtes, Vorschlaege fuer die naechste Frage. - Darf **asynchron/langsamer** sein (verzoegerter Tipp = ok, verzoegerte Uebersetzung = nicht ok) -> zweite, entkoppelte Spur. **Architektur-Konsequenz fuer JETZT (damit Phase 4 spaeter ohne Umbau andockt):** Die EN->DE-Pipeline (Phase 1) von Tag 1 so bauen, dass der **STT-Output abgegriffen werden kann (Fan-out / Event-Stream)** - auch wenn Hermes erst viel spaeter dazukommt. **Voraussetzungen:** Phase 1 (EN->DE-MVP ins Ohr) + Phase 3 (Display/Brille). Hermes existiert bereits (CT151, pve-mu-3) -> spaeter Integration ueber den Transkript-Stream, kein Neubau.
orbitalo commented 2026-06-16 16:36:38 +00:00
Author
Owner
Copy link

ABSCHLUSS Khmer-lokal + Recherche-Fazit (16.06.2026, Tiefenrecherche Hermes/deepseek-v4-pro)

Diesmal mit Desk-Research + Benchmark-Zahlen + Konfidenzangaben (die Lehre aus dem letzten Fehler). Khmer-lokal ist endgueltig begraben.

Bestaetigt

  • EN->DE komplett lokal = GO. faster-whisper (EN-WER ~2-5 %) + NLLB-200-1.3B (EN->DE stark) + Piper-DE, ~7 GB VRAM, <3 s Latenz, 0 EUR laufend. Hohe Konfidenz (FLORES/LibriSpeech-Benchmarks).
  • Khmer-STT lokal = tot. Whisper CER 0.95 (gemessen), MMS/Fine-tunes bestenfalls 20-45 % WER auf gelesener Sprache, in Konversation schlechter. Kein lokales Khmer-ASR ist produktiv.
  • SeamlessM4T verworfen: passt nicht in 10 GB VRAM und schlaegt die Kaskade nicht. Kein Spike noetig.

Supervisor-Korrekturen an der Recherche (wichtig)

  1. RTranslator NICHT als Basis - ist eine Android-App mit On-Device-Modellen. Feldgeraet ist ein iPhone, Rechnen soll auf der 3080 im Server. Falsche Plattform + falsche Topologie. Server-seitige Basis = PolyTalk / WhisperLive.
  2. Khmer-Hybrid (Google Cloud STT) ruht auf UNGEPRUEFTER Annahme - es gibt keine offenen Google-Khmer-Benchmarks (Konfidenz niedrig-mittel). NICHT committen, bevor ein 10-min-Spike die echte Khmer-WER von Google STT gemessen hat.
  3. Wenn Khmer eh in die Cloud geht: Google direkte Speech-Translation (Audio->DE in einem Schritt) gegen den NLLB-Pivot (KM->EN->DE) testen - evtl. besser + simpler. Der Pivot-Vorteil selbst ist nur Analogieschluss (unbewiesen fuer Khmer).

ENTSCHEIDUNG

  • Bauen jetzt: EN->DE lokal auf CT201, Basis PolyTalk (server-seitig), iPhone-Browser als MVP-Client, MT via NLLB-1.3B oder vorhandenes Ollama.
  • Khmer: geparkt hinter EINEM billigen Cloud-STT-Spike (Google Khmer-WER messen + Direkt-Translate vs. Pivot). Erst danach ggf. Hybrid.
  • Verbleibende ungeloeste Punkte sind klar als "erst messen" markiert: (a) Google-Khmer-Qualitaet, (b) Pivot vs. direkt.

Quellen (Hermes): MMS arxiv 2305.13516, SeamlessM4T v2 (Meta), NLLB-200 arxiv 2207.04672/FLORES-200, faster-whisper + WhisperLive (Repos), Google STT Pricing.

## ABSCHLUSS Khmer-lokal + Recherche-Fazit (16.06.2026, Tiefenrecherche Hermes/deepseek-v4-pro) Diesmal mit Desk-Research + Benchmark-Zahlen + Konfidenzangaben (die Lehre aus dem letzten Fehler). **Khmer-lokal ist endgueltig begraben.** ### Bestaetigt - **EN->DE komplett lokal = GO.** faster-whisper (EN-WER ~2-5 %) + NLLB-200-1.3B (EN->DE stark) + Piper-DE, ~7 GB VRAM, <3 s Latenz, 0 EUR laufend. Hohe Konfidenz (FLORES/LibriSpeech-Benchmarks). - **Khmer-STT lokal = tot.** Whisper CER 0.95 (gemessen), MMS/Fine-tunes bestenfalls 20-45 % WER auf *gelesener* Sprache, in Konversation schlechter. Kein lokales Khmer-ASR ist produktiv. - **SeamlessM4T verworfen:** passt nicht in 10 GB VRAM und schlaegt die Kaskade nicht. Kein Spike noetig. ### Supervisor-Korrekturen an der Recherche (wichtig) 1. **RTranslator NICHT als Basis** - ist eine **Android-App mit On-Device-Modellen**. Feldgeraet ist ein **iPhone**, Rechnen soll auf der **3080 im Server**. Falsche Plattform + falsche Topologie. Server-seitige Basis = **PolyTalk / WhisperLive**. 2. **Khmer-Hybrid (Google Cloud STT) ruht auf UNGEPRUEFTER Annahme** - es gibt **keine offenen Google-Khmer-Benchmarks** (Konfidenz niedrig-mittel). NICHT committen, bevor ein 10-min-Spike die echte Khmer-WER von Google STT gemessen hat. 3. **Wenn Khmer eh in die Cloud geht:** Google **direkte Speech-Translation** (Audio->DE in einem Schritt) gegen den NLLB-Pivot (KM->EN->DE) testen - evtl. besser + simpler. Der Pivot-Vorteil selbst ist nur Analogieschluss (unbewiesen fuer Khmer). ### ENTSCHEIDUNG - **Bauen jetzt: EN->DE lokal** auf CT201, Basis PolyTalk (server-seitig), iPhone-Browser als MVP-Client, MT via NLLB-1.3B oder vorhandenes Ollama. - **Khmer: geparkt** hinter EINEM billigen Cloud-STT-Spike (Google Khmer-WER messen + Direkt-Translate vs. Pivot). Erst danach ggf. Hybrid. - Verbleibende ungeloeste Punkte sind klar als **"erst messen"** markiert: (a) Google-Khmer-Qualitaet, (b) Pivot vs. direkt. Quellen (Hermes): MMS arxiv 2305.13516, SeamlessM4T v2 (Meta), NLLB-200 arxiv 2207.04672/FLORES-200, faster-whisper + WhisperLive (Repos), Google STT Pricing.
orbitalo commented 2026-06-16 16:48:27 +00:00
Author
Owner
Copy link

Richtungswechsel + Parken (16.06.2026): Brille ist das tragende Feature, nicht die Uebersetzung

User-Entscheidung

Der Kern des Projekts ist die Text-Einblendung in der Brille (Live-Untertitel + Hermes-Tipps als Intelligenzverstaerker). Die Uebersetzungsfunktion ist zweitrangig und nur eine Textquelle fuers Display. Klartext des Users: "die ganze sache faellt wenn die brille nicht teil des planes ist". Damit ist der bisherige Audio-zentrische Plan (PolyTalk/CT201 als Kern) degradiert; die lokale EN->DE-Pipeline wird optional.

Recherche-Ergebnis: Brillen-Display ist machbar (verifiziert)

Das "Betriebssystem"-Repo = MentraOS (Mentra-Community/MentraOS, MIT-Lizenz):

  • Open-Source-OS fuer Smart-Glasses, unterstuetzt Even Realities G1 UND G2 (+ Vuzix Z100, Mentra Mach 1, Mentra Live).
  • Hat fertige Apps: "Captions" (Live-Untertitel) + "Translation" -> Kern-Feature off-the-shelf, ohne Code.
  • TypeScript-SDK mit Low-Level-Zugriff auf Display/Mikro/Kamera (AppServer/onSession). Eigene App (Hermes-Tipps-Layer) laeuft auf eigenem Server -> 100 % kontrollierbar.
  • Architektur: Mini-Apps laufen auf dem Handy (iPhone unterstuetzt), Handy macht BLE+Display. -> Keine native iOS-App from scratch noetig.

Self-Hosting-Lage:

  • MentraOS selbst = MIT-Open-Source. ABER: Cloud-Relay, MentraAI, Store, First-Party-Captions/Translation sind proprietaer und nutzen per Default Cloud-STT (Azure/Deepgram/Soniox) + Cloud-LLM (OpenAI/Anthropic).
  • Self-Host moeglich: Relay-Server selbst hosten (Docker, auf jervais), STT -> CT201-Whisper, LLM -> Hermes/Ollama. Voll-lokal (Whisper/Ollama/SearXNG) offiziell "in Arbeit". Edge-SDK = komplett offline, aber nur 1 App gleichzeitig.

Direkter BLE-Weg (ohne Mentra, Purist): G1 laesst sich direkt ueber BLE mit beliebigem Text bespielen - offizielles Protokoll (even-realities/EvenDemoApp, Cmd 0x4E), Community-Libs (emingenc/even_glasses pip, Feras797/matrix-ar, Cheddies1/even-g1-companion mit 0x52 Live-Streaming-Text). Tooling-Reife v.a. auf G1.

G1 vs G2 (fuer Text-HUD)

Fuer einen text-lastigen Use-Case zaehlt Display-Flaeche/Schaerfe -> G2 klar besser: 75 % groesseres + schaerferes Display, bis 1200 nits, ~48 h Akku (G1: ~24 h), 36 g, Magnetometer/IP54. Preis 599 $/£ (Glasses-only). G1 nur bei hartem Budget.

Warum geparkt

Das Brillen-Erlebnis ("ist es der Hit?") laesst sich nicht ohne echte Hardware validieren - reine Software-Validierung unmoeglich. Gate = Hardware-Investition (~599 EUR) in ein offenes Experiment. User hat entschieden: erstmal parken, spaeter entscheiden.

Naechster Schritt, wenn reaktiviert

  1. Hardware-Gate: G2 (Premium-Daily-Driver) ODER guenstige MentraOS-Brille (Vuzix Z100 / Mentra Mach 1, Preise vorher pruefen) zum Konzept-Test besorgen.
  2. Validieren mit fertigen Mentra-Captions (null Code) -> entscheidet das ganze Projekt.
  3. Wenn ja: einzigartiger Eigenbau = MentraOS-Mini-App fuer Hermes-Tipps (CT151 anzapfen), Uebersetzung optional via Mentra oder CT201.

Stand Infrastruktur (bleibt bestehen)

CT201 (jervais-translate, RTX-3080-Passthrough) laeuft - EN->DE lokal validiert, Khmer-lokal verworfen (s.o.). Nichts wird abgebaut, nur pausiert.

## Richtungswechsel + Parken (16.06.2026): Brille ist das tragende Feature, nicht die Uebersetzung ### User-Entscheidung Der Kern des Projekts ist die **Text-Einblendung in der Brille** (Live-Untertitel + Hermes-Tipps als Intelligenzverstaerker). Die **Uebersetzungsfunktion ist zweitrangig** und nur *eine* Textquelle fuers Display. Klartext des Users: "die ganze sache faellt wenn die brille nicht teil des planes ist". Damit ist der bisherige Audio-zentrische Plan (PolyTalk/CT201 als Kern) **degradiert**; die lokale EN->DE-Pipeline wird **optional**. ### Recherche-Ergebnis: Brillen-Display ist machbar (verifiziert) **Das "Betriebssystem"-Repo = MentraOS** (`Mentra-Community/MentraOS`, MIT-Lizenz): - Open-Source-OS fuer Smart-Glasses, **unterstuetzt Even Realities G1 UND G2** (+ Vuzix Z100, Mentra Mach 1, Mentra Live). - Hat **fertige Apps**: "Captions" (Live-Untertitel) + "Translation" -> Kern-Feature off-the-shelf, ohne Code. - **TypeScript-SDK** mit Low-Level-Zugriff auf Display/Mikro/Kamera (`AppServer`/`onSession`). Eigene App (Hermes-Tipps-Layer) laeuft **auf eigenem Server** -> 100 % kontrollierbar. - Architektur: Mini-Apps laufen auf dem **Handy** (iPhone unterstuetzt), Handy macht BLE+Display. -> **Keine native iOS-App from scratch noetig.** **Self-Hosting-Lage:** - MentraOS selbst = MIT-Open-Source. ABER: Cloud-Relay, MentraAI, Store, First-Party-Captions/Translation sind **proprietaer** und nutzen per Default Cloud-STT (Azure/Deepgram/Soniox) + Cloud-LLM (OpenAI/Anthropic). - **Self-Host moeglich:** Relay-Server selbst hosten (Docker, auf jervais), STT -> CT201-Whisper, LLM -> Hermes/Ollama. Voll-lokal (Whisper/Ollama/SearXNG) offiziell "in Arbeit". Edge-SDK = komplett offline, aber nur 1 App gleichzeitig. **Direkter BLE-Weg (ohne Mentra, Purist):** G1 laesst sich direkt ueber BLE mit beliebigem Text bespielen - offizielles Protokoll (`even-realities/EvenDemoApp`, Cmd `0x4E`), Community-Libs (`emingenc/even_glasses` pip, `Feras797/matrix-ar`, `Cheddies1/even-g1-companion` mit `0x52` Live-Streaming-Text). Tooling-Reife v.a. auf G1. ### G1 vs G2 (fuer Text-HUD) Fuer einen text-lastigen Use-Case zaehlt Display-Flaeche/Schaerfe -> **G2 klar besser**: 75 % groesseres + schaerferes Display, bis 1200 nits, ~48 h Akku (G1: ~24 h), 36 g, Magnetometer/IP54. Preis 599 $/£ (Glasses-only). G1 nur bei hartem Budget. ### Warum geparkt Das Brillen-Erlebnis ("ist es der Hit?") laesst sich **nicht ohne echte Hardware validieren** - reine Software-Validierung unmoeglich. Gate = Hardware-Investition (~599 EUR) in ein offenes Experiment. User hat entschieden: **erstmal parken, spaeter entscheiden**. ### Naechster Schritt, wenn reaktiviert 1. Hardware-Gate: G2 (Premium-Daily-Driver) ODER guenstige MentraOS-Brille (Vuzix Z100 / Mentra Mach 1, Preise vorher pruefen) zum Konzept-Test besorgen. 2. Validieren mit **fertigen Mentra-Captions** (null Code) -> entscheidet das ganze Projekt. 3. Wenn ja: einzigartiger Eigenbau = **MentraOS-Mini-App fuer Hermes-Tipps** (CT151 anzapfen), Uebersetzung optional via Mentra oder CT201. ### Stand Infrastruktur (bleibt bestehen) CT201 (jervais-translate, RTX-3080-Passthrough) laeuft - EN->DE lokal validiert, Khmer-lokal verworfen (s.o.). Nichts wird abgebaut, nur pausiert.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
backup/live-state-20260621
No results found.
Labels
Clear labels   
flugscanner

Flugpreisscanner

  
fuenfvoracht

FünfVorAcht Telegram

  
infrastruktur

Server, Container, Netzwerk

  
jarvis

Projekt Jarvis — KI-Assistent mit Sprache, Smart Home, Monitoring

  
ki-tower

RTX 3090 / Lokale KI

  
nice-to-have

Kein Zeitdruck

  
prio-1

Höchste Priorität

  
wartung

Backups, SSL, Monitoring

  
wordpress

Arakava News / RSS Manager

No labels
flugscanner
fuenfvoracht
infrastruktur
jarvis
ki-tower
nice-to-have
prio-1
wartung
wordpress
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: orbitalo/homelab-brain#103
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?