VRAM-Arbitrierung Bugfix + #61-Routingkarte-Plan
This commit is contained in:
parent
03d5393453
commit
19e6ae7ec1
101
vram-arbitrierung-und-routingkarte-20260724.md
Normal file
101
vram-arbitrierung-und-routingkarte-20260724.md
Normal file
|
|
@ -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).
|
||||
Loading…
Reference in a new issue