diff --git a/vram-arbitrierung-und-routingkarte-20260724.md b/vram-arbitrierung-und-routingkarte-20260724.md new file mode 100644 index 0000000..d549d85 --- /dev/null +++ b/vram-arbitrierung-und-routingkarte-20260724.md @@ -0,0 +1,101 @@ +# VRAM-Arbitrierung (Bugfix) + #61-Routingkarte/Pipelining-Plan, 2026-07-24 + +## Teil A: VRAM-Thrashing-Bugfix (belegt, reversibel umgesetzt) + +### Befund (live verifiziert, nicht nur behauptet) +- `nvidia-smi`: A40 hatte **45477/46068 MiB belegt (nur 59 MiB frei)**, 100% Util, bei einem + einzelnen SDXL-Sampling-Job. +- `M:\comfyui-live.log`: derselbe SDXL-Job brauchte **54-73 Sekunden/Iteration** (32 Steps -> + ~38 Minuten fuer EIN Bild). Normal fuer SDXL auf A40: 1-2s/it, also 15-40s Gesamtzeit. + Faktor ~50-100x langsamer -> Thrashing bestaetigt, kein Einzelfall. +- Root Cause: `--highvram` (aus #19, gesetzt fuer dedizierte Wan2.2-Beschleunigung) laesst + ComfyUI Modelle NIE aus dem VRAM entladen. Bei gemischter Queue (SDXL-Checkpoints + + Wan2.2-GGUF-Experten) stapeln sich die Modelle im VRAM bis Torch ueberbucht -> Swap/Thrashing. + `--highvram` war fuer #19 (rein Wan2.2, dediziert) korrekt und brachte dort 4,3x Speedup -- + ist aber falsch fuer gemischte Produktionsqueues. + +### Fix (additiv, reversibel, NICHT sofort scharf geschaltet) +1. Backup: `M:\start-comfyui-task.ps1.bak-vramfix-20260724-024847` + (MD5 `cab1f639...` == Original vor Aenderung, verifiziert). +2. `M:\start-comfyui-task.ps1` (Default-Scheduled-Task `ComfyUI-Server`): `--highvram` + entfernt -> ComfyUI faehrt wieder im Default-Dynamic-VRAM-Modus, entlaedt Modelle beim + Wechsel zwischen Model-Typen automatisch. Kein VRAM-Stapeln mehr fuer die normale + gemischte SDXL+Wan2.2-Produktionsqueue. +3. Neu: `M:\start-comfyui-task-wan-dedicated.ps1` -- Kopie mit `--highvram`, fuer bewusst + dedizierte Wan2.2-Batch-Fenster (kein SDXL parallel), um die #19-Beschleunigung (4,3x) + dort NICHT zu verlieren. Manuell/zeitgesteuert einsetzbar, ist NICHT der Scheduled-Task. +4. Scheduled Task `ComfyUI-Server` zeigt unveraendert auf `start-comfyui-task.ps1` -- + Aenderung greift automatisch beim naechsten Neustart dieses Tasks, KEIN Reboot/Kill + noetig und laut Auftrag auch nicht selbst durchgefuehrt (laufende SDXL-Queue nicht + gestoert). Rueckweg: `Copy-Item ...bak-vramfix-20260724-024847 start-comfyui-task.ps1 -Force`. + +### Verifikation ausstehend (braucht main/Baer-GO fuer ComfyUI-Neustart) +- Vorher: 54-73s/it SDXL (dieser Bericht), 45477 MiB VRAM belegt. +- Nachher (Plan): nach Neustart mit neuer Config ein SDXL-Referenzbild (gleicher + Checkpoint/Aufloesung/Steps) rendern, Zeit + `nvidia-smi`-VRAM vor/nach messen. Erwartung: + Sekunden statt Minuten, VRAM faellt nach Job auf Checkpoint-Groesse (~5-8GB) statt konstant + hoch zu bleiben. +- Zusaetzlich: ein Wan2.2-Referenzlauf auf `start-comfyui-task-wan-dedicated.ps1` gegenpruefen, + dass die 4,3x aus #19 dort weiterhin gelten (kein Regressions-Risiko fuer den dedizierten Pfad). + +### Empfehlung fuer main/Orchestrator-Ebene (nicht in diesem Schritt umgesetzt) +ComfyUI bietet die API `POST /free {"unload_models":true,"free_memory":true}`. Der +Job-Forwarder/Orchestrator koennte das zusaetzlich explizit aufrufen, wenn ein Job-Typ-Wechsel +erkannt wird (SDXL->Wan2.2 oder umgekehrt) -- schnelleres, gezieltes Entladen statt auf +ComfyUIs automatisches Management zu warten. Nicht umgesetzt, weil das eine Aenderung an +`job_forwarder`/Orchestrator-Code waere (ausserhalb des heutigen additiv-reversiblen +Config-Scopes) -- als Folgeschritt vorgeschlagen. + +--- + +## Teil B: #61 Routingkarte + Look-ahead-Pipelining (Plan, nicht vollstaendig umgesetzt) + +### Bekannte Ressourcen (aus Auftrag + verifizierten Quellen) +- **A40 (VM302, ComfyUI :8188)**: einzige echte GPU im aktuellen Pfad. Serialisiert durch + `_A40_GUARD`-Semaphore (`/opt/gpu1-status/app.py`, VM201) -- verhindert parallele + A40-Jobs auf Portal-Ebene (Schritt 1+2, dokumentiert `barby/hermes-erkenntnisse/ + burst-compute/w44-a40-guard-step2-2026-07-23.md`). Guard haelt den Lock nur waehrend des + Submit-Calls, NICHT ueber die gesamte Renderdauer -- bekannte Luecke, dort dokumentiert. +- **CPU (VM302)**: fuer `pipe_04_restore_mux.py`/`pipe_05_interpolate.py` aktuell + `libx264 -preset slow` (CPU-Encoding). NVENC (`h264_nvenc`) ist auf der ffmpeg-Binary + bereits vorhanden, aber laut #19-Bericht bewusst nicht angefasst (aktive #17-Pipeline, + kein Umbau ohne vollen Test). +- **Shadow / Monster**: im Auftrag als weitere Routing-Ziele genannt (#71-Offload-Karte). + Ich konnte die #71-Doku in dieser Session NICHT auffinden (Forgejo-Volltextsuche/Qdrant + lieferte keinen Treffer auf "#71 Offload-Karte" mit Shadow/Monster-Rollenzuordnung). + **Ehrlich markiert**: die konkrete Schritt->Knoten-Zuordnung fuer Shadow/Monster kann ich + ohne #71-Originaldokument nicht ausfuellen, ohne zu raten. Empfehlung: main/Baer liefert + Pfad zu #71 (Dateiname/Repo), dann wird die Karte in einem Folgeschritt konkret ausgefuellt. + +### Vorlaeufige Routing-Logik (nur A40+CPU-Teil belastbar, Rest Platzhalter) +| Schritt | Ziel | Beleg | +|---|---|---| +| SDXL/Wan2.2 Sampling, VAE Decode, Upscale (ComfyUI) | A40 | einzige GPU im Pfad, `_A40_GUARD` | +| `pipe_04_restore_mux.py`, `pipe_05_interpolate.py` (aktuell) | CPU (libx264) | #19-Bericht, ffmpeg-Log | +| `pipe_04`/`pipe_05` (Vorschlag, ungetestet) | A40 (NVENC) | vorhanden aber nicht aktiviert | +| Shadow-Knoten | ? | #71 noch nicht gefunden | +| Monster-Knoten | ? | #71 noch nicht gefunden | + +### Look-ahead-Pipelining -- Plan (nicht implementiert) +Idee (Standard-Ansatz fuer sequenzielle GPU/CPU-Pipelines): waehrend Segment N auf der A40 +rendert, kann das VORHERIGE fertige Segment N-1 bereits parallel auf CPU nachbearbeitet +werden (Restore/Mux/Interpolate), statt strikt sequenziell A40->CPU->A40->CPU zu warten. +Voraussetzung: die A40-Guard-Semaphore muesste pipeline-stufenweise (nicht global) greifen, +und `pipe_0x`-Skripte muessten async/Queue-fähig werden (Producer/Consumer statt +Blocking-Call-Kette). Das ist ein groesserer Umbau der `#17`-Pipeline-Skripte -- laut +Auftrag heute nur als **Plan** dokumentiert, nicht scharf geschaltet (kein ungetesteter +Eingriff in die aktive Produktionskette). + +### Benchmark-Plan fuer Teil B (sobald main/Baer grosseres Zeitfenster gibt) +1. Referenz-Clip (gleiche Parameter wie #19-Messung) end-to-end durch die volle Pipeline + (Wan2.2 -> Lipsync -> Restore/Mux -> Interpolate) sequenziell zeitstempeln (pro Stufe). +2. Gleicher Clip mit Look-ahead (Stufe N-1 CPU parallel zu Stufe N A40) -- Vergleich Wallclock + gesamt. +3. NVENC- vs. libx264-A/B auf `pipe_04`/`pipe_05` separat messen (isoliert von Pipelining). + +## Status +- Teil A: umgesetzt (Config), Verifikation (Vorher/Nachher-Benchmark) noch offen, braucht + ComfyUI-Neustart -> main/Baer-Entscheidung. +- Teil B: Routing-Analyse fuer A40/CPU belastbar, Shadow/Monster braucht #71-Fundstelle, + Look-ahead-Pipelining als Plan dokumentiert, NICHT implementiert (Risiko fuer aktive + #17-Pipeline zu hoch fuer einen ungetesteten Direktumbau in diesem Schritt).