GGUF vs bf16 en ComfyUI: Cuánta VRAM y Velocidad Ganas Realmente (RTX 3090, Prueba Real)

“Usa la versión GGUF, pesa menos y va más rápido” es el consejo que circula en cualquier hilo de ComfyUI sobre modelos grandes. Es cierto en parte — pero decidimos comprobar qué pasa realmente con la VRAM, no solo con el tamaño del fichero, generando la misma imagen dos veces: una con el checkpoint bf16 completo de Z-Image Turbo, otra con su cuantización GGUF Q8_0. Mismo prompt, mismo seed, misma RTX 3090.

⚠️ Nota de transparencia: nuestra primera medición de VRAM tenía un fallo metodológico — monitorizamos nvidia-smi solo durante los primeros ~2 minutos de cada generación y nos perdimos el tramo final, que es donde en realidad está el pico. Al corregirlo y medir la generación completa de principio a fin (con la GPU en reposo al empezar cada prueba), el resultado cambió. Dejamos esta nota en vez de borrar el rastro porque el proceso de encontrar el propio error es, en sí mismo, la lección más útil del artículo.

De un vistazo: bf16 vs GGUF Q8_0

Por qué probamos esto en vez de asumirlo

La cuantización GGUF se ha convertido en la respuesta por defecto para correr modelos grandes en GPUs de consumidor: menos bits por parámetro, fichero más pequeño, cabe donde antes no cabía. Lo que rara vez se verifica es si “fichero más pequeño” se traduce automáticamente en “menos VRAM durante la generación, y en la misma proporción” — son cosas relacionadas pero no idénticas, porque lo que ocupa VRAM no es el fichero en disco sino los tensores que el modelo construye en memoria durante el cómputo.

Elegimos Z-Image Turbo para esta prueba porque ya teníamos ambos formatos descargados en local (bf16 y GGUF Q8_0) del pipeline de imágenes hero de ComfyLab, así que no hizo falta bajar nada nuevo para hacer la comparativa honesta.

⚠️ Nota de precisión editorial: el titular habitual es “fp8 vs GGUF”, pero no encontramos ningún checkpoint fp8_scaled real de Z-Image Turbo publicado (solo bf16, int8_convrot y nvfp4 en el repo oficial de Comfy-Org) que pudiéramos bajar sin agotar el espacio en disco disponible en el momento de la prueba. Comparamos bf16 (precisión completa) contra GGUF Q8_0, que es la comparación real y verificable que pudimos ejecutar — no vamos a titularlo “fp8” solo porque sea la búsqueda más habitual.

El test: mismo prompt, mismo seed, misma GPU

Generamos la misma escena con ambos formatos:

• Prompt: “cinematic photograph of a vintage mechanical typewriter on a wooden desk near a rain-streaked window, warm afternoon light, dust particles visible in the light beam, shallow depth of field, sharp focus on typewriter keys, 35mm photography, high detail, film grain”
• Seed: 555111333 (fijo en todas las ejecuciones)
• Resolución: 1024×1024
• Sampler: res_multistep / simple, 8 pasos, cfg 1
• Text encoder: qwen_3_4b.safetensors (idéntico en ambos casos, solo cambia el modelo de difusión)

El único cambio entre ejecuciones fue el nodo de carga del modelo: UNETLoader apuntando a z_image_turbo_bf16.safetensors en un caso, UnetLoaderGGUF apuntando a Z-IMAGE/z_image_turbo-Q8_0.gguf en el otro.

Para la velocidad, cada formato se ejecutó dos veces: una primera vez (“en frío”, sin el fichero en caché de disco) y una segunda vez inmediatamente después (“en caliente”). Para la VRAM, remedimos ambos formatos por separado partiendo de la GPU completamente en reposo (liberada explícitamente vía el endpoint /free de ComfyUI antes de cada prueba), con nvidia-smi muestreando cada segundo durante toda la generación, no solo al principio.

Resultado 1: velocidad — GGUF ganó claramente

En ambos casos GGUF fue más rápido, tanto en frío como en caliente. Esto tiene sentido: hay menos bytes que leer de disco (6.2GB vs 12.3GB) y, aparentemente, la ruta de carga de ComfyUI-GGUF para este modelo es eficiente incluso teniendo que dequantizar.

👉 Lo que confirma: si tu cuello de botella es tiempo de carga o lectura de disco, GGUF ayuda de verdad.

Resultado 2: VRAM — GGUF gana, pero por mucho menos margen del que sugiere el disco

Traza real de nvidia-smi muestreada cada segundo, ambas pruebas partiendo de la GPU en reposo. El pico no está al cargar el modelo — está al final, coincidiendo con la decodificación VAE.

GGUF Q8_0 sí usó menos VRAM en pico que bf16 — una diferencia de 3.9GB, aproximadamente un 18% menos. Pero fíjate en el contraste con el ahorro en disco: el fichero GGUF pesa un 50% menos que el bf16. El ahorro de VRAM no es proporcional al ahorro de disco, ni de lejos.

Por qué: ComfyUI-GGUF no ejecuta el cómputo directamente sobre los pesos cuantizados — los dequantiza a una precisión más alta durante el forward pass. Ese proceso genera tensores en memoria que ocupan más que el fichero cuantizado en disco, así que parte del ahorro teórico de GGUF se pierde durante la generación. Sigue habiendo ahorro neto (17.4GB es menos que 21.3GB), pero mucho más modesto del que cabría esperar de un fichero la mitad de pequeño.

El otro dato que salta a la vista en la gráfica: el pico de VRAM en ambos formatos llega casi al final de la generación, no al cargar el modelo. Esto coincide con la decodificación VAE del latente final a imagen — un paso que no está cuantizado en ninguno de los dos casos y que añade una cantidad de VRAM considerable sobre lo que el modelo ya tiene ocupado. Si vas a dimensionar cuánta VRAM necesitas para un workflow, no midas solo el momento de carga: el pico real puede estar al final.

⚠️ Importante: si tu objetivo es exprimir al máximo una GPU con poca VRAM, no asumas que el ahorro de GGUF en disco se traduce 1:1 en VRAM. En nuestra prueba, pasar de bf16 a GGUF Q8_0 liberó 3.9GB, no los ~6GB que el tamaño del fichero podría sugerir. Mide con nvidia-smi durante la generación completa, no solo al cargar el modelo.

Resultado 3: calidad visual — prácticamente idéntica

Mismo prompt, mismo seed. Las diferencias solo aparecen en detalles finos como el texto ilegible de las teclas o la posición exacta de las partículas de polvo — atribuible al redondeo numérico de la cuantización, no a pérdida de calidad real.

Con Q8_0 (la cuantización GGUF más conservadora, 8 bits), no encontramos pérdida de calidad perceptible: composición, iluminación, profundidad de campo y nitidez del sujeto principal fueron equivalentes en ambas imágenes. Las únicas diferencias visibles están en detalles menores que ya son inherentemente aleatorios en cualquier generación (texto ilegible en las teclas, polvo en el aire).

👉 Lo que aprendimos: a Q8_0, la cuantización GGUF no cuesta calidad visible. No hemos probado niveles más agresivos (Q4, Q5) sobre este mismo modelo — es razonable esperar que ahí sí empiece a notarse degradación, pero queda como prueba pendiente.

Cómo replicarlo en tu propio workflow

El cambio entre ambos formatos es mínimo a nivel de grafo:

1. Sustituye el nodo UNETLoader por UnetLoaderGGUF (o viceversa).
2. Apunta unet_name al fichero .gguf en vez del .safetensors.
3. Todo lo demás — CLIPLoader, VAELoader, KSampler, seed — se queda exactamente igual.

Si tu prioridad es espacio en disco, GGUF gana claramente (50% menos). Si tu prioridad es VRAM, GGUF también gana, pero mide cuánto necesitas realmente con tu propio modelo — en nuestra prueba el ahorro fue de solo un 18%, no proporcional al tamaño del fichero. Y en ambos casos, dimensiona la VRAM necesaria mirando el pico al final de la generación (decodificación VAE), no solo el momento de carga del modelo.

Limitaciones de esta prueba

• Solo comparamos bf16 vs GGUF Q8_0 de un único modelo (Z-Image Turbo). No hay fp8_scaled real en la comparativa por falta de un checkpoint público descargable dentro del espacio en disco disponible.
• No probamos niveles de cuantización GGUF más agresivos (Q4_K_M, Q5_K_M, Q6_K) sobre este mismo modelo — el patrón de VRAM y el margen de ahorro podrían cambiar en cuantizaciones más pesadas.
• Es un único modelo de imagen de unos 6B parámetros; el comportamiento de VRAM en modelos de vídeo mucho más grandes (como LTX 2.3 22B, donde sí tenemos varios niveles GGUF descargados) queda como comparativa pendiente.
• Es una única ejecución por formato para la medición final de VRAM (n=1) — no promediamos varias corridas.

Preguntas frecuentes

¿GGUF siempre usa menos VRAM que bf16 en ComfyUI?

En nuestra prueba con Z-Image Turbo en una RTX 3090, sí — GGUF Q8_0 tuvo un pico de VRAM más bajo (17.4GB) que el bf16 completo (21.3GB). Pero el ahorro real (18%) fue mucho menor que el ahorro en disco (50%), así que no asumas que un fichero la mitad de pequeño te va a liberar la mitad de VRAM.

¿Por qué el pico de VRAM llega al final de la generación y no al cargar el modelo?

Porque coincide con la decodificación VAE del latente final a imagen, un paso que consume bastante memoria independientemente del formato del modelo de difusión. El modelo se queda residente en VRAM durante ese paso, así que el pico total es aproximadamente el tamaño del modelo en memoria más el coste de esa decodificación.

¿Entonces para qué sirve más GGUF, disco o VRAM?

Sobre todo disco: la mitad de tamaño con calidad equivalente a Q8_0. El ahorro de VRAM es real pero mucho más modesto (18% en nuestra prueba) porque ComfyUI-GGUF dequantiza los pesos on-the-fly durante el cómputo.

¿Perdí calidad visual al usar GGUF Q8_0 en vez de bf16?

En nuestra comparativa con el mismo prompt y seed, la diferencia fue prácticamente imperceptible a simple vista. Q8_0 es la cuantización más conservadora de GGUF — niveles más agresivos (Q4, Q5) probablemente muestren más diferencia.

¿Por qué la primera generación tarda tanto más que la segunda?

Por la caché de disco del sistema operativo. La primera carga de cada checkpoint tiene que leer el fichero completo desde disco por primera vez; las siguientes generaciones con el mismo modelo se benefician de que Linux ya tiene el fichero en la caché de página en RAM.

Sigue leyendo

Si quieres ver cuantización GGUF aplicada a un modelo de vídeo mucho más grande, nuestra prueba de LTX Director sobre LTXV-2.3 y la transferencia de movimiento de cámara con IC-LoRA usan variantes GGUF Q6_K del modelo dev de 22B parámetros. Y si te interesa cómo se comporta Z-Image Turbo en generación normal, el mismo checkpoint bf16 es el que usamos en el pipeline de imágenes hero de ComfyLab.

Conclusión: mide la generación completa, no solo la carga

🏆 Nuestra recomendación

Si tu límite es espacio en disco → GGUF gana claramente, la mitad de tamaño con calidad equivalente a Q8_0. Si tu límite es VRAM → GGUF también gana, pero por un margen mucho menor (18%, no 50%) del que el tamaño del fichero sugiere — mide con tu propio modelo antes de dar el ahorro por sentado. Si tu límite es tiempo de carga → GGUF fue más rápido en ambos escenarios (frío y caliente) en esta prueba.

La lección de fondo, incluyendo nuestro propio tropiezo al medir esto la primera vez: cuando midas VRAM, monitoriza la generación completa, no solo el momento de carga. El pico puede estar en cualquier punto del proceso — en este caso, al final, durante la decodificación VAE — y cortar la medición demasiado pronto te puede dar una conclusión directamente equivocada.

Fuentes

• ComfyUI-GGUF (city96)