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

56 lines
3.8 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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`: **5473 Sekunden/Iteration** (32 Steps → ~38 Min für ein Bild).
Normal für SDXL auf A40 wäre 12s/it (1540s gesamt) → Faktor ~50100x 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,52,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,30,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 (~58GB) 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 (5473s/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.