ComfyUI mit wenig VRAM beschleunigen: SDXL, FLUX und Video auf 6–8-GB-GPUs

Im Terminal steht torch.cuda.OutOfMemoryError: CUDA out of memory. Die ComfyUI-Konsole meldet regular VAE encoding, retrying with tiled VAE encoding, doch das Bild mit 1024×1024 Pixeln wird trotzdem nicht fertig. Eine RTX 3060 mit 8 GB schafft ein einzelnes SDXL-Bild. Sobald Hires Fix, FaceDetailer und ControlNet dazukommen, steigt der Bedarf jedoch auf mehr als 12 GB. Mit 768×768 und deaktiviertem ControlNet läuft es gerade noch, aber die gewünschte Qualität fehlt.

Auf einer Consumer-GPU mit 6–8 GB, Apple Silicon oder AMD-Hardware geht es deshalb darum, SDXL, FLUX und leichte Video-Workflows in ComfyUI möglichst stabil auszuführen und die Kosten jeder Anpassung bei Geschwindigkeit, Qualität und Kompatibilität zu kennen.

---

Zuerst die VRAM-Klasse der GPU bestimmen

Ein VRAM-Budget ist keine Schätzung aus dem Bauch. Die Klasse deiner GPU bestimmt, welche Workflows realistisch sind und welche Strategie zuerst sinnvoll ist.

VRAM-Klassen, mögliche Workflows und geeignete Startpunkte

VRAM	Mögliche Workflows	Grenzen und Risiken	Empfohlener Start
6GB	SDXL mit niedriger Auflösung (512–768) Stark komprimiertes FLUX (Q2_K/Q3_K_S + GGUF + —lowvram/—novram) Video: 8 Frames bei 480p als Grenzfall	Begrenzte Auflösung Zusatz-Nodes führen schnell zu OOM Langsam durch RAM-Offloading	Starke Quantisierung wie Q3_K_S Auflösung bei 512–768 halten ControlNet und Nachbearbeitung deaktivieren Höchstens 8 Videoframes
8GB	Einzelnes SDXL-Bild mit 1024×1024 FLUX fp8/GGUF Q4_K_S ohne Stabilitätsgarantie 8 Frames bei 480p gut, 24 Frames bei 720p als Grenzfall	ControlNet und Hires Fix zusammen führen schnell zu OOM T5 braucht fp8/GGUF Höchstens 1024×1024 FLUX.1 GGUF Q5_K_S ist ein Grenzfall	FLUX.2 Klein 4B GGUF bevorzugen T5 fp8/GGUF Tiled VAE verwenden batch size=1
12GB	SDXL + ControlNet + einfaches Upscaling FLUX Q5_K_S/Q6_K gut nutzbar 24 Frames bei 720p gut, 60 Frames bei 1080p als Grenzfall	Mehrere ControlNets weiter begrenzen Frames × Auflösung berücksichtigen Nachbearbeitung bleibt endlich	FLUX Q5_K_S/Q6_K T5 fp8 optional Tiled VAE optional batch size 2–3 testen
16GB+	FLUX full fp16 oder nahezu verlustfreies Q8_0 Mehr Spielraum für ControlNet/LoRA 60 Frames bei 1080p	FLUX full ist etwa 23 GB groß Frames × Auflösung bleiben relevant Nachbearbeitung erzeugt weiter Spitzen	FLUX Q8_0 oder fp16 T5 fp16 Tiled VAE optional batch size 4–8 testen

Typische Spitzenverursacher, absteigend

1. Modellgewichte: SDXL-Checkpoint etwa 6,5 GB, FLUX fp16 etwa 23 GB
2. T5-Encoder: fp16 etwa 9 GB und damit zu groß für 8 GB, fp8 etwa 4–5 GB, GGUF in Q3/Q4/Q5
3. Latent-Auflösung: Ein Latent mit 2048×2048 kann sich 8 GB nähern
4. VAE Encode/Decode: Bei 2048×2048 sind Spitzen um 8 GB möglich
5. Batch-Größe: Gleichzeitige Inferenz erzeugt die höchste Spitze
6. ControlNet/Detailer: Jeweils etwa 2–3 GB in den genannten Beispielen
7. Videoframes: Frames × Auflösung × VideoVAE
8. Cache/Preview: ungefähr 0,5–1 GB

Der tatsächliche Verbrauch hängt von Auflösung, Präzision, Modellversion, Batch, Nachbearbeitungs-Nodes, Videoframes, PyTorch- und Treiberversion sowie Custom Nodes ab. Abweichungen von 1–2 GB sind möglich. Nutze die Tabelle als Startbudget und miss anschließend den echten Workflow.

---

Startparameter für ComfyUI mit wenig VRAM

ComfyUI bietet mehrere Startparameter für VRAM und Arbeitsspeicher. Sie ändern sich mit den Versionen. Die folgende Übersicht bezieht sich auf ComfyUI v0.18.0+ um März 2026. Maßgeblich bleiben python main.py --help und die aktuelle offizielle Dokumentation.

Startparameter, Zweck, GPU-Klasse und Geschwindigkeit

Parameter	Zweck	GPU-Klasse	Geschwindigkeit	Einsatz
--lowvram	Teilt das Modell und streamt Teile aus dem RAM	4–8GB	20–40% langsamer	Ohne Wirkung bei aktivem Dynamic VRAM Manuell nach —normalvram testen
--novram	Hält Gewichte in CPU/RAM und verschiebt nur aktive Berechnungen zur GPU	Unter 4GB	50–70% langsamer	Letzter Ausweg Sehr langsam, kann aber laufen
--normalvram	Erzwingt den Standardmodus und deaktiviert Dynamic VRAM	12GB+	Keine erwartete Änderung	Für manuellen —lowvram-Test Oder bei Fragmentierungs-OOM
--reserve-vram N	Reserviert N GB VRAM für das Betriebssystem	Alle	Keine erwartete Änderung	Schützt vor Systemproblemen Oft 2–4GB reservieren
--async-offload	Lagert Gewichte asynchron aus	Alle	Beispiel: 5–10% schneller	Reduziert CPU-GPU-Warten bei reichlich RAM, meist 32GB+
--fp8_e4m3fn-unet	Erzwingt fp8 für UNet	8–12GB	Etwa neutral	Wird von FLUX oft ignoriert Interne compute dtype beachten
--fp8_e4m3fn-text-enc	Nutzt fp8 für den Text-Encoder	8GB	Etwa neutral	Senkt T5 von etwa 9 auf 4–5GB Für Low-VRAM-FLUX
--fp8_e5m2fn-text-enc	Alternative fp8-Variante für den Text-Encoder	8GB	Etwa neutral	Alternative zu fp8_e4m3fn
--preview-method none	Deaktiviert Vorschauen	Alle	Etwas schneller	Spart etwa 0,5–1GB Erster OOM-Test
--cache-none	Deaktiviert den Cache	Wenig RAM	Langsamer	Spart RAM, berechnet aber Nodes neu
--cache-lru 10	Hält 10 Ergebnisse im LRU-Cache	Viel RAM	Schneller	Ausgewogener Cache 10–20 testen
--cache-classic	Alter aggressiver Cache	Viel RAM	Schneller	Kann mehr RAM benötigen
--force-fp16	Erzwingt global fp16	Alle	Etwa neutral	Kann 2–3GB sparen
--use-pytorch-cross-attention	Erzwingt PyTorch SDP Attention	Alle	Beispiel: 5–20% schneller	ComfyUI wählt oft automatisch xformers/SDP Nur gezielt erzwingen
--use-flash-attention	Erzwingt Flash Attention	Alle	Beispiel: 5–20% schneller	Benötigt flash-attention Nicht mit jeder CUDA-Version kompatibel
--fast	Experimenteller Schnellmodus	Alle	Ungewiss	Fortgeschrittenes Experiment Kann Qualität/Stabilität verändern Keine 8GB-Standardeinstellung

Befehlsbeispiele

# Grundkonfiguration für 8 GB VRAM
python main.py --lowvram --force-fp16 --fp8_e4m3fn-text-enc --preview-method none

# Grenzkonfiguration für 6 GB VRAM
python main.py --novram --force-fp16 --fp8_e4m3fn-text-enc --preview-method none --reserve-vram 2

# Schnellere Konfiguration bei reichlich RAM
python main.py --async-offload --cache-lru 10 --use-pytorch-cross-attention

Veränderliche Angaben: Parameter können sich ändern. Verlasse dich auf python main.py --help und die aktuelle Dokumentation. FLUX kann --fp8_e4m3fn-unet wegen seiner internen compute dtype ignorieren; stelle bei Bedarf weight_dtype im Node ein.

---

Warum —lowvram den VRAM-Fehler nicht verhindert

ComfyUI v0.18.0+ um März 2026 aktiviert Dynamic VRAM standardmäßig. Ist es aktiv, wird --lowvram ignoriert, weil bereits eine adaptive Offloading-Strategie arbeitet.

--lowvram manuell verwenden

• Nach dem Deaktivieren von Dynamic VRAM mit --normalvram
• Bei Fragmentierungs-OOM in einem bestimmten Workflow --disable-dynamic-vram testen

Alternativen

• Das Standardverhalten von Dynamic VRAM verwenden
• --novram nur als letzten Ausweg nutzen und 50–70% Geschwindigkeitsverlust akzeptieren
• Mit --reserve-vram 2-4 Platz für das Betriebssystem lassen

Vorteil von Dynamic VRAM: Es schätzt den Bedarf und lagert bei Bedarf automatisch in RAM aus.

Risiko von Dynamic VRAM: Einzelne Workflows können weiter durch Fragmentierung ausfallen. Dann lohnt ein Test mit --disable-dynamic-vram.

---

Drei FLUX-Wege für 8 GB: fp8, GGUF und Klein 4B

FLUX ist ein Modell mit 12 Milliarden Parametern; die Originaldatei ist etwa 23 GB groß. Für 8 GB gibt es drei Routen mit unterschiedlichen Kosten.

FLUX-Quantisierungswege

Route	Dateigröße	VRAM	Qualität vs fp16	GPU	Geschwindigkeit	Kompatibilität	Einsatz
FLUX full (fp16)	~23GB	~20GB+	100%	24GB+	Am schnellsten	Offiziell	Professionell Genug VRAM
FLUX fp8 checkpoint	~12GB	~11GB	~95–98%	12GB gut/16GB+	Relativ schnell	Offizielle Quantisierung	Ab 12GB Eine Datei
FLUX GGUF Q8_0	~12,7GB	~11GB	~99%	12GB+/16GB+	Langsamer durch Offload	city96-Node, WIP	Ab 12GB Nahezu verlustfrei
FLUX GGUF Q5_K_S	~8,5GB	~7,5GB	~94–96%	8GB Grenzfall/12GB gut	Langsam durch Offload	city96-Node, WIP	8GB Qualitätskompromiss
FLUX GGUF Q4_K_S	~6,8GB	~6,5GB	~88–90%	8GB/6GB Grenzfall	Am langsamsten	city96-Node, WIP	6–8GB Hauptsache ausführbar
FLUX.2 Klein 4B GGUF Q4_K_M	~2,6GB	~2,6GB	Eigenes Qualitätsniveau des 4B-Modells	8GB gut	Vier Steps, schnell	Apache 2.0, city96-Node	Für 8GB Vier Steps Schnell

T5-Encoder

T5-Version	Dateigröße	VRAM	GPU
T5 fp16	~9GB	~9GB	24GB+, zu groß für 8GB
T5 fp8_e4m3fn	~4–5GB	~4–5GB	Auf 8GB praktikabel
T5 GGUF Q3/Q4/Q5	~2–4GB	~2–4GB	Grenzfälle mit 6–8GB

Installation

Lade für fp8 die safetensors-Datei herunter, öffne sie mit Load Diffusion Model und stelle weight_dtype auf fp8_e4m3fn.

Installiere für GGUF die Custom Node ComfyUI-GGUF von city96, lade das Modell mit Unet Loader (GGUF) und lege die Datei unter models/unet/ ab.

Risiko der Drittanbieter-Node: GGUF ist als WIP markiert, LoRA-Unterstützung ist experimentell. Die Node ändert sich häufig und ist kein offizieller integrierter Pfad.

Qualitätsbeobachtung von Apatero: Q5_K_S liegt nahe an fp16; Unterschiede fallen vor allem bei Text und feinen Mustern auf. Q4_K_S verliert mehr Details.

Messung von Local AI Master

• FLUX.1-dev Q4_K_S + —lowvram, 1024×1024, 20 Steps, RTX 3060 Ti 8GB: etwa 90–150 Sekunden
• FLUX.2 Klein 4B Q4_K_M, 1024×1024, vier Steps, 8GB: etwa 15–30 Sekunden

Veränderlicher Benchmark: Hardware, Versionen und Workflow verändern diese Werte. Nutze sie als Referenzspanne.

---

OOM bei VAE Encode/Decode mit Tiled VAE senken

Bei 2048×2048 oder Video kann VAE Encode/Decode den VRAM erschöpfen. Tiled VAE verarbeitet das Bild in kleineren Bereichen und senkt die Spitze.

Nodes

VAEDecodeTiled decodiert das Latent tileweise in ein Bild. VAEEncodeTiled codiert ein Bild auf dieselbe Weise in ein Latent.

Parameter

Parameter	Zweck	Startwert	Einsatz
tile_size	Größe eines Tiles	512 bei wenig VRAM 1024 bei Reserve	Kleinere Tiles brauchen weniger VRAM, sind aber langsamer Für 8GB bei 512 beginnen
overlap	Überlappung zwischen Tiles	64	Verhindert Nähte 32–128 testen
fast mode	Schneller Modus	true	Meist aktivieren
temporal_size	Zeitlicher Chunk nur für Video-VAE	8 bei wenig VRAM 16 bei Reserve	Verarbeitet Frames in Gruppen Nur für Video-VAE
temporal_overlap	Überlappung zeitlicher Chunks	2–4	Kontinuität zwischen Frame-Gruppen

Spitzenvergleich von SynpixCloud

Auflösung	Standard-VAE	Tiled 512	Tiled 1024
1024×1024	~2GB	~0,5GB	~1GB
2048×2048	~8GB	~1GB	~2,5GB

Tiled VAE einsetzen bei

• Auflösungen über 1024×1024
• GPUs mit 8–12GB
• Video-VAE-Workflows
• OOM in Hires Fix, Upscale oder FaceDetailer

Hinweis zur Dokumentation: Die Node-Dokumentation ist als AI-generated gekennzeichnet. Prüfe UI und Parameter in deiner aktuellen ComfyUI-Version.

---

OOM nach der Quelle der VRAM-Spitze beheben

Bei CUDA out of memory prüfst du die größten Spitzen zuerst und wendest jeweils eine konkrete Reduktion an.

OOM-Tabelle

Spitzenquelle	VRAM-Beispiel	Reduktion	Priorität
Modellgewichte	SDXL ~6,5GB FLUX fp16 ~23GB	Auf fp8/GGUF wechseln —lowvram/—novram	P0
T5-Encoder	fp16 ~9GB	T5 fp8/GGUF mit kompatiblem Loader	P0 für FLUX
Latent-Auflösung	2048×2048 ~8GB	Auf 1024×1024 oder 512×512 senken	P1
VAE Encode/Decode	2048×2048 bis etwa 8GB	Tiled VAE, tile_size=512, overlap=64	P1
Batch-Größe	batch size=4 bei 1024×1024 etwa 8–12GB	batch size=1 batch count in Queue	P2
ControlNet/Detailer	Je etwa 2–3GB	ControlNet-Pfad deaktivieren Low-VRAM-Route nutzen	P2
Videoframes	Frames × Auflösung × VideoVAE	Temporal Chunking Frames reduzieren Tiled Video-VAE	P2 für Video
Cache/Preview	~0,5–1GB	—preview-method none —cache-none	P3

Reihenfolge der Maßnahmen

1. Auflösung senken: 2048 → 1024 → 512
2. Preview deaktivieren: --preview-method none
3. fp8/GGUF-Modell einsetzen: FLUX Q4_K_S, Q5_K_S oder Klein 4B
4. T5 auf fp8/GGUF umstellen: Für Low-VRAM-FLUX wichtig
5. Tiled VAE einsetzen: Mit tile_size=512 und overlap=64 beginnen
6. Batch-Größe senken: batch size=1, batch count in die Queue
7. ControlNet und Nachbearbeitung deaktivieren: FaceDetailer, Hires Fix, Upscale
8. Bei Video: Frames senken und Temporal Chunking nutzen

---

Zwei Arten langsamer Generierung unterscheiden

Unterscheide zuerst zwischen „langsam, weil Offloading nötig ist“ und „unnötig langsam, weil eine Einstellung ungünstig ist“.

Geschwindigkeitstabelle

Engpass	Merkmal	Diagnose	Anpassung
Erwartete Low-VRAM-Verzögerung
—lowvram/—novram	20–70% langsamer	Startparameter prüfen	Verzögerung akzeptieren Oder GPU mit mehr VRAM
GGUF-Offloading in RAM	Niedrige GPU-Auslastung	GPU-Auslastung prüfen	RAM-Bandbreite begrenzt Bei genug VRAM fp8/fp16
Video mit vielen Frames	VAE Decode langsam	Frames × Auflösung berechnen	Frames senken Temporal Tiling
CPU-Modus —cpu	Extrem langsam	Startparameter prüfen	Nur letzter Ausweg GPU verwenden
Unerwartete Verzögerung
Zu viele Sampler-Steps	FLUX dev über 20 Steps	KSampler prüfen	Für FLUX dev reichen oft 20 schnell/Klein 4B nur vier
Attention-Backend ungünstig	Hoher Speicherbedarf	Startparameter prüfen	Kompatibles xformers Oder PyTorch SDP testen
VAE Decode langsam	tile_size zu klein	VAEDecodeTiled prüfen	Von 512 auf 1024 Etwa 1GB mehr Spitze, 10–30% schneller im Beispiel
CPU-Offload wartet	CPU-GPU-Wartezeit	Startparameter prüfen	—async-offload Genug RAM, häufig 32GB+
Disk-/RAM-Cache ungünstig	Modell lädt wiederholt	Startparameter prüfen	—cache-lru 10 10 Ergebnisse cachen
Anderer Prozess nutzt GPU	Wenig nutzbare GPU-Leistung	Systemmonitor prüfen	Browser, Spiele, Videoeditor schließen

Maßnahmen in dieser Reihenfolge

1. xformers oder SDP Attention: pip install xformers für automatische Erkennung oder --use-pytorch-cross-attention testen; Referenzwerte: 20–30% weniger VRAM und 5–20% schneller
2. FLUX mit vier Steps: schnell oder Klein 4B statt dev mit 20 Steps
3. Tiled-VAE-tile_size erhöhen: 512 → 1024; etwa 1GB mehr Spitze für mögliche 10–30% Beschleunigung
4. Async Offload aktivieren: --async-offload bei ausreichend RAM
5. Andere GPU-Prozesse schließen: Browser, Spiele und Videoeditoren

SynpixCloud-Beobachtung: xformers/SDP Attention benötigte 20–30% weniger VRAM und war 5–20% schneller.

Local-AI-Master-Beobachtung: FLUX.2 Klein 4B Q4_K_M mit vier Steps, 1024×1024 und 8GB brauchte etwa 15–30 Sekunden.

Veränderlicher Benchmark: Alle Werte sind umgebungsspezifische Referenzen.

---

Warum eine kleinere GGUF-Datei langsamer sein kann

Eine GGUF-Datei wie Q4_K_S mit etwa 6,8GB kann trotz geringerer Größe als FLUX fp16 mit etwa 23GB langsamer generieren:

• GGUF kann Modellgewichte in System-RAM auslagern, statt sie im VRAM zu halten; die GPU-Auslastung sinkt
• Während der Inferenz werden Gewichte wiederholt von RAM zu VRAM übertragen
• RAM-Bandbreite ist viel geringer: DDR4/DDR5 etwa 25–50GB/s gegenüber GDDR6X mit etwa 500–1000GB/s

GGUF verwenden, wenn

• fp8 auf einer 6–8-GB-GPU nicht passt und GGUF der verbleibende FLUX-Weg ist
• Du langsamere Generierung akzeptierst, damit das Modell überhaupt läuft

GGUF vermeiden, wenn

• Eine 12GB+-GPU fp8 oder fp16 effizient ausführen kann
• Geschwindigkeit wichtiger ist als das Ausführen um jeden Preis

Apatero-Beobachtung: Q8_0 with CPU offloading may take 5-10 minutes per generation.

---

VRAM-Budget für Video: Frames × Auflösung × VideoVAE

Bei Video treiben Frames × Auflösung × VideoVAE den VRAM hoch. Hier geht es nur um Budget und Spitzenreduktion, nicht um einen vollständigen Wan- oder AnimateDiff-Workflow.

Budgetprinzip

Peak-VRAM ≈ Modellgewichte + T5 + Frames × Latent pro Frame + VideoVAE-Spitze.

Beispiele aus den zitierten ComfyUI-Wan2.2- und Local-AI-Master-Materialien

Videoeinstellung	VRAM-Budget	GPU	Hinweis
8 Frames bei 480p (640×360)	~6–8GB	6GB kann funktionieren	Im zitierten RTX-3050-6GB-Beispiel entstand etwa eine Sekunde Video in unter fünf Minuten
24 Frames bei 720p (1280×720)	~12–16GB	8GB Grenzfall/12GB gut	Temporal Tiling nötig
60 Frames bei 1080p (1920×1080)	~20–24GB+	16GB+	High-VRAM-Weg

Spitze senken

Temporal Tiling teilt Frames in kleinere Gruppen, etwa acht Frames pro Block. Die Parameter heißen temporal_size und temporal_overlap.

Tiled VAE verarbeitet VAE Decode jedes Frames in räumlichen Tiles.

Reduziere Frames von 60 auf 24 und dann auf 8 und teste zuerst die kleinste Ausführung.

Reduziere die Auflösung von 1080p auf 720p und dann 480p.

Das Quellmaterial nennt Wan 2.2 5B für ein 8GB-Ziel oder Wan 2.2 14B GGUF als Beispiel ab 6GB.

Veränderlicher Benchmark: Die Zahlen sind umgebungsspezifische Referenzwerte.

---

OOM bei Serienbildern: Batch Size statt Batch Count verstehen

Batch size und batch count erzeugen sehr unterschiedliche VRAM-Spitzen. Eine große batch size führt schnell zu OOM.

Batch size und batch count

Batch size berechnet mehrere Bilder gleichzeitig; Latents, VAE und aktive Tensoren wachsen mit. Batch count stellt mehrere kleine Batches nacheinander in die Queue und hält den aktiven Batch klein.

VRAM-Vergleich

Konfiguration	Auflösung	Peak-VRAM	OOM-Risiko
batch size=4	1024×1024	~8–12GB	Hoch durch Parallelität
batch count=4, batch size=1	1024×1024	~2–3GB	Niedriger durch sequenzielle Ausführung

Empfehlung

• Bei 6–8GB: batch size=1 und batch count=N
• Bei API-Batches: Queue und Concurrency Control des ComfyUI-API-Workflows verwenden, statt mehrere VRAM-schwere Requests gleichzeitig zu starten

---

Plötzlich OOM nach einem Update: Versionen prüfen

Wird derselbe Workflow nach einem PyTorch-, Treiber- oder ComfyUI-Update langsam oder fehlerhaft, kann sich die Umgebung verändert haben, obwohl Prompt und Graph gleich blieben.

Versionsänderungen mit VRAM-Effekt

PyTorch-CUDA-Verhalten ändert sich, darunter TF32/FP16-Standards und Allocator-Strategien. TF32 und FP16 sind nicht pauschal besser. PyTorch-Beispiele zeigen schnellere TF32-Matrixmultiplikation bei höherem numerischem Fehler. Auch Treiber-, ROCm- und CUDA-Versionen verändern das GPU-Verhalten.

Vorgehen

1. Vor dem Update die Umgebung mit conda oder pip freeze sichern
2. Neue Version in einer getrennten Umgebung testen
3. Stabile PyTorch-, CUDA- und Treiberversion notieren
4. Bei Regression auf eine feste Version zurückgehen

---

Experimentelle Beschleuniger und stabile Startpunkte trennen

Unterscheide fortgeschrittene Experimente von stabilen Einstellungen für den ersten Test.

Fortgeschrittene Experimente, keine Pflicht für 8GB

Option	Status	Risiko	Hinweis
--fast	Experimentell	Kann Qualität/Stabilität verändern	Von ComfyUI als experimental markiert
FlashAttention	Benötigt flash-attention	Manche CUDA-Versionen inkompatibel	Installation aufwendig
Sage Attention	Drittanbieter-Optimierung	Experimentell, kann Präzision verändern	Passende CUDA/PyTorch-Version nötig
TensorRT	TensorRT SDK und Zusatzsetup	Modellkonvertierung komplex	Nicht für Einsteiger

Stabile Startpunkte

Option	Status	Wirkung	Hinweis
xformers	Bei kompatibler Umgebung stabil	Referenz: 20–30% weniger VRAM, 5–20% schneller	pip install xformers ComfyUI erkennt es automatisch
SDP Attention mit —use-pytorch-cross-attention	Stabil	Referenz: 20–30% weniger VRAM, 5–20% schneller	ComfyUI wählt eventuell automatisch das beste Backend

---

Fazit

GPU-Klasse: Bestimme zuerst 6GB, 8GB, 12GB oder 16GB+ und beginne mit einem passenden Basis-Workflow.

Startparameter: Im zitierten Verhalten von v0.18.0+ ist Dynamic VRAM standardmäßig aktiv; --lowvram kann daher wirkungslos sein. Prüfe Parameter mit python main.py --help.

Quantisierung: Die zitierten Messungen nennen FLUX.2 Klein 4B GGUF als schnellen 8GB-Weg und FLUX.1 GGUF Q4_K_S, wenn das Einpassen wichtiger als Geschwindigkeit ist. GGUF-Offloading hängt stark von der RAM-Bandbreite ab.

Fehlerreihenfolge: Prüfe OOM nach Modellgewichten → T5 → Latent-Auflösung → VAE → batch size → ControlNet → Videoframes → Cache. Trenne bei Geschwindigkeit erwartete Offload-Verzögerung von einem einstellbaren Engpass.

Nächste Schritte

1. GPU-Klasse 6GB, 8GB, 12GB oder 16GB+ bestimmen
2. Für die zitierten 8GB-Fälle eine Route wie FLUX.2 Klein 4B oder FLUX.1 GGUF Q4_K_S wählen
3. Bei OOM die Speicher-Checkliste anwenden
4. Bei unerwarteter Langsamkeit die Geschwindigkeits-Checkliste anwenden
5. Für Video Temporal Tiling verwenden

Wenn die Basisumgebung noch nicht läuft, beginne mit dem ComfyUI-Einsteigerleitfaden. Bei roten Nodes, fehlenden Modellen oder nicht reproduzierbaren Workflows hilft die Checkliste zur Wiederverwendung von ComfyUI-Workflows. Falls die Wahl zwischen SDXL, SD 3.5 und FLUX noch offen ist, lies zuerst den Leitfaden zur Stable-Diffusion-Modellwahl.