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)

Backup: M:\start-comfyui-task.ps1.bak-vramfix-20260724-024847 (MD5 cab1f639... == Original vor Aenderung, verifiziert).
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.
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.
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)

Referenz-Clip (gleiche Parameter wie #19-Messung) end-to-end durch die volle Pipeline (Wan2.2 -> Lipsync -> Restore/Mux -> Interpolate) sequenziell zeitstempeln (pro Stufe).
Gleicher Clip mit Look-ahead (Stufe N-1 CPU parallel zu Stufe N A40) -- Vergleich Wallclock gesamt.
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).

6.7 KiB Raw Blame History