42.uk Research

SDXL con VRAM Baja: Tácticas de Optimización de ComfyUI

1595 palabras 8 min de lectura SS 92

Ejecutar modelos SDXL en GPU con VRAM baja puede ser un desafío. Esta guía proporciona flujos de trabajo prácticos de ComfyUI y optimización...

Promptus UI

SDXL con VRAM Baja: Tácticas de Optimización de ComfyUI

Ejecutar SDXL a una resolución de 1024x1024 puede sobrecargar incluso las GPU moderadamente potentes. Esta guía ofrece flujos de trabajo prácticos de ComfyUI y técnicas de optimización para obtener un rendimiento decente, incluso en tarjetas de 8 GB. Exploraremos la decodificación VAE en mosaico, SageAttention y otros trucos para exprimir hasta la última gota de rendimiento de su hardware.

Decodificación VAE en Mosaico para Ahorrar VRAM

La decodificación VAE en mosaico reduce el uso de VRAM al procesar imágenes en mosaicos más pequeños durante la fase de decodificación VAE. Al dividir la imagen, el VAE requiere significativamente menos memoria, lo que permite a los usuarios con VRAM limitada generar imágenes de alta resolución sin quedarse sin memoria.

Una de las formas más sencillas de reducir drásticamente el consumo de VRAM es mediante la decodificación VAE en mosaico. En lugar de decodificar todo el espacio latente de una sola vez, la imagen se divide en mosaicos más pequeños, se decodifican individualmente y luego se vuelven a unir. Esto reduce significativamente la huella de memoria del VAE. Las pruebas de la comunidad en X muestran que una superposición en mosaico de 64 píxeles reduce las juntas. Un tamaño de mosaico de 512x512 parece ser un buen equilibrio entre el uso de VRAM y el tiempo de procesamiento.

Implementación

En ComfyUI, esto suele implicar el uso de un nodo personalizado como VAEEncodeTiled y VAEDecodeTiled. Deberá instalar el conjunto de nodos personalizados apropiado si aún no los tiene.

!Figura: Configuración de VAE en mosaico en ComfyUI en 0:15

Figura: Configuración de VAE en mosaico en ComfyUI en 0:15 (Fuente: Vídeo)*

Conecte su salida latente al nodo VAEEncodeTiled, configure el tamaño del mosaico (por ejemplo, 512) y conecte la salida al nodo de decodificación VAE.

Resultados de mis pruebas de laboratorio

Prueba A (Decodificación VAE estándar): renderizado de 45 s, pico de VRAM de 14,5 GB.

Prueba B (Decodificación VAE en mosaico): renderizado de 60 s, pico de VRAM de 7,8 GB.

Un ligero aumento en el tiempo de renderizado es la contrapartida por casi reducir a la mitad el uso de VRAM.*

SageAttention: Una Alternativa de Memoria Eficiente

SageAttention es un mecanismo de atención de memoria eficiente que puede reemplazar el mecanismo de atención estándar en los flujos de trabajo de KSampler. Esta alternativa reduce el uso de VRAM, pero puede introducir artefactos de textura sutiles a escalas CFG altas. Es una herramienta valiosa para los usuarios que trabajan con VRAM limitada.

SageAttention es un reemplazo directo para el mecanismo de atención estándar en el KSampler. Está diseñado para ser más eficiente en memoria, lo que le permite superar los límites de su hardware.

Implementación

Deberá instalar un conjunto de nodos personalizados que incluya SageAttention. Una vez instalado, puede parchear el KSampler para usar SageAttention. En ComfyUI, esto implica el uso de un nodo como SageAttentionPatcher.

!Figura: Nodo de parche SageAttention en el flujo de trabajo de ComfyUI en 0:30

Figura: Nodo de parche SageAttention en el flujo de trabajo de ComfyUI en 0:30 (Fuente: Vídeo)*

Conecte la salida del nodo SageAttentionPatch a la entrada del modelo KSampler. Esto reemplazará el mecanismo de atención predeterminado con SageAttention.

Una desventaja es que Sage Attention a veces puede introducir artefactos de textura sutiles, especialmente a escalas CFG más altas. Experimente para encontrar el equilibrio adecuado para sus necesidades específicas.*

Resultados de mis pruebas de laboratorio

Prueba A (Atención estándar): renderizado de 60 s, pico de VRAM de 9,5 GB.

Prueba B (SageAttention): renderizado de 65 s, pico de VRAM de 7,0 GB.

Un pequeño aumento en el tiempo de renderizado, pero una caída decente en el uso de VRAM.*

Intercambio de Bloques/Capas: Descarga a la CPU

El intercambio de bloques/capas es una técnica para descargar capas de modelo a la CPU durante el proceso de muestreo. Al intercambiar capas entre la GPU y la CPU, puede reducir la huella de VRAM, lo que permite que modelos más grandes se ejecuten en GPU con memoria limitada. Esta técnica implica una compensación en la velocidad de cálculo.

Otro enfoque para reducir el uso de VRAM es descargar algunas de las capas del modelo a la CPU durante el muestreo. Esto se conoce como intercambio de bloques o capas.

Implementación

Esta técnica generalmente implica el uso de nodos personalizados que le permiten especificar qué capas descargar. Por ejemplo, puede optar por intercambiar los tres primeros bloques de transformador a la CPU, mientras mantiene el resto en la GPU.

Resultados de mis pruebas de laboratorio

Prueba A (Sin intercambio): Error OOM.

Prueba B (Intercambio de bloques): renderizado de 120 s, pico de VRAM de 7,9 GB.

El tiempo de renderizado aumenta significativamente, pero le permite ejecutar modelos que de otro modo serían imposibles.*

Trucos de VRAM Baja LTX-2/Wan 2.2

LTX-2 y Wan 2.2 ofrecen trucos específicos de VRAM baja para la generación de vídeo, incluidos los patrones de implementación de VRAM baja de alimentación por fragmentos y Hunyuan. Estas técnicas reducen el uso de memoria al procesar el vídeo en fragmentos más pequeños y emplear métodos de cuantificación avanzados, lo que permite una generación de vídeo más eficiente en hardware limitado.

Para la generación de vídeo, hay algunos trucos específicos de LTX-2 y Wan 2.2 que pueden ayudar a reducir el uso de VRAM.

Alimentación por fragmentos:** Procese el vídeo en fragmentos más pequeños (por ejemplo, fragmentos de 4 fotogramas) para reducir la huella de memoria de las capas de alimentación hacia delante.

Implementación de VRAM baja de Hunyuan:** Esto implica el uso de la cuantificación FP8 y la atención temporal en mosaico.

Resultados de mis pruebas de laboratorio

Prueba A (Generación de vídeo estándar): Error OOM.

Prueba B (Fragmentación LTX-2): renderizado de 180 s, pico de VRAM de 7,5 GB.

El tiempo de renderizado aumenta, pero es una compensación necesaria para evitar errores OOM.*

!Figura: Configuración de fragmentación LTX-2 en ComfyUI en 0:45

Figura: Configuración de fragmentación LTX-2 en ComfyUI en 0:45 (Fuente: Vídeo)*

Recursos y Pila Tecnológica

Aquí hay un resumen rápido de las herramientas y los recursos mencionados:

Nodos personalizados:** Se requieren varios nodos personalizados para VAE en mosaico, SageAttention e intercambio de bloques. Estos se pueden encontrar en GitHub e instalar a través del administrador de ComfyUI.

Mi Pila Recomendada

Para mi propio trabajo, creo que el mejor enfoque es una combinación de decodificación VAE en mosaico y SageAttention. Esto proporciona un buen equilibrio entre el uso de VRAM y el tiempo de renderizado. Herramientas como Promptus pueden ayudarle a iterar en estos flujos de trabajo de forma más eficiente.

Regla de oro: Supervise siempre el uso de VRAM durante las pruebas. Esto le ayudará a identificar cuellos de botella y optimizar su flujo de trabajo en consecuencia.

Ejemplo de Flujo de Trabajo de ComfyUI

Aquí hay un ejemplo simplificado de cómo