- La cuantización GGUF reduce el tamaño de grandes modelos de difusión como FLUX.1 (de ~24 GB a 5–12 GB), permitiendo su ejecución en GPUs de consumo con 6–16 GB de VRAM.
- Instale el nodo personalizado ComfyUI-GGUF del desarrollador city96, coloque los
.ggufarchivos enComfyUI/models/unet/, y use el nodoUnetLoaderGGUFen lugar del cargador estándar UNETLoader. - Q4_K_S o Q5_K_S ofrecen la mejor relación calidad-VRAM para la mayoría de las tarjetas gráficas. Q8_0 es casi sin pérdidas, pero ahorra menos memoria. Q2_K está orientado a GPUs de 4–6 GB, con compromisos visibles en la calidad.
- El codificador de texto T5-XXL de FLUX (~9 GB en fp16) también puede cargarse como GGUF mediante
DualCLIPLoaderGGUF, liberando así una cantidad significativa adicional de VRAM.
GGUF es un formato binario desarrollado por el proyecto llama.cpp para almacenar pesos cuantizados de redes neuronales. Originalmente diseñado para LLM, fue adaptado para las UNets de modelos de difusión, y el nodo personalizado ComfyUI-GGUF nodo personalizado de city96 incorpora ese soporte a ComfyUI. El resultado práctico: FLUX.1-dev, que requiere aproximadamente 24 GB de VRAM en precisión completa BF16, se vuelve ejecutable en una GPU de 6–8 GB con cuantización Q4 —con una calidad de imagen que, a menudo, resulta indistinguible a simple vista del modelo en precisión completa.
Por qué GGUF es relevante para la generación de imágenes
.safetensors .safetensors archivos en FP16 o BF16. Para modelos de generaciones anteriores (SD1.5, unos 2 GB; SDXL, unos 7 GB), esto es manejable en hardware de gama media. En cambio, los archivos de precisión completa de FLUX.1 y SD3 ocupan 24 GB y 16 GB respectivamente, superando el límite de VRAM de cualquier GPU consumidora individual.
La cuantización GGUF asigna cada peso a una representación entera más pequeña. Un peso Q8_0 utiliza 8 bits en lugar de 16, reduciendo aproximadamente a la mitad el tamaño del modelo con una pérdida de calidad prácticamente imperceptible. Las variantes Q4 usan 4 bits por peso, reduciendo el tamaño a aproximadamente una cuarta parte del formato fp16. Estos ahorros se acumulan de forma espectacular en modelos con miles de millones de parámetros. Utilice la Calculadora de VRAM calculadora de memoria GPU
FLUX.1 también incluye un codificador de texto T5-XXL de gran tamaño (~9,3 GB en fp16). Combinar un UNet en formato GGUF con un codificador T5-XXL también en GGUF permite que toda la canalización FLUX.1 se ejecute en tarjetas gráficas que, de otro modo, serían completamente incapaces de ejecutarlo. Ambos componentes pueden cargarse de forma independiente en formato GGUF.
Instalación del nodo personalizado ComfyUI-GGUF
Mediante ComfyUI Manager (recomendado)
- Abra ComfyUI y haga clic en Manager en la barra lateral.
- Ir a Instalar nodos personalizados.
- Busque
nodo personalizado ComfyUI-GGUF. - Haga clic Instalar junto a la entrada de city96 y reinicie ComfyUI.
Instalación manual
Clone el repositorio en su directorio custom_nodes y luego instale su dependencia en Python:
cd ComfyUI/custom_nodes
git clone https://github.com/city96/ComfyUI-GGUF
Linux / macOS (entorno virtual):
source ComfyUI/venv/bin/activate
pip install -r ComfyUI/custom_nodes/ComfyUI-GGUF/requirements.txt
Windows (versión portátil de ComfyUI):
ComfyUIpython_embedspython.exe -m pip install -r ComfyUIcustom_nodesComfyUI-GGUFrequirements.txt
Windows (entorno virtual):
ComfyUIvenvScriptsactivate.bat
pip install -r ComfyUIcustom_nodesComfyUI-GGUFrequirements.txt
La dependencia principal es el paquete Python gguf . Reinicie ComfyUI tras la instalación.
Obtención de archivos de modelos GGUF
city96 publica versiones GGUF de FLUX.1-dev y FLUX.1-schnell en Hugging Face bajo el nombre de usuario city96. Busque city96 FLUX.1-dev-gguf en Hugging Face para encontrar el repositorio. Cada repositorio contiene varios .gguf archivos, uno por nivel de cuantización. Descargue únicamente el archivo correspondiente al nivel de cuantización deseado; no necesita descargarlos todos.
También están disponibles en Hugging Face versiones GGUF del codificador de texto T5-XXL (busque t5-v1_1-xxl-encoder-gguf). El codificador CLIP-L es lo suficientemente pequeño (~240 MB) como para que rara vez merezca la pena cuantizarlo.
Miembros de la comunidad también suben variantes GGUF de modelos FLUX ajustados finamente a CivitAI. La misma estructura de nodos y directorios se aplica independientemente del origen desde donde descargue el archivo.
Dónde colocar los archivos de modelos
| Tipo de archivo | Directorio |
|---|---|
UNet de difusión GGUF (p. ej., flux1-dev-Q4_K_S.gguf) | ComfyUI/models/unet/ |
Codificador de texto GGUF (p. ej., T5-XXL) .gguf) | ComfyUI/models/clip/ |
VAE (.safetensors, sin cambios) | ComfyUI/models/vae/ |
El VAE para FLUX no está cuantizado y permanece en su ubicación habitual. Únicamente el UNet y el codificador de texto se benefician de la carga en formato GGUF.
Uso de los nodos cargadores GGUF
Tras instalar ComfyUI-GGUF y reiniciar, aparecen nuevos nodos en el navegador de nodos. Estos reemplazan a sus equivalentes estándar en su flujo de trabajo: no puede cargar un .gguf archivo UNETLoader.
| estándar. | Reemplaza | Acepta |
|---|---|---|
UnetLoaderGGUF | UNETLoader | .gguf modelos de difusión |
UnetLoaderGGUFAdvanced | UNETLoader | .gguf con opciones adicionales |
DualCLIPLoaderGGUF | DualCLIPLoader | GGUF o .safetensors CLIP/T5 |
CLIPLoaderGGUF | CLIPLoader | Codificador CLIP único en formato GGUF |
Para un flujo de trabajo FLUX estándar: sustituya UNETLoader para UnetLoaderGGUF, y sustituya DualCLIPLoader para DualCLIPLoaderGGUF si también está utilizando un T5-XXL en formato GGUF. Conecte las salidas a los mismos nodos descendentes que antes: las formas de los tensores son compatibles.
Elección del nivel de cuantización
La tabla siguiente muestra cifras aproximadas únicamente para los pesos del UNet de FLUX.1. Su presupuesto total de VRAM debe cubrir además el VAE (~350 MB), los codificadores de texto (240 MB para CLIP-L, más la memoria asignada al T5-XXL) y los tensores intermedios durante la generación. Utilice la Referencia de requisitos de VRAM junto con esta tabla y consulte la guía para GPUs si está decidiendo qué tarjeta comprar.
| Cuantización | Tamaño aproximado del archivo (UNet de FLUX.1) | VRAM típica necesaria | Calidad frente a BF16 |
|---|---|---|---|
| BF16 (referencia) | ~24 GB | 24+ GB | Referencia |
| Q8_0 | ~12 GB | ~13 GB | Casi idéntica |
| Q5_K_S | ~8 GB | ~8–9 GB | Degradación mínima |
| Q4_K_S | ~7 GB | ~7–8 GB | Ligera, a menudo imperceptible |
| Q4_0 | ~6,5 GB | ~7 GB | Ligera |
| Q3_K_S | ~5,5 GB | ~6 GB | Moderado |
| Q2_K | ~4,5 GB | ~5 GB | Notable |
Puntos prácticos de partida: Q5_K_S o Q4_K_S para tarjetas de 8–12 GB (mejor relación calidad/VRAM). Q3_K_S o Q2_K para tarjetas de 6 GB si también utiliza un T5-XXL cuantizado. Q8_0 para tarjetas de 16 GB cuando desee máxima fidelidad manteniendo el modelo íntegramente en la VRAM.
Los puntos de control estándar de difusión se distribuyen como
En Q8_0, las diferencias respecto a BF16 son virtualmente imperceptibles en comparaciones lado a lado. En Q4_K_S, pueden observarse degradaciones muy sutiles en texturas finas y renderizado de texto tras una inspección minuciosa, pero las salidas son de calidad profesional para la mayoría de los casos de uso. Q2_K introduce una suavidad visible y artefactos ocasionales, especialmente en rostros y detalles finos; se trata de una opción de último recurso para hardware extremadamente limitado en memoria.
La velocidad de generación con GGUF puede ser comparable o incluso superior a la de cargar un modelo BF16 con descarga a CPU, ya que los pesos cuantizados reducen la presión sobre el ancho de banda de memoria. Sin embargo, si su GPU puede alojar íntegramente el modelo BF16 en la VRAM sin descarga, esto generalmente será más rápido que la inferencia con GGUF. La ventaja de velocidad de GGUF es más pronunciada cuando la alternativa implica intercambiar capas entre la VRAM y la memoria del sistema.
En Apple Silicon (macOS), el backend MPS admite la inferencia GGUF mediante ComfyUI-GGUF, aunque las características de rendimiento difieren de las de CUDA de NVIDIA. Los resultados son funcionales, pero la velocidad de generación puede ser inferior a la de una GPU NVIDIA equivalente. La arquitectura de memoria unificada de Apple Silicon implica que el límite práctico de VRAM es mayor que el de las GPUs discretas con la misma capacidad nominal, por lo que podría ejecutar niveles de cuantización superiores a los indicados en la tabla anterior.
En GPUs AMD (Linux, ROCm), la inferencia GGUF funciona mediante el backend ROCm de PyTorch. Instale previamente la versión de PyTorch compatible con ROCm para ComfyUI antes de instalar ComfyUI-GGUF. El rendimiento y la compatibilidad varían según la generación de la GPU; las tarjetas RDNA 3 (serie RX 7000) ofrecen el soporte más fiable.
Preguntas frecuentes
¿Puedo cargar un archivo .gguf con el nodo estándar UNETLoader?
No. El nodo estándar UNETLoader solo acepta archivos .safetensors . Debe instalar el nodo personalizado ComfyUI-GGUF y utilizar UnetLoaderGGUF para cargar modelos de difusión .gguf .
¿Necesito cuantizar yo mismo mis modelos o puedo descargar archivos ya cuantizados?
Para FLUX.1-dev y FLUX.1-schnell, city96 proporciona en Hugging Face archivos GGUF pre-cuantizados que cubren todos los principales niveles de cuantización. Descargue el archivo .gguf específico correspondiente al nivel deseado; no necesita ejecutar ninguna herramienta de cuantización por su cuenta.
¿Funciona GGUF con modelos SD1.5 y SDXL?
Técnicamente sí, pero el beneficio es pequeño. SD1.5 ocupa ~2 GB y SDXL ~7 GB en fp16, ambos caben cómodamente en GPUs de gama media para consumidores. La cuantización GGUF resulta más valiosa para modelos muy grandes (FLUX.1, SD3), cuyos pesos en precisión completa superan la capacidad de VRAM de la mayoría de las tarjetas.
¿Un T5-XXL en GGUF es notablemente peor que la versión fp16 completa?
En Q8_0 o Q5_K_S, el seguimiento de prompts y la calidad de la codificación textual son efectivamente idénticos a los de fp16. En niveles de cuantización inferiores (Q2_K, Q3_K_S) puede producirse ocasionalmente una adherencia ligeramente reducida a prompts complejos, pero este efecto es sutil comparado con el impacto sobre la calidad del UNet al mismo nivel de cuantización.
Mi flujo de trabajo fue creado para un modelo FLUX en precisión completa. ¿Debo reconstruirlo?
No. Sustituya UNETLoader con UnetLoaderGGUF y (opcionalmente) DualCLIPLoader con DualCLIPLoaderGGUF. Todas las conexiones descendentes — KSampler, decodificación VAE, condicionamiento — permanecen sin cambios. Las salidas de estos nodos son compatibles en forma de tensor con el resto de un flujo de trabajo FLUX estándar.
¿Por qué ComfyUI sigue agotando la VRAM incluso con un modelo cuantizado?
El UNet GGUF constituye solo una parte del consumo total de VRAM. Una canalización FLUX completa también carga CLIP-L (~240 MB), T5-XXL (hasta ~9,3 GB en fp16) y el VAE (~350 MB), además de los búferes de trabajo durante la generación. Si sigue experimentando agotamiento de VRAM, cargue también el T5-XXL en formato GGUF mediante DualCLIPLoaderGGUFy considere habilitar el mosaico integrado del VAE en ComfyUI para el paso de decodificación.
