hermes-erkenntnisse/benchmark-vramfix-sdxl-2026-07-24.md

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.