Qwen-Image-Edit-2511 en 24 GB: Benchmark Multi-GPU y Setup de Producción

Qwen-Image-Edit-2511 es un MMDiT (Multimodal Diffusion Transformer) de Alibaba/Qwen. No es un LLM: es un modelo de edición de imágenes con tres piezas bien diferenciadas. Entender qué hace cada una y con qué frecuencia se ejecuta es clave para gestionar la VRAM correctamente.

La clave: el transformer es el cuello de botella real — se ejecuta en bucle en cada step de denoising. El text encoder solo se ejecuta una vez por imagen, lo que lo convierte en el candidato idóneo para moverlo fuera de la GPU principal sin impacto grave en velocidad.

bitsandbytes INT4 dinámico

El primer intento fue cuantizar el modelo en runtime con bitsandbytes. El resultado fue inmediato y definitivo:

UserWarning: "no linear modules were found in the model"
# bitsandbytes busca capas nn.Linear estándar.
# El DiT de Qwen usa arquitectura custom — no las expone.
# El modelo carga en bf16 completo ignorando la cuantización.

Con 55 GB de modelo y 24 GB de GPU, diffusers cargó los primeros 17 GB en VRAM y el resto quedó en RAM del sistema. Durante la inferencia los pesos no se movían correctamente entre RAM y GPU — las imágenes generadas eran ruido puro.

torchao FP8/INT4

Incompatible con torch 2.5 (torch.int1 no existe). Con torch 2.6 aparecen conflictos con diffusers 0.37. Callejón sin salida independientemente de la versión de partida.

DiffSynth-Studio

Bug en preparing_device: recibe un dtype en lugar de un device. El text encoder bf16 (16 GB) llenaba la GPU solo al intentar cargarlo — sin llegar a la inferencia.

El repo ovedrive/Qwen-Image-Edit-2511-4bit resuelve el problema con una cuantización selectiva que no trata todas las capas por igual:

# Cuantización selectiva por zonas del transformer
Capas 0–29      (entrada):  bf16 completo   → preserva calidad perceptual
Capas 30–N-30   (centro):   NF4 4-bit       → máxima compresión
Capas N-30–N    (salida):   bf16 completo   → preserva reconstrucción

Resultado: transformer 39 GB bf16  →  ~12 GB NF4 en VRAM

NF4 (Normal Float 4-bit) es superior a INT4 uniforme: sus 16 valores posibles siguen una distribución normal, que coincide con la distribución real de los pesos en redes neuronales. El error de cuantización se minimiza donde más afecta a la calidad de salida.

Con el modelo NF4 funcionando en una sola GPU, el consumo en reposo era de 18.1 GB — demasiado para convivir con otros modelos en producción. El siguiente paso: mover el text encoder (4.5 GB) fuera de la 3090 Ti.

Intento 1: text encoder en CPU

enable_model_cpu_offload() mueve todos los componentes a RAM del sistema y los sube a GPU solo cuando se necesitan. Libera mucha VRAM — pero a un coste de velocidad demasiado alto:

La penalización de 7.3 segundos viene del movimiento CPU↔GPU de todos los componentes en cada step. El transformer sube, procesa y baja — igual que el text encoder. Inviable para producción.

Intento 2: text encoder en la RTX 3060 (misma placa base)

La RTX 3060 está conectada en la misma placa por PCIe. La transferencia de embeddings entre GPUs es órdenes de magnitud más rápida que desde CPU RAM. Los embeddings de texto son apenas unos pocos MB — la transferencia tarda menos de 50ms.

Solo 1 segundo de penalización a cambio de liberar 5 GB en la 3090 Ti. Con 11 GB libres en reposo, otros modelos conviven sin problema. Este es el sweet spot.

diffusers asume que todos los componentes están en el mismo device. Para que funcione con multi-GPU se necesita un patch que redirige el routing de embeddings:

# Distribuir componentes entre GPUs
pipe.transformer  = pipe.transformer.to("cuda:0")   # RTX 3090 Ti
pipe.vae          = pipe.vae.to("cuda:0")
pipe.text_encoder = pipe.text_encoder.to("cuda:1")  # RTX 3060

# Patch: execution device siempre cuda:0
QwenImageEditPipeline._execution_device = property(
    lambda self: torch.device("cuda:0")
)

# Patch: routing de embeddings cuda:1 → cuda:0
_orig = pipe._get_qwen_prompt_embeds
def _patched(prompt, image=None, device=None, dtype=None):
    e, m = _orig(prompt, image=image, device=torch.device("cuda:1"), dtype=dtype)
    return e.to("cuda:0"), m.to("cuda:0") if m is not None else m
pipe._get_qwen_prompt_embeds = _patched

El repo lightx2v/Qwen-Image-Edit-2511-Lightning incluye una LoRA de destilación que reduce la inferencia de 40 a 4 steps — una ganancia de ~10× en velocidad.

# ✓ Configuración correcta con Lightning
output = pipe(
    image=input_image,
    prompt="change background to sunset beach",
    num_inference_steps=4,
    true_cfg_scale=1.0,      # Sin double-pass CFG
    guidance_scale=None,     # Ignorado con Lightning
    # NO usar negative_prompt — rompe colores a ≥1024px
)

# Para cambios difíciles (pelo, barba) — desactivar Lightning
output = pipe(
    image=img,
    prompt="change beard and hair to completely black",
    negative_prompt="white hair, gray hair, blurry",
    num_inference_steps=20,
    true_cfg_scale=12.0,    # ~120s, VRAM pico 21.5 GB
)

Qwen-Image-Edit es un modelo de edición semántica, no de generación desde cero. Necesita una imagen de entrada y modifica partes de ella según el prompt. Su caso de uso natural es "cambia el fondo a París" — no "pon esta cara en París".

La LoRA de fal/Qwen-Image-Edit-2511-Multiple-Angles-LoRA define 96 posiciones de cámara mediante tokens especiales: 4 elevaciones × 8 azimuths × 3 distancias.

# Formato:  [azimuth] [elevation] [distancia]
" front view eye-level shot medium shot"
" right side view eye-level shot medium shot"
" back view eye-level shot medium shot"
" high-angle shot front view medium shot"

# Combinar Lightning + Angles (mejor que Angles solo con 20 steps)
pipe.set_adapters(["angles", "lightning"], adapter_weights=[0.9, 1.0])

La combinación Lightning + Angles produce mejor calidad que Angles solo con 20 steps. Con 4 steps el modelo hace cambios conservadores que no generan anatomía errónea. Una vuelta completa de 360° (8 azimuths + 3 elevaciones = 11 imágenes) se completa en menos de 3 minutos.

¿Tiene imagen de entrada?
├── SÍ
│   ├── Editar fondo / ropa / estilo       → Lightning 4-step  (~14s)
│   ├── Cambiar ángulo de cámara           → Lightning + Angles (~16s)
│   ├── Boceto → objeto / arquitectura     → Lightning 4-step  (~14s)
│   └── Cambio color pelo / barba          → 20 steps cfg=12   (~120s)
└── NO
    ├── Generar desde prompt                → Flux Schnell / RealVisXL
    └── Boceto → persona / animal           → RealVisXL + ControlNet Canny

Mientras realizábamos estos benchmarks, Alibaba lanzó el 10 de febrero de 2026 Qwen-Image-2.0 — un modelo que unifica generación y edición en una sola arquitectura de 7B parámetros, frente a los 20B del modelo que hemos estado usando en este benchmark. El cambio de escala es dramático.

Todos los checkpoints usados en este benchmark son Apache 2.0 y están disponibles en HuggingFace. El orden de descarga importa: el modelo base primero, las LoRAs después.

Modelo base NF4 — transformer + text_encoder + VAE

Creado por Abhishek Dujari (ovedrive/Qwen-Image-Edit-2511-4bit). Cuantizado desde el modelo oficial Qwen/Qwen-Image-Edit-2511. Ocupa ~17 GB en disco frente a los 55 GB del original.

huggingface-cli download ovedrive/Qwen-Image-Edit-2511-4bit \
    --local-dir /workspace/qwen-image-edit/model-4bit

LoRA Lightning — 4-step y 8-step

De ModelTC / lightx2v/Qwen-Image-Edit-2511-Lightning. El repo incluye también un split FP8 de 19 GB que no hemos usado — se puede ignorar descargando solo los .safetensors sueltos:

# Descarga completa del repo (incluye el split FP8 de 19 GB — no necesario)
huggingface-cli download lightx2v/Qwen-Image-Edit-2511-Lightning \
    --local-dir /workspace/qwen-image-edit/lora-lightning

# Recomendado: solo el 4-step bf16 (811 MB)
huggingface-cli download lightx2v/Qwen-Image-Edit-2511-Lightning \
    --include "Qwen-Image-Edit-2511-Lightning-4steps-V1.0-bf16.safetensors" \
    --local-dir /workspace/qwen-image-edit/lora-lightning

Resumen de archivos en disco