6.3 KiB
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.ps1vor/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\modelsviaextra_model_paths.yamleingebunden (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.usedvor 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.ps1vor/nach identisch, Prod-Queue während gesamter Messreihe nur bei Leerlauf genutzt, aktiver Prod-Job (consoromail_scene1_barby) nicht gestört.