MiniMax H3 en ComfyUI: Sage Attention, Sol-Attn y Latent Upscale en RTX 3090

Read in English →

El 3 de septiembre aparecieron el mismo día dos vídeos de YouTube (ambos con menos de 400 visitas cuando los vimos) proponiendo trucos de velocidad para MiniMax H3 en ComfyUI: una LoRA de aceleración por pasos, una combinación de Sage Attention con una nueva “Sol-Attn” de Kijai, y un latent upscale en dos pasadas. No repetimos las cifras del vídeo — las probamos en nuestra propia RTX 3090, con el mismo prompt y seed en cada comparación para aislar solo la variable que cambiaba. Los dos primeros trucos (Sage Attention y Sol-Attn) funcionan tal como se anuncian. El tercero escondía un bug real que ninguno de los dos vídeos originales menciona — y que, como vas a ver más abajo, tampoco resolvimos del todo a la primera.

De un vistazo

Corrigiendo lo que los subtítulos automáticos destrozaron

Los dos vídeos originales tienen subtítulos automáticos en inglés generados por YouTube, y varios nombres propios técnicos salían irreconocibles. “Soul attention” no es un error de transcripción cómico — es Sol-Attn, un método real de sparse attention de Kijai basado en el paper Sol-Attn (arXiv:2607.24027), publicado como ComfyUI-SolAttn_triton. Y “comfy kitchen attention” del segundo vídeo tampoco era un error — es un paquete real (comfy-kitchen, ya instalado en nuestra propia instalación de ComfyUI 0.34.2 como dependencia del core).

La LoRA de aceleración que describía el primer vídeo (una versión de 4 pasos y otra de 8 pasos, publicadas con dos semanas de diferencia) coincide mejor por fechas con la turbo LoRA oficial de lightx2v/Comfy-Org, documentada directamente en la plantilla nativa de MiniMax H3 de ComfyUI — no con la alternativa “PDD Acc LoRA” de Alibaba PAI que consideramos al principio. No pudimos confirmarlo al 100% sin ver la pantalla del vídeo, así que usamos la turbo LoRA oficial que ya teníamos descargada.

Método: mismo prompt, misma seed, caché compartida

Para que la comparación de atención fuera limpia, usamos el mismo prompt, la misma seed (777) y la misma longitud de clip (294 frames, 12,25s) en las tres primeras pruebas:

Tracking shot of a red fox sprinting through a snowy pine forest at dawn, powder snow
kicking up behind its paws, low morning mist between the trees, warm sun rays cutting
through fog, frost on branches, photorealistic wildlife cinematography, shallow depth
of field, natural sound of snow crunching and wind through pines.

Resolución 736×416, sampler euler, scheduler simple, 4 pasos, LoRA turbo siempre activa. Los logs de ComfyUI confirman que la conditioning y el ruido base se reutilizaron de caché entre las tres pruebas (execution_cached sobre los nodos 1-8) — el Δ de tiempo medido es exclusivamente el coste del backend de atención, no ruido de reconstrucción.

Prueba 1-3: Sage Attention y Sol-Attn

👉 Lo que importa: Sol-Attn se instaló con un simple git clone en custom_nodes/ (sin compilar nada a mano — Triton compila su propio kernel en el primer uso) y corrió sin errores en nuestra Ampere, pese a que el README del propio proyecto dice explícitamente “tested on RTX 4090 and RTX 5090”. No es una promesa vacía de compatibilidad — es una tarjeta de generación anterior en la que, en esta configuración concreta, funcionó bien.

Resultado con Sage Attention + Sol-Attn combinadas: 78 segundos para 12,25 segundos de vídeo, misma seed que el resto de pruebas. Sin distorsión estructural visible.

La configuración exacta que usamos para el nodo SolAttnPatch:

tau: 1.3
start_percent: 0.0    end_percent: 1.0
dense_blocks: "0-2"    (los primeros 3 bloques se quedan en Sage Attention)
sink_conditioning: exact_kv_and_rows
int8_qk: true          int8_pv: true
morton: false           morton_curve: 2d_frame
use_tma: false

⚠️ Advertencia real de nuestra prueba: el primer intento con SolAttnPatch falló con un error HTTP 400 porque el nodo (schema V3 de ComfyUI) exige explícitamente 7 campos que ninguno de los dos vídeos menciona en pantalla: int8_pv, verbose, morton, morton_curve, use_tma, dense_blocks y sink_conditioning. Si construyes el grafo a mano o por API en vez de la interfaz gráfica (que rellena los valores por defecto sola), tenés que declararlos todos.

Prueba 4: latent upscale en dos pasadas — y un bug real

El tercer truco genera un vídeo base a resolución baja para fijar el movimiento rápido, y luego lo escala en espacio latente con un modelo dedicado (minimax_h3_latent_upscaler_3d_bf16.safetensors, de LBH-123-AI) en vez de regenerar todo a resolución alta. Usamos el mismo prompt y seed que el resto de pruebas: base 736×416 → destino 1344×768 (~3,3x área).

El nodo MMH3SpatialSplitParams divide el frame en tiles para procesarlos por separado, y ya sabíamos por una prueba interna anterior (25/08, sobre un proyecto de vídeo distinto) que su parámetro fade_width/fade_height viene con un valor por defecto (32px) demasiado bajo frente al overlap (128px), lo que produce una costura de color visible entre tiles. Corregimos eso poniendo fade_width=fade_height=128 — confirmamos hoy que sigue siendo el valor por defecto sin corregir en la versión actual del nodo, no fue un problema puntual de una instalación vieja.

Con la costura corregida, probamos primero con el tamaño de tile por defecto (512×512), que sobre un destino de 1344×768 necesita una rejilla de 2×2 tiles:

285,1 segundos de render para esto: hasta cuatro zorros distintos visibles a la vez, uno por cuadrante de la rejilla 2x2. Mismo prompt, misma seed que el resto del artículo — no es un problema del prompt.

Esto no es el bug de costura conocido. Es algo más grave: cada tile generó una escena casi independiente — con su propio zorro — en vez de una porción recortada de la misma escena continua. La costura de color se puede vivir con ella; un sujeto duplicado invalida el clip entero.

Primer intento de arreglo, insuficiente: repetimos la prueba con tiles más grandes — tile_width=896, tile_height=768 (la altura completa del destino, solo partición horizontal, rejilla 2×1). Al revisar un único frame (el 150 de 294) vimos un solo zorro y dimos el problema por resuelto. Fue un error de verificación. Al revisar sistemáticamente 9 frames repartidos por todo el clip, la duplicación seguía ahí en varios de ellos — solo que, en algunos, el segundo zorro queda parcialmente oculto detrás de un árbol o fuera de foco, mucho menos obvio que con tiles pequeños pero real:

Frame 30 de 294 con tiles de 896x768: dos zorros todavía visibles, uno a cada lado del límite entre los dos tiles horizontales. Menos severo que con tiles de 512, pero no resuelto.

Lo que sí funcionó, verificado en 9 frames: eliminar la partición en tiles del todo — un único tile de 1344×768 (el destino completo), sin ninguna rejilla:

Mismo prompt, misma seed, mismos 1344×768 de destino, sin tiles. Un solo zorro en los 9 frames que revisamos, más nítido en el detalle de escarcha — pero 340,1 segundos, más lento que las dos configuraciones con tiles.

👉 La regla práctica real, no la que publicamos al principio: en esta prueba, la duplicación de sujeto no desaparece por usar tiles “suficientemente grandes” — se reduce en frecuencia, pero solo dejó de aparecer al quitar la partición en tiles por completo. Eso invierte el beneficio de velocidad: la única configuración fiable que verificamos fue también la más lenta de las tres (340,1s vs 285,1s y 170,2s). Si tu escena tiene un sujeto único y saliente moviéndose por el cuadro (como este zorro), verificá varios frames repartidos por todo el clip — no uno solo — antes de confiar en cualquier tamaño de tile. No hemos barrido el espacio completo de tamaños para encontrar un punto intermedio que elimine la duplicación sin perder toda la velocidad de la partición en tiles.

VRAM: el ahorro es de tiempo, no de memoria

Solo capturamos un snapshot de VRAM (no medimos el pico por cada prueba individual): 23,4GB de 24,5GB con los modelos residentes, en una generación a resolución más baja que las pruebas principales de este artículo. Esto coincide con lo que ya advertía el vídeo original sobre el latent upscale: cuando ahorra, ahorra tiempo, no memoria — en algún punto del proceso se sigue trabajando con el latente a resolución alta.

Limitaciones de esta prueba

• Una sola GPU (RTX 3090). No podemos generalizar a Ada Lovelace/Blackwell ni a tarjetas con menos VRAM.
• Un solo prompt y una sola seed por comparación — sin repetición estadística.
• No comparamos explícitamente “generar directamente a 1344×768 sin upscale” contra el pipeline de dos pasadas con el mismo número de pasos — ese dato haría falta para poder afirmar con cifras exactas cuánto tiempo ahorra (o no) el latent upscale frente a ir directo a la resolución final.
• No probamos la LoRA de 8 pasos ni la variante “PDD Acc LoRA” de Alibaba PAI mencionada como alternativa en el primer vídeo — solo la turbo LoRA de 4 pasos que ya teníamos descargada.
• No barrimos el espacio de tamaños de tile entre 896px y “sin partición” — puede existir un punto intermedio que elimine la duplicación sin perder toda la velocidad de la partición en tiles, no lo hemos encontrado.
• Nuestra primera verificación de la configuración de 896x768 se basó en un único frame de muestra y concluyó erróneamente que el problema estaba resuelto — lo corregimos revisando 9 frames repartidos por el clip antes de publicar. Vale como recordatorio de que un solo frame nunca es evidencia suficiente para un clip de varios segundos.

Conclusión

Sage Attention y la combinación con Sol-Attn de Kijai cumplen lo que prometen en nuestra propia RTX 3090: -27% y -40% de tiempo de render respectivamente, sin coste de calidad visible en esta prueba, y Sol-Attn funciona en Ampere pese a que su propio README no lo menciona como tarjeta probada. El latent upscale en dos pasadas es más complicado de lo que parece: reduce el sujeto duplicado a medida que agrandás los tiles, pero en nuestra prueba concreta no desapareció del todo hasta quitar la partición en tiles por completo — y esa configuración fue la más lenta de las tres, no la más rápida. No hay un ajuste gratis aquí: hay un trade-off real entre velocidad y fiabilidad que depende de cuánto tolere tu escena la partición en tiles.

🏆 Nuestra recomendación

Sage Attention es la mejora de menor riesgo de este artículo — instalación de un pip install, sin cambios de comportamiento visibles, actívala siempre que trabajes con MiniMax H3. Sol-Attn merece una prueba si necesitás exprimir más velocidad y podés verificar el resultado visualmente antes de confiar en una corrida larga sin supervisión. Para el latent upscale en dos pasadas: si tu escena tiene un sujeto único y saliente en movimiento, no confíes en un tile “suficientemente grande” sin verificar varios frames del clip completo — y si necesitás garantía real de que no habrá duplicación, la única configuración que verificamos limpia en esta prueba fue sin partición en tiles, aceptando que es más lenta que generar por partes.

Sigue Leyendo

Si el bug de costura por fade_width es lo que te trajo aquí, tenemos el diagnóstico original y la corrección completa en nuestra guía de reducción de VRAM en ComfyUI. Si buscás más técnicas generales de aceleración más allá de MiniMax H3, revisá nuestra guía de cómo acelerar la generación en ComfyUI. Y si lo que buscás es face+body swap con este mismo modelo, probamos el workflow real de Face Swap y Body Swap con Ref2VA en RTX 3090. Si te interesa exprimir la acción rápida, comparamos la LoRA PDD Acc de 8 pasos de Alibaba PAI contra la turbo de 4 pasos.