diff --git a/wan22-comfyui-speedup-highvram-20260723.md b/wan22-comfyui-speedup-highvram-20260723.md
new file mode 100644
index 0000000..f82e4cd
--- /dev/null
+++ b/wan22-comfyui-speedup-highvram-20260723.md
@@ -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