ComfyUI GGUF: Große Diffusionsmodelle auf GPUs mit geringem VRAM ausführen

GGUF ist ein Binärformat, das vom llama.cpp-Projekt zur Speicherung quantisierter neuronaler Netzwerk-Gewichte entwickelt wurde. Ursprünglich für Sprachmodelle (LLMs) konzipiert, wurde es später auch für UNets von Diffusionsmodellen angepasst; der ComfyUI-GGUF benutzerdefinierte Knoten von city96 integriert diese Funktionalität nun in ComfyUI. Das praktische Ergebnis: FLUX.1-dev, das im vollständigen BF16-Präzisionsmodus rund 24 GB VRAM benötigt, lässt sich bereits bei Q4-Quantisierung auf einer GPU mit 6–8 GB VRAM ausführen – bei einer Bildqualität, die dem menschlichen Auge oft nicht vom Originalmodell zu unterscheiden ist.

Warum GGUF für die Bildgenerierung wichtig ist

.safetensors ausgeliefert Dateien im FP16- oder BF16-Format. Bei älteren Modellgenerationen (SD1.5 mit ca. 2 GB, SDXL mit ca. 7 GB) ist dies auf Hardware mittlerer Leistungsklasse noch handhabbar. Bei FLUX.1 und SD3 hingegen betragen die Dateigrößen in voller Präzision 24 GB bzw. 16 GB – weit über der VRAM-Kapazität jeder einzelnen Consumer-GPU.

Die GGUF-Quantisierung ordnet jedes Gewicht einer kleineren ganzzahligen Darstellung zu. Ein Q8_0-Gewicht nutzt 8 Bit statt 16 und halbiert damit die Modellgröße nahezu ohne spürbaren Qualitätsverlust. Q4-Varianten verwenden 4 Bit pro Gewicht und reduzieren die Größe auf etwa ein Viertel der FP16-Version. Diese Einsparungen summieren sich bei Modellen mit Milliarden von Parametern dramatisch. Nutzen Sie den VRAM-Rechner um vor dem Download abzuschätzen, wie viel GPU-Speicher ein bestimmtes Quantisierungsniveau benötigt.

FLUX.1 verfügt zudem über einen großen T5-XXL-Textencoder (ca. 9,3 GB im FP16-Format). Die Kombination eines GGUF-basierten UNets mit einem GGUF-basierten T5-XXL-Encoder ermöglicht es, die gesamte FLUX.1-Pipeline auf Grafikkarten auszuführen, auf denen sie andernfalls gar nicht lauffähig wäre. Beide Komponenten können unabhängig voneinander im GGUF-Format geladen werden.

Installation des ComfyUI-GGUF-Benutzerknotens

Über ComfyUI Manager (empfohlen)

1. Öffnen Sie ComfyUI und klicken Sie auf Manager in der Seitenleiste.
2. Gehe zu Benutzerdefinierte Knoten installieren.
3. Suchen Sie nach ComfyUI-GGUF.
4. Klicken Installieren neben dem Eintrag von city96 und starten Sie ComfyUI danach neu.

Manuelle Installation

Klonen Sie das Repository in Ihr Verzeichnis custom_nodes und installieren Sie die erforderliche Python-Abhängigkeit:

cd ComfyUI/custom_nodes
git clone https://github.com/city96/ComfyUI-GGUF

Linux / macOS (venv):

source ComfyUI/venv/bin/activate
pip install -r ComfyUI/custom_nodes/ComfyUI-GGUF/requirements.txt

Windows (portable ComfyUI):

ComfyUIpython_embedspython.exe -m pip install -r ComfyUIcustom_nodesComfyUI-GGUFrequirements.txt

Windows (venv):

ComfyUIvenvScriptsactivate.bat
pip install -r ComfyUIcustom_nodesComfyUI-GGUFrequirements.txt

Die wichtigste Abhängigkeit ist das Python-Paket gguf . Starten Sie ComfyUI nach der Installation neu.

Beschaffung der GGUF-Modelldateien

city96 stellt GGUF-Versionen von FLUX.1-dev und FLUX.1-schnell auf Hugging Face unter dem Benutzernamen city96bereit. Suchen Sie auf Hugging Face nach city96 FLUX.1-dev-gguf , um das entsprechende Repository zu finden. Jedes Repository enthält mehrere .gguf Dateien, jeweils eine pro Quantisierungsstufe. Laden Sie lediglich die einzelne Datei herunter, die der gewünschten Quantisierungsstufe entspricht – Sie benötigen nicht alle Dateien.

GGUF-Versionen des T5-XXL-Textencoders sind ebenfalls auf Hugging Face verfügbar (suchen Sie nach t5-v1_1-xxl-encoder-gguf). Der CLIP-L-Encoder ist mit ca. 240 MB so klein, dass eine Quantisierung in der Regel keinen nennenswerten Aufwand lohnt.

Community-Mitglieder stellen zudem GGUF-Varianten feinabgestimmter FLUX-Modelle auf CivitAI bereit. Die gleiche Knoten- und Verzeichnisstruktur gilt unabhängig davon, von wo Sie die Datei herunterladen.

Wo die Modelldateien abzulegen sind

Der VAE für FLUX wird nicht quantisiert und bleibt an seinem üblichen Ort. Nur das UNet und der Textencoder profitieren von der GGUF-Ladefunktion.

Verwendung der GGUF-Ladeknoten

Nach der Installation von ComfyUI-GGUF und dem Neustart von ComfyUI erscheinen neue Knoten im Knotenbrowser. Diese ersetzen ihre Standardentsprechungen in Ihrem Workflow – Sie können eine .gguf Datei nicht mit dem Standardknoten UNETLoader.

Für einen Standard-FLUX-Workflow: Tauschen Sie UNETLoader für UnetLoaderGGUF, und tauschen Sie DualCLIPLoader für DualCLIPLoaderGGUF aus, falls Sie zudem ein GGUF-basiertes T5-XXL verwenden. Verbinden Sie die Ausgaben mit denselben nachgeschalteten Knoten wie zuvor – die Tensorformate sind kompatibel.

Auswahl des Quantisierungsgrads

Die folgende Tabelle zeigt ungefähre Werte ausschließlich für die FLUX.1-UNet-Gewichte. Ihr gesamtes VRAM-Budget muss außerdem den VAE (~350 MB), die Text-Encoder (240 MB für CLIP-L sowie zusätzlichen Speicherplatz für T5-XXL) und die während der Generierung benötigten Arbeitstensoren abdecken. Nutzen Sie die Referenz zu VRAM-Anforderungen zusammen mit dieser Tabelle und konsultieren Sie den GPU-Leitfaden bei der Entscheidung, welche Grafikkarte Sie kaufen sollen.

Praktische Startpunkte: Q5_K_S oder Q4_K_S für Grafikkarten mit 8–12 GB VRAM (bestes Verhältnis von Qualität zu VRAM). Q3_K_S oder Q2_K für 6-GB-Karten, falls Sie zudem ein quantisiertes T5-XXL verwenden. Q8_0 für 16-GB-Karten, wenn Sie maximale Genauigkeit wünschen und das Modell dennoch vollständig in den VRAM laden möchten.

Standard-Diffusions-Checkpoints werden als

Bei Q8_0 sind Unterschiede gegenüber BF16 in direkten Seit-an-Seit-Vergleichen praktisch nicht erkennbar. Bei Q4_K_S können bei genauer Betrachtung feine Texturen und Textdarstellungen sehr subtil an Qualität verlieren; die Ergebnisse sind jedoch für die meisten Anwendungsfälle produktionsreif. Q2_K führt zu sichtbarer Weichzeichnung und gelegentlichen Artefakten, insbesondere bei Gesichtern und feinen Details – es stellt daher eine letzte Option für extrem speichereingeschränkte Hardware dar.

Die Generierungsgeschwindigkeit mit GGUF kann vergleichbar sein oder sogar schneller als das Laden eines BF16-Modells mit CPU-Offloading, da quantisierte Gewichte den Speicherbandbreitenbedarf reduzieren. Falls Ihre GPU jedoch das vollständige BF16-Modell ohne Offloading komplett im VRAM halten kann, ist dies in der Regel schneller als die GGUF-Inferenz. Der Geschwindigkeitsvorteil von GGUF fällt am deutlichsten aus, wenn die Alternative das Zwischenspeichern von Layern zwischen VRAM und Systemspeicher erfordert.

Auf Apple Silicon (macOS), unterstützt der MPS-Backend GGUF-Inferenz über ComfyUI-GGUF, doch unterscheiden sich die Leistungsmerkmale von NVIDIA CUDA. Die Ergebnisse sind funktionsfähig, doch kann die Generierungsgeschwindigkeit langsamer sein als auf einer vergleichbaren NVIDIA-GPU. Aufgrund der einheitlichen Speicherarchitektur von Apple Silicon liegt die praktische VRAM-Obergrenze höher als bei diskreten GPUs mit derselben nominellen Kapazität; Sie können daher möglicherweise höhere Quantisierungsstufen nutzen, als es die obige Tabelle nahelegt.

Auf AMD-GPUs (Linux, ROCm), funktioniert GGUF-Inferenz über PyTorchs ROCm-Backend. Installieren Sie vor der Installation von ComfyUI-GGUF zunächst die ROCm-kompatible PyTorch-Version für ComfyUI. Leistung und Kompatibilität variieren je nach GPU-Generation; RDNA-3-Karten (RX-7000-Serie) bieten die zuverlässigste Unterstützung.

Häufig gestellte Fragen

Kann ich eine .gguf-Datei mit dem Standard-UNETLoader-Knoten laden?

Nein. Der Standard- UNETLoader akzeptiert ausschließlich ausgeliefert -Dateien. Sie müssen den benutzerdefinierten ComfyUI-GGUF-Knoten installieren und UnetLoaderGGUF verwenden, um .gguf Diffusionsmodelle zu laden.

Muss ich meine eigenen Modelle selbst quantisieren, oder kann ich vorkuantisierte Dateien herunterladen?

Für FLUX.1-dev und FLUX.1-schnell stellt city96 auf Hugging Face vorkuantisierte GGUF-Dateien für sämtliche wichtigen Quantisierungsstufen bereit. Laden Sie die jeweilige .gguf -Datei für die gewünschte Stufe herunter – Sie müssen keinerlei Quantisierungswerkzeuge selbst ausführen.

Funktioniert GGUF auch für SD1.5- und SDXL-Modelle?

Technisch ja, doch der Nutzen ist gering. SD1.5 umfasst etwa 2 GB und SDXL etwa 7 GB im fp16-Format – beide passen problemlos auf Consumer-GPUs mittlerer Klasse. GGUF-Quantisierung ist vor allem bei sehr großen Modellen (FLUX.1, SD3) sinnvoll, deren vollpräzise Gewichte die VRAM-Kapazität der meisten Grafikkarten überschreiten.

Ist ein GGUF-basiertes T5-XXL spürbar schlechter als die vollständige fp16-Version?

Bei Q8_0 oder Q5_K_S entsprechen Prompt-Following und Text-Encoding-Qualität praktisch exakt der fp16-Version. Bei niedrigeren Quantisierungsstufen (Q2_K, Q3_K_S) kann es gelegentlich zu leicht beeinträchtigter Prompt-Adhärenz bei komplexen Prompts kommen, doch ist dieser Effekt im Vergleich zum Einfluss derselben Quantisierungsstufe auf die UNet-Qualität eher subtil.

Mein Workflow wurde für ein vollpräzises FLUX-Modell erstellt. Muss ich ihn neu aufbauen?

Nein. Ersetzen Sie UNETLoader mit UnetLoaderGGUF und (optional) DualCLIPLoader mit DualCLIPLoaderGGUF. Alle nachgeschalteten Verbindungen – KSampler, VAE-Dekodierung, Conditioning – bleiben unverändert. Die Knotenausgaben sind mit den übrigen Komponenten eines Standard-FLUX-Workflows tensorkompatibel.

Warum stößt ComfyUI trotz eines quantisierten Modells immer noch an die VRAM-Grenze?

Der GGUF-UNet-Knoten stellt nur einen Teil des gesamten VRAM-Bedarfs dar. Eine vollständige FLUX-Pipeline lädt zudem CLIP-L (~240 MB), T5-XXL (bis zu ~9,3 GB im fp16-Format) und den VAE (~350 MB) sowie Arbeitsspeicherpuffer während der Generierung. Falls Sie weiterhin an die Grenze stoßen, laden Sie T5-XXL ebenfalls als GGUF über DualCLIPLoaderGGUF, und aktivieren Sie gegebenenfalls die integrierte VAE-Tiling-Funktion von ComfyUI für den Dekodierungsschritt.