KI-Video — Lokale Produktionspipeline
Stand: 16.03.2026
Ziel
Lokale, weitgehend automatisierte Produktionsstrecke fuer YouTube-Videos im Commentary-/Erklaerstil.
Kein Spielzeug-Demo, sondern eine praktisch nutzbare Pipeline: Thema rein → fertiges Video raus.
Videoformat
| Eigenschaft |
Beschreibung |
| Typ |
Commentary, Erklaervideos, Meinungs-/Analyseformate |
| Stil |
Sprecherstimme + Bilder + leichte Bewegung + Einblendungen |
| Optional |
Sprechender Avatar (SadTalker) |
| Nicht |
Realfilm, Hollywood-VFX, aufwendige 3D-Animation |
| Vorbild |
Kanaele mit klarer Erzaehlung, guter Struktur, visueller Unterstuetzung |
Pipeline-Schritte
1. Themenfindung / Recherche
│
2. Skript-Erstellung (lokales LLM)
│
3. Bildgenerierung (Szenen / Illustrationen)
│
4. Sprachausgabe / Voiceover (TTS)
│
5. Optional: Avatar / sprechendes Gesicht
│
6. Zusammenschnitt + Ken-Burns + Compositing
│
7. Export fuer YouTube
Geplante Komponenten
Textgenerierung (Skripte)
| Komponente |
Modell |
VRAM |
Anmerkung |
| Skript-LLM |
Qwen 2.5 32B (Q4_K_M) |
~20 GB |
Passt auf RTX 3090 (24 GB), eng aber machbar |
| Alternative |
Qwen 2.5 14B (Q5) |
~12 GB |
Komfortabler, laesst Platz fuer andere Tasks |
| Fallback |
Qwen 2.5 7B |
~6 GB |
Fuer Entwuerfe/Vorarbeit, parallel moeglich |
Realistisch: 32B fuer finale Skripte, 7B/14B fuer Brainstorming und Iteration.
32B belegt fast den gesamten VRAM — andere GPU-Tasks muessen warten.
Bildgenerierung
| Komponente |
Modell |
VRAM |
Anmerkung |
| Bilder |
FLUX.1-dev |
~12 GB |
Gute Qualitaet, laeuft auf RTX 3090 |
| Alternative |
SDXL |
~7 GB |
Weniger VRAM, mehr Flexibilitaet |
| Upscaling |
Real-ESRGAN |
~2 GB |
Nachschaerfung auf 4K |
FLUX.1-dev liefert bessere Qualitaet als SDXL, braucht aber mehr VRAM.
Kann NICHT gleichzeitig mit Qwen 32B laufen — sequentiell.
Sprachausgabe (TTS)
| Komponente |
Modell |
VRAM |
Anmerkung |
| TTS |
XTTS v2 (Coqui) |
~2-4 GB |
Deutsche Stimme, Voice-Cloning moeglich |
| Alternative |
Piper TTS |
CPU-only |
Schneller, weniger natuerlich |
| Fallback |
OpenAI TTS API |
— |
Beste Qualitaet, kostet Geld |
XTTS v2 ist der beste Kompromiss: lokal, deutsch, Stimme klonbar.
Kann auf GPU oder CPU laufen. Bei GPU: parallel zu leichteren Tasks moeglich.
Avatar (optional)
| Komponente |
Modell |
VRAM |
Anmerkung |
| Talking Head |
SadTalker |
~4-6 GB |
Foto + Audio → sprechendes Gesicht |
| Alternative |
Wav2Lip |
~2 GB |
Einfacher, weniger natuerlich |
| Zukunft |
LivePortrait / EMO |
variabel |
Bessere Qualitaet, noch nicht stabil |
SadTalker ist ausgereift und braucht wenig VRAM.
Input: 1 Foto + 1 Audiodatei → Video mit Lippensync.
Video-Compositing
| Komponente |
Tool |
GPU? |
Anmerkung |
| Schnitt |
FFmpeg |
Nein (CPU) |
Ken-Burns, Ueberblendungen, Text-Overlays |
| Sequenzierung |
Python + moviepy |
Nein |
Szenen zusammenfuegen |
| Encoding |
FFmpeg + NVENC |
Optional |
GPU-beschleunigtes Encoding |
| Untertitel |
Whisper + FFmpeg |
~1.5 GB |
Automatische Untertitel |
FFmpeg ist das Rueckgrat — robust, scriptbar, keine GPU noetig fuer die meisten Operationen.
NVENC (RTX 3090) fuer schnelles Encoding im letzten Schritt.
Hardware
Hauptmaschine: ki-tower (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 oder Proxmox (noch offen) |
| Logischer Name |
ki-tower |
Unterstuetzung: gpu-worker (Mining-Rig, Muldenstein, geplant)
| Eigenschaft |
Wert |
| GPUs |
Mehrere AMD RX 6600 XT (je 8 GB VRAM) |
| Funktion |
Worker-Pool fuer leichtere Pipeline-Schritte |
| Geeignet fuer |
Upscaling, TTS, Whisper, Batch-Bildgenerierung (SDXL) |
| Nicht geeignet fuer |
Qwen 32B, FLUX.1-dev, SadTalker auf hoher Qualitaet |
| ROCm |
Inoffiziell (gfx1032), 1-Karten-Test steht aus |
Arbeitsteilung
ki-tower (RTX 3090, 24 GB) gpu-worker (RX 6600 XT, je 8 GB)
├── Qwen 32B (Skripte) ├── SDXL Batch (Nebenbilder)
├── FLUX.1-dev (Hauptbilder) ├── Real-ESRGAN (Upscaling)
├── SadTalker (Avatar) ├── XTTS v2 / Piper (TTS)
├── FFmpeg + NVENC (Finaler Render) ├── Whisper (Untertitel)
└── Orchestrierung └── Vorverarbeitung
VRAM-Budget pro Pipeline-Schritt (RTX 3090)
Die Schritte laufen SEQUENTIELL, nicht parallel — nur eine schwere Aufgabe gleichzeitig:
Schritt 1: Skript → Qwen 32B → ~20 GB VRAM → entladen
Schritt 2: Bilder → FLUX.1-dev → ~12 GB VRAM → entladen
Schritt 3: TTS → XTTS v2 → ~4 GB VRAM → entladen
Schritt 4: Avatar → SadTalker → ~6 GB VRAM → entladen
Schritt 5: Compositing → FFmpeg (CPU) → 0 GB VRAM
Schritt 6: Encoding → NVENC → ~1 GB VRAM
Gesamtzeit pro Video (geschaetzt, 10 Min Video):
- Skript: 5-15 Min
- Bilder (20-30 Stueck): 20-40 Min
- TTS: 5-10 Min
- Avatar: 10-20 Min
- Compositing: 5-10 Min
- Encoding: 2-5 Min
- Gesamt: ca. 1-2 Stunden pro 10-Min-Video
Architektur
Orchestrator (Python)
├── /scripts/ → Skript-Generierung (Qwen via llama.cpp / vLLM)
├── /images/ → Bild-Generierung (ComfyUI / FLUX)
├── /audio/ → TTS (XTTS v2 Server)
├── /avatar/ → Talking Head (SadTalker)
├── /compose/ → Video-Assembly (FFmpeg + moviepy)
├── /export/ → Finaler Render + Upload-Vorbereitung
└── /projects/ → Pro Video ein Projektordner mit allen Assets
Jeder Schritt ist ein eigener Service/Container:
- Kann einzeln gestartet/gestoppt werden
- Belegt VRAM nur wenn aktiv
- Austauschbar (z.B. FLUX → SDXL, XTTS → Piper)
Nicht-Ziele
- Kein Forschungsprojekt
- Keine Bastelwiese ohne Ergebnis
- Keine Dauerabhaengigkeit von Cloud-Abos
- Keine Architektur die nur auf dem Papier funktioniert
- Kein Hollywood-Kino
Stufenplan
Stufe 1 — Grundlagen (ki-tower aufbauen)
| Was |
Status |
| ki-tower Hardware zusammenbauen |
geplant |
| Debian 12 + NVIDIA-Treiber + CUDA + Docker |
geplant |
| llama.cpp / vLLM mit Qwen 2.5 installieren |
geplant |
| Erster Skript-Test: Thema → strukturiertes Skript |
geplant |
Stufe 2 — Bilder + TTS
| Was |
Status |
| ComfyUI + FLUX.1-dev installieren |
geplant |
| XTTS v2 Server aufsetzen (Docker) |
geplant |
| Test: Skript → passende Bilder + Voiceover |
geplant |
Stufe 3 — Avatar + Compositing
| Was |
Status |
| SadTalker installieren |
geplant |
| FFmpeg-Pipeline: Bilder + Audio + Avatar → Video |
geplant |
| Erster kompletter Durchlauf: Thema → fertiges Video |
geplant |
Stufe 4 — Orchestrierung + Automatisierung
| Was |
Status |
| Python-Orchestrator: alle Schritte verkettet |
geplant |
| Projektordner-Struktur (Assets pro Video) |
geplant |
| GPU-Worker-Integration (falls ROCm-Test erfolgreich) |
geplant |
Stufe 5 — Produktion + Optimierung
| Was |
Status |
| Regelmaessige Videoproduktion (1-2 pro Woche) |
geplant |
| Prompt-Templates fuer verschiedene Videoformate |
geplant |
| Qualitaetskontrolle + Feedback-Loop |
geplant |
| Optional: Semi-automatischer YouTube-Upload |
geplant |
Offene Entscheidungen
| Frage |
Optionen |
Tendenz |
| OS fuer ki-tower |
Debian 12 vs Proxmox |
Debian (einfacher fuer GPU) |
| LLM-Server |
llama.cpp vs vLLM vs Ollama |
vLLM (schneller bei Batch) |
| Bild-UI |
ComfyUI vs API-only |
ComfyUI (flexibler, Workflows) |
| TTS Sprache |
Deutsch-only vs Multi |
Deutsch zuerst, Englisch spaeter |
| Avatar ja/nein |
Immer vs nur bei manchen Videos |
Optional pro Video |
Risiken
| Risiko |
Schwere |
Mitigation |
| VRAM-Engpass bei 32B + Bildern |
Mittel |
Sequentiell arbeiten, 14B als Alternative |
| TTS-Qualitaet Deutsch |
Mittel |
XTTS v2 Voice-Cloning testen, Fallback OpenAI |
| Avatar wirkt unnatuerlich |
Niedrig |
Avatar nur optional, kann weggelassen werden |
| Pipeline zu komplex |
Mittel |
Stufe fuer Stufe, jeder Schritt einzeln testbar |
| GPU-Worker ROCm-Probleme |
Mittel |
1-Karten-Test, Fallback: alles auf ki-tower |
