50 lines
6.3 KiB
Markdown
50 lines
6.3 KiB
Markdown
# Wan2.2/ComfyUI Speed-Stufe 2: SageAttention 2.2 + TeaCache + torch.compile — Worker A2
|
||
|
||
**Datum:** 2026-07-23, VM302/A40. Aufbauend auf Worker A1 (--highvram, 4,3x, 739→172s).
|
||
|
||
## Setup (isoliert, Prod nicht angefasst)
|
||
- Zwei separate ComfyUI-Kopien+venvs, KEINE Prod-Dateien verändert (MD5 von `start-comfyui-task.ps1` vor/nach identisch: `cab1f639ee595174f8ca3cf2c322b2f1`).
|
||
- `D:\comfyui-test` + `D:\comfyui-test-venv` (torch 2.5.1+cu121, identisch zu Prod) — Baseline-Reproduktion.
|
||
- `D:\comfyui-test-venv-sage` (torch 2.8.0+cu128, triton-windows 3.4.0, SageAttention 2.2.0+cu128torch2.8.0) — Sage/Compile-Tests.
|
||
- Modelle read-only von `M:\ComfyUI\models` via `extra_model_paths.yaml` eingebunden (keine Kopie, kein Schreibzugriff).
|
||
- Ports 8195/8196 (Prod bleibt 8188), eigenes Output-Verzeichnis `D:\comfyui-test-output`.
|
||
- Referenz-Workflow 1:1 aus A1s Benchmark-MP4-Metadaten extrahiert (512×896, 49 Frames, GGUF Q5_K_M HighNoise+LowNoise, Lightning-4step-LoRA, KSamplerAdvanced 2+2 Split).
|
||
|
||
## 🚨 Kritischer Befund: VRAM-Konkurrenz auch bei "idle" Prod
|
||
Prod hält durch `--highvram` auch im Leerlauf oft 30-42GB von 46GB VRAM resident (schwankend). Ein zweiter voller Wan2.2-Lauf gleichzeitig sättigt die A40 nahezu vollständig → Messwerte werden durch Paging verfälscht (ein Testlauf zeigte dadurch 347s statt der späteren sauberen 300s). Reine `nvidia-smi`-Util-/Queue-Prüfung reicht NICHT — auch `memory.used` prüfen und **niemals zwei Wan2.2-Instanzen parallel laufen lassen**, selbst wenn Prod-Queue leer ist. Für alle sauberen Messungen wurde jeweils nur EINE Instanz gleichzeitig betrieben, Prod-Queue+Memory vor jedem Lauf geprüft.
|
||
|
||
Nebenbefund: `nohup ... &` unter Git-Bash liefert mit `$!` nicht die PID des eigentlichen `python.exe`-Arbeitsprozesses (venv-Wrapper spawnt einen Kind-Prozess) — `kill $!` tötete wiederholt nur den Wrapper und ließ Ghost-Server mit vollem VRAM-Verbrauch weiterlaufen. Fix: echte Worker-PID über `Get-CimInstance Win32_Process` per Commandline-Match finden und gezielt killen.
|
||
|
||
## Ergebnisse (A/B, gleicher Workflow/Seed-Disziplin, saubere Einzel-Instanz-Messung)
|
||
|
||
| Konfiguration | cold | warm |
|
||
|---|---|---|
|
||
| Baseline (--highvram, kein Sage) | 300,1s | **129,4s** |
|
||
| + SageAttention 2.2 | 379,6s | **148,5s** |
|
||
|
||
**SageAttention 2.2 macht diesen Workflow auf der A40 LANGSAMER, nicht schneller (+~15% warm, +~26% cold).**
|
||
|
||
Grund: A40 ist Ampere (sm_86). SageAttention 2.2s schnelle "2++"-Kernel sind laut Upstream (woct0rdho/SageAttention) exklusiv für Ada/Blackwell (RTX 40xx/50xx, CUDA≥12.8-Pfad); auf Ampere fällt es auf die älteren SageAttention2-Kernel zurück. Bei nur 4 Sampling-Steps (2+2 Split) macht Attention-Compute ohnehin nur einen kleinen Teil der Laufzeit aus (Modell-Load/VAE dominieren) — der Quantisierungs-Overhead von Sage frisst den kleinen Gewinn komplett auf und kostet netto Zeit.
|
||
**Empfehlung: NICHT in Prod übernehmen.** Kein GO für SageAttention auf diesem Workflow/dieser GPU.
|
||
|
||
Baseline-Zahlen selbst (isolierte Umgebung, single-instance) liegen mit 129s warm sogar leicht besser als A1s Prod-Messung (172s) — vermutlich Messmethodik-Differenz (HTTP-Prompt-Submit-bis-history-completed hier vs. A1s Messverfahren), kein Widerspruch zur A1-Empfehlung, nur nicht 1:1 vergleichbar in Absolutzahlen. Die A/B-Delta (Sage vs. kein-Sage) innerhalb dieser Messreihe ist der belastbare Teil.
|
||
|
||
## TeaCache
|
||
Node `welltop-cn/ComfyUI-TeaCache` geklont, initialer Import schlug fehl (`precompute_freqs_cis` fehlt in der Prod-Version von `comfy.ldm.lightricks.model` — Upstream-Node erwartet neuere ComfyUI-API). Fix per try/except-Patch in der isolierten Kopie (nur LTXV-Pfad betroffen, Wan-Unterstützung unberührt) — Node lädt danach sauber. **Timing-A/B nicht mehr durchgeführt** (Zeitbudget): bei nur 4 Sampling-Steps (2 pro Sampler-Stage) ist TeaCaches Step-Skip-Cache-Mechanismus konzeptionell kaum wirksam — die dokumentierten Speedups (1,6-2,3x) stammen aus 20-50-Step-Workflows. Einschätzung: für DIESEN 4-Step-Lightning-Workflow vermutlich kein nennenswerter Zusatzgewinn, eher zusätzliches Fehlerrisiko. Kein Beleg, daher keine Empfehlung — offen für spätere Prüfung falls ein High-Step-Workflow ansteht.
|
||
|
||
## torch.compile + GGUF
|
||
`TorchCompileModel`-Node (ComfyUI-Kern, `comfy_extras/nodes_torch_compile.py`) vor beide KSamplerAdvanced-Stufen gehängt (Backend `inductor`), Modell = GGUF-quantisiertes Wan2.2. Kompilierung lief >15 Minuten ohne Fortschritt/Fehler (kein Crash, aber praktisch nutzlos) — abgebrochen aus GPU-Courtesy, da Prod zwischenzeitlich wieder aktiv wurde. **Nicht praxistauglich** in dieser Kombination (GGUF-Tensor-Dequant-Ops + torch.compile/inductor graph-spezialisieren vermutlich exzessiv). Kein GO, keine weitere Zeit investiert.
|
||
|
||
## ffmpeg NVENC
|
||
`h264_nvenc`/`hevc_nvenc`/`av1_nvenc` sind im installierten ffmpeg vorhanden, aber **blockiert durch Treiber-Version**: `Driver does not support the required nvenc API version. Required: 13.1 Found: 13.0` — braucht NVIDIA-Treiber ≥610.00, aktuell 596.36. Kein Crash, sauberer Fehler. **Kein GO ohne Treiber-Update** — Treiber-Update NICHT selbst durchgeführt (Prod-Risiko, braucht Bär-OK + Wartungsfenster, evtl. Reboot nötig).
|
||
|
||
## Fazit / Nächste Schritte
|
||
- **Kein einziger der vier geprüften Ansätze liefert heute einen belegten, sicheren Produktions-Speedup** auf dieser Ampere-A40 für den bestehenden 4-Step-Lightning-Workflow. A1s `--highvram`-Fix bleibt der wirksame Hebel (4,3x).
|
||
- Isolierte Testumgebung (`D:\comfyui-test*`) bleibt für spätere Tests stehen (z. B. TeaCache-Timing bei High-Step-Workflows, NVENC nach Treiber-Update, SageAttention bei anderen Workload-Profilen).
|
||
- Bei künftigen Parallel-Messungen: IMMER nur eine Zusatz-Instanz gleichzeitig zu Prod, VRAM per `nvidia-smi --query-gpu=memory.used` vor JEDEM Lauf prüfen, echte Worker-PID (nicht Bash-`$!`) zum Beenden nutzen.
|
||
|
||
## Beweise
|
||
- Output-Videos (512×896, 49 Frames, korrekt verifiziert per ffprobe): `B:\comfyui-output\a2_speedtest_baseline_warm_129s.mp4`, `B:\comfyui-output\a2_speedtest_sage_warm_148s.mp4`
|
||
- Rohlogs: `D:\comfyui-test\bench-venvA-*.log`, `D:\comfyui-test\bench-venvB-*.log`
|
||
- Prod unverändert: MD5-Vergleich `start-comfyui-task.ps1` vor/nach identisch, Prod-Queue während gesamter Messreihe nur bei Leerlauf genutzt, aktiver Prod-Job (`consoromail_scene1_barby`) nicht gestört.
|