MiniMax-H3 w6a8 en ComfyUI: qué cambia de verdad en 16 GB de VRAM
TL;DR
- El checkpoint w6a8 de MiniMax-H3 pesa 15,98 GB, verificados contra la API de Hugging Face. En una GPU “de 16 GB” —16 GiB = 17,18 GB de memoria real— sobran unos 1,2 GB brutos: el modelo carga, pero sin margen operativo para latentes y activaciones de vídeo. El “perfect for 16 GB VRAM” que hizo viral el hilo de Reddit era el deseo de su autor, no una medición.
- Lo que w6a8 cambia de verdad no es la velocidad —un ~2% de mejora según la única medición del hilo, anécdota en una 5060 Ti— sino el presupuesto de VRAM: unos 5 GB menos que int8_convrot (20,97 GB) con un error de pesos ~3× menor que W4A8, según el PR de kernels. Ese margen se traduce en más segundos de vídeo o más resolución antes del OOM.
- El error al cargar que motivó el hilo ya es historia: el post cayó unas 16 horas después del merge del soporte (PR #16483, 29-sep 01:44 UTC) y solo 4 horas antes de la release estable v0.38.0 (29-sep 21:46 UTC) que lo incluye. Hoy, ComfyUI actualizado carga el modelo sin drama.
- En 16 GB el problema nunca fue solo el diffusion model: el text encoder Qwen3-VL-32B y los VAE suman otros ~19 GB incluso con los cuants más ligeros. Lo que hace w6a8 es reducir la parte que debe vivir residente en VRAM; el resto lo resuelve el offload a RAM de ComfyUI. Con 32 GB de RAM de sistema, según kijai en el hilo, int8_convrot rinde igual — y entonces w6a8 solo te ahorra precisión regalada.
Verificado vs claim
| Dato | Estado | Fuente |
|---|---|---|
| Checkpoint w6a8 = 15,98 GB (fl2va y ref2va, idéntico tamaño) | Verificado (API HF, blobs, 30-sep-2026) | Repo Comfy-Org/MiniMax-H3 |
| ”It seems perfect for 16 GB VRAM” | Claim del OP del hilo: lo refuta el propio tamaño del checkpoint (15,98 GB en 16 GB no deja headroom operativo) | Hilo de Reddit |
| ~2% de mejora de velocidad de w6a8 vs int8_convrot | Anécdota atribuida: un usuario, RTX 5060 Ti, sin metodología publicada | Hilo de Reddit |
| Error al cargar en estable el día del post | Verificado el contexto: soporte w6a8 merged unas 16 horas antes, release estable 4 horas después del post | PR ComfyUI #16483, release v0.38.0 |
| w6a8: 0,78 bytes/peso; error de pesos relL2 0,024 vs 0,073 de W4A8; misma velocidad que W4A8 | Verificado (tabla del PR de kernels, RTX 5090) | PR comfy-kitchen #191 |
| Con 32 GB de RAM y offload dinámico, int8_convrot rinde igual que w6a8 | Afirmación de kijai (autor del PR de soporte) en el hilo, sin medición independiente | Hilo de Reddit |
Qué es MiniMax-H3: 33B densos, audio nativo y letra pequeña
Antes de hablar de cuantización, conviene saber qué se está cuantizando. MiniMax-H3 es un sistema generativo omni-modal: vídeo de 4 a 15 segundos a 24 fps, con audio estéreo nativo sincronizado a 32 kHz —no un añadido de lipsync posterior—, resoluciones con lado corto a 768p por defecto (2K vía el paso H3-Regenerate-2K) y soporte estable de 11 idiomas de prompting, español incluido. La release open incluye dos variantes del modelo base, y son exactamente los dos checkpoints que encontrarás cuantizados: H3-Base-FL2VA (modo primera/última imagen) y H3-Base-Ref2VA (referencias omnimodales: hasta 9 imágenes, 3 clips de vídeo y 3 de audio).
El H3-Omni-Transformer es un Transformer denso de 33B parámetros single-stream, con un detalle que explica media tabla de descargas: unos 13B de esos parámetros viven en ramas AdaLN cuyas salidas pueden precalcularse, así que no se cargan en inferencia. De ahí los checkpoints “pruned”: 40,23 GB en bf16 podado frente a 66,28 GB del completo —el que usarías para fine-tuning, no para inferencia—. El encoder de texto es otro coloso: usa los pesos completos de Qwen3-VL-32B (capa 50) y, cuantizado aparte, pesa hasta 51,51 GB en bf16.
La letra pequeña importa tanto como la ficha técnica. H3-Context-IR —el sistema de orquestación que MiniMax describe como crítico para la calidad de salida— no está incluido en la release open: o pasas por su API alojada o te construyes tu propio preprocesado siguiendo su guía de prompting. Y la sparse attention nativa con la que se entrenó tampoco tiene implementación open de inferencia todavía: la release se ejecuta con full attention. La licencia es la minimax-h3-community-license-agreement, no una Apache/MIT: para cualquier uso más allá del hobby, a leerla. Es el mismo patrón de open-weights con letra pequeña que vimos al analizar Qwen-Image-2.1.
Qué es w6a8: 6 bits de pesos sobre el camino INT8
w6a8 significa pesos a 6 bits y activaciones a 8 bits. Lo implementó kijai sobre el camino INT8 GEMM de comfy-kitchen —los mismos kernels y la misma fontanería de checkpoint que int8 y W4A8 ya usaban—, así que no hay un stack nuevo que mantener: es una opción más del layout existente. La cuantización es uniforme (sin codebook), simétrica y con escalas fp8 por grupo.
El PR de kernels trae los números, medidos sobre pesos reales de H3 en una RTX 5090 (capa out_proj, N=5376, K=7168, M=4096):
| int8 | W4A8 | W6A8 (g32) | |
|---|---|---|---|
| bytes/peso | 1,00 | 0,56 | 0,78 |
| error de pesos (relL2) | 0,0114 | 0,0732 | 0,0237 |
| ms/forward (microbenchmark) | 0,477 | 0,664 | 0,627 |
La lectura útil: w6a8 ocupa 0,78 bytes por peso —entre int8 (1,0) y W4A8 (0,56)— pero con un error de pesos ~3× menor que W4A8 (relL2 0,024 frente a 0,073), a la misma velocidad que W4A8 según el autor del PR. En el microbenchmark a M=4096, int8 sigue por delante (0,477 ms); el autor atribuye la paridad que reivindica con W4A8 a los conteos de tokens reales de H3, donde el kernel queda limitado por ancho de banda. Esa parte es su lectura, no algo que podamos replicar aquí.
El error del OP ya es arqueología: cronología del soporte
El hilo de Reddit se publicó el 29 de septiembre a las 17:36 UTC con un “Comfy gives error” al cargar. La secuencia completa, verificada en la API de GitHub:
- 23-sep, 16:22 UTC — comfy-kitchen #191 añade los kernels w6a8.
- 29-sep, 01:44 UTC — ComfyUI #16483 “Support w6a8 quantization format” (kijai) se mergea.
- 29-sep, 17:36 UTC — el post del OP: checkpoint descargado, estable sin soporte, error.
- 29-sep, 21:46 UTC — sale la release estable v0.38.0, ya con el soporte dentro.
Unas 16 horas entre el merge y el post; solo 4 entre el post y la estable. Kijai lo confirmó en el propio hilo (“supported on nightly, stable soon”). Si llegas ahora desde ese hilo: actualiza ComfyUI a v0.38.0 o superior y el error desaparece. No hay truco de carga que buscar.
Un matiz que el hilo también dejó claro: el VAE de audio solo existe en fp32 (0,61 GB), sin cuantización int8 disponible, y kijai lo señaló como candidato susceptible de perder calidad si se cuantiza. El VAE de vídeo sí tiene versión int8_convrot (2,81 GB frente a 5,21 del fp16).
El presupuesto VRAM real, cuant a cuant
Tamaños exactos de los ficheros del repo oficial Comfy-Org (API de Hugging Face, blobs, 30-sep-2026):
| Componente | Cuant | Tamaño |
|---|---|---|
| Diffusion model (pruned) | w6a8 | 15,98 GB |
| Diffusion model (pruned) | int8_convrot | 20,97 GB |
| Diffusion model (pruned) | fp8_scaled | 20,96 GB |
| Diffusion model (pruned) | bf16 | 40,23 GB |
| Text encoder (Qwen3-VL-32B) | nvfp4_awq | 15,69 GB |
| Text encoder (Qwen3-VL-32B) | int8_convrot | 27,14 GB |
| Text encoder (Qwen3-VL-32B) | bf16 | 51,51 GB |
| VAE vídeo | fp16 | 5,21 GB |
| VAE vídeo | int8_convrot | 2,81 GB |
| VAE audio | fp32 (único disponible) | 0,61 GB |
Notas al pie que cambian la lectura: w6a8 solo existe en versión pruned (los checkpoints completos sin podar son 66,28 GB en bf16 y 34,04 GB en int8_convrot, e incluyen las ramas AdaLN para fine-tuning). Cada LoRA turbo suma ~1,96 GB residentes. Y el nvfp4 del text encoder, contra la intuición, no exige GPU Blackwell.
La cuenta que importa en 16 GB: incluso con la combinación más agresiva posible —w6a8 (15,98) + TE nvfp4 (15,69) + VAE vídeo int8 (2,81) + VAE audio (0,61)— el working set ronda los 35 GB. No hay cuant que haga entrar esto entero en 16 GB, con offload o sin él. Lo que decide el cuant es cuánta memoria residual queda para latentes y activaciones cuando el diffusion model está residente, y ahí w6a8 deja ~5 GB más de margen que int8_convrot. Con 15,98 GB de checkpoint, ese margen bruto en una GPU “de 16 GB” es de ~1,2 GB: el modelo carga, pero a base de que ComfyUI mueva piezas a RAM. Que eso funcione fino depende de cuánta RAM tengas, no del cuant.
Cuándo gana w6a8 y cuándo no
Gana si:
- Tienes 16 GB de VRAM y poca RAM de sistema: el working set residente baja ~5 GB frente a int8_convrot, con menos presión de swap y más margen para duración (hasta 15 s) o resolución antes del primer OOM.
- Estabas rozando el OOM con int8_convrot en cargas largas y prefieres perder algo de precisión antes que recortar la generación.
- Ya estás en v0.38.0+ y tu prioridad es que entre, no que vuele.
Ojo con la segunda bala: nadie ha publicado todavía una comparación de calidad de vídeo H3 w6a8 vs int8_convrot; lo que hay en el hilo son impresiones, y las impresiones no son un benchmark. Para evaluar modelos de vídeo con método en vez de a ojo, hicimos un análisis del benchmark WROP; el mismo criterio aplica aquí — hasta que alguien mida la degradación de w6a8 en H3, la prudencia es tratarlo como cuant de emergencia, no de calidad.
No gana (o gana tan poco que da igual) si:
- Tienes 32 GB o más de RAM de sistema: según kijai, el offload dinámico iguala int8_convrot, y el propio repo de Comfy-Org mantiene int8_convrot como cuant recomendado para los diffusion models (“prefer int8_convrot if you are able to use pytorch with cu130”; fp8 solo si no puedes). Regalar precisión por 5 GB que el offload te da gratis es mala operación.
- Buscas velocidad: ~2% medido por un usuario en una 5060 Ti es ruido, y el microbenchmark del PR pone int8 por delante.
- Tu GPU tiene 24 GB: int8_convrot (20,97 GB) entra entero y con margen. Aquí w6a8 no resuelve ningún problema que tengas.
- No puedes usar cuantización: el bf16 pruned son 40,23 GB. Ahí la conversación es multi-GPU, o la API de Hailuo directamente.
La idea general es la misma que al analizar Bonsai-2 27B ternario: la cuantización no hace el modelo mejor ni más rápido por arte de magia, compra espacio de memoria pagando precisión. La pregunta correcta no es “¿qué cuant es mejor?” sino “¿qué memoria necesito liberar y cuánta precisión estoy dispuesto a pagar por ella?”.
Cómo medirlo en tu carga
Si tienes la GPU, no hace falta creerse ni al PR ni al hilo: mídelo en tu workflow.
- Vigila la VRAM durante una generación real:
nvidia-smi --query-gpu=memory.used,memory.total --format=csv -l 1- Lee el log de ComfyUI al cargar cada modelo: imprime cuánto reserva en VRAM y en RAM y cómo reparte los pesos. Ahí se ve enseguida si el w6a8 te deja margen real o si estás viviendo del offload.
- Cambia una variable cada vez: duración (4 s → 15 s) o resolución (lado corto 768p → arriba), mismo seed, mismo workflow de las plantillas oficiales de Comfy-Org (t2v, i2v, r2v), mismo número de pasos. Anota dónde aparece el primer OOM con int8_convrot y repite con w6a8.
- Si usas el LoRA turbo de 4 u 8 pasos, recuerda que suma ~2 GB residentes: inclúyelo en las dos mediciones o no serán comparables.
Si int8_convrot ya te cubre tu duración y resolución habituales sin acercarte al OOM, no esperes nada medible de w6a8 salvo una calidad ligeramente distinta.
Qué haría yo
Si vienes del hilo por el error de carga: actualiza a v0.38.0 o superior y listo; el soporte está en estable desde el 29-sep.
Si tienes 16 GB de VRAM: prueba w6a8 solo si tu carga actual se queda sin margen para duración o resolución. Si int8_convrot ya entra sin OOM, quédate en él: es el que Comfy-Org recomienda y no pagas precisión por headroom que no necesitas. Y asegúrate de tener buena RAM de sistema; es tan determinante como el cuant.
Si tienes 24 GB de VRAM, o 16 GB con RAM de sistema de sobra: ignora w6a8 de momento. La noticia interesante para ti es otra —que H3 funciona bien en ComfyUI y que el ecosistema de cuants ya cubre desde 15,69 GB del text encoder nvfp4 hasta el checkpoint completo para fine-tuning.
Y si vas a citar la cifra en algún sitio, cita la honesta: el checkpoint pesa 15,98 GB y una GPU “de 16 GB” tiene 17,18 GB de memoria real, así que el margen bruto son unos 1,2 GB para todo lo demás: latentes, activaciones, contexto y ejecución de un vídeo de hasta 15 segundos. Lo que w6a8 compra es presupuesto de VRAM, no una GPU más grande.
Fuentes: Repo Comfy-Org/MiniMax-H3 (tamaños via API, blobs) · Model card oficial MiniMaxAI/MiniMax-H3 · PR ComfyUI #16483 “Support w6a8 quantization format” · PR comfy-kitchen #191 “Add w6a8 quantization support” · Release ComfyUI v0.38.0 · Hilo de r/StableDiffusion (contexto comunitario, no evidencia primaria)