# KI-Video — Lokale Produktionspipeline **Stand: 16.03.2026** ## Ziel Lokale, praktisch nutzbare Produktionsstrecke fuer YouTube-Videos im Commentary-/Erklaerstil. Kein Spielzeug-Demo, kein Forschungsprojekt: Thema rein → fertiges Video raus. ## Videoformat Referenz-Stil: **"Geld & Imperien"** (YouTube, geopolitischer Commentary-Kanal) Beispielvideo: https://youtu.be/4XfhrrbklbM (24 Min, "Irans Hyperschall-Schlag") | Eigenschaft | Beschreibung | |---|---| | **Typ** | Commentary, Erklaervideos, Meinungs-/Analyseformate | | **Laenge** | 10-30 Minuten | | **Stil** | Professionelle Erzaehlstimme + Bilder + Karten + Infografiken + Text-Overlays + Ken-Burns | | **Kein** | Face-Cam, Schnitte auf Person, Realfilm | | **Optional** | Sprechender Avatar (SadTalker) — erst ab v2 | ### Anatomie eines 20-Min-Videos (Referenz) | Element | Menge | Beschreibung | |---|---|---| | **Skript** | ~3500-5000 Woerter | Monolog, professioneller Ton, analytisch | | **Szenenbilder** | 80-120 Stueck | Karten, Infografiken, Symbolbilder, Illustrationen | | **Hero-Bilder** | 10-15 Stueck | Hochwertige Key-Visuals fuer Titelszenen/Kapitelwechsel | | **Text-Overlays** | 20-40 Stueck | Zahlen, Namen, Fakten als Einblendung | | **Voiceover** | 20 Min Audio | Natuerliche deutsche Maennerstimme | | **Hintergrundmusik** | 1-2 Tracks | Ambient, dezent, lizenzfrei | | **Uebergaenge** | ~80-120 | Ken-Burns, Ueberblendungen, Zoom-Ins | ## Produktions-Pipeline (5 GPUs parallel) Kernidee: **Phase 1 ist seriell (Skript), Phase 2 nutzt alle 5 GPUs parallel, Phase 3 ist Assembly.** Das macht aus 3-4 Stunden seriellem Rendern ca. 40-60 Minuten Gesamtzeit. ``` PHASE 1 — SKRIPT (ki-tower, seriell, ~10-15 Min) ══════════════════════════════════════════════════ Thema + Recherche-Notizen (manuell) │ ▼ Qwen 14B (vLLM, :8401) → Skript (~4000 Woerter, 20 Min Lesezeit) │ ▼ Qwen 14B → Szenenplan: 100 Szenen mit je: - Bildprompt (EN, fuer FLUX/SDXL) - Szenentyp (hero / standard / infografik / karte) - Text-Overlay (falls noetig) - Geschaetzte Dauer (Sekunden) │ ▼ Skript + Szenenplan als JSON → Orchestrator PHASE 2 — PARALLEL-PRODUKTION (alle 5 GPUs, ~30-40 Min) ══════════════════════════════════════════════════════════ ┌──────────────────────────────────────────────────────────────────┐ │ ORCHESTRATOR (ki-tower CPU) │ │ Verteilt Jobs, pollt Status, sammelt Ergebnisse │ └──────┬──────────┬──────────┬──────────┬──────────┬───────────────┘ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ┌──────────┐┌──────────┐┌──────────┐┌──────────┐┌──────────┐ │ 3090 ││ 3080 #0 ││ 3080 #1 ││ 3080 #2 ││ 3080 #3 │ │ ki-tower ││ Worker ││ Worker ││ Worker ││ Worker │ │ ││ ││ ││ ││ │ │ FLUX.1 ││ SDXL ││ SDXL ││ XTTS v2 ││ ESRGAN │ │ Hero- ││ Standard-││ Standard-││ Voiceover ││ Upscale │ │ Bilder ││ Szenen ││ Szenen ││ 20 Min ││ + Whisper│ │ 15 Stk ││ ~45 Stk ││ ~45 Stk ││ Audio ││ Untertit.│ │ ~15 Min ││ ~20 Min ││ ~20 Min ││ ~15 Min ││ ~10 Min │ └──────────┘└──────────┘└──────────┘└──────────┘└──────────┘ Alle 5 GPUs arbeiten GLEICHZEITIG. Engpass = Bildgenerierung (~20-25 Min). PHASE 3 — ASSEMBLY + EXPORT (ki-tower, seriell, ~15-20 Min) ════════════════════════════════════════════════════════════ │ ▼ FFmpeg: Bilder + Ken-Burns + Zoom + Ueberblendungen │ ▼ FFmpeg: Audio-Mix (Voiceover + Hintergrundmusik + Lautstaerke-Normalisierung) │ ▼ FFmpeg: Text-Overlays (Fakten, Zahlen, Namen) einbrennen │ ▼ FFmpeg: Untertitel (SRT aus Whisper) einbetten │ ▼ NVENC: H.264/H.265 Encoding → fertiges MP4 (1080p/4K) │ ▼ Export: Thumbnail (FLUX hero-Bild, upscaled) + Titel + Description + Tags ``` ### Zeitschaetzung: 20-Minuten-Video im "Geld & Imperien"-Stil | Phase | Dauer | GPUs aktiv | Engpass | |---|---|---|---| | 1. Skript + Szenenplan | ~15 Min | 1 (3090) | LLM-Inferenz | | 2. Parallel-Produktion | ~25 Min | 5 (alle) | Bildgenerierung | | 3. Assembly + Export | ~15 Min | 1 (3090 NVENC) | FFmpeg Compositing | | **Gesamt** | **~55 Min** | | | Zum Vergleich: Seriell auf nur 1 GPU = ~3-4 Stunden. Mit 5 GPUs parallel: **unter 1 Stunde fuer ein 20-Min-Video.** ### GPU-Auslastung waehrend Phase 2 | GPU | Aufgabe | VRAM | Dauer | Output | |---|---|---|---|---| | **3090** (ki-tower) | FLUX.1-dev Hero-Bilder | ~12 GB | ~15 Min | 15 hochwertige Key-Visuals (1024x1024) | | **3080 #0** | SDXL Standard-Szenen | ~7 GB | ~20 Min | ~45 Szenenbilder (1024x1024) | | **3080 #1** | SDXL Standard-Szenen | ~7 GB | ~20 Min | ~45 Szenenbilder (1024x1024) | | **3080 #2** | XTTS v2 Voiceover | ~4 GB | ~15 Min | 20 Min deutsches Voiceover | | **3080 #3** | Real-ESRGAN + Whisper | ~3 GB | ~10 Min | Upscaled Bilder + SRT-Untertitel | Nach Abschluss der Hauptaufgabe uebernehmen freie GPUs Restarbeiten: - 3080 #2 (fertig mit TTS) → hilft bei restlichen SDXL-Bildern - 3080 #3 (fertig mit Upscale) → generiert Thumbnail-Varianten ## Konkretes Beispiel: "Irans Hyperschall-Schlag" (24 Min) So wuerde ein Video im Stil von "Geld & Imperien" durch die Pipeline laufen: ``` INPUT: Thema: "Irans neue Hyperschallrakete — geopolitische und wirtschaftliche Folgen" Recherche: 3-4 Quellenlinks, eigene Stichpunkte PHASE 1 — Qwen 14B generiert: ├── Skript: ~4500 Woerter, 24 Min Lesezeit │ "Was ich euch heute zeige, veraendert die Welt..." │ Kapitel: Waffentechnik → Strategie → Oel → Europa → Fazit │ └── Szenenplan (JSON): 105 Szenen Szene 001: { typ: "hero", prompt: "dramatic missile launch, night sky, photorealistic", overlay: "Mach 15 — Irans Hyperschallwaffe", dauer: 8s } Szene 002: { typ: "karte", prompt: "middle east map, iran highlighted, military bases marked", overlay: null, dauer: 12s } Szene 003: { typ: "standard", prompt: "patriot missile defense system, desert, realistic photo", overlay: "Patriot-System: $3 Mio pro Abfangrakete", dauer: 10s } ... Szene 105: { typ: "hero", prompt: "world map with shifting power balance, dramatic lighting", overlay: "Die neue Weltordnung", dauer: 15s } PHASE 2 — 5 GPUs parallel (25 Min): 3090: 15 Hero-Bilder (FLUX.1-dev, beste Qualitaet) → Titel, Kapitelwechsel, Outro 3080 #0: 45 Standardbilder (SDXL) → Militaer, Politik, Wirtschaft 3080 #1: 45 Standardbilder (SDXL) → Karten, Infografiken, Symbolbilder 3080 #2: 24 Min Voiceover (XTTS v2) → deutsche Maennerstimme, professioneller Ton 3080 #3: Upscaling aller Bilder auf 1920x1080 + Untertitel-SRT aus Voiceover PHASE 3 — Assembly (15 Min): FFmpeg: 105 Szenen × Ken-Burns/Zoom + Voiceover + Ambient-Musik + Overlays Output: "irans-hyperschall-2026-03.mp4" (1080p, H.265, ~1.5 GB) Bonus: Thumbnail (Hero-Bild #1, upscaled, mit Titel-Text) YouTube-Description + Tags (aus Skript-Metadaten) ``` Gesamtzeit: **~55 Minuten** fuer ein 24-Minuten-Video. Fertig zum Hochladen. ## Hardware ### ki-tower — Hauptmaschine (Muldenstein, geplant) | Eigenschaft | Wert | |---|---| | **CPU** | AMD Ryzen 7 7700 (8C/16T) | | **RAM** | 64 GB DDR5 | | **GPU** | NVIDIA RTX 3090 (24 GB VRAM) | | **Storage** | 1 TB NVMe | | **OS** | Debian 12 + Docker + CUDA | | **Logischer Name** | ki-tower | | **Rolle** | Chef. Alle schweren Aufgaben, Orchestrierung, Hauptpfad. | ### gpu-worker — NVIDIA-Rig (Muldenstein, geplant) — PRIMAERER WORKER | Eigenschaft | Wert | |---|---| | **GPUs** | 4x NVIDIA RTX 3080 (je 10 GB GDDR6X, PCIe 4.0 x16) | | **CUDA** | Voll unterstuetzt, identischer Stack wie ki-tower | | **OS** | Debian 12 + Docker + CUDA | | **Logischer Name** | gpu-worker | | **Rolle** | Produktiver Worker-Pool. CUDA-nativ, kein Workaround noetig. | | **Vorteil** | Selber Code wie auf der 3090 — kein Portierungsaufwand. | ### gpu-reserve — AMD-Rig (Muldenstein, Reserve) | Eigenschaft | Wert | |---|---| | **GPUs** | 8x AMD RX 6600 XT Dual (je 8 GB GDDR6, PCIe 4.0 x8) | | **ROCm** | Inoffiziell (gfx1032, Workaround noetig) | | **Logischer Name** | gpu-reserve | | **Rolle** | Reserve/Nebenrolle. Nur Whisper + CPU-Batch wenn 3080-Rig ausgelastet. | | **Status** | Zurueckgestellt. Entscheidung nach 3080-Rig-Aufbau. Alternative: verkaufen. | ## Rollenverteilung — Was laeuft wo ### ki-tower (RTX 3090) — Hauptpfad | Aufgabe | Modell | VRAM | Anmerkung | |---|---|---|---| | **Skripte** | Qwen 2.5 14B (Q5) | ~12 GB | Default. 32B nur wenn 14B nachweislich nicht reicht. | | **Hauptbilder** | FLUX.1-dev | ~12 GB | Visueller Kern der Videos | | **TTS (v1)** | Piper TTS | CPU-only | Fuer v1 ausreichend, kein VRAM-Verbrauch | | **TTS (v2)** | XTTS v2 | ~4 GB | Upgrade in v2, bessere Stimme, Voice-Cloning | | **Avatar (v2)** | SadTalker | ~6 GB | Optional, erst ab v2 | | **Compositing** | FFmpeg | CPU | Ken-Burns, Ueberblendungen, Overlays | | **Encoding** | FFmpeg + NVENC | ~1 GB | Hardware-beschleunigt | | **Orchestrator** | Python | CPU | Steuert alle Schritte | Wichtig: Schritte laufen SEQUENTIELL. Nur eine schwere GPU-Aufgabe gleichzeitig. 14B statt 32B als Default — laesst 12 GB VRAM frei, kein Flush zwischen Schritten noetig. ### gpu-worker (4x RTX 3080) — Produktive Worker-Jobs | Aufgabe | VRAM | Karten | Anmerkung | |---|---|---|---| | **SDXL** (Batch-Bilder) | ~7 GB | 1-2 | CUDA-nativ, schnell, parallel moeglich | | **XTTS v2** (TTS-Batch) | ~4 GB | 1 | Voice-Cloning Batch-Produktion | | **SadTalker** (Avatar) | ~6 GB | 1 | CUDA-only, hier nativ lauffaehig | | **Whisper** (Untertitel) | ~1.5 GB | 1 | faster-whisper mit CUDA | | **Real-ESRGAN** (Upscaling) | ~2 GB | 1 | 4K-Upscale fuer Thumbnails/Szenen | | **Kleine LLMs** (7-10B) | ~8 GB | 1 | Hilfs-LLM fuer Zusammenfassungen, Tags | | **Embeddings** | ~1 GB | 1 | Fuer Jarvis/RAG, nicht Video-Pipeline | Kernvorteil: Identischer CUDA-Stack wie ki-tower. Code einmal schreiben, ueberall deployen. 4 Karten = 4 parallele Jobs moeglich. Einschalten wenn Batch-Jobs anstehen. ### gpu-reserve (8x RX 6600 XT) — Reserve/Nebenrolle | Aufgabe | VRAM | Karten | Anmerkung | |---|---|---|---| | **Whisper** (whisper.cpp) | ~1.5 GB | 1-2 | Einziger gut getesteter AMD-Usecase | | **CPU-Batch-Jobs** | — | — | Piper TTS, FFmpeg, Text-Vorverarbeitung | Realistisch nutzbar: 1-2 Karten fuer Whisper, Rest bringt kaum Mehrwert. Empfehlung: Erst aufbauen wenn 3080-Rig voll ausgelastet. Alternative: verkaufen. ### NICHT auf das AMD-Rig | Aufgabe | Warum nicht | |---|---| | SDXL / Bildgenerierung | ROCm inoffiziell, CUDA-Version laeuft auf 3080 besser | | XTTS v2 | PyTorch + ROCm ungetestet, auf 3080 CUDA-nativ | | SadTalker | CUDA-only | | Qwen / LLMs | PyTorch + ROCm + Textgen = Frust auf inoffizieller HW | | Irgendwas Produktionskritisches | Workaround-basierte HW darf Produktion nicht blockieren | ## Hardware-Priorisierung: 3080 vs. 6600 XT **Klare Rangfolge:** | Rang | Hardware | Rolle | Begruendung | |---|---|---|---| | 1 | **RTX 3090** (ki-tower) | Chef | 24 GB VRAM, schwere Modelle, Orchestrierung | | 2 | **4x RTX 3080** (gpu-worker) | Produktiver Worker | CUDA-nativ = selber Code wie ki-tower. 10 GB VRAM pro Karte reicht fuer SDXL, XTTS, SadTalker, Whisper. Kein Portierungsaufwand. | | 3 | **8x RX 6600 XT** (gpu-reserve) | Reserve / ggf. verkaufen | ROCm inoffiziell. Jeder Usecase, den die 6600 XT kann, kann die 3080 besser + einfacher. Einziger Vorteil: Kartenanzahl fuer massiv-paralleles Whisper. Realistisch nicht gebraucht. | **Warum 4x 3080 > 8x 6600 XT:** - Gleicher Software-Stack wie ki-tower (CUDA). Code einmal schreiben, ueberall deployen. - 10 GB VRAM vs. 8 GB VRAM. Klingt wenig, macht bei SDXL/SadTalker den Unterschied. - PyTorch + CUDA ist getestet, stabil, dokumentiert. ROCm auf Navi 23 ist Kampf. - Weniger Karten = weniger Strom, weniger Kuehlung, weniger moegliche Fehlerquellen. - 4 parallele CUDA-Worker decken den gesamten Bedarf ab. **Empfehlung AMD-Rig:** Nicht aktiv aufbauen. Falls 3080-Rig irgendwann an Kapazitaetsgrenzen stoesst: 1-Karten-Test mit Whisper. Wenn selbst das nicht lohnt: verkaufen und in NVMe-Storage oder RAM investieren. ## Worker-Architektur ``` ki-tower (3090, Chef) gpu-worker (4x 3080, Worker) gpu-reserve (RX 6600 XT) ┌─────────────────────────┐ ┌──────────────────────────────┐ ┌──────────────────┐ │ Orchestrator (Python) │ │ Debian 12 + Docker + CUDA │ │ Reserve/Whisper │ │ ├── Job Queue (SQLite) │ Tailscale │ │ │ ├── /api/submit-job │◄────────────►│ GPU #0: sdxl-worker :8501 │ │ Whisper :8601 │ │ ├── /api/job-status │ │ GPU #1: xtts-worker :8502 │ │ CPU-Batch :8602 │ │ └── /api/get-result │ Tailscale │ GPU #2: sadtalker :8503 │ │ (nur bei Bedarf)│ │ │ │ GPU #3: whisper/embed :8504 │ └──────────────────┘ │ Qwen 14B (vLLM) :8401 │ │ │ │ FLUX.1 (ComfyUI):8402 │ │ 10 GB VRAM pro Karte │ │ FFmpeg (lokal) │ │ CUDA-nativ, kein Workaround │ └─────────────────────────┘ └──────────────────────────────┘ ``` Prinzipien: - 1 Container = 1 GPU = 1 Aufgabe. Feste Zuordnung, kein dynamisches Scheduling. - SQLite als Job-Queue. Ein User, nicht tausend. Eine Datei reicht. - HTTP-APIs pro Worker. Orchestrator ruft per REST auf, pollt Status. - Kein Service-Mesh, kein Kubernetes. Tailscale verbindet die zwei Maschinen. ## VRAM-Budget (ki-tower, sequentiell) ``` Schritt 1: Skript → Qwen 14B → ~12 GB VRAM Schritt 2: Bilder → FLUX.1-dev → ~12 GB VRAM Schritt 3: TTS → Piper (CPU) → 0 GB VRAM Schritt 4: Compositing → FFmpeg (CPU) → 0 GB VRAM Schritt 5: Encoding → NVENC → ~1 GB VRAM ``` Mit Qwen 14B statt 32B: kein VRAM-Flush zwischen Schritt 1 und 2 noetig. Geschaetzte Produktionszeit: - v1 (nur ki-tower, seriell): ~2-3 Stunden pro 10-Min-Video - v1.5 (5 GPUs parallel): ~55 Min pro 20-Min-Video - Langfristig mit Optimierung: ~40 Min pro 20-Min-Video ## Nicht-Ziele - Kein Forschungsprojekt - Keine Bastelwiese ohne Ergebnis - Keine Dauerabhaengigkeit von Cloud-Abos - Keine Architektur die nur auf dem Papier funktioniert - Kein sofortiger Avatar als Kernbestandteil - Keine ueberkomplizierte Proxmox-/VM-Orgie auf dem Rig - Kein Schoenreden von AMD-ROCm-Limitierungen ## v1 — Minimal Viable Pipeline (nur ki-tower) v1 beweist: die Pipeline funktioniert auf einer Maschine. Schritte manuell anstossen. ``` v1 Pipeline (alles auf ki-tower, seriell): Thema (manuell) │ ▼ Qwen 14B → Skript + Szenenplan (vLLM, :8401) │ ▼ FLUX.1-dev → 30-50 Bilder (ComfyUI, :8402) ← seriell, ~30-45 Min │ ▼ Piper TTS → Voiceover (CPU, :8504) ← parallel moeglich │ ▼ FFmpeg → Ken-Burns + Audio + Overlays → fertiges MP4 ``` Was v1 NICHT hat: - Kein 3080 Worker-Rig (alles seriell auf 3090) - Keinen Avatar - Keine XTTS v2 (Piper reicht fuer v1) - Keine automatische Orchestrierung - Geschaetzte Produktionszeit: ~2-3 Stunden pro 10-Min-Video Erfolgskriterium v1: Ein 10-Minuten-Video komplett lokal produziert. ## v1.5 — 5-GPU-Parallelisierung (ki-tower + 3080-Rig) v1.5 ist der grosse Sprung: **5 GPUs parallel = 3-4x schneller.** ``` v1.5 Pipeline (5 GPUs parallel): Thema (manuell) │ ▼ Qwen 14B → Skript + Szenenplan JSON (ki-tower) │ ▼ Orchestrator verteilt Jobs an alle 5 GPUs gleichzeitig: ├── 3090: FLUX.1-dev → Hero-Bilder (beste Qualitaet) ├── 3080 #0: SDXL → Standard-Szenen Batch A ├── 3080 #1: SDXL → Standard-Szenen Batch B ├── 3080 #2: XTTS v2 → deutsches Voiceover └── 3080 #3: Real-ESRGAN → Upscaling + Whisper → Untertitel │ ▼ FFmpeg → Assembly (Ken-Burns + Audio + Overlays + Untertitel) │ ▼ NVENC → Export MP4 + Thumbnail + YouTube-Metadaten ``` Was v1.5 bringt: - Produktionszeit: ~55 Min statt ~3 Stunden fuer 20-Min-Video - XTTS v2 statt Piper (natuerlichere Stimme) - Automatische Untertitel - 4K-Upscaling fuer Thumbnails - Orchestrator-Script verteilt und sammelt automatisch Erfolgskriterium v1.5: 20-Min-Video in unter 1 Stunde produziert. ## v2 — Erweiterungen (nach funktionierender v1) | Feature | Abhaengigkeit | |---|---| | **XTTS v2** statt Piper | Auf ki-tower (3090) oder 3080-Worker | | **SadTalker Avatar** | Auf 3080-Worker (6 GB VRAM reicht) | | **3080 Worker-Rig** | Aufbau parallel zu v1, CUDA-Stack identisch | | **Python-Orchestrator** | Erst manuell verstehen, dann automatisieren | | **SDXL-Batch auf 3080** | Nebenbilder parallel generieren | | **Qwen 32B** statt 14B | Nur wenn 14B-Skripte nachweislich zu schwach | ## v3+ — Spaeter | Feature | Anmerkung | |---|---| | YouTube-Upload-Automation | Manueller Upload = 2 Klicks. Lohnt erst bei >3 Videos/Woche | | Multi-User / geklonte Instanzen | Erst ein funktionierendes Produkt haben | | Prompt-Templates Bibliothek | Waechst organisch mit der Produktion | | Research-Hub-Integration | Themenvorschlaege automatisch aus RSS/News | ## Umsetzungsreihenfolge ``` PHASE 1 — ki-tower Grundinstallation (Woche 1-2) ├── Debian 12 + NVIDIA-Treiber + CUDA 12 + Docker ├── vLLM + Qwen 2.5 14B → erster Skript-Test └── Ergebnis: "Ich kann lokal ein Skript generieren" PHASE 2 — Bildgenerierung (Woche 3-4) ├── ComfyUI + FLUX.1-dev in Docker ├── Workflow: Skript-Szene → Bildprompt → Bild └── Ergebnis: "Ich kann passende Bilder zu einem Skript erzeugen" PHASE 3 — TTS + Assembly (Woche 5) ├── Piper TTS in Docker (CPU) ├── FFmpeg-Pipeline: Bilder + Audio → Video mit Ken-Burns └── Ergebnis: "Erstes komplettes Video, lokal produziert" PHASE 4 — Polieren + erstes echtes Video (Woche 6) ├── Prompt-Templates fuer Skripte verfeinern ├── FFmpeg-Presets fuer verschiedene Szenentypen ├── Erstes Video auf YouTube hochladen └── Ergebnis: "v1 steht und produziert" PHASE 5 — 3080-Rig Aufbau + v1.5 (Woche 7-9) ├── Debian 12 + NVIDIA-Treiber + CUDA + Docker (selber Stack wie ki-tower) ├── 4 Worker: SDXL #0, SDXL #1, XTTS v2, ESRGAN/Whisper ├── Tailscale + Job-API anbinden ├── Python-Orchestrator: Szenenplan → Jobs verteilen → sammeln ├── XTTS v2 statt Piper (bessere Stimme) └── Ergebnis: "20-Min-Video in unter 1 Stunde, 5 GPUs parallel" PHASE 6 — v2 Features (nach stabiler v1.5-Produktion) ├── SadTalker Avatar auf 3080-Worker (optional pro Video) ├── Automatische Thumbnail-Generierung (FLUX hero + Text-Overlay) ├── YouTube-Metadaten-Generator (Titel, Description, Tags aus Skript) ├── Batch-Produktion: mehrere Videos in Queue └── Ergebnis: "Semi-automatische Videoproduktion mit Worker-Pool" PHASE 7 — AMD-Rig Entscheidung (optional, spaeter) ├── Bewertung ob 3080-Rig Kapazitaet reicht ├── Falls nicht: 1-Karten-Test mit RX 6600 XT + Whisper ├── Falls ja: AMD-Rig verkaufen, Erloese in Storage investieren └── Ergebnis: "Klare Entscheidung ueber AMD-Hardware" ``` ## Entscheidungen (getroffen) | Frage | Entscheidung | Begruendung | |---|---|---| | OS ki-tower | **Debian 12** | Einfacher fuer GPU, Docker, kein Hypervisor-Overhead | | OS gpu-worker | **Debian 12** | Identisch mit ki-tower, CUDA-nativ, kein Sonderweg | | Worker-Rig | **4x RTX 3080** | CUDA-nativ > 8x RX 6600 XT mit ROCm-Workarounds | | LLM-Modell | **Qwen 14B** (Default) | 12 GB VRAM, laesst Platz. 32B nur als Upgrade. | | LLM-Server | **vLLM** | Schneller als llama.cpp bei Batch, Model-Unloading | | Bildgenerierung | **ComfyUI + FLUX.1-dev** | Flexibel, Workflow-basiert, gute Qualitaet | | TTS v1 | **Piper TTS** (CPU) | Kein GPU-Verbrauch, sofort einsatzbereit | | TTS v2 | **XTTS v2** (3090 oder 3080) | Voice-Cloning, natuerlichere Stimme. 4 GB VRAM, passt auf 3080. | | Avatar | **Nicht in v1** | Nice-to-have, nicht Kernprodukt | | Job-Queue | **SQLite** | Ein User, kein Redis/RabbitMQ noetig | | Netzwerk | **Tailscale** | Verbindet ki-tower + gpu-worker, fertig | ## Risiken | # | Risiko | Wahrscheinlichkeit | Impact | Mitigation | |---|---|---|---|---| | 1 | **ROCm auf RX 6600 XT instabil** | Hoch | **Niedrig** | Betrifft nur Reserve-Rig. 3080-Worker ist CUDA-nativ. | | 2 | **Piper TTS deutsch zu robotisch** | Mittel | Hoch | Testen. Wenn zu schlecht: OpenAI TTS als Bruecke (~0.50 EUR/Video). XTTS in v2. | | 3 | **VRAM-Tetris auf 3090** | Mittel | Mittel | 14B statt 32B. Sequentiell. vLLM Model-Unloading. | | 4 | **Pipeline wird zu komplex vor v1** | Hoch | Hoch | v1 brutal einfach. Bash-Scripts, keine Frameworks. | | 5 | **Stromkosten Rig vs. Nutzen** | Mittel | Niedrig | 3080-Rig nur bei Batch-Jobs einschalten. AMD-Rig im Zweifel verkaufen. | ## Kosten-Schaetzung | Posten | Einmalig | Monatlich | |---|---|---| | ki-tower Hardware | vorhanden | — | | gpu-worker Hardware | vorhanden | — | | Strom ki-tower (24/7) | — | ~30-40 EUR | | Strom gpu-worker (bei Bedarf) | — | ~10-30 EUR (nicht 24/7) | | Cloud-APIs (Fallback TTS) | — | ~5-10 EUR | | **Gesamt** | 0 EUR | ~45-80 EUR | Zum Vergleich: Vollstaendig cloud-basierte Videoproduktion (Runway, ElevenLabs, GPT-4) = 100-300 EUR/Monat.