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