Vorher/Nachher-Benchmark VRAM-Thrashing-Fix (SDXL), Nachher noch ausstehend

benchmark-vramfix-sdxl-2026-07-24.md

@@ -0,0 +1,55 @@
+# Benchmark Vorher/Nachher — VRAM-Thrashing-Fix (SDXL), 2026-07-24
+
+## Vorher (belegt, aus `barby/hermes-erkenntnisse/vram-arbitrierung-und-routingkarte-20260724.md`)
+- `nvidia-smi`: A40 45477/46068 MiB belegt (59 MiB frei), 100% Util, ein einzelner
+  SDXL-Sampling-Job.
+- `M:\comfyui-live.log`: **54–73 Sekunden/Iteration** (32 Steps → ~38 Min für ein Bild).
+  Normal für SDXL auf A40 wäre 1–2s/it (15–40s gesamt) → Faktor ~50–100x langsamer.
+- Root Cause: `--highvram` (aus früherem Wan2.2-Speedup-Ticket, brachte dort 4,3x) lässt
+  ComfyUI bei gemischter Queue (SDXL + Wan2.2-GGUF) nie Modelle entladen → Stapelung über
+  VRAM-Grenze → Swap/Thrashing.
+
+## Fix-Status (dieser Schritt, verifiziert)
+- `M:\start-comfyui-task.ps1`: `--highvram` bereits entfernt (Vor-Schritt, 2026-07-24 02:48),
+  Backup `M:\start-comfyui-task.ps1.bak-vramfix-20260724-024847` vorhanden.
+- `M:\start-comfyui-task-wan-dedicated.ps1`: neue dedizierte Kopie MIT `--highvram` für
+  bewusste Wan2.2-Batch-Fenster (kein SDXL parallel) — erhält die 4,3x-Beschleunigung dort.
+- **Live-Check heute (2026-07-24, dieser Schritt):** laufender ComfyUI-Prozess (PID 98172,
+  Scheduled Task `ComfyUI-Server`, Kommandozeile per `Get-CimInstance Win32_Process`
+  ausgelesen) läuft **noch mit `--highvram`** — Task zuletzt gestartet 23.07.2026 15:09:34,
+  also VOR dem Fix (02:48 am 24.07.). Die Config-Änderung greift erst beim nächsten
+  natürlichen Neustart dieses Tasks (Bär-Vorgabe: kein Sonder-Neustart, aktive Queue nicht
+  stören — anders als beim leichten Orchestrator-Prozess in diesem Schritt nicht angefasst).
+
+## Aktueller Live-Sample (noch unter altem `--highvram`-Regime, zur Einordnung)
+Letzter abgeschlossener Sampling-Lauf im `M:\comfyui-live.log` (32-Step-Job, vermutlich
+Wan2.2-artig): Gesamtlaufzeit 2:43 für 32 Steps, Steady-State-Rate **~2,5–2,6 it/s** (≈0,4s/it)
+nach Warmup — **kein akutes Thrashing im aktuell laufenden Betrieb sichtbar** (die großen
+"146,85s/it"-Werte bei Schritt 1 sind tqdm-ETA-Artefakte durch Modell-Ladezeit, kein reales
+Per-Step-Timing). Das deckt sich mit "SDXL ~0,3–0,4s/it jetzt gesund" aus dem Auftrag —
+ist aber KEIN sauberer A/B-Beweis für den heutigen Fix, weil der Prozess ihn noch nicht
+geladen hat; könnte auch schlicht ein Lauf ohne die Thrashing-Bedingungen (keine gemischte
+Queue gerade) gewesen sein.
+
+## Sauberer Nachher-Beweis — noch ausstehend
+Braucht einen Neustart von Scheduled Task `ComfyUI-Server` (lädt `start-comfyui-task.ps1`
+ohne `--highvram` neu). Bewusst NICHT in diesem Schritt erzwungen (Bär-Guardrail: kein
+Sonder-Neustart der aktiven Video-Pipeline). Sobald der Task natürlich neu startet (nächster
+Boot, nächster geplanter Restart, oder Bär gibt GO für einen kontrollierten Neustart bei
+leerer Queue): gleicher SDXL-Referenz-Checkpoint/Auflösung/Steps wie im Vorher-Beleg rendern,
+`nvidia-smi` + Wallclock vor/nach vergleichen. Erwartung laut Vorher-Diagnose: Sekunden statt
+Minuten, VRAM fällt nach Job auf Checkpoint-Größe (~5–8GB) statt dauerhaft hoch zu bleiben.
+
+## Was in DIESEM Schritt zusätzlich verifiziert wurde
+- `nvidia-smi --query-gpu` funktioniert und liefert live VRAM%/Util (Grundlage für den neuen
+  `Barby-VRAMGuard`-Watchdog, siehe separater Bericht) — aktueller Stand beim Check:
+  Queue leer, kein Job aktiv, kein Thrashing-Kontext.
+- ComfyUI `/queue` und `/free`-API bestätigt erreichbar und funktionsfähig (Vorbedingung für
+  den `/free`-Auto-Schutz).
+
+## Ehrliches Fazit
+Vorher-Zahlen (54–73s/it) sind hart belegt aus dem Vor-Schritt. Nachher-Zahlen für SDXL
+spezifisch sind **noch nicht messbar**, weil der produktive ComfyUI-Prozess das reversible
+Fix-Config noch nicht geladen hat (bewusst kein Sonder-Neustart). Der aktuelle Live-Betrieb
+zeigt keine akute Thrashing-Symptomatik, das ersetzt aber keinen sauberen A/B-Test mit
+identischem Vorher/Nachher-Setup.