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