14 KiB
14 KiB
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
| Eigenschaft | Beschreibung |
|---|---|
| Typ | Commentary, Erklaervideos, Meinungs-/Analyseformate |
| Stil | Sprecherstimme + Bilder + leichte Bewegung + Einblendungen |
| Optional | Sprechender Avatar (SadTalker) — erst ab v2 |
| Nicht | Realfilm, Hollywood-VFX, aufwendige 3D-Animation |
Pipeline
1. Themenfindung / Recherche (manuell)
│
2. Skript-Erstellung → Qwen 14B (ki-tower)
│
3. Bildgenerierung → FLUX.1-dev (ki-tower)
│
4. Voiceover → Piper TTS (CPU, ki-tower)
│
5. Compositing → FFmpeg + Ken-Burns (CPU, ki-tower)
│
6. Encoding → FFmpeg + NVENC (ki-tower)
│
7. Export → fertiges MP4 fuer YouTube
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: ~1-2 Stunden pro 10-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. Kein Rig, kein Avatar, keine Automatisierung.
v1 Pipeline (alles auf ki-tower):
Thema (manuell)
│
▼
Qwen 14B → Skript (vLLM, :8401)
│
▼
FLUX.1-dev → 20-30 Bilder (ComfyUI, :8402)
│
▼
Piper TTS → Voiceover (CPU, :8504)
│
▼
FFmpeg → Ken-Burns + Audio + Overlays → fertiges MP4
Was v1 NICHT hat:
- Keinen Avatar
- Kein GPU-Worker-Rig
- Keine automatische Orchestrierung (Schritte manuell anstossen)
- Keinen YouTube-Upload
- Keine XTTS v2 (Piper reicht fuer v1)
Erfolgskriterium v1: Ein 10-Minuten-Video komplett lokal 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 (Woche 7-8, parallel moeglich)
├── Debian 12 + NVIDIA-Treiber + CUDA + Docker (selber Stack wie ki-tower)
├── SDXL-Worker, Whisper-Worker, XTTS-Worker aufsetzen
├── Tailscale + Job-API anbinden
└── Ergebnis: "4 parallele CUDA-Worker laufen"
PHASE 6 — v2 Features (nach stabiler Produktion)
├── XTTS v2 auf 3080-Worker (bessere Stimme, Batch)
├── SadTalker Avatar auf 3080-Worker
├── Python-Orchestrator (automatische Verkettung)
└── 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.