FLUX.1 FP16 vs FP8: velocidad, calidad y compromisos de VRAM

FLUX.1 se ejecuta en dos modos de precisión que sirven a distintas restricciones de hardware. La cuantización FP8 reduce el almacenamiento de pesos aproximadamente a la mitad, pero los ejemplos oficiales de ComfyUI advierten que esto "degrada un poco la calidad". El compromiso se vuelve decisivo cuando la VRAM es limitada: una tarjeta de 12 GB puede necesitar FP8 para ejecutar FLUX.1 Dev en absoluto, mientras una tarjeta de 24 GB tiene espacio para FP16. Para más sobre GGUF y cuantización FP8 juntos, ver Métodos de cuantización GGUF. Para la configuración general del workflow de Flux, ver Workflows de Flux en ComfyUI. Para ejecutar FLUX en tarjetas más pequeñas, ver Flux con 8GB de VRAM.

TL;DR

• Tarjetas de 12 GB: usa checkpoints FP8 o variantes GGUF cuantizadas; FP16 Dev no cabe.
• Tarjetas de 24 GB: FP16 Dev a 50 pasos ofrece la mejor calidad; FP8 libera margen.
• Impacto en la calidad: FP8 "degrada un poco la calidad" según los documentos de ComfyUI; ningún benchmark cuantifica la diferencia perceptual exacta.
• Mecanismo de memoria: FP8 almacena los pesos en punto flotante de 8 bits (float8_e4m3fn), reduciendo la memoria de pesos frente al almacenamiento de 16 bits de FP16.

FLUX.1 Dev vs Schnell: estrategia de destilación

Black Forest Labs publica dos modelos de pesos abiertos con enfoques de destilación distintos. FLUX.1-schnell está destilado por pasos de tiempo (timestep-distilled): produce imágenes en 1–4 pasos sin un muestreador LCM. FLUX.1-dev está destilado por guía (guidance-distilled): requiere unos 50 pasos de muestreo para una buena salida.

La diferencia de pasos proviene de sus estrategias de destilación: Schnell aprende a generar directamente en pocos pasos, mientras que Dev aprende a refinar la calidad a lo largo de muchos pasos.

Mecanismos: cómo FP8 cambia la memoria y la latencia

La cuantización almacena los pesos en 8 bits en lugar de 16 bits. El proceso: llamar quantize() al módulo con el tipo de dato FP8, y luego freeze() reemplaza los parámetros originales por los cuantizados. Cita: "Estamos cuantizando al tipo de dato FP8… Finalmente llamamos a freeze() para reemplazar los parámetros originales por los parámetros cuantizados." URL: https://huggingface.co/blog/quanto-diffusers

En los benchmarks, cuantizar solo el backbone de difusión ahorró ~0,5 GB (12.086 → 11.547 GB). Añadir la cuantización del codificador de texto ahorró ~11 GB (16.403 → 5.363 GB). Cita: "Observamos los siguientes ahorros de memoria al usar FP8… Memoria (GB): 12.086 → 11.547." URL: https://huggingface.co/blog/quanto-diffusers

Los mismos benchmarks muestran que FP8 aumenta la latencia: 1.200 s → 1.540 s. Cita: "Latencia (Segundos): 1.200 → 1.540." URL: https://huggingface.co/blog/quanto-diffusers

ComfyUI integra esto mediante el nodo Load Diffusion Model, que acepta weight_dtype=fp8. Los ejemplos oficiales dicen: "Puedes configurar weight_dtype en el nodo 'Load Diffusion Model' a fp8, lo que reducirá el uso de memoria a la mitad, pero podría reducir la calidad un poco." URL: https://comfyanonymous.github.io/ComfyUI_examples/flux/

Requisitos de VRAM según el tamaño de tarjeta

Tarjetas de 12 GB

Una tarjeta de 12 GB no puede ejecutar FLUX.1 Dev en FP16; el transformador de FLUX.1 Dev tiene 12.500 millones de parámetros (según los documentos de memoria de diffusers), y combinado con los codificadores de texto esto supera un presupuesto de 12 GB. Los workflows de la comunidad sugieren:

• Checkpoint FP8: flux1-dev-fp8.safetensors + codificador de texto t5xxl_fp8_e4m3fn_scaled.safetensors
• Variantes GGUF: cuantización Q4_K_S o Q5_K_M mediante ComfyUI-GGUF

Los documentos de memoria de diffusers señalan que la cuantización "puede combinarse con otras técnicas de optimización de memoria… para equilibrar la velocidad de inferencia y el uso de memoria". Estos enfoques son esenciales en tarjetas de 12 GB.

Más allá de FP8: INT8 como alternativa

La cuantización INT8 es otro camino para reducir la VRAM, especialmente relevante para los modelos de difusión basados en transformadores. Los benchmarks de Quanto de HuggingFace encontraron que la cuantización INT8 "es generalmente mejor en términos de latencia de inferencia" en comparación con FP8 en los modelos probados (PixArt-Sigma, SD3, Aura Flow). Concretamente, INT8 alcanzó una latencia de 1.504 s frente a 1.601 s de FP8 en PixArt-Sigma (batch=1, codificador de texto cuantizado). Para FLUX.1 no se encontró ninguna comparación INT8 vs FP8 en las fuentes abiertas, por lo que la ventaja de latencia no puede confirmarse para este modelo específico. La misma documentación de Quanto señala que excluir la capa de proyección final ("proj_out") de la cuantización INT4 ayuda a preservar la calidad de imagen, un patrón que puede extenderse a otros formatos de cuantización.

El nodo personalizado ComfyUI-GGUF proporciona checkpoints de FLUX.1 cuantizados en GGUF que pueden volcar los pesos inactivos a la RAM del sistema o al disco, permitiendo ejecutarse en tarjetas con tan solo 4 GB de VRAM. Su README señala que los modelos transformer/DiT como FLUX parecen "menos afectados por la cuantización" en comparación con los modelos UNET convolucionales, lo que convierte a GGUF en una vía viable para tarjetas con muy poca VRAM.

La variante FP8 del modelo Schnell de Comfy-Org afirma explícitamente que ejecutarse en FP8 es "mucho más rápido y usa menos memoria" en comparación con FP16 (repositorio de Schnell FP8 de Comfy-Org). Esta es la única afirmación de rendimiento directa encontrada en el dossier para un modo de precisión específico de FLUX.1: la página de Dev FP8 describe solo el beneficio de VRAM, no de velocidad (repositorio de Dev FP8 de Comfy-Org).

Combinar pesos de modelo en FP8 con offloading a CPU, por ejemplo enable_model_cpu_offload(), mantiene la VRAM máxima más baja mientras añade algo de latencia al mover pesos entre CPU y GPU. Para presupuestos de VRAM muy ajustados, el offloading por grupos puede mover grupos de capas internas a la CPU y de vuelta en bloque. Estas estrategias están documentadas como compatibles con la cuantización y torch.compile.

Configuración práctica para cada tarjeta

Configuración para tarjeta de 12 GB

1. Descargar flux1-dev-fp8.safetensors de Comfy-Org en ComfyUI/models/checkpoints/
2. Descargar t5xxl_fp8_e4m3fn_scaled.safetensors en ComfyUI/models/text_encoders/
3. Usar el checkpoint FP8 con el nodo "Load Checkpoint"
4. Considerar GGUF + ComfyUI-GGUF para una VRAM aún menor

Configuración para tarjeta de 24 GB

1. Descargar flux1-dev.safetensors de Black Forest Labs en ComfyUI/models/diffusion_models/
2. Descargar t5xxl_fp16.safetensors del repositorio de codificadores de texto de Comfy-Org
3. Usar el workflow estándar de FLUX Dev con 50 pasos, guía 3.5
4. FP8 sigue siendo una opción si necesitas margen para modelos adicionales

Errores comunes y correcciones

Para una mirada más profunda a los ajustes de muestreador y scheduler más allá de lo cubiertos aquí, ver nuestra guía de muestreadores y schedulers. Para un recorrido completo sobre cómo configurar los workflows de Flux desde cero, incluidas las rutas de descarga de modelos y las conexiones de nodos, ver Workflows de Flux en ComfyUI.

FAQ

¿Cuánta VRAM necesita FLUX.1 Dev en FP8? Comfy-Org afirma que su checkpoint FP8 de archivo único funciona para usuarios con "menos VRAM (menos de 24gb)". No se publica un mínimo exacto.

¿FLUX.1 Schnell FP8 pierde calidad visible? Los ejemplos oficiales de ComfyUI dicen que FP8 "degrada la calidad un poco" en general. Para Schnell a 1–4 pasos, la diferencia de calidad puede ser mínima en muchos prompts.

¿Qué precisión elegir para una GPU de 12 GB? FP8 es necesario para Dev; las variantes GGUF (Q4_K_S) ofrecen una vía alternativa a través de ComfyUI-GGUF.

¿FP8 es realmente más rápida o solo más pequeña? Los mismos benchmarks de cuantización de HuggingFace que documentan el ahorro de memoria de FP8 muestran que FP8 en realidad aumenta la latencia: 1.200 s → 1.540 s. Si este patrón se mantiene para FLUX.1 no está documentado.

¿Puedo mezclar componentes FP8 y FP16? Sí. La documentación de diffusers señala que puedes aplicar distinta cuantización a distintos módulos del pipeline; por ejemplo, FP8 para el codificador de texto pero FP16 para el backbone de difusión.

¿Y la cuantización INT8? El blog de Quanto señala que la cuantización INT8 "es generalmente mejor en términos de latencia de inferencia" que FP8. Esto aplica a los modelos probados (PixArt-Sigma, SD3, Aura Flow), pero no existe ninguna comparación para FLUX.1.

¿Cómo afecta la elección del codificador T5 a la VRAM? Los ejemplos de ComfyUI señalan que el archivo del codificador T5 fp8-escalado está disponible para un menor uso de memoria. Cita: "Puedes usar t5xxl_fp8_e4m3fn_scaled.safetensors en su lugar para un menor uso de memoria, pero se recomienda el fp16 si tienes más de 32GB de RAM." URL: https://comfyanonymous.github.io/ComfyUI_examples/flux/