Optimizar ComfyUI con poca VRAM: SDXL, FLUX y video en GPU de 6–8 GB

El terminal muestra torch.cuda.OutOfMemoryError: CUDA out of memory. La console de ComfyUI informa regular VAE encoding, retrying with tiled VAE encoding, pero la imagen de 1024×1024 tampoco termina. Una RTX 3060 de 8 GB puede generar una imagen SDXL; al sumar Hires Fix, FaceDetailer y ControlNet, el consumo supera 12 GB. Al bajar a 768×768 y desactivar ControlNet, el workflow funciona por poco, pero la calidad ya no es la esperada.

En una GPU de consumo de 6–8 GB, Apple Silicon o hardware AMD, el objetivo es ejecutar SDXL, FLUX y workflows de video ligero con la mayor estabilidad posible y saber qué cambios sacrifican velocidad, calidad o compatibilidad.

---

Identifica primero la categoría de VRAM de tu GPU

El presupuesto de VRAM no es adivinanza. La categoría de la GPU determina qué workflows son realistas y qué estrategia conviene probar primero.

Categorías de VRAM, workflows y punto de partida

VRAM	Workflows viables	Límites y riesgos	Inicio recomendado
6GB	SDXL de baja resolución (512–768) FLUX muy comprimido (Q2_K/Q3_K_S + GGUF + —lowvram/—novram) Video: 8 frames a 480p como caso límite	Resolución limitada Los nodes extra causan OOM con facilidad Lento por offload a RAM	Cuantización agresiva como Q3_K_S Resolución de 512–768 Desactivar ControlNet y postprocesado Máximo 8 frames
8GB	Una imagen SDXL 1024×1024 FLUX fp8/GGUF Q4_K_S sin garantía 8 frames 480p cómodos, 24 frames 720p al límite	ControlNet con Hires Fix puede causar OOM T5 necesita fp8/GGUF No superar 1024×1024 FLUX.1 GGUF Q5_K_S va al límite	Priorizar FLUX.2 Klein 4B GGUF T5 fp8/GGUF Tiled VAE batch size=1
12GB	SDXL + ControlNet + upscale simple FLUX Q5_K_S/Q6_K con margen 24 frames 720p cómodos, 60 frames 1080p al límite	Varios ControlNet aún requieren cuidado Calcular frames × resolución El postprocesado mantiene límites	FLUX Q5_K_S/Q6_K T5 fp8 opcional Tiled VAE opcional Probar batch size 2–3
16GB+	FLUX full fp16 o Q8_0 casi sin pérdida Más margen para ControlNet/LoRA 60 frames 1080p	FLUX full ocupa unos 23 GB Frames × resolución sigue importando El postprocesado aún crea picos	FLUX Q8_0 o fp16 T5 fp16 Tiled VAE opcional Probar batch size 4–8

Fuentes de pico, de mayor a menor

1. Pesos del modelo: checkpoint SDXL de unos 6,5 GB; FLUX fp16 de unos 23 GB
2. Codificador T5: fp16 ronda 9 GB y supera una GPU de 8 GB; fp8 usa unos 4–5 GB; GGUF ofrece Q3/Q4/Q5
3. Resolución latente: un latent 2048×2048 puede acercarse a 8 GB
4. VAE encode/decode: 2048×2048 puede alcanzar picos de unos 8 GB
5. Batch size: la inferencia simultánea crea el pico más alto
6. ControlNet/Detailer: cada uno puede sumar unos 2–3 GB
7. Frames de video: frames × resolución × VideoVAE
8. Cache/preview: alrededor de 0,5–1 GB

El consumo real depende de resolución, precisión, versión del modelo, batch, nodes de postprocesado, frames, PyTorch, driver y custom nodes. Puede variar 1–2 GB. Usa la tabla como presupuesto inicial y mide el workflow real.

---

Argumentos de inicio de ComfyUI para poca VRAM

ComfyUI ofrece argumentos para controlar VRAM y memoria del sistema. Cambian con las versiones. La tabla se basa en ComfyUI v0.18.0+ alrededor de marzo de 2026; python main.py --help y la documentación oficial actual tienen prioridad.

Argumentos, función, GPU y efecto en velocidad

Argumento	Función	GPU	Efecto en velocidad	Uso
--lowvram	Divide el modelo y transmite partes desde RAM	4–8GB	20–40 % más lento	Sin efecto con Dynamic VRAM activo Probar tras —normalvram
--novram	Conserva pesos en CPU/RAM y lleva solo el cálculo activo a GPU	Menos de 4GB	50–70 % más lento	Último recurso Muy lento, pero puede funcionar
--normalvram	Fuerza modo estándar y desactiva Dynamic VRAM	12GB+	Sin efecto esperado	Para probar —lowvram manualmente O ante OOM por fragmentación
--reserve-vram N	Reserva N GB de VRAM para el sistema	Todas	Sin efecto esperado	Evita inestabilidad Suele reservarse 2–4 GB
--async-offload	Descarga pesos de forma asíncrona	Todas	Ejemplo: 5–10 % más rápido	Reduce espera CPU–GPU con mucha RAM, normalmente 32 GB+
--fp8_e4m3fn-unet	Fuerza UNet en fp8	8–12GB	Aproximadamente neutro	FLUX puede ignorarlo Revisar compute dtype
--fp8_e4m3fn-text-enc	Usa fp8 en el codificador de texto	8GB	Aproximadamente neutro	Reduce T5 de unos 9 a 4–5 GB Útil para FLUX con poca VRAM
--fp8_e5m2fn-text-enc	Otra variante fp8 para texto	8GB	Aproximadamente neutro	Alternativa a fp8_e4m3fn
--preview-method none	Desactiva previews	Todas	Algo más rápido	Ahorra unos 0,5–1 GB Primer test de OOM
--cache-none	Desactiva cache	Poca RAM	Más lento	Ahorra RAM, pero recalcula
--cache-lru 10	Guarda 10 resultados en cache LRU	RAM suficiente	Más rápido	Equilibrio razonable Probar 10–20
--cache-classic	Cache agresivo clásico	RAM suficiente	Más rápido	Puede usar más RAM
--force-fp16	Fuerza fp16 global	Todas	Aproximadamente neutro	Puede ahorrar 2–3 GB
--use-pytorch-cross-attention	Fuerza PyTorch SDP attention	Todas	Ejemplo: 5–20 % más rápido	ComfyUI suele elegir xformers/SDP automáticamente Forzar solo en un test
--use-flash-attention	Fuerza Flash Attention	Todas	Ejemplo: 5–20 % más rápido	Requiere flash-attention Algunas versiones CUDA no son compatibles
--fast	Modo rápido experimental	Todas	Incierto	Experimento avanzado Puede afectar calidad/estabilidad No es requisito para 8 GB

Ejemplos de comandos

# Configuración base para 8 GB de VRAM
python main.py --lowvram --force-fp16 --fp8_e4m3fn-text-enc --preview-method none

# Configuración límite para 6 GB de VRAM
python main.py --novram --force-fp16 --fp8_e4m3fn-text-enc --preview-method none --reserve-vram 2

# Configuración de velocidad con suficiente RAM
python main.py --async-offload --cache-lru 10 --use-pytorch-cross-attention

Datos variables: los argumentos pueden cambiar. Consulta python main.py --help y la documentación actual. FLUX puede ignorar --fp8_e4m3fn-unet por su compute dtype interno; configura weight_dtype en el node cuando sea necesario.

---

Por qué —lowvram no evita el OOM

ComfyUI v0.18.0+ alrededor de marzo de 2026 activa Dynamic VRAM de forma predeterminada. Cuando está activo, --lowvram se ignora porque ya existe una estrategia adaptativa de offload.

Cuándo usar --lowvram manualmente

• Después de desactivar Dynamic VRAM con --normalvram
• Si un workflow sufre OOM por fragmentación, probar --disable-dynamic-vram

Alternativas

• Usar el comportamiento predeterminado de Dynamic VRAM
• Reservar --novram para el último recurso y aceptar una pérdida de velocidad de 50–70 %
• Dejar margen al sistema con --reserve-vram 2-4

Ventaja de Dynamic VRAM: calcula el espacio disponible y descarga a RAM automáticamente.

Riesgo de Dynamic VRAM: algunos workflows siguen sufriendo OOM por fragmentación. En ese caso, prueba --disable-dynamic-vram.

---

Tres rutas de FLUX en 8 GB: fp8, GGUF y Klein 4B

FLUX es un modelo de 12 mil millones de parámetros cuyo archivo original ronda 23 GB. En 8 GB hay tres rutas, cada una con un costo.

Rutas de cuantización FLUX

Ruta	Tamaño	VRAM	Calidad vs fp16	GPU	Velocidad	Compatibilidad	Uso
FLUX full (fp16)	~23GB	~20GB+	100 %	24GB+	La más rápida	Oficial	Uso profesional VRAM suficiente
FLUX fp8 checkpoint	~12GB	~11GB	~95–98 %	12GB cómodo/16GB+	Bastante rápida	Cuantización oficial	12GB+ Un archivo
FLUX GGUF Q8_0	~12,7GB	~11GB	~99 %	12GB+/16GB+	Más lenta con offload	node city96, WIP	12GB+ Casi sin pérdida
FLUX GGUF Q5_K_S	~8,5GB	~7,5GB	~94–96 %	8GB límite/12GB cómodo	Lenta con offload	node city96, WIP	8GB Equilibrio de calidad
FLUX GGUF Q4_K_S	~6,8GB	~6,5GB	~88–90 %	8GB/6GB límite	La más lenta	node city96, WIP	6–8GB Priorizar ejecución
FLUX.2 Klein 4B GGUF Q4_K_M	~2,6GB	~2,6GB	Calidad propia del modelo 4B	8GB cómodo	Cuatro steps, rápida	Apache 2.0, node city96	Para 8GB Cuatro steps Rápida

Codificador T5

Versión T5	Tamaño	VRAM	GPU
T5 fp16	~9GB	~9GB	24GB+, supera 8GB
T5 fp8_e4m3fn	~4–5GB	~4–5GB	Viable en 8GB
T5 GGUF Q3/Q4/Q5	~2–4GB	~2–4GB	Casos límite 6–8GB

Instalación

Para fp8, descarga el archivo safetensors, cárgalo con Load Diffusion Model y establece weight_dtype en fp8_e4m3fn.

Para GGUF, instala el custom node ComfyUI-GGUF de city96, carga el modelo con Unet Loader (GGUF) y coloca el archivo en models/unet/.

Riesgo del node externo: GGUF está marcado WIP y el soporte de LoRA es experimental. Cambia con frecuencia y no es una ruta oficial integrada.

Observación de calidad de Apatero: Q5_K_S se acerca a fp16, con diferencias más visibles en texto y patrones finos. Q4_K_S pierde más detalle.

Observación de velocidad de Local AI Master

• FLUX.1-dev Q4_K_S + —lowvram, 1024×1024, 20 steps, RTX 3060 Ti 8GB: unos 90–150 segundos
• FLUX.2 Klein 4B Q4_K_M, 1024×1024, cuatro steps, 8GB: unos 15–30 segundos

Benchmark variable: hardware, versiones y workflow cambian mucho estas cifras. Úsalas como rangos de referencia.

---

Reducir OOM de VAE Encode/Decode con Tiled VAE

A 2048×2048 o en video, VAE Encode/Decode puede agotar la VRAM. Tiled VAE procesa la imagen por regiones pequeñas para reducir el pico.

Nodes

VAEDecodeTiled decodifica el latent a imagen tile por tile. VAEEncodeTiled codifica una imagen a latent del mismo modo.

Parámetros

Parámetro	Función	Valor inicial	Uso
tile_size	Tamaño de cada tile	512 con poca VRAM 1024 con margen	Más pequeño consume menos, pero es más lento Empezar en 512 para 8GB
overlap	Solapamiento entre tiles	64	Evita uniones visibles Probar 32–128
fast mode	Modo rápido	true	Normalmente activado
temporal_size	Chunk temporal solo para Video VAE	8 con poca VRAM 16 con margen	Procesa frames por grupos Solo útil para Video VAE
temporal_overlap	Solapamiento entre chunks temporales	2–4	Continuidad entre grupos

Comparación de picos de SynpixCloud

Resolución	VAE estándar	Tiled 512	Tiled 1024
1024×1024	~2GB	~0,5GB	~1GB
2048×2048	~8GB	~1GB	~2,5GB

Usa Tiled VAE cuando

• La resolución supera 1024×1024
• La GPU tiene 8–12GB
• El workflow usa Video VAE
• Hires Fix, Upscale o FaceDetailer falla en postprocesado

Aviso documental: la documentación del node está marcada como AI-generated. Verifica interfaz y parámetros en tu versión actual.

---

Diagnosticar OOM por fuente del pico

Ante CUDA out of memory, revisa primero los picos mayores y aplica una reducción concreta en cada paso.

Tabla OOM

Fuente del pico	Ejemplo de VRAM	Reducción	Prioridad
Pesos del modelo	SDXL ~6,5GB FLUX fp16 ~23GB	Cambiar a fp8/GGUF —lowvram/—novram	P0
Codificador T5	fp16 ~9GB	T5 fp8/GGUF con loader compatible	P0 para FLUX
Resolución latente	2048×2048 ~8GB	Bajar a 1024×1024 o 512×512	P1
VAE encode/decode	Hasta unos 8GB a 2048×2048	Tiled VAE, tile_size=512, overlap=64	P1
Batch size	batch size=4 a 1024×1024, unos 8–12GB	batch size=1 batch count en queue	P2
ControlNet/Detailer	Unos 2–3GB cada uno	Desactivar rama ControlNet Usar ruta de poca VRAM	P2
Frames de video	Frames × resolución × VideoVAE	Temporal chunking Reducir frames Tiled Video VAE	P2 video
Cache/preview	~0,5–1GB	—preview-method none —cache-none	P3

Orden de cambios

1. Bajar resolución: 2048 → 1024 → 512
2. Desactivar preview: --preview-method none
3. Cambiar a modelo fp8/GGUF: FLUX Q4_K_S, Q5_K_S o Klein 4B
4. Cambiar T5 a fp8/GGUF: importante para FLUX con poca VRAM
5. Usar Tiled VAE: comenzar con tile_size=512 y overlap=64
6. Bajar batch size: batch size=1, batch count en queue
7. Desactivar ControlNet y postprocesado: FaceDetailer, Hires Fix, Upscale
8. En video: reducir frames y usar temporal chunking

---

Separar dos tipos de lentitud

Primero distingue si el workflow es lento porque el offload es necesario o si una configuración lo hace más lento de lo debido.

Tabla de velocidad

Cuello de botella	Señal	Diagnóstico	Ajuste
Lentitud normal con poca VRAM
—lowvram/—novram	20–70 % más lento	Revisar argumentos	Aceptar la lentitud O usar más VRAM
Offload GGUF a RAM	Baja utilización de GPU	Revisar uso de GPU	Limita el ancho de banda RAM Usar fp8/fp16 si cabe
Video con muchos frames	VAE Decode lento	Calcular frames × resolución	Reducir frames Temporal Tiling
Modo CPU —cpu	Extremadamente lento	Revisar argumentos	Solo último recurso Usar GPU
Lentitud anormal
Demasiados sampler steps	FLUX dev supera 20 steps	Revisar KSampler	A FLUX dev pueden bastarle 20 schnell/Klein 4B usa cuatro
Backend attention inadecuado	Alto uso de memoria	Revisar argumentos	xformers compatible O PyTorch SDP
VAE Decode lento	tile_size demasiado pequeño	Revisar VAEDecodeTiled	Pasar de 512 a 1024 ~1GB más de pico, posible 10–30 % más rápido
Espera de CPU offload	Espera CPU–GPU	Revisar argumentos	—async-offload RAM suficiente, a menudo 32GB+
Cache de disco/RAM inadecuado	Modelo se recarga	Revisar argumentos	—cache-lru 10 Guardar 10 resultados
Otro proceso usa GPU	Poco uso útil	Revisar el sistema	Cerrar navegador, juego, editor de video

Acciones en orden

1. xformers o SDP attention: pip install xformers para detección automática, o probar --use-pytorch-cross-attention; referencias de 20–30 % menos VRAM y 5–20 % más velocidad
2. FLUX de cuatro steps: schnell o Klein 4B en vez de dev con 20 steps
3. Aumentar tile_size: 512 → 1024, unos 1GB más de pico para posible mejora de 10–30 %
4. Activar async offload: --async-offload con suficiente RAM
5. Cerrar otros procesos GPU: navegador, juegos y editor de video

Observación de SynpixCloud: xformers/SDP attention redujo VRAM 20–30 % y mejoró velocidad 5–20 % en el entorno citado.

Observación de Local AI Master: FLUX.2 Klein 4B Q4_K_M, cuatro steps, 1024×1024 y 8GB tardó unos 15–30 segundos.

Benchmark variable: todos los valores son referencias dependientes del entorno.

---

Por qué un archivo GGUF más pequeño puede ser más lento

Un GGUF Q4_K_S de unos 6,8GB puede ser más lento que FLUX fp16 de unos 23GB:

• GGUF puede descargar pesos a la RAM del sistema en lugar de mantenerlos en VRAM, reduciendo el uso de GPU
• La inferencia transfiere pesos repetidamente de RAM a VRAM
• El ancho de banda RAM es menor: DDR4/DDR5 ronda 25–50GB/s frente a 500–1000GB/s de GDDR6X

Usa GGUF cuando

• fp8 no cabe en una GPU de 6–8GB y GGUF es la ruta restante para ejecutar FLUX
• Aceptas menor velocidad para que el modelo pueda funcionar

Evita GGUF cuando

• Una GPU de 12GB+ puede ejecutar fp8 o fp16 con más eficiencia
• La velocidad importa más que ejecutar el modelo a cualquier costo

Observación de Apatero: Q8_0 with CPU offloading may take 5-10 minutes per generation.

---

Presupuesto de VRAM de video: frames × resolución × VideoVAE

En video, frames × resolución × VideoVAE puede dominar la VRAM. Aquí se cubre presupuesto y reducción de pico, no un workflow completo de Wan o AnimateDiff.

Principio de presupuesto

Pico de VRAM ≈ pesos del modelo + T5 + frames × latent por frame + pico de VideoVAE.

Ejemplos de los recursos citados ComfyUI-Wan2.2 y Local AI Master

Ajuste de video	Presupuesto VRAM	GPU	Nota
8 frames a 480p (640×360)	~6–8GB	6GB puede funcionar	El ejemplo citado de RTX 3050 6GB produjo cerca de un segundo de video en menos de cinco minutos
24 frames a 720p (1280×720)	~12–16GB	8GB límite/12GB cómodo	Requiere Temporal Tiling
60 frames a 1080p (1920×1080)	~20–24GB+	16GB+	Ruta de alta VRAM

Reducir el pico

Temporal Tiling divide frames en grupos pequeños, por ejemplo ocho a la vez. Los parámetros son temporal_size y temporal_overlap.

Tiled VAE procesa VAE Decode de cada frame en tiles espaciales.

Reduce frames de 60 a 24 y luego a 8, y valida primero la ejecución mínima.

Reduce resolución de 1080p a 720p y luego a 480p.

Los recursos fuente proponen Wan 2.2 5B para un objetivo de 8GB o Wan 2.2 14B GGUF como ejemplo desde 6GB.

Benchmark variable: estos números son referencias dependientes del entorno.

---

Evitar OOM en series: batch size frente a batch count

batch size y batch count producen picos muy diferentes. Aumentar batch size sin control causa OOM fácilmente.

batch size y batch count

batch size ejecuta varias imágenes a la vez; latents, VAE y tensores activos aumentan. batch count coloca varios batches pequeños en una queue y mantiene reducido el batch activo.

Comparación de VRAM

Configuración	Resolución	Pico de VRAM	Riesgo OOM
batch size=4	1024×1024	~8–12GB	Alto por simultaneidad
batch count=4, batch size=1	1024×1024	~2–3GB	Menor por ejecución secuencial

Recomendación

• Con 6–8GB: batch size=1 y batch count=N
• Para batches por API: usar queue y control de concurrencia del workflow de automatización de ComfyUI en lugar de iniciar varias solicitudes pesadas juntas

---

OOM repentino después de actualizar: revisar versiones

Si el mismo workflow se vuelve lento o falla después de actualizar PyTorch, driver o ComfyUI, puede haber cambiado el entorno aunque prompt y graph sean iguales.

Cambios de versión que afectan VRAM

El comportamiento CUDA de PyTorch cambia, incluidos defaults de TF32/FP16 y allocator. TF32 y FP16 no siempre son mejores: ejemplos de PyTorch muestran multiplicación TF32 más rápida con mayor error numérico. Driver, ROCm y CUDA también modifican el comportamiento de GPU.

Proceso recomendado

1. Guardar el entorno antes de actualizar con conda o pip freeze
2. Probar la versión nueva en un entorno separado
3. Registrar versiones estables de PyTorch, CUDA y driver
4. Volver a una versión fija si aparece una regresión

---

Separar aceleraciones experimentales de inicios estables

Distingue experimentos avanzados de configuraciones apropiadas para una primera prueba estable.

Experimentos avanzados, no requisitos para 8GB

Elemento	Estado	Riesgo	Nota
--fast	Experimental	Puede alterar calidad/estabilidad	Marcado experimental por ComfyUI
FlashAttention	Requiere flash-attention	Algunas versiones CUDA incompatibles	Instalación compleja
Sage Attention	Optimización externa	Experimental, puede afectar precisión	Requiere CUDA/PyTorch compatibles
TensorRT	Requiere TensorRT SDK y configuración	Conversión compleja	Poco adecuado para principiantes

Puntos de partida estables

Elemento	Estado	Efecto	Nota
xformers	Estable si es compatible	Referencia: 20–30 % menos VRAM, 5–20 % más rápido	pip install xformers ComfyUI lo detecta
SDP attention con —use-pytorch-cross-attention	Estable	Referencia: 20–30 % menos VRAM, 5–20 % más rápido	ComfyUI puede elegir automáticamente el mejor backend

---

Conclusión

Categoría de GPU: identifica primero 6GB, 8GB, 12GB o 16GB+ y parte de un workflow base adecuado.

Argumentos: en el comportamiento citado de v0.18.0+, Dynamic VRAM está activo de forma predeterminada, por lo que --lowvram puede no tener efecto. Verifica con python main.py --help.

Cuantización: las mediciones citadas presentan FLUX.2 Klein 4B GGUF como ruta rápida para 8GB y FLUX.1 GGUF Q4_K_S cuando hacer caber el modelo importa más que la velocidad. El offload GGUF depende mucho del ancho de banda RAM.

Orden de diagnóstico: pesos del modelo → T5 → resolución latente → VAE → batch size → ControlNet → frames de video → cache. Para la velocidad, separa la lentitud normal del offload de un cuello ajustable.

Siguientes pasos

1. Identificar la categoría 6GB, 8GB, 12GB o 16GB+
2. Para los casos citados de 8GB, elegir FLUX.2 Klein 4B o FLUX.1 GGUF Q4_K_S
3. Aplicar la checklist de memoria ante OOM
4. Aplicar la checklist de velocidad ante lentitud anormal
5. Usar Temporal Tiling en workflows de video

Si el entorno base aún no funciona, empieza por la guía de ComfyUI para principiantes. Para nodes rojos, modelos ausentes o workflows no reproducibles, consulta la checklist para reutilizar workflows de ComfyUI. Si todavía dudas entre SDXL, SD 3.5 y FLUX, lee primero la guía para elegir modelos de Stable Diffusion.