# 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.