8.2 KiB
Wan2.2/ComfyUI Video-Pipeline Speedup — Worker A (Video-Speed), 2026-07-23
Ergebnis in einem Satz
--highvram Flag auf ComfyUI (VM302, A40) gesetzt → 4,3x schnellere Wan2.2-Renderzeit, echt gemessen, kein API/Cloud, keine Störung von #17-Lipsync oder Studio-Jobs.
Root Cause (gefunden per GPU-Monitoring)
Referenz-Workflow (Wan2.2 I2V, 512x896, 49 Frames, GGUF Q5_K_M HighNoise+LowNoise, Lightning-4step-LoRA, cfg=1.0) lief unter ComfyUIs Default-VRAM-Modus (Dynamic VRAM) mit nur 16,8% durchschnittlicher GPU-Auslastung — 216 von 739 Sekunden lag die A40 komplett brach (<10% Util). Peak-VRAM lag bei 44,77GB von 46,07GB — direkt an der Kante. Ursache: die zwei ~10,8GB-GGUF-Experten (HighNoise/LowNoise) plus CLIP (umt5-xxl fp8, ~9GB) drängen sich knapp unter die VRAM-Grenze; ComfyUIs Default-Speichermanagement lädt/entlädt (swapt) dabei wiederholt zwischen CPU-RAM und GPU — sichtbar im rohen ComfyUI-Log als Einzel-Sampling-Batch, der 10:17 Minuten für 8 Schritte brauchte (77s/it statt ~1s/it).
Fix
--highvram zum ComfyUI-Start hinzugefügt (hält beide Experten + CLIP dauerhaft im VRAM, kein
Swap-Zyklus mehr). Datei M:\start-comfyui-task.ps1, Backup vorher: M:\start-comfyui-task.ps1.bak-speedwork-20260723-145410
(MD5 identisch zum Original vor Änderung, verifiziert). ComfyUI-Server-Aufgabe kontrolliert neu gestartet
(Queue vorher leer geprüft, kein laufender Job unterbrochen), /system_stats danach grün, argv bestätigt
--highvram aktiv.
Messung (echter Referenz-Clip, gleiche Auflösung/Länge/Steps, gleicher Prompt, A/B auf derselben A40)
| Lauf | Bedingung | Wallclock | Ø GPU-Util | Peak-VRAM | Idle-Zeit (<10% Util) |
|---|---|---|---|---|---|
| baseline_default | Default Dynamic-VRAM (vorher) | 739,4s | 16,8% | 44,77GB | 216s |
| highvram_run1 | --highvram, Modelle noch kalt (1. Load nach Neustart) |
270,7s (2,7x) | 25,2% | 39,10GB | 92s |
| highvram_run3_warm (anderer Seed, keine Node-Cache-Abkürzung) | --highvram, Modelle bereits warm im VRAM |
171,8s (4,3x schneller) | 42,2% | 38,94GB | 20s |
(Ein Zwischenlauf mit identischem Seed lief in 5,4s durch — das war ComfyUIs Node-Result-Cache [identischer Prompt+Seed+Input], keine echte Neuberechnung. Deshalb Kontrollmessung mit anderem Seed gemacht — die 171,8s sind der belastbare "warm+echte Neuberechnung"-Wert.)
Output-Videos aller Läufe liegen auf B:\comfyui-output\bench_*_00001.mp4 (512x896, 16fps, 3,06s,
h264), per ffprobe verifiziert — alle vier Läufe valide, gleiche Auflösung/Dauer, fairer Vergleich.
Warum das die "Modell-Preload/warm-halten"-Anforderung erfüllt
--highvram ist exakt der ComfyUI-native Weg für "Modelle warm halten": ohne Flag entlädt ComfyUI
Modelle standardmäßig nach jeder Nutzung ins CPU-RAM (und bei VRAM-Druck kommt es zum beobachteten
Thrashing). Mit dem Flag bleiben beide 10,8GB-GGUF-Experten + CLIP + VAE dauerhaft auf der A40 —
jeder Folge-Job (Studio, #17-Pipeline) profitiert automatisch ohne Codeänderung an den Workflows.
Trade-off / Risiko (ehrlich dokumentiert)
Mit --highvram gibt ComfyUI belegtes VRAM nicht mehr proaktiv frei. Bei Peak-Last bleiben ca. 6-7GB
VRAM-Headroom (46,07GB total − 39GB Peak) für parallel laufende Prozesse (z.B. GFPGAN/RealESRGAN-Venv,
die separat vom ComfyUI-Prozess läuft, teilt sich aber dieselbe GPU). Sollte in Zukunft ein zweiter
schwerer GPU-Job gleichzeitig mit einer Wan2.2-Generierung laufen, ist ein OOM theoretisch möglich —
bisher (Queue-Betrieb, ein Job nach dem anderen) nicht aufgetreten. Rückweg: Flag aus
start-comfyui-task.ps1 entfernen (Backup vorhanden) + Task neu starten.
Geprüft: laufende Pipeline nicht gestört
- Queue vor UND nach dem ComfyUI-Neustart leer (
/queueGET), kein Job unterbrochen. - Kein VM302-Reboot, nur ComfyUI-Prozess (Scheduled Task
ComfyUI-Server) neu gestartet — Bär-Guardrail eingehalten. #17-Skripte (pipe_02_wan.py,pipe_02_wan_fast.py,pipe_03_lipsync.py,pipe_04_restore_mux.py,pipe_05_interpolate.py) selbst nicht verändert — der Speedup wirkt rein über den Server-Start-Flag, keine Workflow-JSON-Änderung nötig.- py_compile: n/a (PowerShell-Skript, keine .py-Änderung); Backup + MD5-Vergleich stattdessen als Rückweg-Beleg.
Zusätzlich geprüft, NICHT umgesetzt (Risiko/Aufwand > Nutzen heute)
SageAttention 2.2 + TeaCache (Deep-Research: Civitai/Medium/InstaSD/DigitalCreativeAI-Artikel,
Stand 2026): dokumentierte 30-54% zusätzliche Speedups auf Wan2.1/2.2 in ComfyUI via
"Patch Sage Attention KJ"-Node (ComfyUI-KJNodes) vor den ModelSamplingSD3-Nodes. Nicht installiert,
weil: triton und sageattention fehlen auf VM302 komplett (ModuleNotFoundError), Windows-Build von
sageattention ist notorisch fragil (passende CUDA/Torch/Triton-Wheel-Kombination nötig, oft Kompilieren
aus Source) — echtes Risiko, die produktive venv zu zerschießen. Empfehlung: in einer isolierten
Kopien-venv testen, nicht in der laufenden ComfyUI-Instanz. TeaCache selbst (Kein Compile-Zwang) ist
risikoärmer und könnte als nächster Schritt separat getestet werden.
torch.compile: nicht getestet mit GGUF-quantisierten UNet-Gewichten (dequantisieren pro Layer at runtime) — unklare Kompatibilität, hohes Rest-Risiko für Compile-Fehler mitten im Studio-Betrieb, verschoben.
ffmpeg NVENC (h264_nvenc) statt CPU libx264 -preset slow: in pipe_04_restore_mux.py und
pipe_05_interpolate.py wird aktuell CPU-Encoding mit -preset slow genutzt. NVENC ist auf der
ffmpeg-Binary bereits verfügbar (ffmpeg -encoders | grep nvenc → h264_nvenc/hevc_nvenc/av1_nvenc
vorhanden), aber nicht umgesetzt, weil diese beiden Skripte Teil der aktiven #17-Pipeline sind und
laut Auftrag nicht angefasst werden sollten ohne vollständigen End-to-End-Test der laufenden Kette.
Empfehlung als nächster separater Schritt (klar abgegrenzt, mit eigenem A/B-Beleg).
LatentSync als MuseTalk-Alternative (Deep-Research, r/StableDiffusion / lipsync.com-Vergleich 2026): arbeitet im Latent-Raum statt Pixel-Raum, dadurch potenziell schneller + robustere Identität als MuseTalk. Nicht getestet (würde die aktive Lipsync-Pipeline direkt ersetzen) — als Folgeauftrag vorschlagen, NICHT selbst als Ersatz eingebaut, um #17 nicht zu gefährden.
Bereits vorhandene Optimierungen (von früherer Session, bestätigt aktiv)
Fastpath-Workflow (pipe_02_wan_fast.py) nutzt bereits: GGUF Q5_K_M-Quantisierung (statt fp16/fp8-Volltensor),
Lightning-4-step-LoRA (4 Steps statt 20), cfg=1.0 (distilled, keine negative Guidance nötig),
512x896 Auflösung mit nachgelagertem Real-ESRGAN-4x-Upscale statt nativ in HD zu rendern. Diese Kombination
allein bringt bereits ~5x weniger Sampling-Rechenaufwand gegenüber dem HD-20-Step-Pfad
(pipe_02_wan.py, 720x1280x81f x20 Steps) — das --highvram-Fix multipliziert zusätzlich mit 2,7-4,3x
oben drauf, weil die vorherigen Zahlen alle noch unter dem VRAM-Thrashing gelitten hatten.
Belege / Dateien
- Backup Start-Skript:
M:\start-comfyui-task.ps1.bak-speedwork-20260723-145410 - Geänderte Datei:
M:\start-comfyui-task.ps1(+--highvram) - Benchmark-Skript:
bench_wan.py/bench_wan_seed2.py(Scratchpad, auf Anfrage nachreichbar) - Rohdaten GPU-Sampling:
gpu_baseline_default.log,gpu_highvram_run1.log,gpu_highvram_run3_warm_newseed.log(Scratchpad) - Output-Videos:
B:\comfyui-output\bench_baseline_default_00001.mp4,bench_highvram_run1_00001.mp4,bench_highvram_run3_warm_newseed_00001.mp4— alle per ffprobe verifiziert (512x896, 16fps, 3,06s, h264) - Frühere Referenz-Logs (bereits vor diesem Fix vorhanden, bestätigen dieselbe Diagnose):
B:\barby\wan_gpu_monitor.log,B:\barby\wan_fastpath_timing.log
Empfehlung an Bär / nächste Schritte
- [BÄR-ENTSCHEIDUNG offen] SageAttention/TeaCache in isolierter Test-venv ausprobieren (nicht in Produktion) — potenziell weitere 30-50%.
- NVENC-Encode in pipe_04/pipe_05 als eigener, sauber getesteter Folgeauftrag (nicht heute, um #17 nicht zu riskieren).
- LatentSync als MuseTalk-Ersatz separat evaluieren (Qualität + Geschwindigkeit vergleichen), bevor produktiv getauscht wird.
--highvram-Trade-off im Auge behalten: falls künftig zwei schwere GPU-Jobs parallel laufen sollen (nicht nur Queue), VRAM-Headroom (~6-7GB) neu bewerten.
— Worker A (Video-Speed), VM302/A40, 2026-07-23