- Die GGUF-Quantisierung reduziert große Diffusionsmodelle wie FLUX.1 von ursprünglich ~24 GB auf 5–12 GB und ermöglicht so ihren Betrieb auf Consumer-GPUs mit 6–16 GB VRAM.
- Installieren Sie den ComfyUI-GGUF benutzerdefinierten Knoten von city96, platzieren Sie die
.ggufDateien inComfyUI/models/unet/, und verwenden Sie stattdessen denUnetLoaderGGUF-Knoten anstelle des Standard-UNETLoaders. - Q4_K_S oder Q5_K_S bieten bei den meisten Grafikkarten das beste Verhältnis aus Qualität und VRAM-Verbrauch. Q8_0 ist nahezu verlustfrei, spart aber weniger Speicherplatz. Q2_K richtet sich an GPUs mit 4–6 GB VRAM und geht mit sichtbaren Einbußen bei der Qualität einher.
- Der T5-XXL-Textencoder von FLUX (~9 GB im fp16-Format) kann ebenfalls als GGUF geladen werden – mithilfe des
DualCLIPLoaderGGUF-Knotens – wodurch erheblich mehr VRAM freigegeben wird.
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)
- Öffnen Sie ComfyUI und klicken Sie auf Manager in der Seitenleiste.
- Gehe zu Benutzerdefinierte Knoten installieren.
- Suchen Sie nach
ComfyUI-GGUF. - 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
| Dateityp | Verzeichnis |
|---|---|
GGUF-Diffusions-UNet (z. B. flux1-dev-Q4_K_S.gguf) |
ComfyUI/models/unet/ |
GGUF-Textencoder (z. B. T5-XXL .gguf) |
ComfyUI/models/clip/ |
VAE (ausgeliefert, unverändert) |
ComfyUI/models/vae/ |
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.
| laden. | Ersetzt | Akzeptiert |
|---|---|---|
UnetLoaderGGUF |
UNETLoader |
.gguf Diffusionsmodelle |
UnetLoaderGGUFAdvanced |
UNETLoader |
.gguf mit erweiterten Optionen |
DualCLIPLoaderGGUF |
DualCLIPLoader |
GGUF- oder ausgeliefert CLIP/T5 |
CLIPLoaderGGUF |
CLIPLoader |
Einzelner GGUF-CLIP-Encoder |
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.
| Quantisierung | Geschätzte Dateigröße (FLUX.1 UNet) | Typischer VRAM-Bedarf | Qualität im Vergleich zu BF16 |
|---|---|---|---|
| BF16 (Referenz) | ~24 GB | 24+ GB | Referenz |
| Q8_0 | ~12 GB | ~13 GB | Nahezu identisch |
| Q5_K_S | ~8 GB | ~8–9 GB | Minimaler Qualitätsverlust |
| Q4_K_S | ~7 GB | ~7–8 GB | Leicht, oft nicht wahrnehmbar |
| Q4_0 | ~6,5 GB | ~7 GB | Leicht |
| Q3_K_S | ~5,5 GB | ~6 GB | Mittel |
| Q2_K | ~4,5 GB | ~5 GB | Deutlich wahrnehmbar |
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.