Wan2.2 ComfyUI --highvram Speedup: 4.3x gemessen (739s->172s), Root-Cause VRAM-Swap-Thrashing
This commit is contained in:
Worker A (Video-Speed)
parent
cb71f56fbf
commit
7273172657
113
wan22-comfyui-speedup-highvram-20260723.md
Normal file
113
wan22-comfyui-speedup-highvram-20260723.md
Normal file
|
|
@ -0,0 +1,113 @@
|
||||||
|
# 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 (`/queue` GET), 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
|
||||||
|
1. **[BÄR-ENTSCHEIDUNG offen]** SageAttention/TeaCache in isolierter Test-venv ausprobieren (nicht in
|
||||||
|
Produktion) — potenziell weitere 30-50%.
|
||||||
|
2. NVENC-Encode in pipe_04/pipe_05 als eigener, sauber getesteter Folgeauftrag (nicht heute, um #17 nicht
|
||||||
|
zu riskieren).
|
||||||
|
3. LatentSync als MuseTalk-Ersatz separat evaluieren (Qualität + Geschwindigkeit vergleichen), bevor
|
||||||
|
produktiv getauscht wird.
|
||||||
|
4. `--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
|
||||||
Loading…
Reference in a new issue